كيفية سيارة أجرة مع رمز القديمة عندما كان هناك حاجة إلى مشروع أمس

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

نحن نتعامل مع المشروع

للتعبير عن مدى دقة العمل المدروس والمضني الذي يجب أن يكون مع الإرث القديم ، سأقدم تشابهاً مع مجموعة أوراق.


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

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

1. لقد أنشأنا موقعًا "بسيطًا" ، والآن تريد الحصول على "كعكة" جديدة ، ونحن بحاجة إلى إعادة كتابة كل هذا ، لأن لدينا تراث ...
2. لا أحد يعرف كيف يعمل هذا ..
3. لإضافة وحدة نمطية ، تحتاج إلى التحقق من الموقع بأكمله - وبهذه الطريقة فقط سوف نفهم ماذا وأين يمكن الخروج منه ...
4. لن أذهب إلى هناك على أي حال ، كل شيء سيء بالفعل هناك ...

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

1. لا توجد وثائق فنية. أدنى عتبة للمشاكل ، لأنه يمكنك اختبار التخمينات الأولية والتوصل إليها حول كيفية عمل ذلك.
2. لا وثائق العمل. إذا كانت جميع الوثائق (الفنية والتجارية) مفقودة ، فإن الشعور "يبدو أننا عالق في التاريخ" يأتي بشكل لا إرادي. في الواقع ، حتى الأعمال التجارية لا تتذكر كيف يجب أن تعمل ، مما يعني أن الفريق ، على الأقل ، ليس لديه أي فهم فيما يتعلق بالنتيجة المتوقعة.
3. ليس هناك من صمم هذا. إذا ، بالإضافة إلى عدم وجود وثائق ، لا يوجد أيضًا مطور يمكنه شرح كيفية عمل المشروع ، فرائحته تنبعث منه بالفعل رائحة كريهة.
4. لا نعرف ما يجب أن يحصل عليه المستخدم في النهاية. إنه شيء واحد عندما تنشأ أسئلة حول الواجهة الخلفية فقط ، ولكن إذا كان لا يزال لدينا أي فكرة على الإطلاق عما يجب عرضه في المقدمة ، فهذا قريب بالفعل من الحالة "من المحتمل أن يكون المريض قد مات أكثر من حي".
5. 200+ استخدام كل وظيفة ويطلق عليهم getA . مستوى الصعوبة الخامس: عندما تذهب إلى Legacy ، تشاهد استخدام الدالة A و 200 ، ولا أحد يعرف سبب ...
6. لا يوجد مبرمجين يودون / يمكن أن يتطوروا. لا تعليق

فهم العمل

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

في كثير من الأحيان ، دفع المطورين الأعمال إلى أفكار عديمة الفائدة. في هذه المناسبة ، هناك "صندوق منفصل للاقتباسات الذهبية".

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

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

1. هل الأعمال جاهزة للنمو؟ تحتاج إلى فهم: هل لدى الشركة طلب لرفع المعيار المالي أم تحتاج فقط إلى الخدمة للعمل بكفاءة أكبر.
2. مرحلة النموذج؟ في كثير من الأحيان ، تطلب الشركة نموذجًا أوليًا بسيطًا ، تريد من خلاله "استكشاف" السوق في وقت ملاءمة المنتج. وفقط إذا بدأ في جني الأموال ، يكون العمل جاهزًا لتطوير الميزة في مشروع أكثر تقدماً وكاملة.
3. اكتمل التطوير والآن الدعم فقط؟ من المهم أن نفهم مجموعة كاملة من المهام.
4. هل هناك ما يكفي من النار في أعيننا ولن تخرج؟ يجب أن يلهم المشروع ، وليس تثبيته. من المهم جدًا أن يرغب فريقك في الانخراط في التناسخ في Legacy ، وإلا فإن الناس سوف ينتشرون تدريجياً في مشاريع أكثر إثارة للاهتمام بالنسبة لهم.
5. هل يوجد مهندس معماري؟ هذا هو السؤال الأكثر أهمية - هل لديك شخص يمكنه أن يصنع الهيكل الصحيح ويبدأ في كتابة رمز جيد بالفعل. ليس من المنطقي حتى محاولة البدء إذا لم يكن هناك مهندس معماري. خلاف ذلك ، في غضون أسبوع سوف تصبح الشخص الذي خلق تركة المشكلة.

عندما تبيع الأفكار إلى العمل ، ركز على الرسائل "الجديدة ، والإبداعية ، والإضافية" ... يستجيب النشاط التجاري جيدًا للعروض المقدمة من السلسلة: "سنجعلك ميزة جديدة وسيصبح المشروع X أسرع ..." و "لزيادة التحويل ، أضف ميزة جديدة ... "

ف - التخطيط

للعمل بسرعة وكفاءة مع الديون التقنية ، تحتاج إلى خطة.

1. تعريف المهام التي سوف نتطفل عليها. لماذا التطفل؟ يحدث ذلك غالبًا: لقد بعنا إحدى الميزات ، ونعني به جزئيًا إعادة بناء المنازل.

2. تحديد متطلبات مستوى عال. من الضروري تسجيل طلب أعمال واضح لـ "مستوى عالٍ" من أجل إعداد الوثائق الصحيحة.

3. تعريف الوحدات الرئيسية للنظام ، وفرض وحدات. قبل البدء في إعادة التجهيز ، تحتاج إلى فهم الوحدات الرئيسية للنظام: أين وكيف وكيف وماذا ومع ما يمكن التفاعل وتحديد الكود في أقسام.

4. تعريف التكامل. عند إنشاء وحدة نمطية محددة ، نحتاج إلى التفكير مسبقًا في القدرة على تركيبها في إرث مجاور.

5. تعريف الفريق. واحد في مجال إعادة بناء المساكن ليس محارب. الفريق عنصر مهم جدًا في تحقيق نتيجة ناجحة. يجب أن يكون لديك Fervor ، قيادة فريق والتفاعل الممتاز بين المشاركين في العملية.

6. كيف سنختبر؟ إذا كنت ستقوم بمشروع عالي الجودة ، فأنت بحاجة إلى التفكير في خيارات اختبار المنتج.

إلى جانب ما سبق ، من المهم أيضًا تحديد النتيجة النهائية المرغوبة ، ووضع خطة تحجيم وتسجيل اختناقات المشروع. على سبيل المثال ، في حالة تغيير حجم الشفرة ، من المهم فهم الأماكن التي يمكن أن تنشأ فيها المشكلات في ظل ظروف الأحمال الكبيرة (يمكن أن تكون قاعدة بيانات أو استعلامات ثقيلة أو شبكة أو بعض الارتباطات الوسيطة الأخرى التي يمكن أن "تسقط").

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

النينجا تراث التقنيات

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

1. لا إعادة اختراع العجلة. بالنسبة لي ، هذا هو اختراق الحياة الرئيسي لكتابة التعليمات البرمجية. تم اختراع كل شيء من قبلك ، لا تلجأ إلى الرقص مع الدفوف والتجارب الأخرى لحل مشاكل الكود القديم.

2. الكود هو المعيار. بدون معيار واحد ، سوف يكتب كل مطور بطريقته الخاصة. "أسلوب المؤلف" سوف يساهم في الفوضى ويزيد من القمامة.

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

4. محلل كود ثابت ، PHP للكشف عن فوضى الخ (بدلا من ألف كتاب) . ستكون هناك حاجة إلى هذه التقنيات والتقنيات التلقائية الأخرى لتسريع العملية ، خاصة برمز المراجعة نفسه.

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

6. هيكل قاعدة البيانات ، مصادر البيانات. إنها قاعدة البيانات التي أعتبرها عنق الزجاجة الأولى لأي تراث. لكن الجميع يصمم حسب رغبته ، وحتى في SQL ، يمكنك العثور على عيوب غير مركزة. فيما يلي بعض النصائح للعمل مع قاعدة البيانات الجديدة:

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

7. لكن مزود؟ إذا كان من وجهة نظر معمارية يمكنك العمل مع الكيانات - تعمل. سيساعدك مفهوم شيء محدد ومحدود على عدم إنشاء علاقات غير ضرورية ومكررة.

8. الديكورات ، المحولات ، اللقطات ... هذه الأنماط هي واحدة من الأنواع الرئيسية لدمج الكود الجديد في التراث القديم.

9. الخطة ب ، أو خطة الاستعادة للتكامل. يخطئ الكثيرون في نسيانها. إنه أمر حيوي في الموقف "عندما يحدث خطأ ما" عند صب مواد جديدة. هذا هو ، بمجرد أن نبدأ في بناء العمارة ، بالفعل في هذه المرحلة يجب أن نفهم كيف سنعيدها في حالة وجود خطأ.

10. يصبح كود جديد بدون اختبارات (أرصفة) إرثًا في غضون أسبوع. بغض النظر عن مدى جمال الشفرة الخاصة بك ، فبدون توثيق في غضون أسبوع ، ستكون في حالة "قديمة" - بسبب عدم وضوحها.

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

بدلا من خاتمة

أهم شيء في هذه القصة هو القيام بالعمل وعدم ترك وراءه تراث المراحل الإشكالية الستة (المدرجة بالترتيب من البسيط إلى الأكثر تعقيدًا):

• لا توجد وثائق فنية
• لا وثائق العمل
• ليس هناك من طور هذا
• نحن لا نعرف ما يجب أن يتلقى المستخدم.
• 200 + استخدام كل وظيفة ويطلق عليهم getA ()
• لا يوجد أحد يرغب / يمكنه تطوير هذا.