Команда разработчиков, которая подходит к разработке программного обеспечения или настройке ИТ-инфраструктуры быстро и недорого, «покупает» эту экономию, принимая взамен технический долг. Технический долг относится к преднамеренной или непреднамеренной небрежности, ошибкам и слабым местам в коде. Последующие исправления и обслуживание снижают производительность и приводят к дополнительным дорогостоящим работам. Что нужно иметь в виду, если вы хотите избежать технической задолженности при разработке программного обеспечения?
Как появился термин «технический долг»?
В 1992 году программист и соавтор Манифеста гибкой разработки программного обеспечения Уорд Каннингем ввел метафору технического долга. Каннингем хотел дать понять, насколько важен для программного обеспечения рефакторинг, то есть регулярные исправления кода. Только так можно предотвратить появление все большего «долга» у программного обеспечения из-за растущих функциональных недостатков и структурных слабостей.
Термин «долг» также подразумевает процентные ставки, и технический долг особенно важен для компаний с финансовой точки зрения. Технический долг не только приводит к увеличению рабочей нагрузки и снижению производительности из-за последующего обслуживания, но и к увеличению расходов. Чем больше команда разработчиков пренебрегает обслуживанием несовершенной ИТ-инфраструктуры или приложений, тем больше процентов начисляется на задолженность и тем дороже становятся исправления кода.
Технический долг относится к преднамеренным или случайным ошибкам, недочетам и слабым местам в коде, которые накапливаются из-за неэффективной коммуникации, управления командой, квалификации или поспешного выпуска продуктов. Этот долг постоянно растет, пока не будет проведен рефакторинг.
Квадрант технического долга: четыре типа долга
По мнению Уорда Каннингема, технический долг возникает как следствие небрежного отношения к коду, которое приводит к более быстрым, но несовершенным решениям. Такие короткие пути разработки часто предпринимаются по соображениям экономии времени или бюджета. Тщательно подготовленный, безупречный код труден и требует много времени для создания. Поэтому при некоторых обстоятельствах разработчики предпочитают беспорядочный код, чтобы сэкономить время и силы. Но такая экономия влечет за собой долги.
Для Каннингема этот экономический аспект программирования является вполне нормальным. Если технический долг не погашается с помощью рефакторинга, а код не оптимизируется регулярно, разработка может застопориться или остановиться из-за метафорического интереса.
Марин Фаулер, автор книги «Рефакторинг: Improving the Design of Existing Code, развил метафору Каннингема и разделил долг кода на четыре типа — визуализированные в квадранте технического долга:
|
|
Безрассудный долг |
благоразумный долг |
|
Преднамеренный долг |
|
|
|
Случайная задолженность |
|
|
Согласно Каннингему и Фаулеру, технический долг может возникнуть как преднамеренно, так и случайно. Поскольку технологии и программирование подвержены постоянным изменениям и усовершенствованиям, избежать запаха кода и эрозии кода практически невозможно. Программное обеспечение также стареет и накапливает долг без обновлений и рефакторинга. В большинстве случаев, однако, технический долг обусловлен экономическими решениями или преднамеренными или непреднамеренными ошибками программирования.
Что вызывает технический долг?
Различные виды технической задолженности обычно имеют схожие последствия для разработки программного обеспечения, но их причины могут существенно различаться.
- Неадекватное управление качеством: Проекты выполняются без проверок качества, мониторинга и механизмов тестирования и накапливают текущую задолженность.
- Экономическое давление: экономические факторы и быстрое развитие ставятся во главу угла под давлением клиентов или из-за конкурентного давления, в то время как чистый код игнорируется.
- Недостаточная квалификация: Технические знания команды разработчиков не соответствуют требованиям элегантного, чистого кода. Следствием этого является запах кода или «спагетти-код».
- Недостаточная документация/коммуникация: Процесс разработки ведется без постоянного документирования расширений или изменений кода. Изменения кода также не регистрируются и не передаются последующим программистам. Возможности для рефакторинга ограничены или недоступны.
- Отложенный рефакторинг: Сознательно принятый технический долг не погашается своевременно, потому что рефакторинг игнорируется или откладывается.
- Параллельная разработка приложения: Одновременные этапы разработки, которые сочетаются и не координируются друг с другом, приводят к накоплению кодового долга.
- Слишком сложный код: Участки кода слишком сложны или не имеют смысла. Небольшие изменения могут привести к увеличению количества ошибок и множественных долгов. В худших случаях здесь также может возникнуть код-спагетти.
- Неструктурированные процессы разработки: Разработка приложения начинается до того, как определены и согласованы фактический дизайн или конкретные процессы.
- Аутсорсинг кода: Этапы разработки передаются на аутсорсинг, что приводит к ошибкам в коде при последующем объединении разделов. Руководство команды либо мирится с этими ошибками, либо не замечает их.
- Быстрые изменения по первому требованию: Быстрые изменения в коде не тестируются из-за нехватки времени.
Технический долг и гибкая разработка программного обеспечения
Уорд Каннингем не только определил метафору технического долга, но и был соавтором и одним из первых подписавших Манифест о гибкой разработке программного обеспечения. Эта философия разработки программного обеспечения направлена на содействие более продуктивной и гибкой разработке и выпуску приложений.
Вместо того чтобы привязываться к крупным проектам в течение длительных периодов времени, небольшие и более независимые команды выполняют более короткие этапы работы и быстрее выпускают небольшие проекты, такие как приложения, разделы программы и обновления.
Agile-разработка программного обеспечения приводит к тому, что команды пишут и изменяют небольшие участки кода и быстрее завершают рабочие этапы. Сосредоточившись на скорости и производительности, возрастает риск накопления неаккуратного кода и технического долга. Особенно когда гибкая разработка программного обеспечения ведется без постоянного рефакторинга, долги неизбежно растут.
Какие последствия имеет технический долг для разработки программного обеспечения?
Последствия технического долга во многом напоминают последствия кредитов в финансовой сфере. Если долги не погашаются регулярно и вовремя, на них начисляются проценты, что проявляется в замедлении разработки, снижении производительности и росте затрат.
Поэтому в интересах клиентов организовать обширное и долгосрочное управление качеством и мониторинг после разработки, чтобы избежать более быстрого и экономичного завершения и выпуска продуктов, а не дорогостоящих исправлений или тупика в развитии в более поздние сроки.
Как можно предотвратить технический долг?
Технический долг не может быть полностью устранен из-за новых технологий и меняющихся подходов в разработке программного обеспечения. Чтобы выпускать программы и приложения регулярно и быстро, а также чтобы команды не были привязаны к проектам на длительный срок, технический долг даже сознательно принимается. Но существуют превентивные меры, позволяющие избежать или уменьшить возникновение или накопление задолженности:
- Внедрение стандартизированных процессов рефакторинга и управления качеством
- использование постоянно обновляемых инструментов для измерения и анализа ошибок
- Продвижение технических знаний путем постоянного обучения, следования в ногу с развитием ИТ, а также формирование команд в соответствии с квалификацией
- Аккуратная организация кода с использованием разбиения на классы и четких методов, а также написание кода в манере, понятной для новых или внешних программистов
- Четкое определение обязанностей и функций внутри команд для предотвращения дублирования, избыточности и непродуктивных рабочих шагов
- поддержание ИТ-архитектуры в актуальном состоянии путем постоянного мониторинга, измерения и обеспечения качества.