«Технический долг» — это термин, который мы постоянно используем в индустрии разработки программного обеспечения. Вы также можете услышать, что это называется «кодовым долгом» или сокращенным и более броским «техническим долгом». Как бы вы это ни называли, это часть нашей повседневной жизни.
Несмотря на частотность, то, что мы имеем в виду, когда говорим «технический долг», в некоторых случаях выходит за рамки исходной метафоры. Это неплохо. Первоначальное определение чрезвычайно полезно, и мы не собираемся открывать еще одну дискуссию о том, подходит ли оно.
Однако мы считаем важным, чтобы инженеры, программисты, заинтересованные лица и все, кто участвует в процессе разработки, имели общее понимание этого термина. Вот почему мы хотим расширить определение, чтобы охватить все аспекты того, что мы подразумеваем под «техническим долгом». Затем мы можем применить правильную тактику для эффективного управления им для уникальных бизнес-потребностей, даже если мы рискуем, что более широкое определение чрезмерно расширит исходную метафору технического долга.
Мы собираемся предложить простое, но (на наш взгляд) полное определение технического долга, с которым мы работали в Stepsize. Мы помогаем быстрорастущим компаниям-разработчикам программного обеспечения с измерением и управлением техническим долгом, поэтому мы обнаружили, что нам нужна более конкретная методология технического долга, которая включает в себя то, на какие показатели мы обращаем внимание и как мы их измеряем.
Распаковка этого определения технического долга
Технический долг — это код, написанный вчера, который сегодня является бременем.
На первый взгляд может показаться, что код становится техническим долгом в тот момент, когда он запущен в производство, как будто все в вашей кодовой базе является техническим долгом.
Это потому что так оно и есть.
Роль неопределенности и перемен
Код, который инженеры или программисты пишут для решения проблемы, основан на их текущем понимании этой проблемы. Звучит очевидно, но имеет глубокие последствия. Даже если идеальные инженеры найдут идеальное решение проблемы и отлично его закодируют, их понимание проблемы будет развиваться — и быстро.
Но оставленный без присмотра их код не будет.
Это плохо. Вся эта тяжелая работа может легко превратиться в плохой код уже через несколько коротких дней. Их код больше не подходит. Его функциональность была скомпрометирована каким-то образом. Как и финансовый долг, этот тип долга возникает постоянно, особенно с устаревшим кодом. Кроме того, это происходит намного быстрее, чем вы думаете, в быстрорастущей среде.
В своей книге «Стоит ли высококачественное программное обеспечение своей стоимости?» Мартин Фаулер объясняет, что «программное обеспечение существует в мире неопределенности». ваших пользователей как можно скорее. И если они запросят новую функцию, которую вы не ожидали, это может вызвать неудобные вопросы обо всей структуре, которую вы использовали для решения проблемы, которую, как вы думали, вы решаете.
Иногда вы можете просто почистить и переработать или применить магию рефакторинга, чтобы соответствовать вашему новому пониманию проблемы. Но такие краткосрочные решения заставляют ваш код накапливать мусор. Это только увеличивает ваш технический долг.
Технический долг тормозит всю инженерную команду
Разработчики обнаруживают, что низкокачественный код значительно замедляет их работу уже через несколько недель.
Стоит ли высококачественное программное обеспечение своих денег?, Мартин Фаулер
Вот почему для быстрорастущих организаций важно иметь план управления техническим долгом.
Мартин Фаулер утверждает, что стоит инвестировать в качество кода, поскольку это ускорит разработку новых функций. Если новое понимание рассматриваемой проблемы значительно изменилось, нам необходимо принять меры, иначе остальным программистам в команде разработчиков будет трудно понять наш код, и производительность пострадает. В этом смысле, если код, который мы написали вчера, не поддерживается должным образом или выброшен, он неизбежно станет техническим долгом и замедлит работу всей команды.
Однако не все технологические долги находятся на одной и той же стадии погашения, и именно здесь вступает в игру вторая половина нашего определения.
Никто не может предсказать будущее
Какой бы невероятной ни была наша команда разработчиков, никто не может точно предсказать будущее. Это верно для стартапов, малого и среднего бизнеса и особенно верно для быстрорастущей среды. Вот почему мы заменили метод водопада на Agile-разработку; программное обеспечение не строится как соборы.
Часто бывает так, что на программирование проекта может уйти год, прежде чем вы поймете, каким должен быть наилучший подход к проектированию.
Квадрант технического долга, Мартин Фаулер
Но лучшие в своем деле знают, как справляться с такой высокой степенью неопределенности. Они используют модульные тесты, когда это уместно, постоянно рефакторят код, в котором накопилось слишком много хлама, и не принимают плохой код как технический долг. Вот бесплатное расширение VSCode, которое поможет вам сделать все это прямо в вашем редакторе.
Часто очень реальные ограничения, с которыми мы сталкиваемся — сроки проекта, бюджетные ограничения и многое другое — означают, что мы можем позволить себе выплатить только самый неотложный технический долг, который мешает нашим самым непосредственным и предсказуемым целям — код, который является бременем. сегодня. Именно это побудило нас написать о том, как перестать тратить время разработчиков на технический долг.
Забрать
В таких неопределенных условиях единственный технический долг, с которым мы действительно можем что-то сделать, — это тот, который мешает достижению наших самых непосредственных и предсказуемых целей.
Учитывая наше более широкое определение технического долга, единственное реальное решение состоит в том, чтобы постоянно решать наиболее неотложные технические долги, поскольку мы продолжаем своевременно предоставлять новые функции для наших клиентов. Это технический долг, который, как мы точно знаем, замедлит нас сегодня или скоро.
Различение различных типов технического долга — особенно безрассудного и предусмотрительного — является еще одним важным фактором успешного выполнения этой задачи. У нас есть статья в работе на эту тему, так что следите за обновлениями! Я хотел бы прочитать ваши мысли об этом определении. У вас есть другой, которым вы пользуетесь? Дайте мне знать в комментариях!
