Перевод статьи «Coping up with technical debts as a developer!».
В первой части мы разбирались, что такое технический долг; почитать об этом можно здесь.
Большинство сценариев этой статьи относятся к фронтенд-разработке, но их вполне можно применять в разработке в целом.
Для начала, давайте разберемся с болезнью «если не сломано – не трожь»
Парадигма «не сломано – не трожь» сама по себе проблемой не является. Но она становится таковой, когда ею оправдывают все неправильные вещи, повсеместно встречающиеся в программе.
Например, жертвой этой заразы на раннем этапе своего существования чуть не стал Instagram. Когда в октябре 2010 года было запущено приложение для iPhone, оно работало на одном сервере в Лос-Анджелесе. Работало оно долгое время, а значит, все это время «сломанным» не считалось. Но после того, как резко возросший трафик чуть не сломал сервер, Instagram за три дня перешел на базу данных, размещенную на EC2. Соучредитель Майк Кригер сравнил этот переход с операцией на открытом сердце. Теперь в том, что касается технического долга, Майк старается действовать на опережение, чтобы подобные долги не привели к катастрофическим последствиям.
Понимание вида долга сведение его к чисто техническому
Это как со стаканом с водой. Кому-то он наполовину полный, кому-то – наполовину пустой. Кто-то может даже расширить видение и сказать, что он в любом случае полон, просто одна половина наполнена воздухом. Но никакая из этих точек зрения не является полезной, пока не ясно, какой для нас смысл в этом стакане.
Продуктовая команда может никогда не почувствовать необходимости в обслуживании технического долга. Если достаточное количество пользователей могут использовать систему, то в чем вообще проблема? Если система способна преобразиться из сайта по поиску книг в e-commerce сайт, то где же долг? Если после каждого релиза финансовые цели достигаются, значит, и с технической частью все в порядке, верно? Поэтому вопросы вроде случая со стаканом или наличием технического долга не имеют однозначных ответов.
Если мы рассмотрим систему более детально, в различных ее частях техническая задолженность может быть, а может и не быть. Кроме того, как мы разбирали в предыдущей статье, долги сами по себе тоже бывают разные. Например, беспорядок в коде это вообще не долг, а убытки. И существует много подходов к разработке, которые помогут с этим справиться. Следование выработанным в команде правилам, использование линтера, ревью кода, ревью дизайна и прочие практики помогут укротить беспорядок в коде. Никто не принимает осознанного решения насвинячить, это всегда результат лени и непрофессионализма, и это нельзя «выплатить» в будущем. Беспорядок это всегда потери.
Чтобы провести различие между беспорядком в кое и техническим долгом, я всегда пользуюсь одним простым определением. Беспорядок это результат лени и непрофессиоализма или же недостатка желания сделать так, чтобы код выглядел правильно. А вот технический долг это результат компромиссов в инженерии, на которые часто приходится идти разработчикам и собственникам бизнеса, чтобы укладываться в графики и оправдывать ожидания пользователей. Вы решаете «взять в долг» совершенно сознательно, под давлением ограничений проекта. Это рискованно, однако может принести выгоду.
To-do список для разработчиков
Некоторые команды разработчиков оказываются жертвами того, что бизнес дает высший приоритет новому функционалу, а не улучшению кодовой базы, при этом разработчики несут полную ответственность за баги, сломанный код и последствия технического долга. Команда разработчиков в таких условиях просто не может поступать правильно, хотя четкая коммуникация с владельцами бизнеса определенно может помочь. Ниже представлен список вещей, которые под силу сделать разработчику.
Жизненный выбор в разработке
Разработчики постоянно заняты добавлением нового функционала в программное обеспечение. При этом у них есть два варианта на выбор.
Более простой путь – беспорядочный код или дизайн, зато более быстрое продвижение. Путь посложнее – чистый код и хороший дизайн, занимающие намного больше времени.
Выбирать следует так, чтобы конечный результат был как в случае с более сложным путем. Можно выбрать более простой путь сейчас, но при этом обязательно запланировать работу над техническим долгом – и таким образом все же сделать этот путь более сложным.
Использование показателей для определения технического долга
Показатели это отличный способ сделать нечто субъективное и абстрактное более объективным и осязаемым. Это также позволяет вам ставить какие-то измеряемые цели в плане улучшений. Цикломатическая сложность, покрытие кода, непрерывная интеграция, стоимость отсрочки, количество багов и т. п. Убедитесь, что вы организовали все так, чтобы иметь возможность измерять какие-то вещи и анализировать их с течением времени.
Проактивное поднятие красного флага
Ниже изложены некоторые тревожные сигналы, предупреждающие о том, что проект имеет технический долг. Разработчики должны уметь распознавать их.
- Код имеет «душок», который скорее влияет на производительность, чем приводит к сбоям.
- Повышенная сложность – когда технологии перекрывают друг друга.
- Баги в продукте, которые могут послужить причиной сбоя всей системы.
- Проблемы со стилем кода.
Обнаружив нечто подобное, стоит поднять красный флаг: объявить о «банкротстве» кода и начать планировать выход из создавшейся ситуации.
Не все можно сделать сразу. При необходимости оставляйте в самом коде комментарии TODO или FIXME. Откройте соответствующий тикет в системе, чтобы иметь возможность отследить его в будущем. Добавьте необходимость этих работ в бэклог продукта.
Что касается стиля кода, помочь может создание руководства, которого будут придерживаться все члены команды.
Реактивное привлечение внимания к долгу и вынесение его в качестве темы для обсуждений
Бывает, что сразу проблему и не заметишь, но со временем становится понятно, что есть и лучший способ что-то сделать. И тогда осознаешь, что долг все-таки есть. В подобном случае разработчик должен объявить о конечной дате поддержки этой части ПО. Будет лучше обсудить это с командой и предложить решение, которое поможет вам в будущем.
Для команды одной из самых главных вещей в управлении техническим долгом является, прежде всего, знание о самом существовании долга с последующим уведомлением об этом собственников продукта.
Технический менеджмент должен решить, как донести до не-технических менеджеров информацию о том, во что обходится существование технического долга. Руководитель также должен объяснить важность скорейшего возврата подобных долгов.
Непрерывное документирование
Всегда полагайтесь на документацию и используйте ее повсеместно. Как говорится, «то, что не задокументировали, не делалось». Начните с малого, скажем, с документирования каких-то функций. Отсутствие документации совершенно не помогает в дальнейших работах над проектом. Хороший разработчик всегда документирует все, что может, и делает это даже не для других, а для себя.
Особенности реализации
Что касается управления техническим долгом в ходе разработки, есть три варианта действий.
- Полностью отказаться от выполнения новых требований. То есть, поставить в известность не-технарей о том, что организация может не рассчитывать на выполнение требований и продолжать жить с системой в том виде, в каком она есть. В противном случае понадобятся рефакторинг или полная замена приложения.
- Провести рефакторинг приложения. Эта опция предназначена для уменьшения сложности, удаления дубликатов и улучшения структуры кода. Рефакторинг это единственный способ улучшить внутреннюю структуру кода без изменения поведения программы.
- Заменить приложение. Хотя это и приведет к появлению новых технических долгов, идея состоит в том, чтобы быстро свести их к минимуму. В большинстве случаев подобные решения принимаются не разработчиками.
Подходы к отслеживанию технического долга
Поскольку технические долги могут тянуться в течение нескольких циклов разработки, важно отслеживать их состояние. Для этого можно делать следующее:
- Вести список технических долгов (все случаи, о которых разработчикам известно, что код там не такой чистый, как хотелось бы или как требуется для дальнейшей разработки).
- Разделять и группировать отложенные задачи до состояния пригодных для работы участков.
- Делать пометки о последствиях игнорирования каждого такого участка работ.
- Держать список на видном месте, в понятном состоянии.
- Ставить в известность о техническом долге и его обслуживании команды, которые зависят от ваших поставок.
- Застолбить в расписании время для «выплат» технического долга. Это следует делать регулярно и часто.
Как команде выявлять и отдавать технический долг
Регулярные проверки здоровья системы
Регулярные проверки являются обязательным условием. Они помогут вам понять состояние вашего ПО. Если у разработчиков на итерации фич уходит больше обычного времени, если вы замечаете, что функциональность и производительность вашего продукта падают, это определенно красный флаг.
Еженедельная «выплата» какого-то минимума
Непрерывная, последовательная работа над проблемой это хороший способ в конечном итоге справиться с ней. Регулярные правки и возврат мелких долгов помогут избавиться от больших проблем.
Команда, занимающаяся наведением порядка
Если у вас есть отдельная команда разработчиков, которые могут заниматься отслеживанием задач, связанных с техническим долгом, это очень поможет процессу. Даже в Agile нужно делать спринты, посвященные уборке. Разработчики из этой группы должны помогать и находить, и исправлять ошибки.
Принимая решения сегодня, учитывайте масштабируемость / безопасность / устойчивость ПО в будущем
Все, что реализуется сегодня, должно учитывать будущие требования. Предсказать все возможные требования, конечно, нельзя, однако стоит помнить о таких вещах как масштабируемость и безопасность. Таким образом хотя бы они не станут для вас неожиданными требованиями и не помешают плавному масштабированию системы.
Принимая решение взять на себя технический долг, нужно следить за тем, чтобы ваш код оставался безупречно чистым. Поддержание системы в чистоте – единственный способ погасить этот долг.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
