إعادة كتابة أو إصلاح؟

Question

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

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

Answer 1

يعتمد الأمر حقًا على مدى سوء الأمر.

إذا كان نظامًا صغيرًا، وأنت تفهمه تمامًا، فإن إعادة الكتابة ليست أمرًا مجنونًا.

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

نقاط يجب مراعاتها:

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

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

Answer 2

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

مع تقدم عمليات التنظيف، ستتمكن من مسح المزيد والمزيد من التعليمات البرمجية السيئة في الصناديق المغلفة.ومن ثم يمكنك اختيارهم واحدًا تلو الآخر في المستقبل.

يمكن لأداة مثل javadoc أو Doxygen، إذا لم تكن مستخدمة بالفعل، أن تساعد أيضًا في تحسين توثيق التعليمات البرمجية وفهمها.

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

Answer 3

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

أنظر أيضا: كرة كبيرة من الطين

Answer 4

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

احصل على التعليمات البرمجية القديمة ضمن اختبارات الوحدة وأعد هيكلتها و/أو استبدل أجزاء صغيرة منها بشكل كامل بشكل تدريجي عندما يكون ذلك مناسبًا.

Answer 5

Refactor ما لم يكن سيئًا للغاية بالفعل.

جويل لديه الكثير ليقوله في هذا الشأن..

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

Answer 6

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

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

لم أسمع بعد كيف تم الأمر :)

أعتقد أن الناس يميلون إلى إعادة الكتابة لأنها تبدو أكثر متعة على السطح.

علينا إعادة البناء من الصفر!

سنفعل ذلك بشكل صحيح هذا الوقت!

إلخ.

Answer 7

هناك كتاب جديد سيصدر تطوير تطبيقات Brownfield في .NET بواسطة بالي وبلشام.الفصل الأول مجاني، ويتحدث عن هذه القضايا من منظور ملحد في الغالب.

Answer 8

الإصلاح، أو الأهم من ذلك، إعادة البناء.كلاهما بسبب قال جويل ذلك وأيضًا لأنه، إذا كان هذا هو الرمز الخاص بك، فمن المحتمل أنك تعلمت الكثير من الأشياء منذ أن لمست هذا الرمز آخر مرة.إذا قمت بكتابته في .NET 1.1، فيمكنك ترقيته إلى 3.5 SP1.يمكنك الدخول وإزالة جميع التعليمات البرمجية القديمة التي تم التعليق عليها.أنت الآن أفضل 100 مرة كمطور مما كنت عليه عندما كتبت هذا الرمز لأول مرة.

الاستثناء الوحيد الذي أعتقده هو عندما يستخدم الكود تقنيات قديمة حقًا - وفي هذه الحالة قد يكون من الأفضل لك كتابة إصدار جديد.إذا كنت تنظر إلى بعض تطبيقات VB6 التي تحتوي على 10000 سطر من التعليمات البرمجية مع واجهة خلفية لقاعدة بيانات Access، فمن الواضح أنها تم إعدادها بواسطة شخص لا يعرف الكثير عن كيفية عمل قواعد البيانات (والذي من الممكن أن تكون أنت منذ ثماني سنوات) فمن المحتمل أن تتمكن من سحبه من حل أسرع يستند إلى C#/SQL في جزء صغير من الوقت والرمز.

Answer 9

الأمر ليس بالأبيض والأسود..يعتمد الأمر حقًا على الكثير من العوامل (الأهم هو "ما الذي يريدك الشخص الذي يدفع لك أن تفعله")

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

Answer 10

اعتمادا على حالتك، أنت قد لديك خيار آخر:رمز الطرف الثالث المضمن في الترخيص.

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

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

Answer 11

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