حين يتعلق الأمر بمنهجية اعتماد الجودة في البرمجة، يقدم مجتمع المطورين آراء مختلفة.

• هنالك من يرى ضرورة اعتمادها في المنتجات التقنية منذ البداية بشكل كامل، واعتبارها جزءا ضروريا لإطلاق منتج.
• وهنالك من يرى أن الأمر دائما يتعلق بحاجة البيزنيس و تقدير مدة التطوير المتاحة لإطلاق المنتج.

ونقصد بالجودة كل العمليات و التجارب اللازمة و التي من شأنها تقديم منتج يحقق أهداف البيزنيس بالكفاءة المطلوبة، كما يتيح إمكانية معرفة ومراقبة المشاكل حال حدوثها، ومن المعلوم أن طبيعة العمل التقني قد تجعل المنتج عرضة للكثير من الأخطاء على طول الطريق.

مشكلة الدين التقني

غالبا ماتكون عملية التحقق من الجودة عند نهاية كل عمل برمجي، وبالتالي فإن أغلب المطورين قد يقومون بتأخير كتابة أكواد التجارب الضرورية، لحين الانتهاء من خاصية معينة، أو تأخيرها كليا عند الإنتهاء من المنتج. و قد يرجع ذلك إلى:

• عدم وجود وقت كاف لإنهاء العمل بالشكل المطلوب.
• عدم اهتمام إدارة المنتج بعملية الجودة، كون مخرجات ذلك قدلا تظهر ضرورية للبيزنس، وبالتالي تأخير اعتمادها.
• عدم تأهيل المطور للعملية و استشعاره لأهميتها.

هنا تظهر مشكلة الدين التقني Technical Debt، حيث أن تقليص نطاق الجودة و تقديم حلول بسيطة، كنسخ الأكواد و الحلول و لصقها، يؤدي إلى ديون تراكمية تزداد مع تطوير حجم البناء و المنتج وقد يصعب سداد هذا الدين بعد مرور الوقت و ظهور مشاكل تقنية مرتبطة. اعتماد الجودة يتيح للمطور سداد الديون التقنية في وقته، وبالتالي انتاجية متسارعة مع الوقت.

ومن أهم الأسباب التي قد تدفع المدير أو المهندس أو المطور إلى إصدار برمجي بدون اعتماد للجودة، هو ضغط الوقت و عدم تقدير الوقت اللازم لإنهاء العمليات كاملة بشكل صحيح.

وهنا سيناريو غالب الحدوث وهو مشكلة تقدير الوقت اللازم لاطلاق منتج مع إعتماد التجارب و الجودة :

• مدير المنتج: يعرض المشروع و فكرة تطبيق جوال إلى المدير التنفيذي، الذي يسأله "متى يمكنك القيام بذلك؟".هنا يعطي مدير المنتج تقديرا أوليا "يمكن للفريق تطوير الخدمة في 3 أشهر".
• بعد ذلك يسأل مدير المنتج المبرمج عن تقديره للوقت اللازم، على أمل أن يكون أقل من 3 أشهر التي وعد بها البيزنيس. عندها يقول المبرمج إن الأمر سيستغرق 5 أشهر على الأقل، طبعا لا يروق الأمر لمدير المنتج. كونه لا يمكنه العودة لرئيسه ومراجعة تقديره.
• لذلك يقول للمبرمج "لدينا 3 أشهر فقط، هل يمكنك القيام بالأمر؟" يفكر المبرمج ويقول "حسنًا، يمكنني المحاولة .."

هذا مايجعل المطور يركز بشكل كامل على إنهاء الخصائص لأنها بالنهاية ما سيظهر لصاحب القرار، وبالتالي تأخير عملية كتابة التجارب لوقت غير معلوم.

ومن الحلول لإدارة أفضل للجودة هي :

• توضيح نطاق Scope المخرجات وتقسيم العمل على شكل خدمات Services صغيرة، لكل منها نطاق واضح يتم تحديد وكتابة تجارب الجودة الخاصة به و ضبط مخرجاته.
• الشفرات البرمجية تبنى على نفسها ويجب عليك كمطور إعادة استخدام ما تم برمجته بكفاءة لكتابة ما تحتاجه الآن ، البرمجة السيئة تزيد من إبطاء العمل كلما تقدم.
• كتابة تجارب الجودة عند الانتهاء من كل خاصية أو دالة برمجية وجب تجربتها.
• توضيح أهمية العملية للبيزنيس و المدراء وإقناعهم بضرورتها لإعتمادها في تقدير الوقت اللازم للإنجاز.
• عمل تنظيم للأكواد Refactoring، بشكل دوري.
• كتابة التجارب و بناء Pipeline للتحقق عند إضافة التحديثات وإدماجها مع github مثلا.
• عمل تجارب يدوية بين الفينة و الأخرى، كون هاته العملية قد تظهر أجزاء لم تخضع للتجربة و التمحيص.
• أتمتة عمليات التحقق Tests Automation و الجودة والإدماج مع بيئة الإنتاجية.
• بناء نظام للمراجعة و التحقق ومناقشة الكود Code Review، عبر اعتماد نظام مثل ال Pull Requests.

من المسؤول عن الجودة والتجارب؟

• إذا لم يكن هنالك عنصر خاص بمتابعة الأمر فإن الفريق ككل هو مسؤول عن الجودة، يمكن لفريق المنتج الغير تقني أن يقوم بتجارب يدوية. ومن الضروري أن يقوم المطور بتسليم الخصائص مع أكواد التجارب الخاصة functional tests بها. مع إمكانية إضافة تجارب خاصة بالوحدات كالدوال functions والأقسام classes وهذه تعرف بال unit tests.
• يجب أن يدمج مدير المنتج أو قائد المشروع هذه التجارب في pipline للتحقق من الاختبارات، ويمكن أيضا اطلاق- الاختبارات في بيئة تجريبية داخلية عند كل عملية مراجعة. وتدوين المشاكل حال ظهورها.

هذا مايساعد على أتمتة انتاجية المنتج و بالتالي تسريع إطلاقه و نجاحه.