Итеративный рефакторинг В прошлый раз я поделился своим опыто | )
Итеративный рефакторинг
В прошлый раз я поделился своим опытом знакомства с новым проектом, состояние которого требует рефакторинга. Я уверен что оптимизация архитектуры приложения поможет повысить эффективность и скорость дальнейшей разработки, поэтому поднял этот вопрос с командой.
Конечно все согласны что нужно начинать борьбу с тех. долгом. Однако нельзя просто так взять и остановить разработку чтобы переписать систему.
Продукт находиться на стадии MVP, бизнесу необходимо как можно быстрее запуститься и получить фидбек от первых пользователей. У нас много задач и сжатые сроки.
Как правильно поступать в такой ситуации?
Я уверен что от технического долга избавиться невозможно, он всегда будет присутствовать на любом проекте. Борьба с ним - процесс итеративный.
Вместо того, чтобы остановить разработку и все переписывать, стоит закладывать в оценку сроков на выполнение каждой новой задачи дополнительных 2-3 дня на рефакторинг.
Вместо того, чтобы тратить на таску 3 дня, на нее уйдет неделя, но в процессе можно оптимизировать логику, которую задевает эта задача.
При работе с уже написанным кодом стоит придерживаться правила Бойскаута - оставлять код чище, чем он был до тебя.
Например, поступила новая задача расширить функционал создания пользователя. Это отличная возможность переписать слой работы с данными для сущности пользователя, вынести из нее бизнес-логику в сервис и отделить ее от транспортного уровня.
В процессе можно задекомпозировать уже существующие методы, переименовать непонятные переменные и переписать участки кода с несколькими уровнями вложенности.
При изучении логики работы с базой данных, можно подумать как оптимизировать SQL запросы и лишиться лишних вызовов к БД.
Дополнительно, если старый код еще не покрыт тестами, то у тебя появилась замечательная возможность это исправить.
Каждое такое изменение будет незначительно улучшать качество проекта, на 1% в единицу времени.
Да, выполнение бизнес задач будет отнимать немного больше времени, однако спустя уже несколько месяцев такой практики качество кодовой базы значительно вырастет, а архитектура системы будет “чище”, что позволит выиграть время в долгосрочной перспективе.
