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