В этой статье я хочу описать свой опыт погашения технического долга на нашем проекте в виде гайда. В гайде я выделю несколько самых распространенных случаев технического долга и предложу методы их решения. Так как это довольно обширная тема, я посоветую несколько книг для изучения, потому что в рамках данной статьи поговорить обо всем не вижу возможным. Все описанное относится к BackEnd части, но возможно, будет подходить и для других разработчиков. Буду рад, если вы поделитесь своим опытом по этой теме в комментариях.

А у вас накопились долги?

Как появляется технический долг

Простыми словами, технический долг возникает тогда, когда в приоритет ставится быстрая реализация бизнес задач, которая приводит к хорошим краткосрочным бизнес результатам, но в дальнейшем усложняет поддержку и расширяемость проекта.

В мире уже есть много определений и видов технического долга, но я опишу только 5 проблем, с которыми мы столкнулись на нашем проекте, и распишу, как их не допускать, а если допустили, как исправить.

Некачественный код и архитектура

Определение

По сути, самый большой раздел, где может образоваться больше всего техдолга.  

Код, написанный в сжатые сроки, без правильного планирования и соблюдения конвенций может приводить к результату, что его будет сложно понимать, поддерживать и расширять. Это означает, что каждый раз, когда вы будете добавлять к такому коду баг фикс или фичу ваш технический долг будет расти экспоненциально (рис. 1). А это, в свою очередь, будет приводить к тому, что в таком коде, будет все больше и больше багов, и критичных ошибок, что в свою очередь, уже влияет на бизнес, т.к. из-за частых поломок, доверие пользователей будет снижаться. Это хороший аргумент, чтобы убедить бизнес/заказчиков в том, что нужно больше времени на разработку или нужно выделять определенное время для погашения технического долга.

Плохо построенная архитектура на начальном этапе может в дальнейшем привести к ограничению (замедлению разработки) в масштабируемости проекта и усложнению добавления/изменения составных частей: языков программирования, фреймворков, БД, кешей, брокеров сообщений, интеграций с внешними системами и т.д.

Исправление

Чтобы избежать плохого кода и архитектуры нужно прочитать много книг и переделать кучу разных проектов. Но вот основные советы:

1. Соблюдайте единый стиль написания кода, который принят в вашей, если такового нет, то создайте его. Прикрутите линтер к вашему проекту и прогоняете через него код, сделайте невозможным деплой приложения, без одобрения линтера.

2. Регулярно проводите рефакторинг кода, используйте лучшие дизайн паттерны и сохраняете его удобочитаемость и поддерживаемость.

3. Следуйте принципам SOLID, шаблонам проектирования и стилям архитектуры, чтобы ваш код был хорошо структурирован и масштабируем.

4. Регулярно проверяйте ранее написанный код, чтобы убедиться, что код высокого качества и соответствует требованиям.Если надо, вносите улучшения, чтобы уменьшить технический долг.

В конце статьи я предложу несколько книг, в котором эти пункты более подробно описаны, следуя советам из этих книг, вы можете гарантировать, что ваш код имеет высокое качество, хорошо структурирован и удобен в сопровождении, а также свободен от технического долга.

Тесты

Определение

По моему мнению, недостаточное покрытие кода тестами или использование плохих тест кейсов также может образовывать технический долг.

Неправильные процессы тестирования могут привести к упущенным ошибкам, уязвимостям и другим проблемам, которые могут привести к техническому долгу. Если эти проблемы не устранены до деплоя, они могут привести к увеличению затрат на обслуживание, снижению удовлетворенности пользователей и снижению доверия к приложению. 

Исправление

Главное в тестах, чтобы они хотя бы были :) Покрытие кода тестами в идеале должно быть приближено к 100%, но некоторые разработчики считают приемлемым результатом — 80%. Можно ли не тестировать вообще или недостаточно тестировать? Можно. Но этой приведет к техническому долгу, который будет замедлять скорость дальнейшей разработки. 

Вот несколько основных видов тестов, которые необходимо написать:

1. Unit тесты — основные тесты, которые пишет разработчик. Этот вид тестов пишется для небольшого куска кода, чтобы удостовериться что он правильно отрабатывает поведение, которые вы заложили в него. Один раз написав, в дальнейшем вы их прогоняете при добавлении новой кодовой базы, чтобы убедиться, что новый код не ломает предыдущие наработки.

2. Интеграционное тестирование нужно для того, чтобы отловить баги, которые не отловили в unit тестах. Соответственно, уровень тестируемого кода переносим выше, на уровень взаимодействия разных кусков кода. Например: интеграцию между разными компонентами системы интернет магазина — корзины и платежной системой.

3. Есть еще разные виды тестирования: functional tests, end-to-end tests, performance tests, security tests. Но как правило, если команда большая, это делается другими людьми, если нет, это также может стать вашей обязанностью.

Избыточное использование ресурсов

Определение

Неэффективное использование ресурсов может привести к техническому долгу, поскольку это может увеличить стоимость обслуживания и эксплуатации приложения. Например, система, которая неэффективно использует память, вычислительную мощность и ресурсы хранения, может работать медленно, не отвечать на запросы или быть подвержена сбоям. Это может негативно повлиять на пользовательский опыт и привести к снижению удовлетворенности и доверия к приложению.

Кроме того, неэффективное использование ресурсов может привести к тому, что приложение потребует больше ресурсов для работы и обслуживания, что приведет к увеличению затрат на оборудование. Это может привести к увеличению времени разработки новых функций и обновлений, снижению конкурентоспособности и увеличению технического долга.

Исправление

Вот некоторые советы для оптимизации:

1. Оптимизируйте алгоритмы и структуры данных: убедитесь, что алгоритмы и структуры данных, используемые в коде, самые оптимальные в отдельно взятой ситуации.

2. Используйте библиотеки и инструменты, которые заведомо эффективны и хорошо оптимизированы для вашего случая.

3. Используйте кэширование и другие методы оптимизации производительности: внедрите кэширование и другие методы оптимизации производительности, чтобы свести к минимуму использование ресурсов и повысить общую эффективность.

4. Регулярно тестируйте и профилируйте код, чтобы выявлять узкие места в производительности и области, в которых можно улучшить использование ресурсов.

Легаси

Определение

На нашем проекте не было проблемы легаси, т.к. проект новый, и соответственно использовались все свежие технологии, которые были на тот момент. Но в связанных микросервисах были такие проблемы, которые мне пришлось устранить. Со временем устаревшие технологии, конвенции, антипаттерны могут стать техническим долгом, который начнет мешать расти приложению.

Исправление

Прежде чем менять старые технологии, нужно убедиться, а нужно ли. Как говорят: работает — не трогай. Вот некий план, как решиться и что делать дальше:

1. Оцените влияние: определите влияние устаревших технологий на код, включая любые проблемы с совместимостью, производительностью, безопасностью или поддержкой.

2. Определите альтернативы: изучите и оцените альтернативные технологии, которые могут заменить устаревшие технологии, и определите преимущества и недостатки каждой альтернативы.

3. Спланируйте переход: разработайте подробный план перехода от устаревших технологий, включая сроки, требования к ресурсам и любые потенциальные риски или проблемы.

4. Применяйте поэтапный подход. Рассмотрите поэтапный подход к переходу начиная с некритических систем и постепенно переходя к более важным системам.

5. Реализация плана. Выполнение плана по отказу от устаревших технологий, включая все необходимые изменения кода, обучение разработчиков и обновления систем поддержки.

6. Мониторинг и оценка: отслеживайте влияние перехода и оценивайте результаты, внося в план все необходимые корректировки.

7. Непрерывное обновление: регулярно оценивайте технологии, используемые в коде, и при необходимости вносите обновления, чтобы код оставался актуальным и эффективным.

Документирование и логирование  

Определение

Игнорирование написания документации к своему проекту также может приводить к техническому долгу. Стоит внимательно отнестись к этой части тех. долга, потому что от документации напрямую будет зависеть, насколько быстро новые разработчики будут вникать в проект и в какие сроки они напишут свой код. Чем дольше нет документации или нет подробно описанной документации, тем вход в проект будет усложняться, а нынешним разработчикам все труднее и труднее вносить изменения.

Также я отношу к потенциальному техдолгу логирование, потому что неправильное или недостаточное логирование может приводить к замедлению устранений ошибок и анализа выполнения работы приложения. 

Исправление

Несколько советов по документированию кода:

1. Комменты. Добавляете комменты в свой код, если вы понимаете, что другой разработчик с первого взгляда ориентируясь на названия классов, методов, переменных не поймет, что он делает, другими словами, если есть какая-то хитрая бизнес логика. Однако некоторые влиятельные разработчики считают комменты антипаттерном, поэтому их надо использовать редко и с осторожностью.

2. API документация. Сервисы типа Swagger позволяют очень быстро и удобно описывать каждый конкретный эндпойнт вашего API, а также используется для отправки запросов и предварительного теста вашего кода.

3. README файлы. Создавайте такие файлы, чтобы описать верхнеуровневого, например, архитектуру микросервиса, что он делает и какая у него функциональность. Можно также добавить важные моменты, без которых работа с этим микросервисам невозможна, все остальное лучше писать в Wiki.

4. Wiki странички. Здесь уже можно описать более подробно про каждый сложный компонент, который вы разработали. Какие микросервисы у проекта есть, раздел с best practices, какие-то важные проблемы, которые решали в прошлом и теперь это аффектит на нынешнюю разработку. В общем, все ответы на вопросы для новопришедшего разработчика на вашем проекте.

Логирование может быть разных уровней, каждый из них нужно применять в определенных ситуациях. Самые главные из них:

1. Уровень INFO — информационные логи которые нужны, чтобы отслеживать поведение системы, например, для отслеживания добавления/удаления элементов в БД. 

2. Уровень WARNING — логи, которые указывают на определенные потенциальные проблемы, которые впоследствии должны быть проанализированы и решены.

3. Уровень DEBUG, TRACE — логи, которые используются для дебага и которые предоставляют более детальную информацию о поведении приложения для диагностики, устранения неполадок или тестирования приложения. TRACE предоставляет еще более расширенную информацию

4. Уровень ERROR — информация, что есть ошибка, которую нужно исправлять в срочном порядке, возможно хот фиксом.

Вывод

Как вы могли заметить, я подробно не расписал каждую деталь как и что нужно делать, потому что уместить всю эту большую тему в одну статью невозможно. Поэтому это и называется мини-гайдом, в котором я дал направление, на что обратить внимание и описал вкратце основы. Для того чтобы более детальнее разобраться нужно прочитать не одну книгу и написать много-много строчек кода. Вот некоторые хорошие книги, которые я рекомендую, чтобы стать лучшим программистом и никогда не встречаться больше с техдолгом;)

Чистый код - Роберт Мартин

Рефакторинг - Мартин Фаулер

Паттерны объектно-ориентированного проектирования - Гамма, Хелм

Грокаем алгоритмы - Адитья Бхаргава

Высоконагруженный приложения - Мартин Клеппман