المبادئ

السبعة التي ألتزم بها، بالترتيب الذي أستخدمه بها.

1. اجعله يعمل أولًا، ثم اجعله صحيحًا، ثم اجعله أفضل

قاعدة Kent Beck — نسخته الأصلية تنتهي بـ “اجعله سريعًا”، لكنني في معظم كود المنتج أرى أن الأولوية الثالثة يجب أن تكون النظافة وسهولة التغيير، لا السرعة الخام. الالتزام نفسه: بهذا الترتيب، لا في وقت واحد. الـ PR القبيح الذي يعمل يصل إلى الـ production؛ الأنيق الذي لم يكتمل لا يصل. الـ refactoring يذهب في PR منفصل، بعد أن يُدمج تغيير السلوك وتنجح الاختبارات.

2. commits صغيرة، PRs صغيرة، تُدمج بانتظام

الـ PR الذي يحتوي على 40 ملفًا ليس شاملًا — بل هو عائق للمراجعة وكابوس عند الحاجة إلى rollback. إذا كان تغييرك يمس فعلًا 40 ملفًا، قسّمه حسب الاهتمام وضع الـ PRs في stack. وقت المراجع أغلى من وقتك.

3. كل push يترك main باللون الأخضر

CI أحمر على main هو مقاطعة تصيب الفريق كله. إذا اندمج PR الخاص بك بحالة حمراء، فمهمتك التالية هي إصلاحه — لا التذكرة التي كنت على وشك أن تلتقطها. main الأخضر أصلٌ مشترك؛ لا تنفقه من أجل راحتك الشخصية.

4. امتلك PR الخاص بك من الفتح إلى الـ production

فتح الـ PR هو أول 20% من العمل. المتابعة على تعليقات المراجعة، مراقبة الـ CI، تتبّع الـ deploy، فحص الـ logs في الصباح التالي — تلك هي الـ 80% الباقية. إذا دمجت واختفيت، فسيتعين على شخص آخر أن يعتني بكودك. ذلك الشخص يقوم الآن بعملك.

5. امنع الأخطاء بالأنظمة، لا بالـ QA

الـ Types تلتقط فئة من الأخطاء. حدود المكونات تلتقط فئة أخرى. الاختبارات الآلية، وبيئات الـ staging، وبوابات الـ CI تلتقط المزيد. الـ QA يلتقط ما فاته كل ذلك — وهذا يجب أن يكون عددًا صغيرًا ومتناقصًا. في كل مرة يجد فيها الـ QA خطأً كان بإمكان type أو test التقاطه، فذلك نظام يجب إضافته، لا خطأ يجب إصلاحه. المزيد عن هذا النمط من التفكير في مراجعة الكود.

6. صمّم من المنتج، لا من الـ framework

لم أصمّم يومًا نظامًا بسؤال “ماذا يريد Next.js هنا؟”. أسأل: ما الذي يفعله العميل؟ ما الذي يفعله الـ operator؟ ماذا يحدث إذا فشلت عملية دفع في الثانية صباحًا؟ الـ framework يجب أن يخدم هذه الأسئلة — عندما يبدأ في إملائها، فهو غالبًا الـ framework الخاطئ للمشكلة.

7. حدِّث دون إعادة كتابة

إعادة الكتابة هي دائمًا الجواب الخاطئ تقريبًا. طموحة، تبدو شجاعة، وقد أهلكت من الشركات الناشئة أكثر مما فعل أي bug. الجواب الصحيح عادةً هو الاستمرار في تسليم النظام الحالي، مع الهجرة route تلو الآخر، خلف flag، مع اختبارات.

تحديث GoDiligent كان تقريبًا 50 PR — React 16 إلى 18، و Pages Router إلى App Router — تدريجيًا، route تلو الآخر، مع تشغيل الـ stack القديم والجديد جنبًا إلى جنب حتى يُنقل كل screen. عمل الميزات لم يتوقف من أجل freeze. هذا هو نمط الهجرة الذي سأدافع عنه أمام أي CEO في كل مرة: أبطأ على الورق، أسرع في الممارسة، وأقل احتمالًا بشكل كبير للانفجار. هذا المبدأ يقود معظم ما في بنية الواجهة الأمامية أيضًا.