Есть ли названный анти-паттерн для исторически выросшего программного обеспечения? [закрыто]

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

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

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

Так что со временем обслуживание системы становится все сложнее и сложнее.

(Интересно, есть ли картинки для такого рода антишаблонов, чтобы сделать это более понятным никому не программистам - как автомобиль, который был построен, просто добавляя все больше и больше функций, не думая об общем дизайне. Как будто у кого-то есть необходимость буксировать трейлеры едут задом наперед, а затем инженер просто приваривает фаркоп к передней части автомобиля. Работа выполнена. Но теперь капот больше не открывается.)

Вы ссылаетесь на технический долг .

Мы все накапливаем техническую задолженность по продуктам, которые мы разрабатываем с течением времени; рефакторинг является одним из самых распространенных и эффективных способов сокращения этого технического долга, хотя многие компании никогда не погашают свой технический долг. Эти компании, как правило, находят свое программное обеспечение крайне нестабильным в течение многих лет, и технический долг становится настолько отвратительным, что вы не можете постепенно его погасить, потому что для его погашения потребуется слишком много времени.

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

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

Управление техническим долгом

Существует много способов управления техническим долгом, хотя, как и в случае реального долга, лучшим подходом является частое его погашение. К сожалению, как и в случае с реальными долгами, иногда целесообразнее накапливать больше за короткий период, когда, например, время выхода на рынок функции может удвоить или утроить ваш доход. Сложная задача - взвесить эти конкурирующие приоритеты, а также определить, когда рентабельность инвестиций в долг не стоит того или иного за данную функцию.

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

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

Ваше описание подходит к Большому мячу грязи Фута и Йодера :

За последние несколько лет ряд авторов ... представили шаблоны, которые характеризуют программные архитектуры высокого уровня ... В идеальном мире каждая система была бы примером одного или нескольких таких шаблонов высокого уровня. Тем не менее, это не так. Архитектура, которая на самом деле преобладает на практике, еще не обсуждалась: БОЛЬШОЙ МЯЧ .

БОЛЬШОЙ ГРЯЗЬ МУДА является хаотично структурированным, раскидистым, неряшливым, скотчем и подвешенным проводом, джунглями кода спагетти. Мы все их видели. Эти системы демонстрируют безошибочные признаки нерегулируемого роста и повторного, целесообразного восстановления. Информация беспорядочно распределяется между отдаленными элементами системы, часто до такой степени, что почти вся важная информация становится глобальной или дублируется. Общая структура системы, возможно, никогда не была четко определена. Если бы это было так, оно могло бы размываться до неузнаваемости. Программисты с легким архитектурным чувством избегают этих болот. Только те, кто не заботится об архитектуре и, возможно, знакомы с инерцией повседневной рутинной работы по исправлению дыр в этих провалах дамб, довольствуются работой на таких системах ...

Почему система становится большим шариком грязи? Иногда из THROWAWAY CODE появляются большие уродливые системы . THROWAWAY CODE - это быстрый и грязный код, который должен был использоваться только один раз, а затем отбрасываться. Тем не менее, такой код часто берет свою жизнь, несмотря на случайную структуру и плохую или несуществующую документацию. Это работает, так зачем это исправлять? Когда возникает связанная проблема, самым быстрым способом ее решения может быть целесообразное изменение этого рабочего кода, а не разработка правильной общей программы с нуля. Со временем простая одноразовая программа порождает БОЛЬШОЙ МЯЧ.

Даже системы с четко определенной архитектурой подвержены структурной эрозии. Непрекращающийся натиск меняющихся требований, которые привлекает любая успешная система, может постепенно подорвать ее структуру. Системы, которые когда-то были аккуратными, зарастают, поскольку рост PIECEMEAL постепенно позволяет элементам системы разрастаться неконтролируемым образом.

Если такое разрастание не ослабнет, структура системы может стать настолько опасной, что от нее придется отказаться. Как и в случае с разрушающейся окрестностью, возникает нисходящая спираль. Поскольку система становится все труднее и труднее для понимания, обслуживание становится более дорогим и более сложным. Хорошие программисты отказываются работать там. Инвесторы выводят свой капитал. И все же, как и в случае с окрестностями, существуют способы избежать и даже обратить вспять этот вид упадка. Как и во всем остальном во вселенной, противодействие энтропийным силам требует вложения энергии. Программное джентрификация не является исключением. Способ остановить энтропию в программном обеспечении состоит в ее рефакторинге. Постоянное стремление к рефакторингу может удержать систему от превращения в БОЛЬШОЙ ШАР ГРЯЗИ ...

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