Чистый код, недовольный бизнес
Рубрика «Пятничные байки из опыта».
На прошлом проекте попал в классическую ситуацию из книг. Наша команда топила за грамотные, масштабируемые решения, а бизнесу было все равно на красоту. На фоне этого частенько возникали конфликты.
Быстрые решения позволяют получать деньги в короткие сроки – это факт. Но возникают проблемы с поддержкой и масштабированием. Можно навертеть костылей и велосипедов, тогда в определенный момент любые изменения будут занимать огромное количество времени. Ведь мы не заботимся о документировании, переиспользовании или оптимизации, а работаем на скорость.
С другой стороны, на проработку грамотной архитектуры требуются ресурсы, которых не всегда хватает. Вот и приходится выдерживать баланс между скоростью и чистотой.
Конкретно в нашем случае очень любили накинуть бизнес логику на слой с интеграциями. Это при наличии оркестратора слоем выше. «Ну а че, вам же быстрее, чем логику править» Нам и правда быстрее, но двигались к унификации и старались делать адаптеры похожими друг на друга. Это позволяло быстро вносить изменения в существующий код.
Придерживаться паттернов не только полезно, но и интересно. Ты начинаешь применять теорию, а не бездумно идти по простому пути. Очень жаль, что технические инициативы перестали воспринимать после ухода тимлида. Проработав полгода под его руководством, получил колоссальный опыт и сильно прокачался.
А как у вас на проектах? Приходится ли примерять на себя роль архитектора и отстаивать те или иные решения?
Рубрика «Пятничные байки из опыта».
На прошлом проекте попал в классическую ситуацию из книг. Наша команда топила за грамотные, масштабируемые решения, а бизнесу было все равно на красоту. На фоне этого частенько возникали конфликты.
Быстрые решения позволяют получать деньги в короткие сроки – это факт. Но возникают проблемы с поддержкой и масштабированием. Можно навертеть костылей и велосипедов, тогда в определенный момент любые изменения будут занимать огромное количество времени. Ведь мы не заботимся о документировании, переиспользовании или оптимизации, а работаем на скорость.
С другой стороны, на проработку грамотной архитектуры требуются ресурсы, которых не всегда хватает. Вот и приходится выдерживать баланс между скоростью и чистотой.
Конкретно в нашем случае очень любили накинуть бизнес логику на слой с интеграциями. Это при наличии оркестратора слоем выше. «Ну а че, вам же быстрее, чем логику править» Нам и правда быстрее, но двигались к унификации и старались делать адаптеры похожими друг на друга. Это позволяло быстро вносить изменения в существующий код.
Придерживаться паттернов не только полезно, но и интересно. Ты начинаешь применять теорию, а не бездумно идти по простому пути. Очень жаль, что технические инициативы перестали воспринимать после ухода тимлида. Проработав полгода под его руководством, получил колоссальный опыт и сильно прокачался.
А как у вас на проектах? Приходится ли примерять на себя роль архитектора и отстаивать те или иные решения?