Дизайн системы, технический долг и скорость разработки Меся | )
Дизайн системы, технический долг и скорость разработки
Месяц назад я устроился разработчиком в стартап от крупной компании из США, которая создает программные продукты для большого Enterprise. Проект находиться на стадии MVP, старого legacy нет. В команде бэкенда только два программиста.
Зачастую на таких проектах приятно работать. Впереди тебя ждет разработка новых фич вместо поддержки старого функционала и постоянного фиксинга багов.
Первую неделю я изучал кодовую базу и закрыл скоуп задач по второстепенной логике. Откровенно говоря, я остался не в восторге от качества кода и архитектуры проекта.
Бизнес-логика намешана внутри транспортного слоя и репозитория, из-за чего покрывать тестами подобное решение очень сложно. Подавляющая часть переменных, функций и методов имеют непонятные и неконсистентные именования.
Архитектуре характерна сильная связность. Изменение одного метода влечет за собой непредсказуемые последствия на корректность работы абсолютно разных компонентов.
Большинство методов имеют слабую декомпозицию, за счет чего они очень длинные и сложны к восприятию. По коду часто встречаются цепочки из условных операторов и циклов с несколькими уровнями вложенности. Можно встретить “не чистые” функции, которые по выполнению оставляют побочные эффекты, о которых ты даже не догадываешься.
Все вышеперечисленные проблемы несут за собой ряд последствий. Изучать логику проекта сложно, у новых разработчиков уходит на старте много времени. Поддерживать и расширять подобный код становиться трудно, из-за чего проект со временем начинает обрастать костылями. С каждой новой фичей тех. долг растет, а сложность кодовой базы возрастает экспоненциально.
На вторую неделю я взял в работу задачу по интеграции со сторонним продуктом, который входит в экосистему решений компании. Потратив 2 дня на изучение бизнес требований, API спецификации, общение со специалистами со стороны заказчика и проектирования технического решения я приступил к разработке.
Данная задача подразумевает расширение существующего функционала. Однако углубившись в уже реализованную логику, я не смог ничего добавлять, пока не отрефакторил 80% написанного кода.
На задачу, которую можно выполнить за 3-4 дня, у меня ушло полторы недели. Помимо реализации бизнес логики мне пришлось переписать огромное количество кода и убедиться, что вся остальная логика системы при этом не поломалась. Без надлежащего покрытия тестами это тоже не простая задача.
Многие программисты и менеджеры убеждены, что в условиях сжатых сроков, писать плохой код полный костылей экономит время.
Я считаю все совсем наоборот.
Инвестиция времени в проектирование грамотного дизайна системы и составление стандартов разработки на начале проекта позволит быстро двигаться и выкатывать новые фичи в будущем.
При плохой архитектуре, когда нужно быстро добавить новую фичу, приходиться писать костыль. С каждым таким разом тех. долг растет, а скорость разработки падает.
В следующий раз я поделюсь своим взглядом к подходу решения данной проблемы.
В процессе рефакторинга я завел документ, в котором начал выписывать принципы по написанию кода в нашем проекте. Документ предназначен стандартизировать и унифицировать подходы к написанию кода на проекте. Это один из первых шагов на формировании культуры разработки внутри команды.
Люди бывают разные. Когда вы приходите на проект и начинаете оптимизировать код, внедрять новые практики, стремитесь повышать качество и делиться своим опытом, не все специалисты могут относиться к этому позитивно.
Кто-то адекватно воспринимает ваши предложения и замечания, вносит свои предложения и проявляет инициативу по улучшению ситуации. Есть и такие, кто видит в подобном косвенную критику его навыков как разработчика.
Главное правильно преподносить информацию, а если вы недавно пришли в команду, помните, что сначала нужно заработать карму.
