Привет, Хабр! Я Антон Коваль — системный архитектор в Smartup. Технический долг есть в любом крупном проекте. Он возникает, когда копятся компромиссные решения, проблемы в коде или архитектуре. Важно, что эти решения и проблемы усложняют и удорожают поддержку и обновление кода в будущем. Это своеобразные «проценты». Чем больше долг, тем больше «процентов» приходится платить.
В статье поделюсь опытом работы с техдолгом. Сначала определим, что это, затем подумаем, как решать. Пишите в комментариях свой опыт — подискутируем.
Примеры техдолга
Команда не пишет юнит тесты. От этого в коде появляется все больше ошибок, что увеличивает время разработки нового функционала. Отсутствие юнит-тестов — это техдолг. Все хорошие программисты знают, что юнит-тесты должны писаться всегда, это неотъемлемая часть кода. Можно считать, что без тестов фича не сделана.
Сейчас команда решает сделать упрощенную архитектуру, а нюансы и улучшения «сделают потом». Однако «потом» так и не наступает, и компромиссная архитектура приводит к проблемам с развитием проекта.
Еще один пример — отсутствие документации. Очевидно, что без нее доработка и поддержка становятся очень сложными. Особенно, когда на проект приходят новые люди.
Причины технического долга
Ошибки управления проектом.
Очень сжатые сроки приводят к компромиссам. А когда такой метод управления становится постоянным, у команды нет времени сделать необходимые изменения. Также нехватка времени возникает, когда оценка проекта/фичи сильно занижена. Также я встречал нежелание исправлять техдолг на уровне управления. Например, команда хочет упразднить техдолг, но управляющие не желают тратить на это время (либо команда не может обосновать необходимость). Иногда сложно объяснить бизнесу, что надо потратить пару недель, чтобы привести все в порядок, так как за это время они не получат новых фич.Низкая культура программирования, нехватка знаний и опыта у команды.
Техдолг накапливается даже тогда, когда все хорошо, никто не стоит с пистолетом за спиной. Если команда не контролирует стиль и качество кода, применение современных практик разработки (тесты, документация, рефакторинг, continuous integration), то со временем накопится огромный багаж техдолга.
Каким бывает техдолг
Я бы разделял техдолг по приоритетам. Что быстрее и больнее начнет отражаться на скорости разработки, на качестве приложения, что менее важно. Так проблемы в архитектуре выглядят важнее и опаснее, чем отсутствие юнит тестов.
Техдолг ничем не отличается от фич или багов. Их можно и нужно оценивать и держать на доске наравне с обычными задачами. Только так можно отслеживать накопление или уменьшение долга.
Техдолг проявляется в коде отсутствием тестов и документации. Он копится, когда не проводится регулярный рефакторинг. Много TODOшек, FIXMEшек в коде тоже могут сигнализировать о техдолге.
Как уменьшить технический долг
Самый действенный способ уменьшить техдолг — не допускать его. Нельзя начинать проект со строчки кода и первого класса. Первым делом нужно принять стандарты и стиль кодинга, интегрировать инструменты, которые будут измерять качество кода, покрыть код тестами, создать структуру документации. Если сделать это заранее, долг будет накапливаться медленнее.
От техдолга нужно постепенно избавляться. Регулярно добавлять связанные с этим задачи в разработку, обосновывать и защищать перед заказчиком необходимость таких изменений. Если техдолг есть сейчас, в будущем нельзя допустить подобной проблемы. Окей, у нас есть классы, не покрытые тестами. Значит все новые классы и методы нужно ими покрыть. В этом случае техдолг по тестам точно не будет расти.
Как объяснить бизнесу, что с техдолгом нужно работать
Техдолг страшен «процентами». Проблемы и компромиссы в архитектуре приводят к неработоспособности приложения. А плохое качество кода — причина долгой разработки, кучи ошибок. Все это можно объяснить, а самое главное — показать. Хотите продемонстрировать страдающее качество кода, представьте бизнесу сколько багов находят клиенты. Покажите отчет, отражающий, как падает производительность команды, насколько меньше делаете фич по сравнению с более ранним периодом. Из-за техдолга релизы происходят гораздо реже, а хочется, чтобы каждые пару недель.
Оцените баги, которые возникают из-за большого технического долга. Благодаря этому, можно оценить в днях работу, которая вызвана недоработками и плохой реализацией. Если технической долг есть на уровне архитектуры, можно замерить максимальную нагрузку, которую выдержит приложение. Эта цифра наглядно покажет заказчику, что можно выжать из текущего приложения. Если бизнесу нужно больше пользователей, потребуются вложения. Предложите делать новые фичи, параллельно решая задачи из техдолга.
Комментарии (5)
dbalabolin
15.03.2024 16:45Если кодер не пишет комменты то это его лень, а вовсе не необходимость ускорить процесс
А вот тухлая архитектура это тоже не тех долг. Чаще она не потому такая, что не проработали. А без реального запуска было не понятно.
И часто ничего потом улучшать не надо. Проект умер или ему и так норм. Но если проект жив, то у него будет ресурс на переделку.
dsv180
15.03.2024 16:45Сейчас команда решает сделать упрощенную архитектуру, а нюансы и улучшения «сделают потом»
Это сознательный обман Заказчика вызванный сознательным/не сознательным желанием качать с него деньги.
Еще один пример — отсутствие документации. Очевидно, что без нее доработка и поддержка становятся очень сложными.
Это технология "писать на коленке", каком бы в коллективе любого размера и проэкте любой сложности она не применялась. Суть IT разработчики не желают работать в строгом соответствии к требованиям производственного процесса.
Я бы разделял техдолг по приоритетам. Что быстрее и больнее начнет отражаться:
на скорости разработки
на качестве приложения, что менее важно.
Я специально отформатировал цитату чтобы яснее стали понятны Ваши приоритеты - "качество не важно, лишь бы сдать заказчику". А потом Вы начнете качать из заказчика деньги. В подтверждение этого своего вывода я приведу еще одну Вашу же цитату:
Регулярно добавлять связанные с этим задачи в разработку, обосновывать и защищать перед заказчиком необходимость таких изменений.
Другими словами, вначале мы сознательно закладываем "упрощенную архитектуру", а когда заказчик начинает понимать, что проект "ходит по граблям" начинаем ему объяснять, что устранение этих граблей это серьезная работа, которая делается за отдельные (серьезные) деньги.
Хотите продемонстрировать страдающее качество кода, представьте бизнесу сколько багов находят клиенты.
А причем тут прикладной бизнес, если это Вы заложили эту кучу багов, которые находят клиенты прикладного бизнеса и от которых страдает не Ваше, а его лицо?
Вначале вы портите своему клиенту репутацию, а потом объясняете что за исправление ее появления, надо отдельно заплатить.Если технической долг есть на уровне архитектуры, можно замерить максимальную нагрузку, которую выдержит приложение. Эта цифра наглядно покажет заказчику, что можно выжать из текущего приложения. Если бизнесу нужно больше пользователей, потребуются вложения.
Собственно еще раз Вы демонстрируете, что не создаете инструмент для который решает его задачи. А все строго наоборот Вы создаете инструмент для решения своей задачи - доить заказчика.
Как написал предыдущий комментатор: Техдолг это несделанная работа.
Я продолжу его мысль, несделанная работа за которую получены деньги. что в свою очередь означает оказание услуг не надлежащего качества и теоретически уголовно наказуемо.
P.S. И не надо писать про сложность и трудоемкость процесса разработки ПО и сложности общения с Заказчиком.
Просто представляйте, что вам в автосалоне продадут автомобиль с таки же техническим долгом, какой вы своим заказчикам оставляете. И да, работать с этим техдолгом, будут строго по принципам описанным в Вашей статье.
IgorIlyin
15.03.2024 16:45С такими критериямии, весь наш текущий проект - это развитие и наращивание техдолга. Но величина его роста ограничена, например сейчас куски написанные на COM+ уходят, и списываются все связанные с ними долги.
dae-fromru
15.03.2024 16:45Это вы только вершину айсберга поскребли, а техдолг может и с другой стороны расти, не только со стороны неопытности руководителей или исполнителей.
-
Ошибки управления проектом
Слабое владение или отсутствие владения тех. деталями со стороны руководителей приводит к неверной оценке трудозатрат, что выливается в "сжатые сроки"
Те же "сжатые сроки" получаются, когда руководители пытаются откусить кусок больше, чем могут проглотить. Списывать только на неопытность? Этим и люди с большим стажем страдают в первую очередь из-за оторванности от коллектива.
Неумение переложить требования бизнеса на язык заказчика - классика, всегда и везде. Это экономия на сотрудниках (аналитиках), которая приводит к тех. долгу. С одной стороны сиюминутные затраты меньше, с другой стороны отложенные затраты больше.
Попытки воспитать "универсальных солдат" в компании приводят к размыванию ответственности, и в итоге даёт ситуацию, когда вроде бы все всё умеют, но никто ни за что не отвечает.
-
Тех. культура, опыт и т.п.
Недостаток - конечно приводит к тех. долгу. Пока люди учатся, пока они набьют шишки в поле с граблями - долг неизбежно растёт. Контролировать можно только установлением стандартов в компании, или, хотя бы, в отделе.
Никакие тесты не спасут от техдолга. Более того, избыток тестов сам по себе начинает создавать техдолг, т.к. зачастую тесты представляют собой код более низкого качества, чем то, что они проверяют. Этим страдают абсолютно все, даже бигтехи на Западе. Только стандарты и только кросс ревью, но это замедляет процесс разработки, и если руководство не согласно на увеличение сроков... ну вы сами понимаете.
Архитектура - основной источник техдолга. Не код, а именно архитектура. Код может быть идеален, вылизан, покрыт тестами в хвост и в гриву, но если архитектура система убогая, то никакой код не спасёт. Неизбежно будут нагорожены костыли со всеми вытекающими.
Переусложенние (overengineering) - ещё один массовый источник техдолга. Многие любят велосипеды изобретать, и на определённом этапе это даже хорошо, для научения, но плохо для перспективы. Этим даже многие т.н. сеньоры грешат.
Это тоже далеко не исчерпывающий список.
Самый действенный способ уменьшить техдолг — не допускать его.
Совсем не допускать не получится, только если вы не вселенский гений, который ещё до начала работы над проектом видит все итоги реализации, внедрения, и поддержки. Техдолг неизбежен, именно поэтому существует отладка, тестирование, рефакторинг и т.п. Работа над проектом включает в себя работу с техдолгом. Это только hello world можно написать с ходу без "долгов", а что-то посложнее - не выйдет. Не допускать здесь это видеть, контролировать, не давать расти, и даже уменьшать. Техдолг это двигатель качества пока у вас нет 20+ лет разнообразнейшего опыта.
А бизнесу надо просто показывать план. Вот сейчас так, вы хотите это, значит займёт столько-то, потому что изначально не предусматривалось и т.п. Тут нечего добавить.
-
dbalabolin
Как это вдруг не отлаженный код стал тех долгом? Это просто работа не сделана и не более того.