غالبًا ما تكون الفرق في طور تنفيذ المشاريع تواجه السؤال التالي: ما الذي يجب إيلاء المزيد من الاهتمام - إصدار ميزات جديدة أو تحسين جودة الكود؟ عادة ، يختار المديرون الميزات. غالبًا ما يكون المطورون غير راضين عن هذا الوضع ، معتقدين أنهم ليس لديهم وقت كاف للعمل على بنية وجودة الشفرة.
يقول
قانون شركة بترريدج : "يمكن الرد على أي عنوان ينتهي بعلامة استفهام بالكلمة". أولئك الذين يعرفونني شخصياً يعرفون أنني لا أشارك هذا الفكر. لكن في هذه المقالة أريد أن أذهب إلى أبعد من ذلك وأثبت أن إثارة السؤال من عنوان هذه المقالة ببساطة لا معنى له. تشير مثل هذه الصيغة للسؤال إلى وجود مفاضلة بين التكلفة والجودة. ويجب الحفاظ على التوازن باستمرار. في هذه المقالة ، سأثبت أن هذه التسوية لا تنطبق على عالم تطوير أنظمة الكمبيوتر ، وفي الواقع ، فإن إنشاء برامج عالية الجودة أرخص في النهاية.
على الرغم من أن الجمهور المستهدف الرئيسي للمقال هو المطورين ، إلا أنه لا يتطلب معرفة خاصة لفهمه. أريد أن تفيد هذه المقالة كل شخص مرتبط بطريقة أو بأخرى بعملية التطوير ، وخاصةً المديرين الذين يشكلون متجه تطوير المنتج.
تعودنا على الاختيار بين السعر والجودة.
كما كتبت سابقًا ، عند تطوير البرامج ، يجب عليك دائمًا الاختيار بين جودة المنتج وتكاليف تطويره. عند شراء هاتف ذكي جديد ، لديك خيار. ادفع المزيد من المال واحصل على معالج أسرع ومزيد من الذاكرة وشاشة محسّنة أو ادفع أقل ، لكن تضحي ببعض الميزات. هناك استثناءات لهذه القاعدة: أحيانًا يكون المنتج عالي الجودة أرخص. وأحيانًا لا يمكن للناس مقارنة موضوعين بشكل موضوعي واختيار منتج أفضل. على سبيل المثال ، لا يلاحظون الفرق بين الشاشات المصنوعة باستخدام تقنيات مختلفة تمامًا. ومع ذلك ، فإن العبارة "تكاليف عالية الجودة أكثر" عادة ما تكون صحيحة.
جودة البرمجيات حوالي الكثير.
عند الحديث عن جودة البرنامج ، يجب أن تبدأ بتحديد معايير الجودة. ما هو برنامج الجودة؟ من هذه اللحظة ، تصبح الأمور معقدة بعض الشيء ، لأن أي نظام كمبيوتر لديه العديد من المعايير التي يمكن من خلالها تقييم جودته. يمكنك تقييم UI و UX: ما مدى سرعة وبساطة يمكن للمستخدم حل مشكلته؟ يمكن تقييم الموثوقية: هل هناك أي أخطاء في البرنامج تؤدي إلى سلوك غير صحيح وغير مستقر؟ المعيار الآخر هو الهندسة المعمارية: إلى أي حد يتم تنظيم الكود المصدري للبرنامج ، وكيف يمكن للمبرمج أن يجد قطعة الكود التي يحتاجها في الوقت الحالي؟
القائمة أعلاه لمعايير الجودة ، بالطبع ، ليست كاملة. لكن هذه المعايير كافية لإظهار شيء واحد مهم. بعض المعايير التي يتم من خلالها تقييم جودة البرنامج عادة ما تكون غير مرئية للمستخدمين النهائيين. يمكن للعملاء تقديم ملاحظات ومعرفة مدى نجاح البرنامج في حل مشكلات أعمالهم. قد يشكو المستخدمون من الواجهة غير المريحة. أو سوف يشكون من الأخطاء ، خاصةً إذا كانت تؤدي إلى فقدان البيانات أو إلى عدم توفر النظام لفترة طويلة. لكن المستخدمين ليسوا قادرين على تقدير بنية ونوعية الشفرة.
لذلك ، أقسم معايير الجودة إلى فئتين:
خارجي (على سبيل المثال ، UI / UX أو وجود أخطاء)
وداخلية (هندسة). الفرق الأكثر أهمية هو أنه يمكن للمستخدمين تقييم الجودة الخارجية ، لكنهم لا يستطيعون فهم مدى جودة (أو سيئة) البنية الداخلية للنظام.
للوهلة الأولى ، الجودة الداخلية لا تهم المستخدمين (ولكن في البداية فقط)
إذا لم يتمكن المستخدمون من تقييم الجودة الداخلية للبرنامج ، فهل هذا المعيار مهم؟ دعونا نتخيل موقفًا افتراضيًا قرر فيه فريقا التطوير ، بشكل مستقل عن بعضهما البعض ، إنشاء تطبيق لتتبع التأخير في الرحلات والتنبؤ به. أدير فريقًا واحدًا ، وتتصدر ريبيكا الفريق الثاني. مجموعة الوظائف الأساسية للتطبيقات هي نفسها تقريبًا ، كما تحولت الواجهة لكلا التطبيقين إلى أنها مريحة للغاية ومدروسة ، ولا توجد أخطاء حرجة في التطبيقات. الاختلاف الوحيد هو أن الكود المصدري للتطبيق من Rebecca منظم ومنظم بشكل واضح ، والكود الذي أنشأه فريقي هو مجموعة من الفصول والأساليب الفوضوية بأسماء غامضة ومنطق أكثر غموضًا حول كيفية ربط هذا الكود. هناك اختلاف آخر: أبيع طلبي بمبلغ 6 دولارات ، وتبيع ريبيكا نفس التطبيق تقريبًا مقابل 10 دولارات.
نظرًا لأن شفرة مصدر التطبيقات لا يمكن للمستخدمين الوصول إليها ، ولا تؤثر جودة الشفرة على تجربة المستخدم ، فلماذا يدفع المستخدمون 4 دولارات إضافية؟ وبعبارة أخرى - لماذا تبالغ في الدفع للجودة الداخلية ، والتي لا تهم المستخدمين؟
إذا قمت بتطوير هذه الفكرة بشكل أكبر ، فيمكنك التوصل إلى استنتاج مفاده أن الاستثمار في الجودة الخارجية أكثر ربحية من الاستثمار الداخلي. بالاختيار بين تطبيقين ، يمكن للمستخدم اختيار التطبيق الأكثر تكلفة إذا كان لديه واجهة أفضل وأكثر ملاءمة. لكن المستخدمين لا يرون الهيكل الداخلي للتطبيقات ، ناهيك عن حقيقة أنه يمكن للمستخدم مقارنة بنية التطبيقين. فلماذا تدفع أكثر مقابل شيء لا يحقق فوائد عملية؟ ولماذا يجب على المطورين قضاء الوقت والموارد في تحسين الجودة الداخلية لبرامجهم؟
البرامج ذات الجودة الداخلية العالية أسهل في التوسع
لماذا من المهم للغاية بالنسبة للمبرمجين الحصول على كود الجودة؟ يقضي المبرمجون معظم وقتهم في القراءة والتحرير. حتى عند تطوير نظام جديد ، يتم تنفيذ العمل دائمًا تقريبًا في سياق الكود المكتوب بالفعل. عندما يضيف مبرمج ميزة جديدة ، فإنه يحتاج أولاً إلى معرفة كيف تتناسب هذه الميزة مع بنية التطبيق الحالية. بعد ذلك ، تحتاج غالبًا إلى إجراء تغييرات على البنية بحيث يمكن تنفيذ ميزة جديدة. غالبًا ما تحتاج إلى استخدام هياكل البيانات الموجودة بالفعل في النظام. لذلك ، يجب أن تفهم أن هياكل البيانات هذه تعني نوع العلاقات الموجودة بينها وما هي هياكل البيانات الجديدة التي يجب إضافتها لتنفيذ الميزات.
كود عالي الجودة يسمح للمبرمجين بالتصفح بسرعة. الوصول إلى موقف يصبح فيه الكود صعبا في فهمه هو في الواقع بسيط للغاية. يمكن أن تتشابك الظروف المنطقية ؛ يمكن للعلاقات بين هياكل البيانات أن تكون معقدة وضمنية. قد تكون الأسماء التي أعطاها توني للمتغيرات والوظائف قبل 6 أشهر واضحة له ، ولكنها أيضًا غير مفهومة للمطور الجديد ، وكذلك الدوافع التي دفعت توني إلى ترك الشركة. عادةً ما يطلق المطورون على هذا
"الدين الفني" (
الدين الفني ) ، أو بمعنى آخر ، الفرق بين الحالة الحالية للكود والحالة المثالية التي يمكن أن يكون عليها.
واحدة من المزايا الرئيسية التي تقدمها الجودة العالية للرمز هي أن المبرمج يمكنه أن يفهم بسرعة كيف يعمل النظام وإجراء التغييرات اللازمة. عندما ينقسم التطبيق إلى وحدات ، لا يحتاج المبرمج إلى دراسة جميع سطور شفرة المصدر البالغ عددها 500000 ويمكنه العثور بسرعة على مئات الخطوط التي يحتاجها في الوقت الحالي. عندما يعطي المبرمجون أسماء ذات معنى للمتغيرات والوظائف والفئات ، يمكنك بسهولة فهم ما يفعله كل جزء من التعليمات البرمجية دون الاضطرار إلى الخوض في السياق بعمق. إذا تزامنت هياكل البيانات في البرنامج مع المصطلحات من مجال المجال للشركة ، فمن السهل على المبرمج ربط طلب الوظيفة الجديدة بكيفية عمل النظام. يزيد الدين الفني أيضًا من الوقت الذي يستغرقه العمل مع الكود. يزيد احتمال ارتكاب الأخطاء أيضًا. في حالة الأخطاء نظرًا لضعف جودة الرمز ، سيتطلب الأمر وقتًا إضافيًا لترجمة المشكلة وحلها. وإذا لم يتم ملاحظة الخطأ على الفور ، فسيؤدي ذلك إلى حدوث مشاكل في رمز الإنتاج وحقيقة أنه سيتعين عليك قضاء المزيد من الوقت في حل هذه المشكلات في المستقبل.
يؤثر كل تغيير في الكود على مستقبل المنتج. غالبًا ما يكون هناك موقف حيث توجد طريقة بسيطة وسريعة لتنفيذ ميزة جديدة ، ولكن على حساب كسر الهيكل الحالي (أي بسبب زيادة الدين التقني). إذا اختار مبرمج هذا المسار ، فسيقوم بإصدار ميزته بشكل أسرع ، ولكنه يبطئ عمل المطورين الآخرين الذين سيتعين عليهم دعم هذا الرمز لاحقًا. إذا قام كل فرد في الفريق بهذا ، فسوف ينمو حتى التطبيق المصمم جيدًا والذي يحتوي على كود جيد إلى ديون فنية ، وحتى التغييرات القليلة ستستغرق عدة أسابيع.
يريد المستخدمون الحصول على ميزات جديدة في أسرع وقت ممكن.
نحن نقترب من نقطة مهمة ، وهي: الإجابة على السؤال ، لماذا لا تزال الجودة الداخلية للبرامج مهمة للمستخدمين؟ جودة داخلية عالية تشجع على إصدار أسرع للميزات الجديدة ، لأنها أسهل وأسرع وأقل تكلفة. تبدو تطبيقاتي الخاصة بـ Rebecca كما هي تقريبًا ، ولكن بعد بضعة أشهر ، ستسمح لها رمز الجودة العالي الخاص بـ Rebecca بإصدار ميزة جديدة كل أسبوع ، وسأظل عالقًا في مكانها ، وسأحاول التعامل مع الديون الفنية ومحاولة إطلاق ميزة جديدة واحدة على الأقل. لن أكون قادرًا على التنافس مع ريبيكا في سرعة التطوير ، وسوف يتفوق تطبيقها بسرعة على وظيفتي. في النهاية ، سيحذف المستخدمون طلبي ويستخدمون تطبيق ريبيكا ، على الرغم من أنه يكلف أكثر.
تصور لتأثير الجودة الداخلية
الميزة الرئيسية للجودة الداخلية العالية للبرنامج هي تخفيض تكلفة التغييرات المستقبلية. لكن كتابة التعليمات البرمجية عالية الجودة تتطلب المزيد من الجهد ، وهذا يزيد من الموارد اللازمة على المدى القصير.
يوضح الرسم البياني أدناه بشكل تخطيطي كيف يمكنك أن تتخيل نسبة الوظائف والوقت المستغرق لتطويرها. عادة ، يبدو المنحنى مثل هذا:
هذه هي الطريقة التي تبدو بها عملية التطوير عندما لا تكون الشفرة عالية الجودة. في البداية ، التطوير سريع بما فيه الكفاية ، ولكن بعد ذلك يتطلب المزيد من الوقت لتوسيع الوظيفة. في مرحلة زمنية معينة ، من أجل إجراء تغيير بسيط ، يجب أن يتعلم المبرمج أولاً الكثير من التعليمات البرمجية المعقدة والمربكة. بعد إجراء التغيير ، اكتشف أن هناك شيئًا ما قد تعطل ، وهذا يؤدي إلى قضاء وقت إضافي في اختبار الأخطاء وإصلاحها.
الجودة الداخلية العالية تساهم في كفاءة التطوير في مراحل لاحقة. تمكنت بعض الفرق من الحصول على التأثير المعاكس ، عندما يتم تحرير كل ميزة جديدة بشكل أسرع من الميزة السابقة بسبب إمكانية إعادة استخدام الكود المكتوب بالفعل. لكن هذا يحدث بشكل غير متكرر ، لأنه يتطلب فريقًا محترفًا للغاية مع تنظيم جيد للعمل. ولكن في بعض الأحيان هذا لا يزال يحدث.
ومع ذلك ، هناك خدعة واحدة. في المراحل الأولية من التطوير ، يكون تجاهل جودة الكود أكثر فعالية من اتباع المعايير العالية. لكن متى تنتهي هذه الفترة؟
للإجابة على هذا السؤال ، تحتاج أولاً إلى توضيح أن الصور تمثل الصور
الكاذبة . لا توجد طريقة واحدة حقيقية لتقييم أداء الفريق. ليس من السهل فهم مدى تأثير الشفرة السيئة على الجودة النهائية للمنتج (وإذا كان هذا الارتباط موجودًا ، ما مدى وضوح ذلك). بالمناسبة ، هذه المشكلة لا تتعلق فقط بصناعة تكنولوجيا المعلومات. كيف ، على سبيل المثال ، لتقييم جودة عمل المحامي أو الطبيب؟
لكن بالعودة إلى السؤال ، عند أي نقطة يستحق البدء بالتفكير في جودة الكود. يعتقد المطورون المتمرسون أن جودة كود الجودة تبدأ في التباطؤ في غضون بضعة أسابيع بعد بدء المشروع. في مرحلة مبكرة من المشروع ، يمكن تجاهل جمال العمارة والكود.
أيضًا ، من خلال تجربتي الخاصة ، يمكنني القول إنه حتى المشاريع الصغيرة تحصل على ميزة تنافسية خطيرة إذا كانت تستخدم ممارسات تطوير حديثة وفعالة في عملها وتفكر في جودة الكود.
حتى أفضل الفرق تكتب أحيانًا كودًا سيئًا
يعتقد هؤلاء الجدد في عملية التطوير أن الرمز السيئ يشير إلى أن الفريق لا يعمل بشكل جيد. ولكن ، كما تبين الممارسة ، حتى الفرق الأكثر خبرة ترتكب أحيانًا أخطاء وتكتب كودًا سيئًا.
لإثبات ذلك بوضوح ، أريد أن أخبركم عن محادثة مع أحد أفضل فريقينا. في تلك اللحظة ، كان قد انتهى للتو من العمل في مشروع اعتبره الجميع ناجحًا للغاية. كان العميل سعيدًا بالنظام الجديد ، سواء من الميزات الجديدة أو من الموارد التي تم إنفاقها على تطويره. كان الفريق سعيدًا أيضًا بالمشروع المنجز. كان القائد الفني للفريق مسرورًا جدًا بالنتيجة ، لكنه اعترف في الواقع أن بنية النظام لم تكن ناجحة جدًا. سألته: "لكن كيف تكون أحد أفضل المهندسين لدينا؟" أجاب حيث أجاب أي مهندس معماري ذو خبرة: "لقد اتخذنا قرارات جيدة ، ولكن الآن فقط نفهم كيفية القيام بذلك بشكل صحيح."
يقارن العديد من الأشخاص إنشاء أنظمة معقدة بتصميم ناطحات السحاب. على ما يبدو ، هذا هو السبب في أن المطورين ذوي الخبرة يطلق عليهم اسم "المهندسين المعماريين". ولكن في عملية إنشاء البرامج ، هناك دائمًا بعض عدم اليقين وغير المعتاد بمجالات النشاط الأخرى ، حيث تكون حالات عدم اليقين أقل كثيرًا. لدى العملاء العاديين فهم ضعيف لما يريدون من البرنامج ويبدأون في فهم ذلك فقط في عملية العمل عليه. في معظم الأحيان ، في تلك اللحظة عندما يتم عرض الإصدارات الأولى من البرنامج. تتغير العناصر التي يتم إنشاء البرامج منها (لغات البرمجة ، المكتبات ، الأنظمة الأساسية) كل بضع سنوات. استنباط تشابه مع بناء ناطحة سحاب ، هل يمكنك تخيل موقف يطلب فيه العميل من مهندس معماري إضافة عشرات الطوابق وتغيير تصميم الطوابق السفلية ، على الرغم من أن نصف المبنى قد تم بناؤه بالفعل؟ يصبح الموقف أكثر تعقيدًا عندما يتبين أن التقنيات المستخدمة لإنتاج الخرسانة ، يتم تحديث خواصه وخصائصه الفيزيائية كل عامين.
في مواجهة التحديات الجديدة المستمرة ونمو عددهم وتعقيدهم ، يتعين على الفرق أن تتوصل إلى شيء جديد باستمرار. على نحو متزايد ، من الضروري حل المشكلات التي لم يحلها أحد من قبل ، وبالتالي لا يوجد حل معروف ومُثبَّت لهم. عادةً ما يكون الفهم الواضح للمشكلة فقط وقت حلها ، لذلك كثيراً ما أسمع رأيًا مفاده أن فهم الشكل الذي يجب أن تبدو عليه بنية النظام المعقد يأتي بعد سنة على الأقل من بدء العمل. وحتى فريق التطوير الأكثر احترافية في العالم لن يكون قادرًا على جعل النظام مثاليًا.
يختلف الفريق المحترف والمنظم عن الفريق الأقل تنظيماً من حيث أنه في عملية العمل على النظام ، فإنه يخلق دينًا تقنيًا أقل ويتخلص أيضًا من الموجود. هذا يساعد المشروع على التطور بسرعة وإصدار ميزات جديدة في أسرع وقت ممكن. يستثمر هذا الفريق في إنشاء اختبارات تلقائية ، مما يساعد على تحديد المشكلات بشكل أسرع وقضاء وقت أقل في العثور على الأخطاء وإصلاحها. يعمل أعضاء هذا الفريق باستمرار للحفاظ على رمز عالي الجودة والتخلص بسرعة من التعليمات البرمجية السيئة حتى يبدأ في التدخل في المضي قدمًا. تساهم أنظمة CI أيضًا في تحقيق ذلك ، خاصةً في المواقف التي يعمل فيها كثير من الأشخاص في وقت واحد في مهام مختلفة. كاستعارة ، يمكنك إحضار المطبخ بعد الطهي. من المستحيل طهي شيء ما دون تلطخ الطاولة والأطباق وأدوات المطبخ الأخرى. إذا لم تقم بتنظيفها على الفور ، فسوف تجف الأوساخ ومن ثم سيكون غسلها أكثر صعوبة. وفي المرة التالية التي تريد فيها طهي شيء ما ، سيكون من الصعب عليك القيام بذلك لأنه عليك أولاً غسل جبل الأطباق.
بحث وتقييم DevOps (DORA)
ليست المفاضلة بين التكلفة والجودة هي الوحيدة في عالم تطوير البرمجيات التي تبدو بسيطة للوهلة الأولى ، ولكن في الممارسة العملية ، كل شيء يتبين أنه أكثر تعقيدًا إلى حد ما. هناك أيضًا نقاش واسع حول ما هو الأفضل للاختيار - سرعة التطور ومعدلات الإصدار ، أو معدلات أبطأ واختبار صارم. من المعتقد أن استخدام الطريقة الثانية يسمح بتحقيق استقرار أعلى لأنظمة الإنتاج. ومع ذلك ، أثبتت دراسة
DORA أن هذا ليس كذلك.
بعد جمع الإحصاءات على مدى عدة سنوات ، حدد الباحثون الممارسات التي تساهم في رفع مستوى أداء الفريق. اتضح أن أكثر الفرق فاعلية تقوم بتحديث خادم الإنتاج عدة مرات في اليوم ، ولا يستغرق إصدار الكود منذ لحظة كتابته للنشر أكثر من ساعة. يتيح لك اتباع هذا النهج إطلاق تغييرات في أجزاء صغيرة ، وتقل احتمالية حدوث أضرار جسيمة. الفرق التي تحدث إصدارات أقل ، وفقًا للإحصاءات ، تواجه الكثير من المشكلات الخطيرة. بالإضافة إلى ذلك ، يمكن للفرق التي اعتادت على وتيرة عالية التعافي بشكل أسرع بعد وقوع حادث. أظهرت الدراسات أيضًا أن العمليات في مثل هذه الفرق عادة ما تكون محاذاة بشكل أفضل وتعمل بطريقة أكثر تنظيماً.
دعم الأنظمة ذات البنية الجيدة أرخص
أهم النقاط التي تحدثنا عنها أعلاه:
- عدم الاهتمام بجودة الكود يؤدي إلى تراكم الديون الفنية
- الدين التقني يبطئ تطوير النظام
- حتى الفرق المهنية في بعض الأحيان تتخذ قرارات سيئة. لكن تطبيق الممارسات الحديثة و "السداد" الدوري للديون الفنية يسمح لك بإبقائه تحت السيطرة
- الحفاظ على مستوى عالٍ من جودة الرمز يقلل الدين التقني. وهذا يجعل من الممكن التركيز على الميزات الجديدة وإطلاقها بأقل جهد وأسرع وأرخص.
لسوء الحظ ، يصعب على المطورين عادة توضيح ذلك للإدارة. كثيرا ما أسمع شكاوى من أن الدليل لا يجعل من الممكن الحفاظ على رمز الجودة العالية عن طريق الحد من الوقت المخصص للعمل في المهام. عند الإجابة على أسئلة الإدارة ، لماذا تنفق موارد إضافية على جمال الشفرة ، عادةً ما يجيب المطورين على أن هذا مؤشر على الاحترافية العالية. ولكن استخدام هذه الوسيطة فقط يعني أن موارد إضافية يتم إنفاقها على الحفاظ على الجودة العالية ، والتي يمكن استخدامها في مهام أخرى. وهذا يقوض حجة الاحتراف نفسه. الحقيقة هي أنه بسبب البنية ذات الجودة الرديئة والرمز السيئ ، تصبح الحياة أكثر صعوبة على الجميع: حيث يصعب على المطورين العمل معها وتكلفة العملاء أكثر. عند مناقشة جودة الكود مع الإدارة ، أحث على اعتباره مجرد مؤشر اقتصادي. إذا تم تنفيذ البرنامج من الداخل بجودة عالية ، فسيكون من الأسهل والأرخص إضافة ميزات جديدة إليه. هذا يعني أن الاستثمار في كتابة كود الجودة يقلل في النهاية من تكاليف التطوير الإجمالية.
هذا هو السبب الحقيقي وراء كون السؤال من عنوان المقال ببساطة غير منطقي. إنفاق موارد إضافية على الهندسة المعمارية والرمز الجيد ، من الناحية الاقتصادية ، في النهاية ، أكثر ربحية. , , , . , . ( ). , .
. :
, , . – . . , . .