Комментарии 33
А это не про "Моно-репозиторий" случаем рассказ. Удобная штука, кстати. Экономит человеческие ресурсы. Вот для техно-гигантов это шок конечно читать такое, что одна команда тащит целый проект на себе. У них там по 15 человек на один микросервис. А тут человек 5-6 на проект. И надо микросервисно сделать условно Авито. Естественно язык там будет один. Естественно люди придут к моно-репе. Будут код делить на слои. Техно слой закатают в либу, опубликуют локально, ибо руководство против опен-сорса условно например. Крутой термин "Квантовый сервис". Мне зашёл. Такие решение появляются от квантовых бюджетов и сроков, кстати. И о чудо, они даже работают и rps держат не хуже истинных микросервисов. А почему, да потому что там даже связи бизнес модели можно не через шины делать а просто кодом. Огонь, пушка, топчик. И шок контент. Техно-гигантам не читать. Это не микросервисы. Это квантовые сервисы. За ними будущее. Как за квантовыми компьютерами.
Спасибо большое! Моя компания занимается консультированием в области IT. Мы переписываем подобные решения ввиде наипростейшего монолита на голанге, котрый гоняется на одной EC2 medium размера. Не подскажите, где посмотреть список ваших клиентов?
Классный текст, спасибо ? Есть о чем подискутировать
"Квантовая архитектура" позволяет по максимуму устранить дублирование кода.
А всегда ли "дублирование" - это зло? Кажется этот момент стоит уточнить, возможно, ввести ограничение на применимость подхода. Что именно у вас зарыто в общей либе?
В своих проектах стараемся разделять весь код на то, что сделал один раз и с большой вероятностью не меняем (условно называем "инфраструктурный код"), и то, что меняется, логику, которая чаще уникальна (условно " бизнес-код").
Так вот, инфраструктурный код унифицируем по структуре и копируем от сервиса к сервису, а бизнесовый - он уникален и составляет суть сервиса.
Таким образом мы снижаем нагрузку на обновление-доработку общей либы, которая конечно тоже есть.
Интересно, когда уже генерация кода Т4 станет устоявшимся анти-паттерном?
Мы не находим в этом ничего "анти". Прекрасно работающее, технологичное средство. Единственное ограничение - не надо загружать в шаблон разрабатываемые сборки. Он их начинает держать даже после отрабатывания шаблона.
Можете развернуть мысль о том что "T4" это анти-паттерн?
Если вы ссылаетесь на два процессора (это такой класс с бизнес-логикой), то уместные имена будут:
ClientProcessor
,OrderProcessor
, чтобы отличить один процессор от другого.
Называть что-либо "процессор" - это уже антипаттерн.
https://stackoverflow.com/questions/5569666/what-is-a-better-name-than-manager-processor-etc
Мы нашли, что это самый информативный и удобный термин. Отказываться от него, просто потому, что кто-то назвал его антипаттерном - это странно.
Антипаттерны так и рождаются. Кто-то находит неподходящий термин удобным, распространяет идею. Через год в программе появляется второй процессор (бизнес-требования меняются) и люди понимают, что называть первый просто "processor" было неправильно.
У вас второго шага просто не произошло ещё.
Представьте себе изменение, которое надо применить ко всем контроллерам во всех микросервисах.
Собственно, это единственная проблема, которую такой монолитный подход решает. В остальном монолит только создаёт проблемы.
Но зачем изменения во всех микросервис ах? Микросервисы должны быть независимы по определению и вообще могут быть написаны на разных языках.
Микросервисы, при всей их отдельности - это часть большой системы, которая эволюционирует. Соответственно, есть изменения, которые распространяются на систему целиком и на все МС.
Всё взаимодействие с микросервисом должно быть ограничено его API и SLA. Остальное должно быть внутренним делом команды или разработчика, который его поддерживает. Откуда взяться изменениям для всех? Не политика ли случаем?
У нас все микросервисы разрабатываются одной и той же командой. От случая к случаю появляется идея, которая применима ко всем МС.
Дайте догадаюсь, это - нефункциональные требования и даже не SLA. В таких случаях новый модный фреймворк обычно обкатывают на новых микросервис ах, избавляясь от риска заодно сломать старые.
Ну а вообще, для единственной команды которая поддерживает сразу весь функционал, нужды в микросервисах вероятно, и нет
Все, конечно, элегантно пишете, и про дублирование, и про репликацию с транзакциями.. но после прочтения осталалось послевкусие.. сложности что ли
Вот прилетела вам две баги, одна инфраструктурная, одна - бизнесовая. Как вы их отлаживаете?
Как у вас с онбордингом? Сложно ли "среднему" разрабу приступить к работе, разобраться в проекте?
Есть ли какие-то правила ограничения вложенности/наследуемости компонентов? Вангую невозможность разобраться с используемостью (контракта/процессора)-наследника в десятом поколении
Инфраструктурные баги очень редки, не более 5-7% от общего числа. Они, конечно, исправляются в первую очередь, как правило.
Насчёт онбординга, пока такой проблемы не возникало, т.к. новых разработчиков на горизонте нет. Но вообще, эта статья задумывалась, в том числе, как указание на необходимость существенно расширить документацию путём добавления технического писателя.
Что касается наследования, у нас, как правило, глубина 2, в редких случаях 3.
Ну и еще вопрос о транзакции. Что у вас стоит за надежностью? Например, если когда отвалится шина?
Ни разу не видел ничего хорошего от игры в https://en.wikipedia.org/wiki/Code_golf в продакшн коде.
Ну, мы в эту игру и не играем. Мы не стремимся сделать код короче любой ценой, мы устраняем избыточность.
Ну на мой взгляд устранение избыточности это и есть укорочение любой ценой. Ведь любой символ который можно удалить избыточен. Или не любой. Кстати, а почему бы не изъять отступы? И переменные как a,b,c,d,e называть, меньше же читать? А вообще очень здраво про всё это написано в соседнем посте https://habr.com/ru/articles/750114/
Код может быть либо избыточен, либо оптимален, либо укорочен максимально. Вы говорите о максимальной краткости, а мы стремимся к золотой середине. В статье же ясно написано - "без перегибов".
Формула элегантности включает в себя гармонию, т.е. код должен быть сбалансирован (золотая середина). Сверх-сокращённый код столь же плох, как и простыни.
Главное не подменять понятия и не заниматься самообманом.
Вот вы пишите, что вместо строковых констант применяете enum-ы. Но ведь это обман. У константы можно поменять имя, и значение константы не изменится. У константы можно поменять значение, и при этом никакой код, использующий константу не поменяется. Здесь вы не можете сделать ни того, ни другого. И семантически, enum это перечисление с числовым значением, а не справочник строк.
По поводу сбалансированности. Отказ от var при чём не везде и без чётких критериев как-то играет против любого баланса.
Мне показалось, что вы вплотную подошли к границе "создадим свой ЯП поверх C#", где-то вопреки правилам, а где-то наоборот крайне консервативно (no-var). Серьёзные перекосы.
1) Мы применяем enum'ы в четырёх случаях, в одном из которых 120 элементов, соответствующих именам таблиц - а отнюдь не везде.
2) Поменять название или значение - в данном случае подпадает под YAGNI.
3) Не вижу обоснования, как явное указание типа отходит от золотой середины.
Не важно в каких случаях, если вы enum используете как строковую константу, при чём по её имени члена.
if( some == $"{MyEnum.MyValue}" ) ...
vs
if( some == "MyValue" ) ...
Почему бы тогда просто не использовать строки? Ибо первый вариант настолько плох, насколько это вообще в принципе возможно. Ну наверное nameof :)
Очень легко. Если имя типа можно заменить на var, тогда имя типа явно лишнее.
IDE сегодня достаточно продвинутые, чтобы отображать всю нужную информацию. Зачем этот обезьяний труд, как будто код пишется в блокноте и там же читается?
Статья мне понравилась, хотя есть спорные решения, и в статье есть противоречия.
А это не про "Моно-репозиторий" случаем рассказ. Удобная штука, кстати. Экономит человеческие ресурсы. Вот для техно-гигантов это шок конечно читать такое, что одна команда тащит целый проект на себе. У них там по 15 человек на один микросервис. А тут человек 5-6 на проект. И надо микросервисно сделать условно Авито. Естественно язык там будет один. Естественно люди придут к моно-репе. Будут код делить на слои. Техно слой закатают в либу, опубликуют локально, ибо руководство против опен-сорса условно например. Крутой термин "Квантовый сервис". Мне зашёл. Такие решение появляются от квантовых бюджетов и сроков, кстати. И о чудо, они даже работают и rps держат не хуже истинных микросервисов. А почему, да потому что там даже связи бизнес модели можно не через шины делать а просто кодом. Огонь, пушка, топчик. И шок контент. Техно-гигантам не читать. Это не микросервисы. Это квантовые сервисы. За ними будущее. Как за квантовыми компьютерами.
Элегантные «квантовые» микросервисы