Чем дольше работаю разработчиком - тем меньше верю в «идеальную архитектуру»
Раньше мне казалось, что хороший backend обязательно должен быть:
• идеально разделён • с кучей абстракций • паттернами • слоями • “правильной” архитектурой
И чем сложнее всё выглядело — тем «профессиональнее» казался проект.
Сейчас уже смотрю на это сильно спокойнее.
Потому что почти всегда в реальной разработке побеждает не самая красивая архитектура, а та, которую:
• понимает команда • можно быстро менять • не страшно трогать через полгода
И самое забавное — многие проблемы появляются именно после попытки сделать “слишком правильно”.
Особенно на ранних этапах проекта.
Когда у тебя: • 3 микросервиса на 2 endpoint’а • 15 abstraction layers • CQRS/Event Sourcing просто «на будущее»
Хотя продукт ещё даже не взлетел.
Со временем понял простую вещь:
- архитектура должна решать проблемы проекта, а не создавать новые.
Сейчас мне гораздо ближе подход:
сначала простое решение → потом усложнение только если реально понадобилось.
И, честно, поддерживать такие проекты обычно намного приятнее.
· 13.05
Подход правильный. У программистов есть такое правило: Do the simplest thing that works - Сделай простейшую вещь, которая работает. Если что-то уже работает, дальше можно наращивать функционал. Как говорится, вы идете от простого к сложному. Так всегда более практично.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён