Чи є названий анти-шаблон для історично вирощеного програмного забезпечення? [зачинено]

Чи є анти-шаблон, який описує історично вирощену програмну систему, де кілька розробників просто додавали нові функції в систему, але ніхто насправді не стежив за загальною архітектурою, а також не проводився рефакторингах?

Я думаю, що це відбувається, коли керівництво / клієнт постійно просить нову функцію, і ніхто ніколи нічого не рефактує, а лише додає до того, що раніше робили інші розробники.

Причиною також може бути те, що розробник просто переповнений програмною системою і не дуже розуміє, як вона працює в даний час, а потім просто додає / клеїть свій код в самому кінці (замість того, щоб переробляти код і змінювати його.)

Тож з часом все складніше та складніше підтримувати систему.

(Цікаво, чи є фотографії для такого типу анти-шаблону, щоб зробити це більш зрозумілим для людей, які не програмують - як автомобіль, який був побудований, додавши ще більше функцій, не замислюючись про загальний дизайн. Як у когось є потреба в буксируванні причепи під час їзди назад, а потім інженер просто приварює буксир до передньої частини автомобіля. Робота виконана. Але зараз капот більше не відкривається.)

Ви посилаєтесь на технічну заборгованість .

Всі ми накопичуємо технічну заборгованість у продуктах, які ми розробляємо з часом; рефакторинг - це один із найпоширеніших та ефективних способів зменшення цього технічного боргу, хоча багато компаній ніколи не погашають свою технічну заборгованість. Ці компанії, як правило, знаходять своє програмне забезпечення вкрай нестабільні роки в дорозі, і технічний борг стає настільки жахливим, що ви не можете його поступово сплачувати, тому що платити за це потрібно буде занадто багато часу.

Технічний борг має цей термін, тому що він відповідає тій же поведінці боргу. Ви отримуєте борг, і поки ви продовжуєте витрачати гроші (створюючи функції) і не сплачуючи цей борг, він лише зростатиме. Так само, як заборгованість, коли вона стає занадто великою, ви потрапляєте в пункти, де, можливо, хочете повністю її пролити за допомогою таких небезпечних завдань, як перезаписи. Також як реальна заборгованість, оскільки вона накопичується до певного моменту, вона взагалі перешкоджає вашій здатності витрачати (створюючи функції).

Просто, щоб кинути ще один термін у суміш, згуртованість означає те, наскільки добре поєднується система, мікро на рівні лінії чи макро на рівні системи. Високо згуртована система дозволить всім її частинам добре поєднуватися між собою і виглядати так, як один інженер це написав. Ваша посилання вище на те, що хтось просто приклеює свій код до кінця, порушує згуртованість цієї системи.

Управління технічним боргом

Існує маса способів управління технічною заборгованістю, хоча, як і реальна заборгованість, найкращим підходом є її погашення часто. На жаль, як реальна заборгованість, іноді краща ідея накопичити більше за короткий період, коли, наприклад, час на ринок тієї чи іншої функції може удвічі або втричі перевищити ваш дохід. Складна частина зважує ці конкуруючі пріоритети, а також визначає, коли рентабельність боргів не стоїть за цю особливість порівняно, коли вона є.

Тому іноді варто нараховувати борг за короткий період, але так рідко буває, і як з усіма боргами, чим коротший період, тим краще. Тому в кінцевому підсумку (бажано швидко ) після накопичення технічної заборгованості вам доведеться сплатити її, це загальні підходи:

• Рефакторинг
  • Це дозволяє взяти біти коду, які були лише зрозуміли, що вони були заміщені частково через або після завершення реалізації, і помістити їх у правильне місце (або більш правильне все одно).
• Перепишіть
  • Це як банкрутство. Це витирає шифер чистим, але ви починаєте з нічого і маєте всі можливості зробити ті самі помилки, а то й більші. Підхід із високим ризиком із високою винагородою до технічної заборгованості, але іноді це ваш єдиний варіант. Хоча це так рідше, ніж багато хто скаже вам.
• Огляд архітектури
  • Це скоріше активний підхід до погашення технічної заборгованості. Це робиться, якщо хтось має повноваження щодо технічних деталей, щоб зупинити реалізацію, незалежно від планів та графіків проекту, щоб забезпечити накопичення менше технічного боргу.
• Код заморозки
  • Замороження коду змін може дозволити дихати кімнатою, де ваш борг не збільшується чи зменшується. Це дає вам час спланувати свій підхід до зменшення технічної заборгованості, сподіваючись на найвищу рентабельність інвестицій на ваш підхід.
• Модуляризація
  • Це як підхід рівня 2, який доступний лише тоді, коли ви використовуєте або «Огляд архітектури», щоб вже була модульна система, або «Рефакторинг» для переходу до неї. Якщо у вас є модульна система, ви можете виплачувати борг цілими шматками системи ізольовано. Це дозволяє робити часткові перезаписи, часткове рефакторинг, а також мінімізувати нарахування технічної заборгованості, оскільки ізоляція зберігає заборгованість лише в тих областях, де функції ввійшли, на відміну від поширення по всій системі.
• Автоматизовані тести
  • Автоматизоване тестування може допомогти в управлінні вашою технічною заборгованістю, оскільки вони можуть допомогти вам визначити проблеми в системі, сподіваємось, до того, як борг у цих областях набув великого зросту, але навіть після того, як вони все-таки можуть інформувати інженерів про ті небезпечні області, які вони можливо, ще не зрозумів. Крім того, щойно ви отримаєте автоматизовані тести, ви можете вільніше відновлювати речі, не піклуючись про те, щоб занадто сильно зламати. Не тому, що розробники не розбиватимуть справи, а тому, що вони дізнаються, коли вони порушують речі , покладаючись на ручні тестери в сильно заборгованих системах, як правило, мають поганий досвід пошуку проблем.

Ваш опис підходить до Футу та великого куля бруду Йодера :

Протягом останніх декількох років ряд авторів ... представили зразки, що характеризують архітектури програмного забезпечення високого рівня ... В ідеальному світі кожна система була б прикладом одного або декількох таких шаблонів високого рівня. І все-таки це не так. Архітектура, яка насправді переважає на практиці, ще не має обговорюватися: ВЕЛИКИЙ БАЛ МУД .

Велика кулька грязі випадково структурована, розкидана, неохайна, клейка стрічка та дріт, спагетті з джунглями коду. Ми всі їх бачили. Ці системи демонструють безпомилкові ознаки нерегульованого зростання та повторного, доцільного ремонту. Інформація нерозбірливо ділиться між віддаленими елементами системи, часто до тієї точки, коли майже вся важлива інформація стає глобальною або дублюється. Загальна структура системи, можливо, ніколи не була чітко визначена. Якби це було, воно, можливо, зірвало невпізнання. Програмісти з часткою архітектурної чутливості уникають цих трясовин. Тільки ті, хто не стурбований архітектурою, і, мабуть, задоволений інерцією щоденного клопоту пробивання отворів у цих невдалих дамбах, із задоволенням працюють над такими системами ...

Чому система стає ВЕЛИКОЮ БАЛОЮ ГРУЗІ? Іноді з КОДУ НАРОДЖЕННЯ виникають великі потворні системи . КОД «ТРОХУАЙД» - це швидкий і брудний код, який призначався для використання лише один раз, а потім відкидається. Однак такий код часто набуває власного життя, незважаючи на випадкові структури та погану або неіснуючу документацію. Це працює, так навіщо це виправляти? Коли виникає пов'язана проблема, найшвидшим способом її вирішення може бути доцільна зміна цього робочого коду, а не розробка належної загальної програми з нуля. З часом проста програма, що викидається, зароджує ВЕЛИКИЙ МОЛОК ГРУЗІ.

Навіть системи з чітко вираженою архітектурою схильні до структурної ерозії. Невпинна атака змін змін, які викликають будь-яка успішна система, може поступово підірвати її структуру. Колись охайні системи заростали, коли ПІЄМЕЙНИЙ РОСТ поступово дозволяє елементам системи розповсюджуватися безконтрольно.

Якщо таке розповсюдження продовжиться невдало, структура системи може настільки сильно поставити під загрозу, що від неї потрібно відмовитися. Як і в районі, що занепадає, виникає низхідна спіраль. Оскільки система стає все складніше і складніше для розуміння, обслуговування стає дорожчим і складнішим. Хороші програмісти відмовляються працювати там. Інвестори вилучають свій капітал. І все ж, як і для мікрорайонів, є способи уникнути і навіть змінити такий занепад. Як і будь-що інше у Всесвіті, протидія ентропічним силам вимагає вкладення енергії. Гентрифікація програмного забезпечення не є винятком. Спосіб затримки ентропії в програмному забезпеченні - це рефактор. Постійне зобов'язання щодо рефакторингу може запобігти заглибленню системи у ВЕЛИКУЮЧУ БУЛЬНУ МУЛ ...

• ... Один із найефективніших ворогів грязі - сонячне світло. Піддаючи зміщений код контрольній стрілці, можна встановити основу для його рефакторингу, ремонту та відновлення. Огляди коду - це один із механізмів, який можна використовувати для впливу коду на денне світло.