حجة إعادة الكتابة تُعرض دائمًا تقريبًا كحجة تقنية ولا تكون كذلك تقريبًا أبدًا. فالدافع الحقيقي أن كل تغيير صار بطيئًا، وأن التقديرات توقّفت عن كونها قابلة للتصديق، وأن الفريق فقد الثقة في قدرته على توقّع تكلفة مهمة أسبوعين. وهذه مشكلات حقيقية بعواقب تجارية حقيقية، والإعادة إحدى عدة استجابات ممكنة لها — لكنها الاستجابة التي تبدو أكثر شيء كفعلٍ، ولهذا تفوز بجدالات كان ينبغي أن تخسرها.
وقد كنا على جانبي هذا. فقد أوصينا بإعادات كتابة وسلّمناها، وأقنعنا عملاء بالعدول عن إعادات كنا سنُدفع لنا بسخاء لأدائها. والفرق بين الحالتين لم يكن جودة الكود القائم أبدًا، فقد كانت سيئة في الاثنتين. بل كان هل ما يجعل التغيير مكلفًا شيء تُزيله الإعادة فعلًا.
ما يجعل التغيير مكلفًا فعلًا
قبل تسعير إعادة الكتابة، يستحقّ التحديد إلى أين يذهب الوقت، فالجواب كثيرًا ما ليس الكود. وفي الأنظمة التي نُطلب لتقييمها، الأسباب المتكرّرة هي هذه.
- لا مجموعة اختبارات، فكل تغيير يحتاج تحقّقًا يدويًا من أشياء لا علاقة لها بالتغيير.
- ونشرٌ يستغرق ظهيرة وشخصًا، فتُجمّع التغييرات ويحمل كل إصدار مخاطرة أكبر.
- ولا بيئة تجربة تشبه الإنتاج، فتُكتشف المفاجآت بواسطة العملاء.
ولا واحد من الثلاثة خاصية للكود. بل خواصّ للممارسة الهندسية حوله، ويمكن إصلاحها دون لمس المعمارية، وهي عادةً ربع سنة عمل لا سنة. والأهمّ أنها يجب إصلاحها على أي حال: فإعادة تُسلَّم إلى الممارسة نفسها تُنتج نظامًا جديدًا بطيء التغيير أيضًا، وهي أشيع طريقة تُخيّب بها الإعادة كل المشاركين.
فأول تمرين نافع أن تأخذ آخر عشرة تغييرات سلّمها الفريق وتكتب لكل واحد إلى أين ذهب الزمن المنقضي فعلًا. لا التقدير — بل الزمن المنقضي، بما فيه الانتظار. وفي معظم الحالات يكون أغلبه في التحقّق والنشر لا في كتابة الكود، وتلك النتيجة تُعيد صياغة المحادثة كلها قبل مناقشة أي معمارية.
السؤال الأول: ما لا يُصلح في مكانه؟
توجد قائمة قصيرة من المشكلات التي تقاوم الإصلاح التدريجي فعلًا، وتستحقّ المعرفة لأنها الحجة التقنية الصادقة الوحيدة للإعادة. فنموذج بيانات لا يستطيع تمثيل ما يحتاجه العمل الآن — عميل يمكن أن ينتمي لمؤسّستين مثلًا حين يفترض المخطّط واحدة — مشكلة حقيقية، لأن كل ميزة تُبنى عليه يجب أن تُرمّز الحلّ البديل والحلول البديلة تتراكم.
ووقت تشغيل خارج الدعم ولا يمكن ترقيته لأن تابعًا غير موجود للنسخة الأحدث مشكلة أخرى، وهي التي تفرض الأمر في النهاية بغضّ النظر عن تفضيل أحد، لأن ترقيعًا أمنيًا يتوقّف عن التوفّر في وقت ما. والتفصيل المهمّ أن هذه مشكلة مؤرّخة: لها موعد نهائي، ما يجعلها قابلة للتخطيط، وهي أصغر مما تبدو عادةً لأن التابع المانع مكتبة واحدة غالبًا لا الحزمة كلها.
وأربعة أسباب ليست في القائمة.
- اللغة غير عصرية.
- أو الإطار قديم لكنه مدعوم.
- أو الكود قبيح.
- أو فريق جديد لا يحبّ أعراف القديم.
وكل واحد منها مصدر احتكاك حقيقي ولا يبرّر أي منها التكلفة، لأن الاحتكاك الذي تسبّبه خطّي تقريبًا في العمل الذي تؤدّيه والإعادة تكلفة ثابتة كبيرة تُدفع قبل تخفيف أي منه.
السؤال الثاني: من يملك المعرفة؟
نظام يعمل ثماني سنوات يُرمّز آلاف القرارات، معظمها غير موثّق وكثير منها استجابات لمشكلة حقيقية لا يتذكّرها أحد. فالشرط الغريب الذي يستثني نوع عميل معيّنًا من خصم موجود بسبب حادثة في 2019. والإعادة إما تنقل تلك القرارات أو تعيد اكتشافها تذكرة دعم تذكرةً، وأيّهما يحدث يعتمد كليًا على هل من اتّخذها لا يزال متاحًا للسؤال.
وهذا هو السؤال الذي يغيّر الجواب أكثر من غيره، وله صيغة بسيطة بقسوة: لو ترك الشخصان اللذان يفهمان النظام الحالي العمل غدًا، هل تُكمل الإعادة؟ وإن كان الجواب الصادق لا، فالإعادة ليست مشروع اثني عشر شهرًا، بل مشروع اثني عشر شهرًا زائد الزمن اللازم لاستعادة معرفة توجد حاليًا في المحادثة فقط، وذلك الحدّ الثاني غير قابل للتقدير.
اكتب القواعد أولًا
إن كنت ستعيد الكتابة، فأول تسليم ليس المعمارية بل مستند يسرد قواعد العمل التي يفرضها النظام الحالي، مكتوبًا بقراءة الكود ومؤكّدًا من يتذكّرون السبب. وهذا ممل ويأخذ بضعة أسابيع وهو أعلى أثر قيمةً في المشروع كله — بما في ذلك حالة إلغاء الإعادة بعدها، لأن المستند يعيش بعد القرار ويجعل النظام القائم آمن التغيير.
السؤال الثالث: ما يتوقّف أثناء البناء؟
هذه هي التكلفة التي لا تكون في الشريحة أبدًا. فطوال مدة الإعادة، يجب بناء كل ميزة جديدة مرتين أو تأجيلها، وعمليًا تُؤجّل، ما يعني أن العمل يتوقّف عن استلام التغييرات طوال تشغيل المشروع. فإعادة اثني عشر شهرًا ليست تكلفة هندسية لاثني عشر شهرًا؛ بل تكلفة هندسية لاثني عشر شهرًا زائد اثني عشر شهرًا من منافس يُسلّم ما لا تستطيع.
وتتعامل الفرق مع هذا بالوعد ببناء الميزات في النظامين، وذلك الوعد لا يصمد بعد الشهر الثالث. ولا يستطيع، لأن البناء مرتين يُنصّف ناتج الفريق في اللحظة نفسها التي تكون الإعادة متأخّرة فيها، والقرار المحلي العقلاني دائمًا إيقاف النظام القديم. ويُتّخذ ذلك القرار بهدوء، من لا أحد بالتحديد، ويكون تجميد الميزات الذي قال الجميع إنه لن يحدث قائمًا بحلول الصيف.
فسعّرها بصدق في البداية. اسأل ما يتوقّع العمل تسليمه في الأرباع الأربعة القادمة، واسأل أيّها مستعدّ للاستغناء عنه. وإن كان الجواب أنها كلها جوهرية، فالإعادة بنطاقها غير ميسورة بغضّ النظر عن التقدير الهندسي، ويجب أن تنتقل المحادثة إلى نهج يُسلّم باستمرار.
| ما يُسعّر | ما لا يُسعّر عادةً | حجم الفجوة تقريبًا |
|---|---|---|
| بناء النظام الجديد | ميزات لم تُسلَّم خلالها | مماثلة للبناء نفسه |
| ترحيل البيانات | تشغيل النظامين معًا | أشهر من بنية مزدوجة |
| المسار السعيد | قواعد عمل غير موثّقة | أسابيع من التنقيب |
| تدريب المطوّرين | إعادة تدريب كل مستخدم | غالبًا أكبر بند منفرد |
| عطلة التحويل | ربع السنة بحوادث مرتفعة | خطّط لثلاثة أشهر |
استبدله على أجزاء بدلًا من ذلك
النهج الذي يتجنّب معظم ما سبق هو وضع النظام الجديد أمام القديم ونقل الوظائف مسارًا واحدًا في المرة، مع ترك القديم يخدم كل ما لم يُنقل بعد. فكل جزء يُسلَّم للإنتاج وحده، وكل واحد قابل للعكس منفردًا، ويستمرّ العمل في استلام التغييرات طوال الوقت. وهو أبطأ في إجمالي الساعات الهندسية وأرخص بشكل هائل في المخاطرة.
والعيب الصادق أنك تشغّل نظامين لفترة والحدّ بينهما عمل حقيقي: جلسات مشتركة، ورؤية متّسقة للبيانات، وطبقة توجيه يجب أن يملكها أحد. وقد رأينا ذلك الحدّ أصعب جزء في المشروع. ولا يزال أفضل، لأن الحدّ مشكلة هندسية معروفة بشكل معروف، أما التحويل الكبير فيكدّس كل المجاهيل في عطلة واحدة.
وهو يُنتج أيضًا نقطة قرار كل أسابيع قليلة بدل واحدة في النهاية. فبعد نقل ثلاثة مسارات يعرف كل المشاركين تكلفة المسار، ويمكن إعادة تقدير البرنامج الباقي مقابل دليل لا تفاؤل. وتلك هي الخاصية التي تمنع بأكثر موثوقية مشروع اثني عشر شهرًا الذي يصير ثلاثين.
النظام الجديد سيَقدُم أيضًا
أثر النظام الثاني موثّق جيدًا ولا يزال يصطاد فرقًا دقيقة، لأن الإعادة هي اللحظة الوحيدة التي يمكن فيها أخيرًا تضمين كل فكرة مؤجّلة. والنتيجة نظام أعمّ مما تتطلّبه المشكلة، والعمومية هي ما يجعل البرمجيات صعبة التغيير أساسًا. فالنظام القديم بطيء التغيير جزئيًا لأنه تراكمت فيه ميزات؛ والجديد قد يكون بطيء التغيير في يومه الأول لأنه توقّعها.
والحارس ضدّه نطاق مكتوب يقول إن النظام الجديد يفعل بالضبط ما يفعله القديم، زائد الشيء الواحد الذي كان مستحيلًا، ولا شيء غير ذلك. وكل إضافة فوق ذلك تذهب لقائمة تُبنى بعدها كتغيير عادي يُقاس بالمعيار العادي. وهذا غير محبوب وهو الفرق بين إعادة تنتهي وإعادة لا تزال على بعد ثلاثة أشهر لمدة سنتين.
سعّره مقابل تكلفة البقاء
تُقارن إعادة الكتابة دائمًا تقريبًا مقابل لا شيء، ولهذا تبدو دائمًا جديرة بالأداء. والمقارنة الصادقة مقابل تكلفة السنتين القادمتين على النظام الحالي — ساعات الدعم والحلول اليدوية والميزات التي تُسعّر بثلاثة أمثال ما ينبغي بسبب مكان وجوبها. وذلك الرقم موجود ولم يكتبه أحد، وحتى يكتبه أحد تُحاكم إعادة الكتابة مقابل بديل متخيّل قيمته صفر.
وبناء ذلك الرقم يأخذ يومًا تقريبًا. أحصِ تذاكر الدعم الموجودة فقط بسبب عيب معروف، والساعات المصروفة شهريًا على تقرير يجمّعه أحد يدويًا، والميزتين أو الثلاث التي سُعّرت ثم أُسقطت بهدوء لأن التقدير كان سخيفًا. واضرب في أربعة وعشرين شهرًا. والنتيجة كبيرة بما يبرّر عملًا جادًا كثيرًا وغير كبيرة بما يبرّر البدء من جديد كثيرًا، وكلا الجوابين نافع.
والمقارنة يجب أن تضمّ أيضًا تكلفة تشغيل النظامين معًا، وهو البند المنسيّ دائمًا. فطوال استبدال مرحلي تدفع لمجموعتي استضافة ومجموعتي تراخيص والأشخاص الذين يُبقون الاثنين حيّين، وذلك التداخل يدوم روتينيًا ضعف المخطّط. وليس سببًا لتجنّب العمل؛ بل سبب لوضعه في الموازنة بدل اكتشافه في الشهر السابع.
تجميد الميزات الذي لم يوافق عليه أحد
كل إعادة كتابة كاملة تحتوي بندًا غير معلن: تتوقّف الأعمال عن طلب الأشياء حتى تنتهي. ولا يوقّع أحد ذلك البند ولا يصدّقه أحد عند الإشارة إليه، ثم بعد ثمانية عشر شهرًا هناك قائمتا عمل — الميزات المُعاد بناؤها والميزات المطلوبة منذ بدء البناء — وفريق عليه تسليم الاثنتين في قاعدتي الكود. وتلك هي الآلية التي تصبح بها إعادة الكتابة دائمة لا متأخّرة.
وهي حجة للمراحل القصيرة
والدفاع جعل كل مرحلة قصيرة بما يُطاق معه التجميد. فشريحة ستة أسابيع تنقل قدرة واحدة يمكن حمايتها؛ وبرنامج ثمانية عشر شهرًا لا يمكن. ويعني أيضًا أن كل مرحلة تنتهي بشيء في الإنتاج، فيكون للعمل أرضية — فإن أُلغي البرنامج في الشهر الرابع، فالمراحل الثلاث الأولى مُسلَّمة لا متروكة كفرع لم يدمجه أحد.
وهناك أثر من الدرجة الثانية يستحقّ التسمية. ففريق يُسلّم كل ستة أسابيع يتعلّم كيف يكون تشغيل النظام الجديد فعلًا، ويُعيد ذلك إلى الشريحة التالية. وفريق يُسلّم مرة في النهاية يتعلّم كل ذلك في اليوم نفسه، وهو أيضًا يوم إيقاف النظام القديم. والنسخة المرحلية تكلّف أكثر في عمل التكامل وتشتري معلومات في الوقت الوحيد الذي تبقى فيه المعلومات نافعة.
نظامان يحتاجان مصدر حقيقة واحدًا
أصعب جزء في الاستبدال المرحلي ليس الكود، بل تقرير أي نظام يملك كل قطعة بيانات أثناء تشغيل الاثنين. فإن كان الجواب «كلاهما»، فقد بنيت مشكلة مزامنة، والمزامنة بين مخطّطين مختلفين هي حيث تفشل الترحيلات المرحلية فعلًا. وكل كيان يحتاج مالكًا واحدًا للمدة، بالجانب الآخر يقرأ لا يكتب، حتى حين يجعل ذلك شاشة واحدة محرجة مؤقتًا.
وقرار الملكية ذاك يُتّخذ لكل كيان ويُكتب، لأنه يتغيّر بنزول المراحل. فقد ينتقل العملاء للنظام الجديد في المرحلة الأولى بينما تبقى الطلبات في القديم حتى المرحلة الرابعة، ويعني ذلك أن طلبًا يشير لثلاث مراحل إلى عميل يعيش في مكان آخر. وهذا عملي بجدول ملكية موثّق وعرض للقراءة فقط، وفوضى بدونه.
- مالك واحد مُسمّى لكل كيان، لكل التداخل.
- الجانب الآخر يقرأ ولا يكتب الخانة نفسها أبدًا.
- جدول ملكية مكتوب يُحدَّث بنزول المراحل.
- تقرير تسوية يقرأه أحد أسبوعيًا.
- جواب محدّد عن أي نظام يفوز في تعارض.
ويجب أن يكون هناك تقرير تسوية من أول أسبوع للتداخل — مقارنة مجدولة للنظامين على الكيانات المشتركة بسرد الاختلافات. ولن يكون فارغًا، فلا مزامنة كاملة، والمقصد معرفة حجم الفجوة باستمرار لا سماعها من عميل. فانحراف أربعة سجلات مهمة ثلاثاء؛ والانحراف نفسه مكتشفًا عند التحويل تحويلٌ مؤجَّل.
ما نوصي به عادةً
في أغلب التقييمات التي أجريناها، كانت التوصية ربع سنة عمل على الاختبارات والنشر والرصد، ثم إعادة تقييم. وهي غير براقة ولها خاصية نافعة: فإن بقي التغيير بطيئًا بعد ذلك الربع، صارت حجة الإعادة أقوى كثيرًا وأفضل دليلًا كثيرًا، وإن لم يبقَ فقد وفّرت سنة. وكلتا النتيجتين أفضل اطّلاعًا من القرار المتاح في البداية.
وحين أوصينا بإعادة، كان ذلك للسببين الأولين في القائمة — نموذج بيانات لا يستطيع تمثيل العمل، أو وقت تشغيل غير مدعوم بموعد نهائي — وكان نطاقها سلسلة نقلات مسارات لا تحويلًا. ومرّتين أُوقف البرنامج في منتصفه لأن قيمة كافية استُعيدت فلم يبرّر الباقي نفسه، وفي المرتين كان التوقّف القرار الصحيح لا فشلًا.
- دقّق إلى أين أمضى آخر عشرة تغييرات وقتها فعلًا.
- سمِّ ما لا يُصلح في مكانه، أو أقرّ بعدم وجوده.
- اكتب قواعد العمل قبل أي معمارية.
- سعّر الميزات التي لن تُسلَّم خلال العمل.
- انقل مسارًا واحدًا ثم أعد التقدير مقابل تكلفته.
والقرار يستحقّ أسبوعًا لا ربع سنة، ويجب أن يُمضى الأسبوع في جمع الأرقام الأربعة أعلاه لا في تصميم البديل. فالتصميم أولًا هو كيف تصبح الإعادة محتومة قبل أن يُثبت أحد أنها ضرورية، لأن فريقًا أمضى شهرًا على معمارية سيدافع عنها، وبحقّ تمامًا.
