Мне было интересно прослушать Ваш доклад и очень приятно то что Вы, в качестве отправной точки, рассказали о вкладе Максима Аршинова в развитие этой очень важной темы для разработчиков вашей страны. Я могу поделиться своей историей. Я, как менеджер проекта и «представитель заказчика из-за рубежа», работал с Максимом над большим проектом более четырех лет. Со стороны команды возглавляемой Максимом в проекте участвовали не менее 10 человек, в разные периоды времени количество разработчиков менялось. Максим реализовал именно ту схему которую он подробно описал в своем докладе. Я думаю что людям прослушавшим его доклад не надо рассказывать о его высоком профессионализме; поверьте мне на слово что он не только блестящий профессионал но и прекрасный человек, менеджер и руководитель группы. Итак - проект на backend-е был реализован по схеме доклада. У разработчиков в России не было проблем найти ошибку, понять логику кода и т.п. В конце моего участия в проекте в нашу команду «тут» были взяты двое местных разработчиков. И вот у них начались проблемы, но какого рода? Они были по техническому уровню несколько ниже разработчиков команды Максима и поэтому в течении месяца-двух они вносили баги из-за непонимания структуры middleware. Если бы, до начала работы, их бы провели по схеме и рассказали как это запроектировано, проблем бы не было, но они отказались по причине "сами-с-усами". Они разобрались в конце концов, но ценой нескольких очень неприятных ошибок в production, и, кстати говоря, непрерывно жалуясь на сложность, непонятность и "зачем так сложно хотя можно просто". Я хотел рассказать о практическом опыте в котором принимал участие лично я. Я не могу назвать вам этот проект, и Максим тоже не сможет по условиям NDA, но, учитывая срок разработки и количество разработчиков, вы сами сможете представить об'ем кода. Бизнес логика была очень и очень непростая.
То есть любой разработчик, когда пишет новый метод, реализующий новую логику, вместе ним должен написать 125 явных вызовов ортогональных абстракций (скоупы логгинга, метрик, валидации, еще черте что). Каждый раз для каждого нового метода, потому что вам лень посмотреть в стартапе порядок регистрации пайплайнов? Ну отличное решение, чо. Давайте тогда сразу вернемся к процедурному программированию, там одна большая портянка на 100500 строк и все понятно, кто где чего вызывает.
@@shaqullЕсть еще 100500 вариантов добавления ортогональных ответственностей и в итоге получится тот же самый медиатр, вид сбоку. И зачем? Чтобы добавить в свой проект кучу плоходокументированного и никем не поддерживаемого инфраструктурного кода?
Не совсем ясно кто мешает расположить Request, Handler и Validator в одном классе. Тогда при одном взгляде на код становится все очевидно + IDE помогает в навигации Например у нас домен сотрудников: Feature folder - Employees; Class - AddEmployee; Employees/AddEmployee.AddEmployeeCommand Employees/AddEmployee.Handler Employees/AddEmployee.Validator Вызов из контроллера будет выглядеть так: var result = await Send(AddEmployee.AddEmployeeCommand("test-name")); При проваливании в эту команду мы сразу увидим и хендлер и валидатор в одном файле.
Чем не устраивает новый подход который выкладываем сами MS в своих примерах? Ендпоинты+обертка для агрегатов в виде репозитория, а для стремных запросов и сложных фильтров использовать спецификации к конкретным агрегатам. Минимум инфраструктурного кода, больше бизнес логики.
@@DoubleQuadruple Для микро да, для больших монолитов с десятками/сотнями эндпоинтов - бррр... Ну или решить этот вопрос раз и навсегда - json rpc! 😀😀😀
Я смотрю что современным программистам совсем сложно жить стало. То им сложно, это им не понятно. Скорее бы вас уже ChatGPT заменил и остались только нормальные программисты.
@@okke00 можно. Но это не значит что если вам что-то не понятно, то это именно сложно. Большенство чужих решений вам изначально могут показаться не понятными. Всегда можно спросить почему так, а не иначе. В чем была причина написать именно так. Если вы на это не способны - вам сложно.
@@vitaliyleschenko Сложность в ПО довольно редко связана именно с доменом, как правило, это искусственная сложность, которая вызвана или несовершенством средств разработки или неумением людей писать поддерживаемый код. Первая проблема решается естественным эволюционным путем, именно поэтому мы сейчас и не пишем все на коболе или фортране каком-нибудь. Со вторым сложнее, т.к. всегда есть определенный процент разработчиков, которые считают, что на работе им надо писать код так, чтобы доказать остальным какие они крутые. Да, бывают ситуации, когда действительно сложное решение оправдано, но чаще это именно история про то, как условный Петя хотел потешить свое эго или просто развлечься. Ну и да, хорошей практикой является документировать свои решения, а не передавать знания как древние сказители, из уст в уста. Обычно если человек, неспособен описать почему было принято именно такое решение в проекте, то это решение не сильно обосновано.
Мне было интересно прослушать Ваш доклад и очень приятно то что Вы, в качестве отправной точки, рассказали о вкладе Максима Аршинова в развитие этой очень важной темы для разработчиков вашей страны. Я могу поделиться своей историей.
Я, как менеджер проекта и «представитель заказчика из-за рубежа», работал с Максимом над большим проектом более четырех лет. Со стороны команды возглавляемой Максимом в проекте участвовали не менее 10 человек, в разные периоды времени количество разработчиков менялось. Максим реализовал именно ту схему которую он подробно описал в своем докладе. Я думаю что людям прослушавшим его доклад не надо рассказывать о его высоком профессионализме; поверьте мне на слово что он не только блестящий профессионал но и прекрасный человек, менеджер и руководитель группы.
Итак - проект на backend-е был реализован по схеме доклада. У разработчиков в России не было проблем найти ошибку, понять логику кода и т.п. В конце моего участия в проекте в нашу команду «тут» были взяты двое местных разработчиков. И вот у них начались проблемы, но какого рода? Они были по техническому уровню несколько ниже разработчиков команды Максима и поэтому в течении месяца-двух они вносили баги из-за непонимания структуры middleware. Если бы, до начала работы, их бы провели по схеме и рассказали как это запроектировано, проблем бы не было, но они отказались по причине "сами-с-усами". Они разобрались в конце концов, но ценой нескольких очень неприятных ошибок в production, и, кстати говоря, непрерывно жалуясь на сложность, непонятность и "зачем так сложно хотя можно просто".
Я хотел рассказать о практическом опыте в котором принимал участие лично я. Я не могу назвать вам этот проект, и Максим тоже не сможет по условиям NDA, но, учитывая срок разработки и количество разработчиков, вы сами сможете представить об'ем кода. Бизнес логика была очень и очень непростая.
zen of pyton очень крутая философия - там сказано что "явное лучше неявного" и оно так и получается по сути))
То есть любой разработчик, когда пишет новый метод, реализующий новую логику, вместе ним должен написать 125 явных вызовов ортогональных абстракций (скоупы логгинга, метрик, валидации, еще черте что). Каждый раз для каждого нового метода, потому что вам лень посмотреть в стартапе порядок регистрации пайплайнов? Ну отличное решение, чо. Давайте тогда сразу вернемся к процедурному программированию, там одна большая портянка на 100500 строк и все понятно, кто где чего вызывает.
Добро пожаловать в гошники! 😀
С интерсептeрами+сорсгенераторами можно будет добавлять сбор метрик/логов/валидации/еще черте что без mediatr
@@shaqullЕсть еще 100500 вариантов добавления ортогональных ответственностей и в итоге получится тот же самый медиатр, вид сбоку. И зачем? Чтобы добавить в свой проект кучу плоходокументированного и никем не поддерживаемого инфраструктурного кода?
Не совсем ясно кто мешает расположить Request, Handler и Validator в одном классе.
Тогда при одном взгляде на код становится все очевидно + IDE помогает в навигации
Например у нас домен сотрудников:
Feature folder - Employees;
Class - AddEmployee;
Employees/AddEmployee.AddEmployeeCommand
Employees/AddEmployee.Handler
Employees/AddEmployee.Validator
Вызов из контроллера будет выглядеть так:
var result = await Send(AddEmployee.AddEmployeeCommand("test-name"));
При проваливании в эту команду мы сразу увидим и хендлер и валидатор в одном файле.
ну так что бы не было загадкой давайте все писать в контроллере, а ?
все новое когда - то забытое старое )
Фи, контроллеры. Прямо в Main через Minimal API!
Чем не устраивает новый подход который выкладываем сами MS в своих примерах? Ендпоинты+обертка для агрегатов в виде репозитория, а для стремных запросов и сложных фильтров использовать спецификации к конкретным агрегатам. Минимум инфраструктурного кода, больше бизнес логики.
@@DoubleQuadruple
Для микро да, для больших монолитов с десятками/сотнями эндпоинтов - бррр...
Ну или решить этот вопрос раз и навсегда - json rpc! 😀😀😀
"В индустрии использование MediatR считается хорошим тоном." - нет, не считается)
+1, это зашквар, инфа 100%
Никогда не понимал людей которые любят использовать MediatR. Мне кажется, что всегда есть поход лучше и проще.
например?
@@iamprovidence-xj5wf всегда.
@@zodchiygigas6098 какой бы подход ты посоветовал использовать в качестве замены MediatR?
Просто булькнул и ушёл..
Нет лучше/хуже. Есть явно, не явно, удобнее, сложнее :)
Наверное надо просто хорошенько во всем разобраться, а уже потом выступать с вопросом "А что-то тут мне не понятно"
🤦♂️
Богохульство, Ересь - батон крошить на MediatR! Предать анафеме! )
Я смотрю что современным программистам совсем сложно жить стало. То им сложно, это им не понятно. Скорее бы вас уже ChatGPT заменил и остались только нормальные программисты.
Ты не поверишь, но вся история IT крутится вокруг борьбы со сложностью. Так то можно и на ассемблере написать все что угодно)
@@okke00 можно. Но это не значит что если вам что-то не понятно, то это именно сложно. Большенство чужих решений вам изначально могут показаться не понятными. Всегда можно спросить почему так, а не иначе. В чем была причина написать именно так. Если вы на это не способны - вам сложно.
@@vitaliyleschenko Сложность в ПО довольно редко связана именно с доменом, как правило, это искусственная сложность, которая вызвана или несовершенством средств разработки или неумением людей писать поддерживаемый код. Первая проблема решается естественным эволюционным путем, именно поэтому мы сейчас и не пишем все на коболе или фортране каком-нибудь. Со вторым сложнее, т.к. всегда есть определенный процент разработчиков, которые считают, что на работе им надо писать код так, чтобы доказать остальным какие они крутые. Да, бывают ситуации, когда действительно сложное решение оправдано, но чаще это именно история про то, как условный Петя хотел потешить свое эго или просто развлечься. Ну и да, хорошей практикой является документировать свои решения, а не передавать знания как древние сказители, из уст в уста. Обычно если человек, неспособен описать почему было принято именно такое решение в проекте, то это решение не сильно обосновано.
Виталий был известный дворник, но по ночам в комментах срал 😁