البحث في الموقع

كتبت قبل بضع سنوات عن المراجعات التقنية المستقلة التي يجب أن يمر بها أي مشروع برمجي بشكل منتظم للتأكد من أنَّ كل شيء تحت السيطرة. ونوّهت مؤخرًا أنه لا يوجد عذر لعدم القيام بها. بالإضافة إلى ذلك، كلما زادت ثقتنا بالمبرمجين، زادت حاجتنا إلى مراجعة مشاريعهم بانتظام. فيما يلي ملخص بسيط لما يجب أن يتضمنه تقرير المراجع. حاولت أن أتطرق إلى هذا الموضوع في بضعة محادثات مؤخرًا مثل: اجعل العملاء يثقون بك في BDMSummit 2017، كيف تكون صادقًا وتحافظ على العميل في PMCon Kharkiv 2017، كيفية تجنب كارثة الاستعانة بمصادر خارجية في Kyiv Outsourcing Forum 2017. وأيضًا، هناك عدد من منشورات المدونة على نفس المنوال، بما في ذلك الأخطاء السبع القاتلة لمشروع برمجيات، وكيفية تجنب كارثة الاستعانة بمصادر خارجية للبرامج، وكيف تنجو من الاستعانة بمصادر خارجية للبرامج. أخيرًا، فيما يلي قائمة كاملة تقريبًا من الأشياء التي يجب أن يتضمنها التقرير الجيد. بشكل أساسي هي قائمة بالأسئلة التي يجب على المُراجع الإجابة عليها. عندما يتم جمع كل الإجابات، يكون التقرير جاهزًا. أهم الأسئلة تمَّ طرحها أوّلاً: هل إجراء الإصدار موثَّق، وآلي، وهل يعمل؟ هل الإصدارات تتجدد بشكل منتظم، على الأقل مرة أسبوعيًا؟ ما حجم الديون التقنية (الأشياء التي يجب إصلاحها "لاحقًا")؟ هل خط التسليم موثوقًا بما يكفي لاستبعاد الأخطاء؟ هل الشيفرة نظيفة؟ كم عدد النماذج المضادّة التي تظهر؟ هل تمَّ تسجيل جميع الأخطاء والميزات كملاحظات؟ هل تم تغطية الشيفرة الأساسية بوحدات اختبار، وهل التغطية مرئية؟ هل تم توقيع اتفاقيات "العمل من أجل التوظيف" مع جميع المطورين؟ هل تم توثيق القرارات التقنية الهيكلية الرئيسية؟ هل التحليل الثابت موضع التنفيذ ومُلزَم لإجراء تغييرات جديدة؟ هل التكاملات المستمرة موضع التنفيذ، وهل تؤخذ تقاريرها في الحسبان؟ هل الفرع الرئيسي (master branch) للقراءة فقط؟ هل يتم جمع المقاييس البرمجية ومراجعتها بانتظام؟ هل مستودع الشيفرة المصدرية يخضع لملكية العميل؟ هل متطلبات التوثيق قصيرة ومحدَّثة؟ هل تحتوي الفئات والطرق والتوابع الرئيسية على توثيق مضمَّن في الشيفرة؟ هل مخلفات مستودع الشيفرة المصدرية مجانية؟ هل تم توثيق واجهات UI/UX؟ هل سجلات الإنتاج مرئية وتتم مراجعتها بانتظام؟ ما مدى استجابة الفريق للملاحظات؟ هل لدى Git تاريخ واضح للتغيرات الموثَّقة؟ بشكلٍ أساسي، هذا تجميع قصير جدًا لأهم الأشياء التي يمكنك العثور عليها في CMMI. إنها تتطلب كل هذا، بالإضافة لقائمة كبيرة من الأشياء الأخرى موجودة في الأعلى. لكن المشروع الصغير لا يحتاج إلى جميع الأسئلة المذكورة. قائمتي أقصر، وأنا متأكد من أنها ستكون كافية لمعظم القرَّاء. بكل الأحوال، يمكنك مشاهدة التقارير التي يقوم المتطوعون بإنشائها للمشاركين في جائزة جودة البرمجيات، إذ يقومون بتحليل المشاريع مفتوحة المصدر والإبلاغ بشكلٍ مختصر عن المشكلات التي يجدونها. أعتقد أنهم يحاولون الإجابة عن نفس مجموعة الأسئلة السابقة تمامًا. ترجمة -وبتصرف- للمقال Software Project Review Checklist لصاحبه Yegor Bugayenko

قال لي أحد أصدقائي عندما اتصل بي البارحة: "اسمع، يا صديقي، لقد وثقت بهم لأكثر من عام - لقد كنّا شركاء، وكانوا يبرمجون كل شيء بالوقت الذي كنت أنا مشغولًا في تطوير الأعمال، والآن استقالوا ولم يتبقَ لي شيئًا، ما الذي يتوجب عليَّ فعلهُ بكل ملفات JavaScript هذه؟ كيف لي أن أتأكد بأنَّ هذه الملفات ملكي؟ بالإضافة لذلك، لا يريدون التعاون معي، أشعر بأنني رهين تصرفهم هذا، من فضلك، ساعدني". فكان جوابي له: "ماذا يمكنني أن أقول؟ لقد فات الأوان يا صديقي، ولكن الخبر السّار هو أنك لست أول من واجه هذه المشكلة". السيناريو النموذجي لوصف المشكلة "الثقة، الدفع، الخسارة". أولًا ستثق في مبرمجيك، وسيكونون شركاء لك تؤمن بعملهم، وتشعر بأنّك متأكدًا أنَّك قد اخترت الأفضل، سيظهرون لك ثقةً كبيرةً جدًا، وستشعر بالحماس عندما تنظر إلى سيرهم الذاتية، إنهم يعرفون جافاسكربت و DevOps و GitHub وحتى البيانات الضخمة، إنّهم بالتأكيد الأفضل لك، بالإضافة إلى ذلك، لديهم خبرة في هذا العمل لمدة عشر سنوات، فما الذي تحتاجه أكثر من ذلك، صحيح؟ ثانيًا أنت تدفع لهم، وإلا ما الذي يدفعهم للعمل، صحيح؟ إنَّ الموهبة الحقيقية باهظة الثمن، كلنا نعرف ذلك، إنّك تدفع لهم بانتظام مقابل الوقت الذي يقضونه في العمل على مشروعك. ستشعر بالحماس لرؤية أموالك تتحول إلى برمجيات تعمل، سيوفرون نسخًا جديدة بانتظام، يوجد هناك بعض الأخطاء، لكن من الطبيعي أن تظهر الأخطاء، صحيح؟ إنهم يقومون بشرح كل شيء لك وأنت تستمر في الدفع لهم. أخيرًا ستخسر عندما تدرك أنَّ هذا البرنامج يعود لهم وليس لك، وبأنَّهم قد استقالوا بسبب بعض أسباب العمل ولم يتبقَ لك شيء، أنت لا تستطيع فهم هذه الملفات، وأصلًا لا تملكها إنَّما هي موجودة في مكان ما في مستودع المبرمجين على منصة Git. توظف المزيد من الأشخاص لمساعدتك على حفظ ما تبقى من البرنامج، لكنهم سيخبرونك أنَّ الوقت قد حان لبدء كل شيء من الصفر. ستُحبط بشكلٍ هائل، وستكون مستعدًا للعودة إلى الخطوة الأولى - لأنك تثق بهؤلاء الموظفين الجدد، فإنهم بالتأكيد سيبدون صادقين، وليسوا مثل المحتالين السابقين. هل يبدو هذا مألوفًا؟ بالطبع أنت تتساءل، ما البديل؟ لا تثق، وبدلًا من ذلك، استعن بخبير مستقل قبل البدء بمشروع ما، بحيث يقوم بشكل منتظم (مثاليًا، كل أسبوعين) بمراجعة كل ما يفعله الموظفين الجدد ويقوم بإبلاغك أين وكيف قد تخسر. سيحافظ هذا الخبير على قائمة بالمخاطر المتوقعة، وأنت بدورك ستتخذ الإجراءات الوقائية اللازمة. لا تثق بنا نحن معشر المبرمجين، فإننا أذكياءٌ وكسولون ومدللون، لذا ستخسر دون جدال. ترجمة -وبتصرف- للمقال ‎Trust. Pay. Lose لصاحبه Yegor Bugayenko