- PVSM.RU - https://www.pvsm.ru -
Каждому разработчику знакома ситуация, когда реализация новой возможности в системе занимает большое количество времени, но релиз уже близко, а тимлид или менеджер проекта пятый раз за день задают уже надоевший вопрос: “Ну когда будет готово?”. И тогда встает непростой выбор — сделать все правильно и не уложиться в сроки релиза или реализовать минимально работающий, но не идеальный с точки зрения технического решения, функционал. Очевидно, что в большинстве случаев будет выбран второй вариант, так как релиз и предоставление результата клиентам здесь и сейчас важнее чистоты кода и архитектуры системы. Но проходит несколько месяцев, и вот уже старое не идеальное техническое решение мешает реализации другого функционала. И дальше такие решения будут накапливаться в огромный ком. Разбираясь с этой проблемой, очень важно сделать правильные выводы и выбрать нужное решение. От этого решения будет зависеть дальнейшая судьба всего проекта. В данной статье мы постараемся разобраться с природой технического долга и посоветовать пути его устранения.
Само понятие технического долга впервые ввел Уорд Каннингем (Ward Cunningham [1]), разработчик технологии wiki [2] и один из создателей экстремального программирования [3]. В 1992 г. в своей статье [4] он сформулировал это понятие в виде метафоры финансового долга: так же, как и при финансовом займе, разработчики могут получить дополнительные средства здесь и сейчас за счет использования быстрых и не оптимальных технических решений, но неизбежно будут расплачиваться за них при дальнейшей разработке, в независимости от того, как будет выплачен этот долг — постепенными выплатами процентов или одним платежом.
Но если проблема технического долга была описана еще 25 лет назад и встречается практически на любом проекте, почему еще нет методики управления проектами, которая позволяла бы избежать само появление технического долга? Ответ кроется в самом понятии проекта. Одним из ключевых отличий проекта от других видов деятельности является уникальность конечного продукта. Там где уникальность, там и непредсказуемость, и именно она порождает изменения на проекте и вносит трудности в первоначальное проектирование системы.
Конечно, можно попытаться построить архитектуру, предусматривая возможные изменения, но здесь команда столкнется с таким понятием как “кошелёк Миллера [5]”: правилом, при котором в кратковременную память человека можно «положить» одновременно не более девяти «монет». А если количество элементов превышает это значение, то
Можно попытаться делить компоненты на более мелкие, чтобы уложиться в этот “кошелек”, но сложности от этого меньше не станет, да и количество абстракций при таком подходе будет расти с катастрофической скоростью. А как известно, любую проблему можно решить путём введения дополнительного уровня абстракции, кроме проблемы слишком большого количества уровней абстракции.
Другие команды предпочитают вообще отказываться от первоначального проектирования, максимально стараясь использовать по ходу разработки универсальные инструменты. С одной стороны, это проще, чем пытаться предсказывать изменения и на первых этапах система будет получаться достаточно гибкой к изменениям. Но со временем, сложность системы, согласно второму правилу Лемана [7], неизбежно будет расти, она станет менее гибкой, и могут возникнуть изменения, идущие вразрез с текущей архитектурой. В этом случае разработчики будут также тратить больше времени на решение архитектурных проблем.
Так или иначе, неизбежность изменений на проекте провоцирует появление технического долга.
Важнейшим показателем того, что на проекте есть проблема с техническим долгом, это, конечно же, сам код. Прежде всего, стоит сказать об особенности написания кода. Дело в том, что написание и чтение кода — два совершенно разных процесса. Когда разработчик пишет код, он сосредоточен лишь на контексте задачи. Но изменение отдельного участка кода влияет на общую картину происходящего. В свою очередь, прежде чем изменять написанный код, нужно иметь представление не только о конкретном участке, но и обо всей картине в целом. Но при чтении, границы контекстов, в рамках которых был написан код, стираются на общем представлении. Такая разница между чтением и написанием кода генерирует дополнительную сложность, которая прямым образом влияет на его качество.
На что следует обратить внимание:
Проблема технического долга весьма актуальна на данный момент, и для каждого проекта требуется индивидуальный подход к проблеме его устранения.
Не стоит бояться выплат, ведь если принять правильную стратегию, то технический долг станет той силой, которая будет заставлять развиваться ваш проект. Именно работа с техническим долгом показывает уровень зрелости как самого проекта, так и команды, которая над ним трудится.
Автор: SSul
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/278818
Ссылки в тексте:
[1] Ward Cunningham: https://en.wikipedia.org/wiki/Ward_Cunningham
[2] wiki: https://en.wikipedia.org/wiki/Wiki
[3] экстремального программирования: https://en.wikipedia.org/wiki/Extreme_programming
[4] статье: http://c2.com/doc/oopsla92.html
[5] кошелёк Миллера: https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D1%87%D0%B8%D1%81%D0%BB%D0%BE_%D1%81%D0%B5%D0%BC%D1%8C_%D0%BF%D0%BB%D1%8E%D1%81-%D0%BC%D0%B8%D0%BD%D1%83%D1%81_%D0%B4%D0%B2%D0%B0
[6] мозг: http://www.braintools.ru
[7] второму правилу Лемана: https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD%D1%8B_%D0%9B%D0%B5%D0%BC%D0%B0%D0%BD%D0%B0
[8] Agile: http://agilemanifesto.org/
[9] Источник: https://habr.com/post/353810/?utm_source=habrahabr&utm_medium=rss&utm_campaign=353810
Нажмите здесь для печати.