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