Software-Architecture

Мост, который нам не нужен Представьте: вы сидите на встрече стартапа. Три инженера. Осталось две недели работы. Продукт ещё не проверен на востребованность. И кто-то — всегда найдётся кто-то — говорит: «Нам, наверное, стоит настроить архитектуру микросервисов с оркестрацией Kubernetes, реализовать очередь сообщений, добавить сервисную сетку и спроектировать её для 100 миллионов одновременных пользователей». Ваше чутье подсказывает, что что-то не так. Вы правы. Это эпидемия избыточной инженерии, и она убивает больше продуктов, чем спасает....

Не каждое программное обеспечение должно быть распределённой системой, работающей на Kubernetes на трёх континентах. Я знаю, знаю — в 2025 году это звучит почти как ересь. Но выслушайте меня. Я видел, как слишком многие талантливые инженеры тратили месяцы на проектирование сложных инфраструктур микросервисов для приложений, которые обслуживают 500 активных пользователей в день. Я видел, как стартапы сжигали деньги на решениях для горизонтального масштабирования, когда бы хватило мощного вертикального масштабирования на год....

Представьте: вы построили идеальный SOLID-замок с безупречной иерархией классов, потоками внедрения зависимостей, словно рвами, и интерфейсами острее зубцов стен. Затем наступает реальность — команда маркетинга хочет башен в форме драконов, бухгалтерия требует переноса данных из подземелья в облако, а UX настаивает, чтобы подъёмный мост вращался, как спиннер. Внезапно ваша крепость кажется скорее тюрьмой. Добро пожаловать в современную разработку программного обеспечения, где единственное постоянство — это изменения, а жёсткость архитектуры — это настоящий технический долг....

Посмотрите, я собираюсь сказать кое-что, что может привести к тому, что меня не пригласят на следующую конференцию по Agile: истории пользователей не всегда являются решением. Вот, я это сказал. Прежде чем вы закроете эту вкладку и напишете гневный комментарий о том, что я «не понимаю Agile», выслушайте меня. Я годами наблюдал, как команды религиозно превращают каждое требование в священный формат «Как… Я хочу… Чтобы…», даже когда это было абсолютно неуместно....

Позвольте мне рассказать вам историю. На прошлой неделе я столкнулся с кодовой базой, которая выглядела так, будто её написал кто-то, кто только что открыл для себя реактивное программирование и решил, что всё должно быть реактивным. Каждое нажатие кнопки, каждый вызов API, каждое чихание были заключены в наблюдаемые объекты. Это было похоже на то, как кто-то использует бензопилу, чтобы нарезать хлеб — технически возможно, но вызывает вопросы о здравомыслии. Не поймите меня неправильно — у реактивного программирования есть своё место....