Ответ
Практически никогда в чистом виде. Работа над коммерческими проектами — это постоянный поиск баланса между качеством архитектуры, сроками, бюджетом и меняющимися требованиями бизнеса.
С какими компромиссами сталкиваюсь чаще всего:
- Наследие (Legacy Code): Приходится интегрировать новые фичи в существующую, далекую от идеала, кодобазу. Например, добавлять GraphQL эндпоинт поверх старого монолита с "жирными" моделями, где бизнес-логика размазана по контроллерам.
- Срочные фиксы и хотфиксы: В критической ситуации (продакшен-инцидент) приоритет — скорость восстановления работы, а не красота решения. Позже такой код обязательно выносится в технический долг для рефакторинга.
- Недостаточное понимание предметной области на старте: Часто требования уточняются в процессе. Архитектура, идеальная на бумаге в начале спринта, может оказаться неоптимальной к его концу.
Мой подход: стремлюсь не к "идеальной" архитектуре, а к прагматичной и поддерживаемой.
- Я применяю принципы SOLID и DRY там, где это дает явную выгоду для тестируемости и расширяемости.
- Явно выделяю границы контекста (Bounded Context) даже в монолите, чтобы позже было проще выделить микросервис.
- Пишу код так, чтобы его мог понять и развивать другой разработчик через полгода.
Пример компромисса: вместо идеального Event-Driven подхода с брокером сообщений (Kafka/RabbitMQ) для небольшой фичи можно временно использовать синхронный вызов сервиса, но обернуть его в интерфейс. Это позволит в будущем заменить реализацию на асинхронную, не меняя код вызывающей стороны.
Ответ 18+ 🔞
Да ты послушай, какой тут философский вопрос подняли! Практически никогда, блядь, в чистом виде — это как мечтать о девственнице в борделе. Работа над коммерческими проектами — это вечный цирк с конями, где ты жонглируешь качеством архитектуры, сроками, бюджетом, а бизнес тебе ещё и новые шарики подкидывает прямо на лету.
С какими пиздецами сталкиваюсь чаще всего, ёпта:
- Наследие (Legacy Code): Вот это, ядрёна вошь, классика. Приходится впихивать новые фичи в старую кодобазу, которая выглядит так, будто её писали пьяные мартышки на спор. Типа, надо прикрутить GraphQL эндпоинт к монолиту, где бизнес-логика размазана по контроллерам тоньше, чем масло по грязному бутерброду.
- Срочные фиксы и хотфиксы: Тут уж, бля, не до архитектурных изысков. Продакшен горит, все орут — приоритет один: заткнуть течь любой ценой, хоть пальцем. Понятное дело, потом этот костыль выносится в технический долг, который будет висеть как дамоклов меч, но терпения ебать ноль, когда всё падает.
- Недостаточное понимание предметной области на старте: А это, сука, вечная песня! Бизнес в начале говорит одно, в середине спринта — другое, а к концу выясняется, что они вообще не то хотели. И архитектура, которая в понедельник казалась гениальной, к пятнице превращается в хитрожопый костыль.
Мой подход, если честно: я не гонюсь за какой-то академической, стерильной идеальностью. Мне нужна архитектура прагматичная и чтобы не стыдно было.
- SOLID и DRY применяю точечно, там, где это реально облегчит жизнь тому бедолаге, кто будет это всё поддерживать после меня.
- Даже в монолите стараюсь явно очертить границы контекста (Bounded Context). Мало ли что — вдруг потом придётся отпиливать кусок в микросервис, а так уже заготовка есть.
- Пишу так, чтобы через полгода я сам, бухой, в три ночи, мог в этом разобраться и не послать себя самого нахуй.
Вот тебе живой пример компромисса: вместо того, чтобы сразу городить овердохуищный Event-Driven с Kafka (что, конечно, красиво), для мелкой фичи можно временно сделать синхронный вызов. Но, ёпта, обязательно обернуть его в интерфейс! Это как поставить временную заплатку, но оставить люк для будущей нормальной двери. Потом, когда будет время и бюджет, просто выкидываешь старую реализацию и вставляешь новую, а весь остальной код даже не заметит подмены. Хуй с горы, зато работает.
