إعادة بناء المنتج من غير ما توقف الشغل عليه

حافظ على اللي شغال

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

احسب تكلفة الوضع الحالي

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

استخدم الأرقام اللي عندك. ساعات الشغل الضايعة، وتأخير التحديثات، والأعطال المتكررة هتوضح هل محتاج تغيّر جزء محدد ولا تعيد بناء جزء أكبر من المنتج.

اختار أول جزء هتغيّره

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

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

خلي الرجوع سهل

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

اتفق على معنى إن الجزء خلص

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