التغييرات في حدود المسؤولية التي أحدثتها الدستور الغذائي

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

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

يقلل الدستور الغذائي من “الاحتكاك العملي”.

وبدأت المشاكل تظهر منذ ذلك اليوم.

لأنه مع انخفاض الاحتكاك، فإن حدود المسؤولية تتحرك أيضًا بهدوء.

ظاهريًا، قد تظن أنك تشتري مؤلفين أسرع، لكن ما تشتريه في الواقع هو المزيد من التغييرات. عندما يكون هناك الكثير من التغييرات، يحتاج النظام إلى قبول أكثر وضوحًا وآليات تحكم أقوى.

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

كيف أصبحت الأمور تدريجياً “المراجع مسؤول”

في الأسبوع الأول بعد تقديم الدستور الغذائي، استخدمه الجميع بتقييد شديد.

-اكتب القطعة

• تغيير اسم الفقرة
• إضافة حكم إذا

إن هذه التغييرات، إن لم تكن مثالية، فإنها تحمل مخاطر محدودة.

بدءًا من الأسبوع الثاني، أصبحت التغييرات أكبر.

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

الجملة الأكثر شيوعاً في هذه المرحلة هي:

انظر، الكود كله مكتوب والمنطق صحيح.

المشكلة هي أن هناك استبدال مخفي في هذه الجملة.

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

الدستور الغذائي يسطح عملية التقارب في المنتصف. يصبح المؤلف “الشخص الذي يقدم المطالب” ويترك القيود للمراجع.

إذن حدود المسؤولية تبدأ من:

• المؤلف مسؤول عن تقريب التغييرات حتى تصبح جاهزة للإصدار

أصبح:

• يتحمل المراجعون مسؤولية تصفية التغييرات حتى لا تسبب أي مشاكل

هذه ليست مسألة أخلاقية، هذه مسألة ميكانيكية.

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

في كثير من الأحيان سيتم دفع الثمن في ثلاثة أماكن على الفور

1) تصبح المراجعة “علم آثار”

في الماضي، نظرت المراجعة إلى اختيارات المؤلف:

• استخدم هذا لتحقيقه
• تقسيم إلى هذه الوظائف
• أضف هذه الحماية هنا

الآن تنظر المراجعة إلى الإخراج:

• هل تجاوز هذا الكود الذي تم إنشاؤه أي حدود؟
• هل هناك أي آثار جانبية جديدة أدخلت؟
• هل قمت بهدوء بتغيير دلالات المنطق القديم؟

انها ليست نفس النوع من العمل.

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

قريبا سترى ظاهرة:

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

لأن “لماذا” لم يتم كتابتها أبدًا.

2) يتم التعامل مع الاختبار على أنه “اختياري”

أكبر إغراء في إنشاء التعليمات البرمجية هو: أنها تبدو كاملة.

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

تكمن المشكلة في أن اختبارات الوحدة هذه غالبًا ما تكون “تتحقق من التنفيذ” بدلاً من “التحقق من المتطلبات”.

الأعراض النموذجية هي:

• زيادة التغطية
• كثرة الحوادث

لأن ما ينقصنا هو معايير القبول، وليس نقص تنسيق JUnit/pytest.

3) تم نسيان مسار التراجع

غالبًا ما تؤدي التغييرات المكتوبة بخط اليد إلى أفكار طبيعية حول “ماذا لو لم ينجح الأمر”.

يمكن أن يؤدي إنشاء التغييرات بسهولة إلى الوهم بأن هذا تنفيذ أنظف ويجب أن يكون جيدًا.

لكن الشيء الأكثر إيلامًا على الإنترنت هو أن “التغييرات كبيرة جدًا ولا يمكنك العودة إليها”.

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

هذه هي أغلى فاتورة بعد نقل حدود المسؤولية.

لإعادة حدود المسؤولية، ما يتعين علينا القيام به ليس “تعطيل الدستور الغذائي”

عندما ترى العديد من الفرق هذه المشاكل، فإن رد فعلهم الأول هو تقييد استخدامها:

• تعطيل توليد شريحة كبيرة
• يحظر تعديل الوحدات الأساسية
• يجب كتابة المنطق الرئيسي باليد

هذه القواعد مفيدة على المدى القصير، ولكنها سرعان ما تصبح شكلية.

إن النهج الفعال حقاً هو نقل جزء “مسؤولية المؤلف” إلى الأمام في عملية استخدام الدستور الغذائي.

لقد قمت أخيرًا بتضييق نطاقها إلى أربعة متطلبات صعبة. إذا غاب أحدهم فلن أستسلم:

1. يجب كتابة نية التغيير بوضوح: قم بوصف السلوك المطلوب تغييره في جملة واحدة، وليس “إعادة هيكلته”.
2. يجب أن تكون معايير القبول قابلة للتنفيذ: ما هي المدخلات، وما هي المخرجات المتوقعة، وكيفية التصرف في حالة الفشل.
3. يجب إدراج حدود المخاطر: من هم المتصلون المتأثرون بهذا التغيير، وما هو السيناريو الأسوأ؟
4. يجب أن تكون خطة التراجع واضحة: الإصدار الذي سيتم الرجوع إليه، وكيفية معالجة البيانات، ومكان مفتاح الرجوع إلى الإصدار السابق.

يمكن أن يساعد الدستور الغذائي في كتابة عمليات التنفيذ، لكنه لا يستطيع أن يحل محل هذه العناصر الأربعة.

والأهم من ذلك: أنه بعد كتابة هذه البنود الأربعة، أصبحت المراجعة أخف.

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

سوء الفهم الأكثر شيوعا

سوء الفهم 1: التعامل مع الدستور الغذائي باعتباره “وافدًا جديدًا يمكنه كتابة التعليمات البرمجية”

يعلق القادمون الجدد في أماكن لا يعرفونها، ويطرحون الأسئلة، ويكشفون عن عدم اليقين.

الدستور الغذائي لا.

سوف يعطيك الإجابة التي تبدو أكثر راحة عندما تكون غير متأكد. وبدون معايير القبول، فإنه يدفن عدم اليقين في الكود.

الخرافة الثانية: استخدام كلمات سريعة للتعويض عن العمليات الهندسية المفقودة

يمكن أن تساعد الكلمات الإرشادية في مطابقة النمط بشكل أوثق، لكنها لا يمكن أن تحل محل آلية حراسة البوابة.

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

سوء الفهم 3: حساب “مقدار الوقت الذي تم توفيره” فقط

المقياس الأكثر خطورة هو: مقدار الوقت الذي يتم توفيره للتطوير لكل متطلبات.

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

أفضل التركيز على مؤشرين:

• توليد معدل إعادة العمل بعد تكامل التغيير
• نسبة الحوادث الناجمة عن تغيرات الأجيال

إنها مرتبطة بحدود المسؤولية.

الحدود القابلة للتطبيق

ليست كل الفرق بحاجة إلى مثل هذه القيود الثقيلة.

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

ولكن بمجرد استيفاء أي مما يلي، يجب أن تكون حدود المسؤولية واضحة:

• ستؤثر التغييرات على الروابط عالية التكلفة مثل الدفع ومراقبة المخاطر والموافقة
• دورة إصدار طويلة وتكلفة إرجاع عالية
• ملكية الكود غامضة والمراجعة تمثل بالفعل عنق الزجاجة

في هذه السيناريوهات، فإن “الأسرع” في الدستور الغذائي سيدفع أولاً إلى التباطؤ.

ملخص

من المؤكد أن Codex يجعل كتابة التعليمات البرمجية أسرع.

ولكن ما تغير حقًا هو الإجابة الافتراضية للفريق على سؤال “من المسؤول عن التغيير؟”

إذا لم يتم المضي قدمًا في النية والقبول والحدود والتراجع، فسوف تنتقل المسؤولية بطبيعة الحال إلى المراجع.

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