Читать книгу - "Антихрупкость в IT - Александр Васильевич Бындю"

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

Плюсы:

1. Работа над системой не останавливается, клиент видит результаты своих вложений.

2. Поставка новых функций и исправление ошибок идёт с самого начала вашей работы.

Минусы:

1. Если код в системе плохой, то вы продолжите добавлять в него ещё больше костылей, увеличивая техдолг (см. раздел II, глава 6).

2. Есть шанс попасть в ситуацию, описанную Бруксом: «Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. Всё меньше сил тратится на исправление ошибок исходного проекта и всё больше – на ликвидацию последствий предыдущих исправлений».

3. Реанимация системы в разы сложнее, чем создание новой. Для этой работы нужна высокая квалификация, а значит, нужно больше вкладываться в поиск и удержание крутых инженеров. Здесь вы столкнётесь с противоречием: крутые инженеры не хотят копаться в плохом коде, поэтому вопрос с мотивацией окажется очень сложным.

Рекомендация, когда стоит оставить всё как есть:

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

2. Нужно очень быстро дать результат, даже путём осознанного добавления «костылей» в код. Я понимаю, что это может усугубить ситуацию с качеством системы, но если бизнес с этого рывка получит огромную прибыль, то в дальнейшем сможет инвестировать её в другие стратегии работы с унаследованной системой, в том числе в переписывание.

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

3. Душитель

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

Метафора этого подхода была описана у М. Фаулера в статье «Strangler Application»[94].

Плюсы:

1. Все плюсы первого подхода с полным переписыванием.

2. Работа старой системы не останавливается, и при этом мы добавляем новые функции.

3. Бизнес сразу начинает видеть результаты своих вложений.

Минусы:

1. Если в системе были серьёзные ошибки, то нам придётся исправлять их в унаследованном коде, то есть вкладываться в старую кодовую базу.

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

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

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

Рекомендация, когда стоит «душить»:

1. Унаследованная система стабильно работает.

2. В основном надо добавлять новые функции, а не расширять уже существующие.

4. Переработка по модулям

Если создать новое приложение «душителя» не получается и код в текущем состоянии оставлять нельзя, то нам остаётся заняться постепенным рефакторингом и улучшением дизайна системы. Для этого релиз за релизом мы изолируем части системы, выделяем независимые модули и переписываем их. Таким образом, через определённое время большая часть системы будет переписана.

Плюсы:

1. Постепенное улучшение качества системы.

2. Возможность сделать постоянную скорость поставки (не максимально высокую, но стабильную).

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

Минусы:

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

2. Не всегда возможно выделить модули.

Рекомендация, когда стоит постепенно переписывать по модулям:

1. Унаследованная система имеет высокую ценность для бизнеса.

2. В системе реализовано много отлаженных модулей.

3. В основном надо расширять уже существующие функции.

Культура и развитие

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

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

Глава 6. Технические долги

Причины появления долгов и стратегии уменьшения техдолга

Этот термин впервые ввёл Ward Cunningham[95]:

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

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

Понять действия, которые приводят к долгам в коде, очень легко, потому что каждый каждый разработчик делает эти долги изо дня в день. Саму систему появления этих долгов можно описать с помощью денежной метафоры[96]:

1. Игнорировать внутреннее качество – брать деньги в долг.

2. Рефакторинг – способ возврата долга.

3. Замедление разработки из-за запутанности системы – выплата процентов.

4. Провал проекта – приезд судебных приставов и конец бизнеса.

Типы долгов

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

Неумышленные

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

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