Software-Architecture

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

Let me tell you a story. Last week, I walked into a codebase that looked like it was written by someone who had just discovered reactive programming and decided that everything needed to be reactive. Every button click, every API call, every sneeze was wrapped in observables. It was like watching someone use a chainsaw to slice bread – technically possible, but you’re left wondering if they’ve lost their mind. Don’t get me wrong – reactive programming has its place....

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

Every developer has that moment. You’re architecting a new system, sketching out microservices on a whiteboard, and suddenly you think: “How hard could it be to build our own message queue?” After all, it’s just moving data from point A to point B, right? Right? Well, buckle up, because I’m about to take you on a journey through the rabbit hole of distributed messaging – and trust me, this particular rabbit hole goes deeper than Alice’s....

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