تحسين الأنظمة السيئة حقًا
https://stackoverflow.com/questions/192464
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
كيف تبدأ في تحسين نظام سيء حقًا؟
اسمحوا لي أن أشرح ما أعنيه قبل أن توصي بإنشاء اختبارات الوحدة وإعادة البناء. يمكنني استخدام هذه التقنيات ولكن هذا سيكون بلا معنى في هذه الحالة.
في الواقع ، فإن النظام مكسور جدًا ولا يفعل ما يتعين عليه القيام به.
على سبيل المثال ، يجب أن يحسب النظام عدد الرسائل التي يرسلها. يعمل في الغالب ولكن في بعض الحالات ينسى "زيادة قيمة عداد الرسائل. تكمن المشكلة في أن العديد من الوحدات الأخرى ذات الحلول الخاصة بها تعتمد على هذا العداد بحيث إذا قمت بتصحيح العداد ، فإن النظام ككل سيصبح أسوأ مما هو عليه حاليًا. يمكن أن يكون الحل هو تعديل جميع الوحدات وإزالة تصحيحاتها الخاصة ، ولكن مع أكثر من 150 وحدة تتطلب الكثير من التنسيق الذي لا أستطيع تحمله.
والأسوأ من ذلك ، أن هناك بعض المشكلات التي لديها حلول ليس في النظام نفسه ، ولكن في رأس الناس. على سبيل المثال ، لا يمكن للنظام أن يمثل أكثر من أربع رسائل ذات صلة في مجموعة رسائل واحدة. تتطلب بعض الخدمات خمس رسائل مجمعة معًا. يعرف قسم المحاسبة هذا القيد وفي كل مرة يحسبون الرسائل الخاصة بهذه الخدمات ، فإنها تحسب مجموعات الرسائل وضربها بمقدار 5/4 للحصول على الرقم الصحيح للرسائل. لا يوجد أي وثائق على الإطلاق حول هذه الانحرافات ولا أحد يعرف عدد هذه الأشياء الموجودة في النظام الآن.
فكيف تبدأ العمل على تحسين هذا النظام؟ ما هي الاستراتيجية التي ستتبعها؟
بعض الأشياء الإضافية: أنا من الرجال الذين يعملون على هذا الأمر ، لذا فهي ليست إجابة مقبولة لتوظيف عدد كافٍ من الرجال وإعادة تصميم/إعادة صياغة النظام. وفي غضون أسابيع أو أشهر قليلة ، يجب أن أظهر حقًا بعض التقدم المرئي ، لذا فهو ليس خيارًا إما أن أقوم بإعادة إنشاء نفسي في غضون عامين.
بعض التفاصيل الفنية: يتم كتابة النظام في Java و PHP ولكني لا أعتقد أن هذا مهم حقًا. هناك قواعدان من قواعد البيانات خلفها ، Oracle وواحدة postgresql. إلى جانب العيوب المذكورة قبل أن تنبعث منها الرمز نفسه ، فهي مكتوبة وتوثيق بشكل سيء للغاية.
معلومات إضافية:
قضية مضادة ليست مشكلة التزامن. تتم إضافة عبارات Counter ++ إلى بعض الوحدات ، ولا تتم إضافتها إلى بعض الوحدات الأخرى. الإصلاح السريع والقذر هو إضافتها حيث تكون مفقودة. الحل الطويل هو جعلها نوعًا من الجوانب للوحدات النمطية التي تحتاج إلى ذلك ، مما يجعل من المستحيل نسيانه لاحقًا. ليس لدي أي مشاكل في إصلاح أشياء مثل هذا ، لكن إذا قمت بإجراء هذا التغيير ، فسوف أكسر أكثر من 10 وحدات أخرى.
تحديث:
قبلت إجابة جريج دي. حتى لو كنت أحب آدم بيلاير ، فلن يساعدني ذلك على معرفة ما سيكون مثاليًا لمعرفة. شكرا جميع على الإجابات.
المحلول
- أخرج الحرائق. إذا كانت هناك أي قضايا ذات أولوية حرجة ، مهما كانت ، فعليك التعامل معها أولاً. اخترقه إذا كان يجب عليك ذلك ، مع قاعدة كود ذات رائحة كريهة ، لا بأس. أنت تعلم أنك ستحسن من المضي قدمًا. هذه هي تقنية المبيعات الخاصة بك التي تستهدف من الذي تقوم بالإبلاغ عنه.
- اختر بعض الفاكهة المنخفضة. أفترض أنك جديد نسبيًا في هذا البرنامج بالذات وأنك تم إعادة المهمة للتعامل معه. ابحث عن بعض المشكلات السهلة على ما يبدو في النظام الفرعي ذي الصلة للرمز الذي لا ينبغي أن يستغرق أكثر من يوم أو يومين لحل كل منهما ، وإصلاحها. قد ينطوي هذا على إعادة إنشاء ، أو قد لا. الهدف هو التعرف على النظام وبأسلوب المؤلف الأصلي. قد لا تكون محظوظًا حقًا (أحد غير المؤهلين اللذين عملوا على نظامي أمامي دائمًا بعد تثبيت تعليقاته بأربع علامات علامات الترقيم بدلاً من واحدة ، مما جعل من السهل جدًا التمييز بين من كتب شريحة معينة من الكود.) لكنك ستقوم بتطوير نظرة ثاقبة على نقاط ضعف المؤلف حتى تعرف ما الذي تبحث عنه. على سبيل المثال ، اقتران مكثف وضيق مع فهم الدولة العالمية مقابل الفهم الضعيف لأدوات اللغة.
- حدد هدفًا كبيرًا. إذا كانت تجربتك تتوافق مع الألغام ، فستجد نفسك في جزء معين من رمز السباغيتي في كثير من الأحيان مع أداء الخطوة السابقة. هذه هي العقدة الأولى التي تحتاجها لفك. من خلال التجربة التي اكتسبتها ، فهمت المكون والمعرفة حول ما كان على الأرجح المؤلف الأصلي خطأ (وبالتالي ، ما تحتاج إلى الانتباه إليه) ، يمكنك البدء في تصور نموذج أفضل لهذه المجموعة الفرعية من النظام. لا تقلق إذا كان لا يزال يتعين عليك الحفاظ على بعض الواجهات الفوضوية للحفاظ على الوظائف ، فقط خذها خطوة واحدة في كل مرة.
رغوة الصابون تكرار شطف! قون
بالنظر إلى الوقت ، فكر في إضافة اختبارات الوحدة لنموذجك الجديد مستوى واحد أسفل واجهاتك مع بقية النظام. لا تنقص الواجهات السيئة في الكود عبر الاختبارات التي تستخدمها ، ستقوم بتغييرها في التكرار المستقبلي.
معالجة القضايا الخاصة التي ذكرتها:
عندما تصطدم بموقف يعمل المستخدمون يدويًا ، تحدث مع المستخدمين حول تغييره. تحقق من أنهم سيقبلون التغيير إذا قدمته قبل غرق الوقت فيه. إذا كانوا لا يريدون التغيير ، فإن وظيفتك هي الحفاظ على السلوك المكسور.
عندما تصطدم بمكون عربات التي تجرها الدواب التي عملت فيها مكونات أخرى متعددة ، أقوم بتبني تقنية مكون موازية. إنشاء عداد يعمل كيف واحد ينبغي الشغل. توفير واجهة مماثلة (أو ، إذا كانت عملية ، متطابقة) وشق المكون الجديد في قاعدة الكود. عندما تلمس المكونات الخارجية التي تعمل حول المكونات المكسورة ، حاول استبدال المكون القديم بالمكون الجديد. واجهات مماثلة تخفيف نقل الكود ، ولا يزال المكون القديم موجودًا في حالة فشلها الجديدة. لا تقم بإزالة المكون القديم حتى تتمكن من ذلك.
نصائح أخرى
ما الذي يُطلب منك الآن؟ هل يُطلب منك تنفيذ الوظائف أو إصلاح الأخطاء؟ هل يعرفون حتى ماذا يريدون منك أن تفعل؟
إذا لم يكن لديك القوى العاملة أو الوقت أو الموارد "لإصلاح" النظام ككل ، فكل ما يمكنك فعله هو مياه الكفالة. أنت تقول أنك يجب أن تكون قادرًا على إحداث بعض "التقدم المرئي" في غضون بضعة أشهر. حسنًا ، مع كون النظام سيئًا كما وصفته ، قد تجعل النظام أسوأ بالفعل. تحت الضغط للقيام بشيء ملحوظ ، ستقوم ببساطة بإضافة رمز ، وجعل Sysem أكثر معقدًا.
تحتاج إلى إعادة تشكيل ، في نهاية المطاف. لا توجد طريقة للتغلب عليها. إذا تمكنت سيكون ذلك مثاليًا, ، حتى لو استغرق الأمر من 6 إلى 9 أشهر أو عام بدلاً من "بضعة أشهر". ولكن إذا لم تتمكن من ذلك ، فعليك اختيار:
- Refactor ، والمخاطر التي ينظر إليها على أنها "لا تنجز أي شيء" على الرغم من جهودك
- لا تكرر الأهداف "المرئية" ، وجعل النظام أكثر تعقيدًا وأكثر صعوبة في إعادة تشكيله في يوم من الأيام. (ربما بعد أن تجد وظيفة أفضل ، ونأمل أن لا يمكن للمطور التالي أن يكتشف المكان الذي تعيش فيه.)
أي واحد هو الأكثر فائدة لك يعتمد شخصيًا على ثقافة شركتك. هل يقررون يومًا ما توظيف المزيد من المطورين ، أو استبدال هذا النظام تمامًا ببعض المنتجات الأخرى؟
على العكس من ذلك ، إذا كانت جهودك "لإصلاح الأشياء" تقطع بالفعل أشياء أخرى ، فهل سيكونون يفهمون عن الوحشية التي يُطلب منك معالجتها بمفردها؟
لا توجد إجابات سهلة هنا ، آسف. يجب عليك التقييم بناءً على وضعك الفردي الفريد.
هذا كتاب بأكمله سيقول بشكل أساسي اختبار الوحدة و refactor ، ولكن مع المزيد من المشورة العملية حول كيفية القيام بذلك
http://ecx.images-amazon.com/images/i/51rcxgpxq8l._sl500_aa240_.jpg
http://www.amazon.com/working-effectively-legacy-robert-martin/dp/0131177052
You open the directory that contains this system with Windows Explorer. Then, press Ctrl-A, and then Shift-Delete. That sounds like an improvement in your case.
Seriously though: that counter sounds like it's got thread-safety issues. I'd put a lock around the increasing functions.
And regarding the rest of the system, you can't do the impossible so try to do the possible. You need to attack your system from two fronts. Take care of the more visibly problematic issues first, so you can show progress. At the same time, you should deal with the more infrastructural problems, so that you have a chance at actually fixing this thing some day.
Good luck, and may the source be with you.
اختر مجالًا واحدًا من الصعوبة المتوسطة لإعادة تشكيله. قم بإنشاء هيكل عظمي من الكود الأصلي مع توقيعات الطريقة فقط من تلك الموجودة ؛ ربما استخدم واجهة حتى. ثم ابدأ بالقرصنة. يمكنك حتى توجيه الأساليب "الجديدة" إلى الطرق القديمة حتى تصل إليها.
ثم ، الاختبار ، الاختبار ، الاختبار. نظرًا لعدم وجود أي اختبارات للوحدة ، فربما تستخدم اختبارات الوحدة التي تم تنشيطها الصوتية القديم (الأشخاص)؟ أو اكتب اختباراتك الخاصة كما تذهب.
قم بتوثيق تقدمك وأنت تذهب في نوع من المستودعات ، بما في ذلك الإحباط والأسئلة ، بحيث عندما يكون Schmuck الفقير التالي الذي يحصل على هذا المشروع هو المكان الذي أنت فيه :).
بمجرد إنجاز الجزء الأول ، انتقل إلى التالي. المفتاح هو البناء على رأس التقدم المتزايد ، ولهذا السبب يجب ألا تبدأ بأصعب جزء أولاً ؛ سيكون من السهل للغاية أن تصبح محبطًا.
جويل لديه عدة مقالات حول إعادة الكتابة/إعادة النية:
لقد كنت أعمل مع نظام قديم له نفس الخصائص منذ ما يقرب من ثلاث سنوات ، ولا توجد اختصارات على علم بها.
أكثر ما يزعجني مع نظامنا القديم هو أنه لا يُسمح لي بإصلاح بعض الأخطاء ، لأن العديد من الوظائف الأخرى يمكن أن تنكسر إذا قمت بإصلاحها. هذا يدعو إلى حلول قبيحة أو إنشاء إصدارات جديدة من الوظائف القديمة. يمكن بعد ذلك استبدال المكالمات إلى الوظائف القديمة بالرسالة الجديدة في وقت واحد (أثناء الاختبار).
لست متأكدًا من هدف مهمتك ، لكنني أنصحك بشدة بلمس كل ما يمكن من الكود. فقط افعل ما عليك القيام به.
قد ترغب في الحصول على أكبر قدر ممكن من التوثيق من خلال إجراء مقابلات مع الأشخاص. هذه مهمة ضخمة ، لأنك لا تعرف الأسئلة التي يجب طرحها ، وسينسى الناس الكثير من التفاصيل.
بخلاف ذلك: تأكد من الحصول على رواتب ودعم أخلاقي كافي. سيكون هناك تبكي وصرير الأسنان ...
حسنًا ، تحتاج إلى البدء في مكان ما ، ويبدو أن هناك أخطاء تحتاج إلى إصلاح. أود أن أعمل من خلال تلك الأخطاء ، وأجعل عمليات إعادة صياغة فوز سريعة ، وكتابة أي اختبارات وحدة ممكنة على طول الطريق. أود أيضًا استخدام أداة مثل Sourcemonitor لتحديد بعض الأجزاء "الأكثر تعقيدًا" من التعليمات البرمجية في النظام ومعرفة ما إذا كان بإمكاني تبسيط تصميمها بأي شكل من الأشكال. في النهاية ، عليك فقط أن تقبل أنها ستكون عملية بطيئة ، واتخاذ خطوات صغيرة نحو نظام أفضل.
سأحاول اختيار جزء من النظام الذي يمكن استخلاصه وإعادة كتابته بمعزل سريع إلى حد ما. حتى لو لم يفعل الكثير ، يمكنك إظهار التقدم بسرعة كبيرة ، ولم يكن لديك مشكلة في التواصل مع الكود القديم مباشرة.
نأمل ، إذا تمكنت من اختيار بعض هذه المهام ، فسوف يرونك تحرز تقدمًا واضحًا ، ويمكنك تقديم حجة لتوظيف المزيد من الأشخاص لإعادة كتابة الوحدات الأكبر. عندما تعتمد أجزاء من النظام على السلوك المكسور ، فلن يكون لديك الكثير من الخيارات سوى الانفصال قبل إصلاح أي شيء.
نأمل أن تتمكن من بناء فريق قادر تدريجياً على إعادة كتابة المجموعة بأكملها.
كل هذا يجب أن يسير جنبًا إلى جنب مع بعض التدريب اللائق ، وإلا فإن العادات القديمة للناس سوف تلتزم ، وسيحصل عملك على اللوم عندما لا تعمل الأمور كما هو متوقع.
حظا طيبا وفقك الله!
يؤدي إلى إهمال كل ما هو موجود حاليًا لديه مشاكل ، ويكتب مشكلات جديدة تعمل بشكل صحيح. توثيق قدر الإمكان حول ما سيتغير ووضع علامات وميض حمراء كبيرة في كل مكان يشير إلى هذه الوثائق.
من خلال القيام بذلك بهذه الطريقة ، يمكنك الحفاظ على الأخطاء الموجودة لديك (تلك التي يتم تعويضها في مكان آخر) دون إبطاء تقدمك نحو الحصول على نظام عمل فعلي.
