تفكيك عمل قابل للتتبع
كل مهمة تنفيذ مرتبطة بمتطلب محدد أو معيار قبول — لا وصف ميزة مرتبط بشكل غير دقيق.
التطوير والتكامل · الخطوة 04 · طريقة عملنا
المواصفة بتتحول إلى برمجيات.
تصميم الحل بينتج مواصفة مُختبرة ومعايير قبول محددة. المرحلة دي بتحوّل المواصفة دي لبرمجيات فعلية ومُتحقَّق منها — متكاملة مع الأنظمة اللي لازم تشتغل جنبها، ومُثبَتة مقابل المعايير اللي اتحددت قبل ما التطوير يبدأ.
التطوير هنا مش تفسير. كل قرار تنفيذي بيرجع لمواصفة اتنتجت أثناء التصميم — مش لما المطوّر افترض إن القصد على الأغلب كان كده.
مش السؤال ده
"هل الكود بيشتغل؟"
لكن السؤال ده
"هل النظام المبني بيحقق معايير القبول اللي اتحددت قبل ما نبدأ — تحت ظروف تكامل حقيقية، لا في عزلة بس؟"
التنفيذ · التحقق · التكامل · قابلية التتبع · انضباط التسليم
ليه التطوير بييجي بعد التصميم
مفيش هنا تخمين.
كل مدخل في المرحلة دي اتنتج أثناء تصميم الحل: وثيقة مواصفة الحل، وتقرير تقييم النموذج الأولي، ومعايير القبول وخطة الاختبار. التطوير مقابل مواصفة غير مُختبرة هيرجّع للكود الإنتاجي بالظبط المخاطرة اللي النموذج الأولي كان المفروض يتخلص منها.
مواصفة الحل + معايير القبول → تنفيذ مُتحقَّق منه
ليه انضباط التسليم مهم
السرعة والاستقرار بيتقاسوا مع بعض، لا يتقايضوا.
أداء تسليم البرمجيات مش مجرد قد إيه الفريق بيكتب كود بسرعة. بحث Forsgren وHumble وKim — المنشور في كتاب Accelerate: The Science of Lean Software and DevOps (2018)، المبني على أبحاث برنامج DevOps Research and Assessment (DORA) عبر سنوات وآلاف المؤسسات — حدد فئتين من الأداء الهندسي لازم تتقاسا مع بعض: الإنتاجية والاستقرار.
زمن التسليم
قد إيه بياخد وقت للتغيير المُعتمَد إنه ينتقل من الالتزام (commit) لحالة قابلة للنشر.
Forsgren، Humble & Kim، Accelerate (2018)؛ أبحاث DORA، State of DevOps.
معدل فشل التغيير
نسبة التغييرات اللي بتُدخل عيب يحتاج معالجة.
Forsgren، Humble & Kim، Accelerate (2018)؛ أبحاث DORA، State of DevOps.
فريق بيسلّم بسرعة لكن بيكسر حاجات بشكل متكرر مش بيؤدي كويس حسب البحث ده — ولا فريق بيسلّم بأمان لكن ببطء شديد لدرجة إنه ما يفرقش. OpenQCore بتحافظ على البُعدين في نظرها في المرحلة دي، بدل التحسين للسرعة بس.
من المواصفة إلى التنفيذ
كل سطر شغل بيرجع لمتطلب.
شغل التنفيذ بيتحلل مباشرة من مواصفة الحل ومعايير القبول — لا من فهم عام لـ"إيه اللي التصميم كان قاصده".
تعريف الاكتمال
المهمة مش مكتملة لما الكود يُكتب. هي مكتملة لما تحقق معيار القبول المرتبط بيها تحت الاختبار.
التحكم في انحراف المواصفة
لما التنفيذ يكشف فجوة أو غموض في المواصفة، المواصفة بتتحدَّث وتُراجَع — لا يُعاد تفسيرها بصمت من أي حد بيكتب الكود في اليوم ده.
التحقق المبني على الاختبار
التحقق بيحصل في كل طبقة، لا في النهاية بس.
OpenQCore بتبني التحقق حسب هرم الاختبار — إطار عمل واسع الاستخدام، شاع بفضل Mike Cohn، لموازنة تغطية الاختبار عبر طبقات النظام بدل تركيزها في اختبارات end-to-end بطيئة ومكلفة.
اختبارات الوحدة
تحقق سريع ومعزول لكل مكوّن مقابل سلوكه المحدد — بما فيه سلوكه تحت مدخلات غير صحيحة.
اختبارات التكامل
تحقق إن المكوّنات بتتفاعل بشكل صحيح حسب عقود البيانات اللي اتحددت أثناء تصميم الحل.
اختبارات شاملة (End-to-End)
تحقق من سير العمل الكامل مقابل معايير القبول اللي اتحددت قبل ما التطوير يبدأ — أصغر طبقة وأغلاها، محفوظة لما فعليًا محتاجها.
الهدف مش أقصى عدد اختبارات. الهدف هو الثقة إن معايير القبول محققة فعليًا، عند أرخص طبقة قادرة تثبت كده.
اختبار التكامل والعقود
عقد API حقيقي بس لما يتُختبر، لا يُوثَّق بس.
عقود البيانات وAPI اللي اتحددت أثناء تصميم الحل ما بتتعاملش كتوثيق يُتبَع بشكل غير رسمي. OpenQCore بتطبّق اختبار العقود المبني على المستهلك — منهج تكوّن رسميًا في أدوات زي Pact — حيث كل نقطة تكامل بتتحقق مقابل عقد قابل للتنفيذ لازم الطرفين يحققوه.
ده مهم تحديدًا للأنظمة اللي لازم تتصل بالبنية التحتية القائمة: عقد بيتفحص بس بمراجعة يدوية ممكن ينحرف بصمت لما أي طرف يتغيّر. عقد بيتُختبر تلقائيًا مينفعش يحصل معاه كده.
مراجعة الكود والتحقق الثابت
مراجع تاني بيمسك اللي المؤلف مش قادر يمسكه.
بحث واسع الاستشهاد به عن مراجعة الأقران للكود — بما فيه الدراسة اللي اتعملت في Cisco Systems واتشاعت في كتاب Cohen وزملائه Best Kept Secrets of Peer Code Review — وجد إن فعالية المراجعة بتعتمد بشكل كبير على الإيقاع والنطاق: مراجعات أصغر وأكثر تكرارًا وبدون ضغط وقت بتمسك عيوب أكتر بكتير من مراجعات كبيرة بتتعمل بسرعة.
OpenQCore بتطبّق مراجعة كود منظَّمة جنبًا إلى جنب مع تحليل ثابت آلي — الأسلوب والتعقيد وفحص الثغرات المعروفة — كطبقة تحقق دائمة، لا مرور مجاملة اختياري قبل الدمج.
خط أنابيب التكامل المستمر
كل تغيير بيتُحقق منه بنفس الطريقة، آليًا.
الالتزام (Commit) → البناء الآلي → اختبارات الوحدة والتكامل → التحليل الثابت والأمني → التحقق من العقود → جاهز للنشر.
التحقق اليدوي وغير المتسق ما بيتوسّعش، وما بيقدّمش إشارة موثوقة عن هل التغيير فعليًا آمن للإصدار — قرار بيُتخذ في المرحلة الجاية، النشر والتمكين. اللي المرحلة دي بتضمنه هو إن التغيير اللي وصل للبوابة دي اتُحقق منه بالفعل مقابل نفس المعيار الآلي زي كل تغيير قبله.
ممارسات التطوير الآمن
الأمان بيتُحقق منه أثناء التطوير، لا يُدقَّق بعد كده.
ممارسات التطوير عند OpenQCore متسقة مع البنية الموصوفة في إطار NIST للتطوير الآمن للبرمجيات (SP 800-218) — بتنظيم نشاط الأمان حول تجهيز المؤسسة، وحماية البرمجيات، وإنتاج برمجيات آمنة بشكل جيد، والاستجابة للثغرات.
فحص التبعيات والثغرات
فحص آلي للتبعيات الخارجية عن ثغرات معروفة كجزء من الـpipeline القياسي، لا تدقيق يدوي دوري.
نمذجة التهديدات
دراسة منظَّمة لإزاي مكوّن معين ممكن يُساء استخدامه، مبنية على أنماط الفشل المحددة أثناء تصميم الحل.
تنفيذ أقل الصلاحيات
نطاقات الوصول والصلاحيات مُنفَّذة عند أضيق مستوى يحقق المواصفة — لا أوسع مستوى مريح.
بوابة التحقق من التكامل
البناء مش جاهز لمجرد إنه بيتم تجميعه.
كل تغيير بيوصل لبوابة تحقق محددة قبل ما يُعتبر مؤهَّل للنشر.
جاهز للنشر
كل معايير القبول محققة، مُتحقَّق منها عبر اختبارات آلية وفحوصات عقود وفحص أمني.
الإرجاع للإصلاح
عيوب محددة ومعروفة لازم تُحل قبل ما التغيير ده يتقدم.
العودة للتصميم
التنفيذ كشف إن المواصفة نفسها ما بتصمدش تحت ظروف حقيقية — الاستجابة الصحيحة هي مراجعة المواصفة، لا كتابة كود يلتف حولها.
تصعيد المخاطر
اتحددت مخاطرة أمنية أو تنظيمية أو معمارية محتاجة قرار أعلى من صلاحية فريق التطوير.
خط أنابيب دايمًا بيوصل لـ"جاهز للنشر" مش بيتحقق من حاجة.
مخرجات المرحلة دي
برمجيات جاهزة لقرار النشر — لسه مش منشورة.
حسب نطاق المشروع، المرحلة دي بتنتج:
قاعدة كود مُتحقَّق منها
تنفيذ قابل للتتبع للمواصفة، ناجح في كل طبقات التحقق المحددة.
تقرير تغطية الاختبار
نتائج اختبارات الوحدة والتكامل والشاملة مربوطة بمعايير القبول.
مجموعة اختبارات العقود
تحقق قابل للتنفيذ لكل نقطة تكامل اتحددت أثناء تصميم الحل.
سجلات مراجعة الكود
تاريخ المراجعة الموثَّق وحل القضايا المُثارة.
نتائج الفحص الأمني
نتائج فحص التبعيات والثغرات والتحليل الثابت وحلها.
توثيق خط أنابيب التكامل المستمر
خط أنابيب التحقق الآلي المُطبَّق على التغيير ده، وعلى كل تغيير بعده.
من التطوير إلى النشر والتمكين
برمجيات مُتحقَّق منها لسه مش برمجيات حية.
التطوير والتكامل بينتج برمجيات اتُحقق منها مقابل مواصفتها — لا برمجيات اتنشرت أو اتراقبت أو أثبتت استقرارها تحت حمل إنتاجي حقيقي. المرحلة الجاية بتحكم إزاي، وإمتى، وبأي أمان البرمجيات دي فعليًا بتوصل للإنتاج.
مواصفة الحل → تنفيذ مُتحقَّق منه → النشر والتمكين
الخطوة 05
النشر والتمكين
إصدار برمجيات مُتحقَّق منها للإنتاج بأمان وعن قصد، مع مسار محدد للتراجع.
مراجع البحث والمنهجية
Forsgren, N., Humble, J., & Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018)؛ Google Cloud، أبحاث DORA State of DevOps
مصدر مقاييس أداء التسليم المُشار إليها أعلاه.
Cohn, M. — Succeeding with Agile (2009)
مصدر مفهوم هرم الاختبار المُشار إليه في التحقق المبني على الاختبار أعلاه.
Cohen, J. وزملاؤه — Best Kept Secrets of Peer Code Review (SmartBear، مبني على بحث في Cisco Systems)
مصدر نتائج فعالية مراجعة الكود المُشار إليها أعلاه.
Pact / العقود المبنية على المستهلك
منهج راسخ لعقود تكامل قابلة للتنفيذ ومُتحقَّق منها آليًا، المُشار إليه في قسم اختبار التكامل أعلاه.
NIST — إطار التطوير الآمن للبرمجيات، SP 800-218
مصدر البنية المُشار إليها في ممارسات التطوير الآمن أعلاه.