Клаудио Пинкус, соучредитель CodeStream, Inc.
Почему вы должны что-то делать с техническим долгом
Каждая растущая кодовая база в каждой отрасли накапливает технический долг. Последствия чрезмерного технического долга - низкая производительность, высокий уровень ошибок, задержки с доставкой обновлений, более высокие затраты, перегруженность разработчиков и менее довольные клиенты.
Поскольку технический долг неизбежен, как смерть и налоги, вопрос в том, как наилучшим образом управлять его накоплением и сокращением и как удерживать его на приемлемом уровне, который не приведет к плохим результатам для бизнеса.
Так что же такое технический долг?
Прежде чем искать решения, что именно мы пытаемся решить? Существует несколько определений технического долга, и здесь я цитирую три:
- Из Википедии: Технический долг - это концепция, которая отражает подразумеваемую стоимость дополнительных доработок, вызванных выбором простого решения сейчас, вместо использования лучшего подхода, который потребовал бы больше времени.
- От Atlassian: Технический долг - это разница между тем, что было обещано, и тем, что было фактически выполнено.
- Из Thinkapps (образно): это грязная посуда, оставшаяся в раковине, когда вы продолжаете готовить в течение 10 дней, не убирая, до тех пор, пока не перестанете готовить вообще.
Мне особенно нравится метафора кухни, поскольку все в организации, а не только разработчики, сразу понимают проблему и последствия бездействия.
Солнечный свет - лучшее дезинфицирующее средство
Эрик Дитрих пишет в блоге NDepend, что единственное, что каждая компания может легко сделать для сокращения технического долга, - это измерить его.
«Вообще говоря, - говорит Дитрих, - сосредоточение внимания на чем-то само по себе может изменить то, на что вы смотрите. Мы могли бы заимствовать физику и думать об этом как об «эффекте наблюдателя». … Если вы хотите улучшить что-то с какой-либо эффективностью, вы должны сначала начать измерять это, чтобы иметь ориентир. Таким образом, освещение чего-либо представляет собой возможную стратегию улучшения как таковую, а также является первым шагом вперед по сравнению с другими вмешательствами. По этой причине я считаю измерение «нулевым шагом».
Поэтому важно измерить его, чтобы позже вы могли сказать, становится ли оно лучше или хуже. Возможно, вам удастся пробежать некоторое время, но метрики - лучшая отправная точка.
Существуют разные подходы к измерению технического долга. Хороший подход предлагает Патроклос Папапетроу в его посте Как рассчитать технический долг и четко его выразить, но суть в том, что вам нужно знать количество усилий, необходимых для погашения долга, по отношению к общему количеству усилий. вложили в создание кода. И человеко-дни, и показатели соотношения должны использоваться командами управления и разработки при определении своей стратегии сокращения технического долга, потому что каждый из них отвечает на свой, но не менее важный вопрос, - говорит Папапетру. Для человеко-дней вопрос в том, какие усилия требуются?, а для соотношения это насколько хорошо или плохо качество кода?
Возможно, у вас возникнет соблазн изменить свои процессы, изменить свою культуру, подробно рассказать о важности технического долга, привлечь экспертов, но я предлагаю три простых шага, которые радикально уменьшат технический долг после нулевого шага.
Шаг первый: не добавляйте ненужную работу
Вот первое, что нужно иметь в виду, чтобы уменьшить долг. Не зацикливайтесь на инструментах и методах, которые, вероятно, не помогут изменить рабочие привычки. Посмотрите, как работают люди, и подумайте, как можно вводить простые, не вызывающие споров шаги, которые внесут большую ясность. В частности, полагайтесь на лучшее взаимодействие внутри кода, который является вторым лучшим дезинфицирующим средством. Документирование кода должно быть естественным побочным продуктом общения, которое уже должно происходить между членами команды. Думайте об этом как о том, что вы находитесь в аэропорту и обращаете внимание на то, что вас окружает: если вы что-то видите, скажите что-нибудь!
Шаг второй: уменьшите шум
Разработчикам нужно время, чтобы сосредоточиться на написании кода. Но как физическая, так и виртуальная среда стали более шумными и требовательными к нашему немедленному вниманию. Такие инструменты, как Slack и Hipchat, полезны и могут помочь решить определенные проблемы быстро и безболезненно, но они также часто используются для самых разных тривиальных вещей, которые нарушают вашу концентрацию. В частности, эти инструменты просто не предназначены для совместной работы над кодом. Так что, если вы хотите уменьшить технический долг, перестаньте обращать внимание на шумные сообщения в ленте Slack или Hipchat. Отключите все эти действия и сконцентрируйтесь на написании хорошего кода и общении о коде со своей командой разработчиков, используя решения, которые практически не содержат шума.
Шаг третий: слишком много говорите о правильных вещах
Ваша команда разработчиков, вероятно, собирается по понедельникам и решает, что будет сделано на этой неделе. Затем все приступают к выполнению своих заданий, а когда наступает пятница, команда собирается и проверяет, что было сделано. У вас, вероятно, были вопросы и комментарии по пути, к которому вы могли бы обратиться, но у кого есть время, чтобы вырезать и вставлять фрагменты кода, объяснять файл, версию, номер строки, находить подходящего человека, с которым можно поделиться этой информацией, и так далее, чтобы Задайте вопрос? Если вы хотите уменьшить технический долг, вы должны найти способ сообщить в нужное время о любой неясности в коде и о любых подходах, которые вы обнаружите, потребуют доработки. Если вы сегодня попытаетесь уложиться в крайний срок, сообщите об этом команде, используя самый простой и эффективный метод, но не откладывайте его на потом. Вы и ваша команда захотите вернуться к этому долгу, когда придет время следить за тем, чтобы посуда не вылилась из раковины, и лучше всего предупредить всех в самом коде, пока концепции еще свежи.
Найдите решения, которые позволят вам сосредоточиться на самом коде, не переключать контекст и не отвлекаться на последний обеденный снимок.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
Https://en.wikipedia.org/wiki/Technical_debt
Http://thinkapps.com/blog/development/technical-debt-definition-importance/
Http://thinkapps.com/blog/development/technical-debt-calculation/
Https://www.atlassian.com/agile/software-development/technical-debt
Https://blog.ndepend.com/the-one-thing-every-company-can-do-to-reduce-technical-debt/
