كتب Brooks عن تأثير النظام الثاني في 1975، وكل فريق كنتُ فيه منذئذٍ أعاد اكتشافه، عادةً حول الوقت الذي يبلغ فيه إعادة الكتابة الشهر السادس بلا نموذج أوّلي عامل. الفخّ ليس الرغبة في نظام أفضل - إنه الاعتقاد بأن القديم كان متماسكاً بالصدفة. هذا المنشور هو القائمة التي أُجبر الآن كل محادثة “دعنا فقط نُعيد كتابة هذا” على اجتيازها.

ما هو تأثير النظام الثاني فعلاً

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

ما لم يُركّز عليه Brooks، لكن الذي جعله واضحاً خمسون عاماً من الأدلة: تأثير النظام الثاني شبه دائماً rewrite، لا بناء جديد. والـrewrites تفشل شبه دائماً لنفس الأسباب الست.

العلامات الست التحذيرية

حين يقول أحد في فريق “دعنا فقط نُعيد كتابة هذا”، أسأل هذه الأسئلة الست بالترتيب. إن كانت الإجابات خاطئة، الـrewrite سيموت. ليس “قد يموت.” سيموت.

1. هل تستطيع الإشارة إلى الألم الإنتاجي الدقيق؟

لا “الكود صعب التعامل معه.” لا “الاختبارات بطيئة.” لا “الإطار قديم.” أريد سلوكاً إنتاجياً مرئياً محدّداً: ارتفاع في latency، فئة خطأ تتكرّر، ميزة أجّلناها ثلاث مرات لأن المعمارية الحالية تجعلها مكلفة.

إن كان الجواب ألم تجربة مطوّر لا ألم إنتاجي، الـrewrite سيفشل. لأن مطوّري النظام الثاني سيعانون، حتماً، من آلام تجربة مطوّر خاصة بهم لم يُحصها أحد بعد. تتداول ألماً معروف الشكل بألم مجهول الشكل.

2. هل تحدّثتَ مع الشخص الذي بناه أصلاً؟

المصمّم الأصلي يعرف لماذا ذاك الشيء الغريب المظهر موجود هناك. 70% من الوقت، الجواب هو حادثة إنتاجية من أربع سنوات غير موجودة في تاريخ الـcommit. إن لم تسأل، ستُعيد تطبيق الخطأ الذي أصلحه. شاهدتُ هذا يحدث لي، مرتين.

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

3. هل هناك “هيكل عظمي ماشٍ” في الخطّة؟

الـrewrite الذي لا يشحن شيئاً من طرف إلى طرف في الأسبوعين الأولين لن يشحن شيئاً أبداً. يجب أن تكون في الخطّة نقطة تعلّم في اليوم 14 تبدو هكذا: “طلب حقيقي واحد يتدفّق عبر النظام الجديد في الإنتاج، يُظلّل النظام القديم، بنسبة 0% من حركة المرور.” إن فتحت الخطّة بـ”أولاً سنبني نموذج البيانات الجديد، ثم طبقة الـAPI الجديدة، ثم طبقة الـUI الجديدة” - تهانئ، كتبتَ خطّة waterfall في 2026 ولم يلاحظ أحد.

في Bytro، التحديث event-driven الذي فعلناه نجح لأننا شغّلنا shadow حيّاً من الأسبوع الثاني. كل طلب ضرب كلا النظامين القديم والجديد. قارنّا المخرجات ليلياً. التناقضات كانت المواصفات.

4. هل لديك مقياس واضح لـ”انتهى”؟

“النظام القديم اختفى” ليس مقياساً. “99% من الطلبات يخدمها النظام الجديد، p99 ضمن 10% من الخط الأساسي، معدّل الخطأ ثابت أو أدنى” مقياس. إن لم تعرف متى انتهيتَ، لن تنتهي أبداً، والفريق سيتأرجح بين نظامين إلى الأبد.

خراب تأثير النظام الثاني ليس أن النظام الجديد سيئ. إنه أن المؤسسة الآن تُدير نظامين بينما “اكتمال” الـrewrite لا يزال على بُعد ربع سنة دائماً. رأيتُ شركات تعيش في تلك الحالة ثلاث سنوات.

5. من يملك النظام القديم بينما الجديد يُبنى؟

الجواب غير الجذّاب: نفس الأشخاص الذين كانوا سيبنون الجديد. إن كانت خطّة الـrewrite تعتمد بهدوء على تجميد النظام القديم - “سنتوقّف فقط عن إضافة ميزات إليه لـ18 شهراً” - الـrewrite ميت قبل أن يشحن.

النظام القديم يتراكم إصلاحات أخطاء حرجة خاصة به بينما الجديد يُبنى. إما تحمل تلك الإصلاحات إلى الأمام (مما يعني بناءها مرتين) أو تشحن النظام الجديد ناقصاً 18 شهراً من الإصلاحات التدريجية (مما يعني أنه ليس فعلاً بديلاً قابلاً للإسقاط).

6. ما هي قصة الـrollback؟

اللحظة التي تُشغّل فيها النظام الجديد بنسبة 1% من حركة المرور، ماذا يحدث حين يصل p99 إلى ثانيتين؟ من يلاحظ؟ ماذا يفعل؟ هل هناك لوحة تحكّم؟ هل هناك إنذار؟ هل الـrollback أمر واحد أو إعادة إعداد وإعادة نشر؟

الـrewrite بلا rollback سريع هو رهان. الرهانات تُسدَّد أحياناً، عادةً حين كان للمهندس الذي يضع الرهان سبب وجيه لكونه على حقّ في مسيرته. في كل حالة أخرى هي حدث يولّد سيرة ذاتية لمن يشرح الانقطاع.

الـrewrite الذي استمتعتُ به فعلاً

الـrewrite الوحيد في مسيرتي الذي سار بسلاسة كان تحديث Bytro. نجح لأننا أجبنا على تلك الأسئلة الست قبل البدء، وأجبنا عليها في معظمها بـ”نعم”:

  1. ألم إنتاجي: ترتيب الأحداث في backend اللعبة في الوقت الحقيقي كان يسبّب desync مرئياً للاعبين عند الانضمام للمباريات. مُحدَّد، مُبلَّغ من المستخدمين، أولوية 1.
  2. المصمّم الأصلي: ما زال في الفريق، مشارك بنشاط في الـrewrite. الجثث كانت مرئية.
  3. هيكل عظمي ماشٍ: الأسبوع الثاني، endpoint واحد يتدفّق عبر event bus الجديد. الأسبوع السادس، خمسة endpoints. الأسبوع الثاني عشر، المسار الحرج.
  4. مقياس للانتهاء: 99% من المباريات تنضمّ عبر المسار الجديد مع p99 ضمن الخط الأساسي. استغرق تحقيقه ما يقارب 11 شهراً - شهرين فوق الخطّة، وهذا قريب بشكل غير معتاد.
  5. الملكية أثناء الانتقال: نفس الفريق يملك كلا النظامين، وجمّدنا التغييرات غير الحرجة على القديم. المنتج وافق لأننا أظهرنا تقدّماً أسبوعياً على المسار الجديد.
  6. الـrollback: قلب feature flag واحد. الـflag اختُبر أسبوعياً - لا مجرّد تعريفه، مُخترَب. في تدريب استعداد حقيقي. هذا أنقذنا في الشهر الثامن حين ظهرت حالة حافّة.

كل rewrite آخر شاهدتُه يموت أخفق في 3+ من تلك الست. لا أعرف استثناءً واحداً.

نسخة هذا لـ2026

الـrewrites في 2026 لها إغراء جديد: “الذكاء الاصطناعي سيُعيد كتابته فحسب.” شغّلتُ ما يقارب 3,400 commit من التطوير بمساعدة الذكاء الاصطناعي عبر هذا الموقع وحده في العام الماضي، وسأقول الجزء الهادئ: الذكاء الاصطناعي لا يحميك من تأثير النظام الثاني. إغراء الـrewrite، إن وجد، أسهل الانصياع له حين تبدو المسوّدة الأولى مجّانية.

ما يتيحه التطوير بمساعدة الذكاء الاصطناعي برخص هو اختبار مسار الترحيل - بناء نسخة 48 ساعة من النظام الجديد ضد endpoint واحد، رؤية ما يؤلم، رميه. هذه تقنية نادرة الاستخدام بشكل لافت. معظم rewrites تلتزم بناءً على شرائح عرض تقديمي؛ نموذج أوّلي بمساعدة الذكاء الاصطناعي يُعطيك أسبوعاً من الأدلة الحقيقية بتكلفة شرائح.

إن أخذتَ شيئاً واحداً من هذا المنشور: لا تدع الـrewrite يبدأ من شرائح عرض تقديمي. اختبره، أرمِ النموذج الأوّلي، وثمّ قرّر.

الشيء الذي أضبطني عادةً فيه

كتبتُ هذا المنشور بأكمله للجدال ضد الـrewrites. وأنا أيضاً، الآن، أُشغّل Fulcrum - لوحة تحكّم وكلاء بنيتُها لأن لا أحد من runtimes الموجودة يناسب طريقة عملي - وهو، بدقّة، rewrite لشيء كنتُ أستطيع بناءه فوق أدوات قائمة.

شغّلتُه عبر قائمتي الخاصة. الألم الإنتاجي كان حقيقياً (لا أداة قائمة تنسّق تشغيلات متعدّد الوكلاء بالطريقة التي أريدها). تحدّثتُ مع المصمّم (أنا؛ دوّنتُ التاريخ أيضاً). الهيكل العظمي الماشي شُحن في الأسبوع الأول. لديّ مقياس واضح للانتهاء. أملك كلا من سير العمل القائم على scripts القديم والشيء الجديد. الـrollback هو “أغلق Fulcrum CLI وعُد إلى aliases الشل.”

ستة من ستة. لذا سمحتُ لنفسي بالـrewrite. لو أصبتُ ثلاثة من ستة، كنتُ رفعتُه على الرف. هذا هو المعيار. استخدمه، وستشحن rewrites الخاصة بك. تجاهله، وستقضي 18 شهراً تشرح لماذا النظام الجديد “قريب من الاكتمال.”