كيفية استخدام الدستور الغذائي وحدوده في المشاريع الحقيقية

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

اكتشفت لاحقًا أن هذا السؤال تم طرحه في الاتجاه الخاطئ.

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

لذلك لن أتحدث عن “تقنيات الكلمات العشر السريعة” في هذه المقالة. سأتحدث فقط عن سطر رئيسي واحد: ** قم بتوصيل Codex بمسار التغيير الذي يمكن قبوله وإعادته وتتبعه **.

1. حدد أولاً “وحدة العمل المناسبة للدستور الغذائي”

الاستخدام الأكثر سهولة هو إلغاء المتطلبات الغامضة مباشرة إلى Codex:

• “إعادة بناء هذه الوحدة”
• “تحسين الأداء”
• “اجعل هذا المكان أكثر أناقة”

من المؤكد أنه يعطي مجموعة من التغييرات، وكلها تبدو صحيحة. المشكلة هي أنه لا توجد طريقة لقبوله أو مراجعته.

لقد قمت بتكثيف المهام المناسبة للدستور الغذائي في ثلاث فئات، ولكل منها “شروط إنجاز” واضحة.

أ. تغييرات السلوك التي يمكن كتابتها كتأكيدات

السمة هي: هل يمكن وصف المدخلات والمخرجات في جملة واحدة.

• إضافة معالجة الحدود إلى وظيفة
• إصلاح الخلل واضح
• قم بترحيل جزء من المنطق إلى واجهة جديدة مع الحفاظ على الدلالات دون تغيير

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

ب. تغييرات ميكانيكية لا حصر لها

الخصائص هي: قواعد واضحة وتغطية يمكن السيطرة عليها.

• إعادة تسمية الدفعة
• ترقية مكالمات API
• البطلان الكامل / معالجة الأخطاء

يعد Codex قويًا لهذا النوع من العمل، ولكن يجب السماح له بإخراج “قائمة تعديل” و"نطاق تغييرات يمكن البحث فيه"، وإلا فإنه يميل إلى تفويت الزوايا.

ج. التحسين المحلي باستخدام المؤشرات الصعبة

والسمة هي: القدرة على تحديد طرق القياس.

• تقليل الإدخال والإخراج مرة واحدة أثناء مرحلة بدء التشغيل
• تقليل التسلسل مرة واحدة لرابط معين
• تقليل إعادة الترتيب غير الضرورية لصفحة معينة

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

2. اكتب المتطلبات على أنها “معايير القبول” ثم اكتب الكلمات الفورية

من المواقف الشائعة كتابة كلمات سريعة مثل كتابة الرغبات:

• “الرجاء الكتابة بأناقة”
• “يرجى اتباع أفضل الممارسات”

هذه غير مقبولة.

أطلب أنه في كل مرة قبل السماح لـ Codex باتخاذ إجراء، أكتب أولاً معيار القبول وأكتبه في نفس وصف المهمة:

• ما هو السلوك الذي سيغيره هذا التغيير؟
• ما هي السلوكيات التي لا يسمح بتغييرها؟
• كيف تتصرف عند الفشل
• كيفية التراجع

ستجد أنه بمجرد كتابة معايير القبول بوضوح، تصبح الكلمات السريعة أقصر.

الهيكل الذي أستخدمه غالبًا هو:

1. الخلفية (جملتين أو ثلاث، لا تتحدث عن التاريخ)
2. الهدف (اكتب السلوك فقط، وليس التنفيذ)
3. القيود (ما لا يمكن نقله)
4. القبول (نقاط الاختبار أو البرامج النصية)
5. تنسيق الإخراج (أعط الخطة أولاً، ثم التصحيح)

3. اطلب من Codex تقديم “خطة التغيير” أولاً، بدلاً من إعطاء الكود النهائي مباشرةً.

أغلى شيء في المشاريع الحقيقية هو “اكتشاف أن الدلالات تغيرت بعد الدمج”.

لذلك جعلت الإخراج الافتراضي لـ Codex عبارة عن عملية مكونة من خطوتين:

• الخطوة 1: قم بإدراج الملفات التي سيتم تغييرها، ولماذا سيتم تغييرها، ومخاطر كل تغيير
• الخطوة 2: تطبيق التصحيح مرة أخرى

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

السبب بسيط:

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

4. اسمح لـ Codex بإخراج “تصحيح قابل للمراجعة” بدلاً من مجرد مجموعة من النصوص

يؤدي نسخ ولصق مئات الأسطر من التعليمات البرمجية في IDE إلى تحويل المراجعة إلى مهمة يدوية.

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

سألتزم بشرطين في الفريق:

• لا تشمل العلاقات العامة الواحدة غرضين غير مرتبطين
• الفرق الأساسي للـ PR الواحد يكون ضمن 200 سطر (وإلا يجب تقسيمه)

من السهل كتابة المزيد والمزيد من المخطوطات، ويجب أن تكون “مغلقة في صندوق صغير” مع قيود العلاقات العامة.

5. اجعل الاختبار هو “المخرج الأول”، وليس “الإضافة الأخيرة”

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

لذلك طلبت منه الإخراج بالترتيب:

1. قائمة حالات الاختبار (التي يتم تغطية الحدود)
2. رمز الاختبار الرئيسي
3. تنفيذ التصحيح

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

6. اكتب “مسار التراجع” في التغيير

غالبًا ما يترك الأشخاص الذين يقومون بالتغييرات يدويًا مسارًا احتياطيًا دون وعي.

من السهل على الشخص الذي قام بالتغيير أن ينسى.

سأطلب من كل تغيير في البنية أن يفي بسياسة التراجع واحدة على الأقل:

-ميزة العلم

• مفاتيح التكوين
• حافظ على المسار القديم لبعض الوقت (الجري المزدوج)

يجب ألا يتم نشر التغييرات الرئيسية بدون مسار التراجع، بغض النظر عمن كتبها. إن الدستور الغذائي يجعل من السهل إجراء “تغييرات كبيرة”.

7. تعامل مع إمكانية التتبع على أنها “عنصر تكلفة” لاستخدام الدستور الغذائي

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

ما يهمني أكثر هو: ما إذا كان من الممكن إعادة إنتاج المشكلة.

لذلك، في هذه العملية، سأسجل بقوة ثلاثة أشياء:

• وصف مهمة الدستور الغذائي هذه المرة (بما في ذلك معايير القبول)
• خطة التغيير المقدمة من الدستور الغذائي
• التصحيح النهائي ونتائج الاختبار

هذه العناصر الثلاثة هي سلسلة الأدلة أثناء مراجعة الحوادث.

بدون تسجيل، كلما استخدمت Codex أكثر، ستشعر وكأنك تقوم بتشغيل نظام غير قابل للتكرار.

8. مجموعة من الهياكل العظمية للكلمات السريعة التي يمكن استخدامها مباشرة

الفقرة التالية هي الحد الأدنى من التغيير لجعل مخرجاتها متصلة بالإنترنت.

يمكنك نسخه مباشرة واستبدال الأقواس المربعة:

يجب إجراء التغييرات في مشروع حقيقي.

الخلفية: [جملتان أو ثلاث تصف الوضع الحالي والمشاكل] الأهداف (المستوى السلوكي):

• ما يجب فعله: [قائمة 2-4 عناصر]
• لا تتغير أبدًا: [القائمة 2-4] القيود:
• غير مسموح له بتقديم تبعيات جديدة/غير مسموح له بتغيير واجهة برمجة التطبيقات العامة/يجب أن يكون متوافقًا مع البيانات القديمة (حدد حسب الحاجة) القبول:
• يعطي قائمة بنقاط الاختبار
• قم بإعطاء رموز حالة الاختبار الرئيسية [N] على الأقل تنسيق الإخراج:

1. قم بتقديم خطة التغيير أولاً (قائمة المستندات + نقاط المخاطرة)
2. ضع أصغر رقعة (فرق)، ولا تقم بتضمين نص توضيحي طويل

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

والسيناريوهات التي لا يكون فيها الدستور الغذائي مناسبًا واضحة أيضًا:

• لا أستطيع حتى تحديد السلوك الذي أريده، لذا يمكنني فقط “تجربته أولاً”
• يعد هذا تغييرًا عالي المخاطر يتضمن ترحيل البيانات والأذونات والتمويل، ولكن لا توجد بيئة قبول كاملة
• الاعتماد على المعرفة الضمنية (المفاتيح عبر الإنترنت، واستراتيجيات التدرج الرمادي، والحوادث التاريخية) دون توثيق

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

ملخص

الجواب على “كيفية استخدام الدستور الغذائي” هو مجموعة من القيود الهندسية.

التفكير في الأمر على أنه تأليف أسرع يضع المسؤولية على المراجعة وعلى الإنترنت.

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