Software Architecture

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

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

У каждого разработчика бывает такой момент. Вы проектируете новую систему, рисуете микросервисы на доске, и вдруг думаете: «Да насколько сложно создать собственную очередь сообщений?» В конце концов, это просто передача данных из точки А в точку Б, верно? Верно? Приготовьтесь, потому что я собираюсь провести вас через кроличью нору распределённых сообщений — и поверьте мне, эта конкретная кроличья нора уходит глубже, чем у Алисы. Соблазнительная простота «просто очереди» Будем честными: базовая концепция кажется почти оскорбительно простой....

«Вы переусложняете это!» — боевой клич каждого основателя стартапа, который наблюдал, как сроки запуска его минимально жизнеспособного продукта (MVP) сдвинулись с «двух недель» на «когда-нибудь в следующем финансовом году». И, честно говоря, большую часть времени они абсолютно правы. Но здесь я собираюсь отстаивать идею, которая, вероятно, вызовет у меня немало резких комментариев: иногда именно переусложнение и нужно. Прежде чем закрыть эту вкладку и написать в твиттере, что я потерял рассудок, выслушайте меня....

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