Часто бывает, что через месяц работы в компании/офисе/подразделении/отделе уже видно, откуда растут ее проблемы и кому следует выдать хорошего леща и выгнать с пиздюлями.
В других случаях пусть не через месяц, но через полгода становится видно, что проблема не в конкретных людях, а в определенных процессах, которые, накладываясь друг на друга, создают проблемы. Это уже сложнее, но, в общем, тоже понятно, что с этим делать и в какую сторону воевать.
Хуже всего ситуация, когда большая часть сотрудников конторы прекрасно видит объективно существующие проблемы, но в упор не понимает их причин. Обычно в таких случаях проблемы длительные, системные и сопровождают контору годами, успешно переживая смены управленцев и процессов. Да, это ключевой момент — проблемы никуда не деваются даже при смене процессов и начальников. Это, пожалуй, самый плохой для конторы вариант, так как все, кому хоть немного не наплевать на результат, в конечном итоге сильно демотивируются и, видя, что ничего поменять тут нельзя, просто сваливают к чертям свинячим, тем самым осуществляя отрицательный отбор в коллективе, так как остаются строго те, кому пофиг.
И вот именно об одной из причин таких проблем сегодня поговорим. Когда и люди не виноваты и процессы вроде адекватные и уже несколько раз меняли, а одни и те же проблемы никуда не уходят.
Когда-то, во времена лихой юности, я был кем-то вроде тех.лида в одной конторе, занимавшейся продуктовой разработкой. И вот как-то раз я шел по офису, помахивая полномочиями. Среди гула обсуждений, кто где бухал на выходных и где лучше чинить тачку, я внезапно услышал один разговор по работе. Один из разработчиков рассказывал другому, как внутри работает сервис, который он разрабатывал. Когда я зловещей тенью возник за его спиной и спросил, за каким хреном он это делает, тот ответил, что второму скоро интегрироваться в своем сервисе с его, вот поэтому, мол, и рассказываю. В этот момент на меня пролился свет с потолка и снизошло озарение, я собрал всю команду и громким матерным голосом нахрен запретил рассказывать внутренности устройства сервисов и их бизнес логику тем из разрабов, кто непосредственно их не пишет. Нужно тебе интегрироваться — вот тебе публичная часть домена и логики, вот тебе готовый клиент и все, топай отсюда. Внутренности тебе знать не просто не нужно, а даже вредно.
Это решение, принятое за 2 минуты потому что «осенило», впоследствии помогло разработке больше, чем 90% советов из умных книжек от седых дядек, и вообще оказалось вершиной целого айсберга, который может потопить с десяток титаников и который мы сегодня и будем обсуждать.
Собственно, перед нами самая современная (по крайней мере на русском) книжка про DDD, которую хвалили еще на английском, то есть книжка вроде должна быть стоящая. А поскольку каждый автор пишет книги в основном в робкой надежде на мой непредвзятый обзор, то, как порядочный мужчина, после прочтения я не мог не ответить взаимностью.
… по крайней мере, одна из главных — это то, что автором DDD является Эванс. А Эванс, как и его лепший кореш Фаулер, был ярым фанатом так называемых rich models. И, как и Фаулер в своем Рефакторинге, не постеснялся напихать в DDD идей этой самой rich models. А самое смешное, что эти идеи в DDD сугубо сбоку и их вполне можно выпилить без ущерба, но тут включается сектантство нашего маленького зоопарка, потому что ну как же, мы же не попрем против Эванса, поэтому до сих пор даже в современных книгах по DDD авторы воспроизводят это говно из rich models в тактических паттернах.
(это я читаю «Изучаем DDD» Хононова и опять кричу на облака)
Наверное, из некоторых моих постов можно подумать, что я недолюбливаю golang. Это не совсем так. «Недолюбливаю» — недостаточно емкое слово для выражения всего спектра моих эмоций. Это как смотреть на гениального студента, который вместо поиска лекарства от рака, выбрал заниматься исследованиями по продлению оргазма у свиней. Потому что, да, я искренне считаю, что у языка есть несколько действительно фундаментальных проблем, из-за которых от него может быть больше вреда, чем пользы.
При этом, за 5 лет неторопливого ковыряния, я понял, что во многих местах язык очень инновационный, смелый и изящный. И, более того, те вещи, за которые я его обожаю, как минимум наполовину пересекаются с теми, за которые я его ненавижу. И нет, это не шизофрения, просто это очередной пример, как наши недостатки зачастую являются продолжением наших достоинств.
Короче, сегодня та самая ночь. Сегодня мы снова срываем покровы. И начнем мы с плохого.
В проектировании ПО вообще и дизайне языков программирования в частности есть одна концепция, которая, при своей невероятной мощи и полезности, является удивительно малоизвестной. Это так называемая концепция синтаксической соли.
В принципе, ее суть можно понять, если логически сравнить с другой, гораздо более известной концепцией синтаксического сахара. Если синтаксический сахар, это синтаксические возможности, которые просто упрощают реализацию того, что можно сделать и без сахара, то синтаксическая соль — наоборот. Это сознательное усложнение использования части возможностей системы со стороны проектировщика.
Спрашивается, что за глупости и мазохизм? Зачем сознательно усложнять использование части функций системы и почему это вдруг может быть полезно?
У нас в команде давно есть вялотекущий холивар на тему «допустимо ли пихать логику в объекты как в классическом ООП» (также известный как старый срач на тему «богатые vs анемичные модели»). Я хотел на эту тему накатать целую статью с разбором всей истории с точки зрения SOLID’а и коннасценции, потом нашел уже готовый такой разбор, понял, что все уже украдено до нас и попустился. Но все еще не могу не отметить, как забавно выглядят манипуляции коннотацией, которым можно даже поучиться.
(Спойлер: рота, ложная тревога, всем вернуться в офис к своим смузи, никто вас на завод все равно не пустит)
С удовольствием, близким к половому, я в очередной раз наблюдаю статьи и разговоры про то, что «скоро программистам придется идти работать на завод или торговать жопой«. И, вы таки не поверите, на этот раз профессию уничтожит (ну или, как минимум, существенно покоцает) ничто иное как lowcode/nocode платформы. Да, опять! И хотя эта бесконечная шарманка про визуальное программирование, которое сделает ненужными программистов, посещает нас каждые лет десять, все равно на каждый такой наброс в комментариях вместе с адекватными людьми обязательно вылупляется несколько паникующих айтишных истеричек с воплями «ну все, нам пиздец, а я еще за курсы не расплатился«.
В общем, как всем известно, каждый день без моего ценного мнения наш мир скатывается в пучину хаоса и бессмысленности, а каждый мой пост добавляет в мир гармонии и упорядоченности. Поэтому пришло время высказаться и открыть страшную тайну, почему это самое визуальное программирование ничего с программистами не сделало в прошлые разы, обломается в этот раз и вряд ли что-то сделает в ближайшие десятилетия, а то заебали уже со своим нытьем.
Специфическая черта хорошо написанных книг — после прочтения они кажутся сильно лучше, умнее и логичнее, чем есть на самом деле. И наоборот — чем хуже написана книга, тем сложнее заметить ее хорошие стороны.
Редкий случай, но книжка «Чистая архитектура» Роберта Мартина относится именно к первому типу — при всех проблемах как концепции, так и самой книги, она хорошо написана, влетает в мозг как по маслу и из-за этого приобрела много слепых сторонников своих идей, а местами так вообще появился легкий запашок сектантства (в основном, вокруг аббревиатуры SOLID). У меня же за годы, прошедшие с момента ее прочтения, накопилось слишком много всякого сказать по теме, так что время пришло.
Так как тема обширная и сама собой разделяется на две части (прям как жопа), сегодня мы вкратце пройдемся именно по книжке, ее плюсам и минусам. А в следующий раз поговорим конкретно про концепцию чистой архитектуры и ее проблемы (спойлер: да, на мой взгляд их там есть)
Программист, политрук тебе врет! Он говорит тебе, что микросервисы нужны для простого скейлинга — как будто тебе кто-то мешает запихать в образ весь монолит целиком и его отскейлить по 50 нодам, ведь скейлинг по сути упирается в данные. Политрук говорит тебе, что микросервисы нужны, чтобы эффективнее распараллеливать разработку — но ты и сам понимаешь, что это брехня, ведь пока не отрисуешь всю архитектуру системы, не нарежешь микросервисы и не согласуешь контракты, никакой разработки не будет, а то же самое вполне можно провернуть и с монолитом, если разработчикам хватит дисциплины.
Так зачем же нужны миросервисы, спросишь ты? Да нахер они тебе не нужны, отвечу я — и буду прав. Потому что это одна из тех концепций, которая может быть очень полезной, но только в действительно умелых руках (гусары, традиционно молчать!). И эти руки — не программистские. А если ты задаешь такие вопросы, значит тебе оно точно не надо.
