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