إعادة البناء بلا رحمة أو بناء واحدة للتخلص منها؟

Question

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

-- فريد بروكس، شهر الرجل الأسطوري [التأكيد على الألغام]

بناء واحدة لرميها بعيدا.هذا ما قالوا لي.ثم قالوا لي أننا جميعا رشيق الآن، لذلك ينبغي لنا إعادة البناء بلا رحمة.ما يعطي؟

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

Answer 1

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

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

Answer 2

تخلص مبكرًا، وأعد البناء لاحقًا

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

المواقف المختلفة تتطلب أساليب مختلفة.أنا شخصياً أفضل إعادة البناء لتصميم أفضل كلما أمكن ذلك.تؤدي إعادة البناء إلى أخطاء أقل من إعادة الكتابة.

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

Answer 8

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

أطيب التحيات

Answer 9

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

Answer 10

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

على سبيل المثال، لقد كتبت قاعدة تعليمات برمجية كبيرة في Ruby on Rails، وعلى مدى 2-3 سنوات الماضية، تقدمت RoR كثيرًا.لقد اتخذت أيضًا بعض القرارات في الهندسة المعمارية التي تحتاج إلى إصلاح.لذا، سأتخلص من واحدة وأبني واحدة جديدة من الصفر.ومع ذلك، لا أزال قادرًا على استخدام 70-80% أو نحو ذلك من الكود القديم الخاص بي، حيث إنني لا أزال أكتب بلغة Ruby and Rails.

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

لذلك، من خلال اختيار تقنية رائعة منذ البداية، تمكنت من التخلص من واحدة منها، ولكن مع ذلك أخذت معي 70-80% من الأشياء القديمة التي لا تزال تعمل.

Answer 11

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

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

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

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

Answer 12

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

Answer 13

كمدير تطوير في هذه المنظمة، "لا يُسمح لي" بكتابة كود الإنتاج.

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

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

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

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

Answer 14

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

غالبًا ما تؤدي إعادة هيكلة نظام البقرة النقدية القديم إلى عمليات قرصنة قديمة الطراز.أعتقد أن إعادة البناء تبدو أفضل بكثير من القرصنة.