كود المصدر QA: ليس فقط للمطورين بعد الآن

قبل عشرين عامًا ، عندما كنت أعمل في صناعة السيارات ، غالبًا ما كان مدير أحد المصانع يقول ، "لدينا يوم واحد لبناء سيارة ، لكن عميلنا لديه عمر لفحصها". كانت الجودة في غاية الأهمية. في الواقع ، في القطاعات الأكثر نضجًا مثل صناعات السيارات والبناء ، يعد ضمان الجودة أحد الاعتبارات الرئيسية التي يتم دمجها بشكل منهجي في عملية تطوير المنتج. في حين أن هذا مدفوع بالتأكيد بالضغط من شركات التأمين ، إلا أنه تمليه أيضًا - كما لاحظ مدير المصنع - من خلال العمر الافتراضي للمنتج الناتج.

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

تعريف "الجودة"

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

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

نظرًا لمدى انتشار البرامج وسرعة توزيعها ، يمكن أن يكون تأثير عيوب البرامج كبيرًا. يمكن أن تؤدي مشكلات مثل الأخطاء وتعقيد التعليمات البرمجية إلى الإضرار بالنتائج النهائية للشركة من خلال إعاقة اعتماد المنتج وزيادة تكاليف إدارة أصول البرامج (SAM) ، بينما يمكن أن تؤثر الانتهاكات الأمنية وانتهاكات امتثال الترخيص على سمعة الشركة وتثير مخاوف قانونية. حتى عندما لا يكون لعيوب البرامج نتائج كارثية ، فإن لها تكلفة لا يمكن إنكارها. في تقرير عام 2018 ، وجدت شركة البرمجيات Tricentis أن 606 فشل برمجيات من 314 شركة مسؤولة عن 1.7 تريليون دولار في الإيرادات المفقودة في العام السابق. في تقرير صدر مؤخرًا لعام 2020 ، قدرت CISQ تكلفة البرامج ذات الجودة الرديئة في الولايات المتحدة بمبلغ 2.08 تريليون دولار ، مع تكاليف مستقبلية أخرى تقدر بنحو 1.31 تريليون دولار يتم تكبدها من خلال الديون الفنية. يمكن التخفيف من هذه الأرقام من خلال التدخلات السابقة ؛ متوسط ​​تكلفة حل مشكلة ما أثناء تصميم المنتج أقل بكثير من حل نفس المشكلة أثناء الاختبار ، وهذا بدوره أقل أضعافًا مضاعفة من حل المشكلة بعد النشر.

التعامل مع البطاطا الساخنة

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

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

النظر في دور مدير المنتج

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

• هل يجب أن أستخدم مكتبة OSS (برمجيات مفتوحة المصدر) أم أنشئ وظائف من البداية؟ ما التراخيص والمسؤوليات المحتملة المرتبطة بالمكتبات المختارة؟
• أي مجموعة تقنية هي الأكثر أمانًا؟ الذي يضمن دورة تطوير سريعة ومنخفضة التكلفة؟
• هل يجب أن أعطي الأولوية لإمكانية تكوين التطبيق (تكلفة عالية / تأخير زمني) أو تنفيذ إصدارات مخصصة (تكلفة صيانة عالية / نقص في قابلية التوسع)؟
• ما مدى جدوى دمج المنتجات الرقمية التي تم الحصول عليها حديثًا مع الحفاظ على جودة الشفرة العالية وتقليل المخاطر وإبقاء التكاليف الهندسية منخفضة؟

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

تنفيذ عملية من 7 خطوات

تؤدي عملية تقييم جودة كود المصدر الكاملة إلى تشخيص يأخذ في الاعتبار المجموعة الكاملة من قرارات الجودة بدلاً من بعض الأعراض المعزولة لمشكلة أكبر. تتماشى الطريقة المكونة من سبع خطوات المعروضة أدناه مع توصيات CISQ لتحسين العملية وتهدف إلى تسهيل الأهداف التالية:

• ابحث عن المشكلة وقياسها وقم بإصلاحها بالقرب من سببها الجذري.
• استثمر بذكاء في تحسين جودة البرامج بناءً على قياسات الجودة الشاملة.
• واجه المشكلة عن طريق تحليل المجموعة الكاملة للقياسات وتحديد أفضل التحسينات وأكثرها فعالية من حيث التكلفة.
• ضع في اعتبارك التكلفة الكاملة لمنتج البرنامج ، بما في ذلك تكاليف الملكية والصيانة ومواءمة لوائح الترخيص / الأمان.
• راقب جودة الكود عبر SDLC لمنع المفاجآت غير السارة.

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

2. تحليل المكدس الفني: تأخذ هذه الخطوة في الاعتبار لغات البرمجة المختلفة وأدوات التطوير المستخدمة ، والنسبة المئوية للتعليقات لكل ملف ، والنسبة المئوية للشفرة التي يتم إنشاؤها تلقائيًا ، ومتوسط ​​تكلفة التطوير ، والمزيد.

الأدوات المقترحة: cloc

البدائل: Tokei، scc، sloccount

3. تحليل الإصدارات: بناءً على نتائج هذا الجزء من التدقيق ، والذي يتضمن تحديد جميع إصدارات قاعدة التعليمات البرمجية وحساب أوجه التشابه ، يمكن دمج الإصدارات والتخلص من الازدواجية. يمكن دمج هذه الخطوة مع تحليل نقاط الأخطاء (النقاط الفعالة) ، والذي يحدد الأجزاء الصعبة من التعليمات البرمجية التي يتم مراجعتها بشكل متكرر والتي تميل إلى توليد تكاليف صيانة أعلى.

الأدوات المقترحة: cloc ، scc ، sloccount

4. مراجعة الكود الآلي: يقوم هذا الفحص بالتحقيق في الكود بحثًا عن العيوب وانتهاكات ممارسات البرمجة والعناصر الخطرة مثل الرموز المميزة المشفرة والطرق الطويلة والازدواجية. ستعتمد الأداة (الأدوات) المحددة لهذه العملية على نتائج المكدس الفني وتحليلات الإصدارات أعلاه.

الأدوات المقترحة: SonarQube، Codacy

البدائل: RIPS و Veracode و Micro Focus و Parasoft وغيرها الكثير. خيار آخر هو Sourcegraph ، وهو حل بحث برمجي عالمي.

5. تحليل الأمان الثابت: هذه الخطوة ، المعروفة أيضًا باسم اختبار أمان التطبيق الثابت (SAST) ، تستكشف الثغرات الأمنية المحتملة للتطبيق وتحددها. تقوم غالبية الأدوات المتاحة بفحص الكود وفقًا للمخاوف الأمنية التي تحدث بشكل متكرر والتي تحددها منظمات مثل OWASP و SANS.

الأدوات المقترحة: WhiteSource ، Snyk ، Coverity

البدائل: SonarQube و Reshift و Kiuwan و Veracode

6. تحليل مكونات البرامج (SCA) / تحليل الامتثال للترخيص: تتضمن هذه المراجعة تحديد المكتبات مفتوحة المصدر المرتبطة بشكل مباشر أو غير مباشر بالرمز ، والتراخيص التي تحمي كل من هذه المكتبات ، والأذونات المرتبطة بكل من هذه التراخيص.

الأدوات المقترحة: Snyk ، WhiteSource ، Black Duck

البدائل: FOSSA و Sonatype وغيرها

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

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

اختيار الأدوات الصحيحة

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

• حزمة التكنولوجيا المدعومة: ضع في اعتبارك أن غالبية العروض المتاحة تدعم فقط مجموعة صغيرة من أدوات التطوير ويمكن أن تؤدي إلى إعداد تقارير جزئية أو مضللة.
• بساطة التثبيت: قد تتطلب الأدوات التي تعتمد عمليات التثبيت الخاصة بها على البرمجة النصية المعقدة استثمارًا هندسيًا كبيرًا.
• إعداد التقارير: يجب إعطاء الأفضلية للأدوات التي تصدر تقارير مفصلة ومنظمة بشكل جيد تحدد المشكلات الرئيسية وتقدم توصيات للإصلاحات.
• التكامل: يجب فحص الأدوات لسهولة التكامل مع أدوات التطوير والإدارة الأخرى المستخدمة.
• التسعير: نادرًا ما تأتي الأدوات مع قائمة أسعار شاملة ، لذلك من المهم التفكير بعناية في الاستثمار المعني. عادةً ما تأخذ نماذج التسعير المختلفة في الاعتبار أشياء مثل عدد أفراد الفريق وحجم الكود وأدوات التطوير المعنية.
• النشر: عند تقييم النشر داخل الشركة مقابل النشر السحابي ، ضع في اعتبارك عوامل مثل الأمان. على سبيل المثال ، إذا كان المنتج الذي يتم تقييمه يتعامل مع بيانات سرية أو حساسة ، فقد يكون من الأفضل استخدام الأدوات والأدوات المحلية باستخدام نهج التدقيق الأعمى (FOSSID).

ابقائها مستمرة

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

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