إعادة بناء ديون دون ألم شديد

يتجنب العديد من المطورين في فريقنا إعادة البناء. كشفت مناقشة هذا الوضع الأسباب التالية.

لماذا لا يعيد الكثيرين إعادة البناء

• مخيف لكسر الوظائف الحالية

• مضيعة للوقت: إذا تغير الكود الذي تعيد بنائه ، فإن دمجه (عدة مرات) من الفرع الرئيسي يصبح أمرًا مزعجًا

• هناك خطر عدم التواجد في الوقت المناسب للموعد النهائي للمهمة

في الوقت نفسه ، تعد إعادة البناء جزءًا لا يتجزأ تقريبًا من عملية التطوير. ترتبط حاجتها بالمتطلبات التالية:

• المتطلبات الأولية لا تكتمل أبدًا ويتم التطوير وفقًا لافتراضات معينة ، يتضح لاحقًا أن بعضها غير صحيح أو غير دقيق

• غالبًا ما تحتاج إلى إجراء تعديلات سريعة لجعله يعمل هنا والآن ، دون التفكير في مزيد من الدعم

عندما يكون هناك ما يبرر إعادة البناء (مطلوب)

أرى الأسباب التالية لتغيير هيكل الكود:

1. رمز مكرر

   هناك أسباب قليلة لوجود رمز مكرر ؛ في أغلب الأحيان ، تحتاج إلى التخلص منه

2. التعميم

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

   , GooglePay. , ApplePay SamsungPay . VendorPay

3. ,

4. /

   , 50 500 ,

: , , .

• , . , , , , . , () , .

?

, , :

• (unit )

• -

• , -

feature- master' .

, , , . , , , . , , .

- (- + ) , , ( master'), - - .

, master rebase - master.

يتحمل هذا النهج بعض النفقات العامة ، ولكنه يخفف من صعوبات إعادة البناء الرئيسية:

• مراجعة ودمج إعادة البناء ليست مخيفة للغاية ، لأنها في الأساس لا تجلب تغييرات وظيفية ، أو أن هذه التغييرات الوظيفية مرئية بوضوح في طلب سحب صغير

• ليست هناك حاجة لدعم تغييرات المطورين الآخرين لأنه يتم دمج التغييرات في الفرع الرئيسي على الفور تقريبًا

• في حالة دعم المواعيد النهائية ، يمكنك التوقف عن إعادة البناء بعد دورة اليومين أو الثلاثة التالية