Антихрупкость в 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 или любой другой член команды делает ошибки при разработке проекта, неверно применяя шаблоны проектирования или неправильно используя принципы проектирования.
В то же время это самый опасный тип долгов, так как участники разработки не видят рисков. Они не могут правильно оценить время на добавление новой функциональности или реорганизации уже работающей системы.
