Поддержу. В жизни не было и мысли относиться к кому-то иначе, основываясь на его цвете кожи и т.п, но всё это движение приводит к возникновению исключительно негативных мыслей. Приходится сдерживать себя, ведь очень легко провалиться в «враг моего врага — мой друг» и начать желать успеха людям с другой стороны баррикад.
Что ещё печальнее, я искренне не думаю, что это помогает борьбе с реальным расизмом. Получается, мало того, что мы не решаем настоящую проблему, мы ещё и создаём новые. Хотелось бы верить, что я ошибаюсь, переименование бранчей кому-то помогает и не превратится со временем в цензуру всего и вся.
Вообще, самое главное, по моему мнению, обеспечить типобезопасность для API, для этого нужны статически типизированные языки на фронте и бэке и единый источник правды, из которого потом будут сгенерированы клиенты API / интерфейсы для серверов. А что будет этим источником правды — спека swagger или классы с аннотациями — не так важно и определяется скорее структурой команды и/или проекта.
Абсолютно согласен, в идеале докинуть сверху consumer-driven contracts.
Спасибо за обсуждение.
Если в API что-то поменять, то при сборке будут заново сгенерированы клиент, интерфейсы контроллеров и DTO
Самописного кода у вас там нет? Боюсь, как бы генератор его не потерял.
Главный плюс такого подхода: фронтенд-разработчик может менять спеку API так, как нужно ему, не зная java
Абстрактно соглашусь, но на практике как часто вам нужно менять модель и не менять сам код АПИ? Грубо говоря, если я добавил новое поле к условному заказу, то мне и обрабатывать его надо, так что бекенд работа всё равно присутствует.
Это в корне не верно. OpenApi — пром. стандарт описания сервисов, соответственно пишутся сервисы на сваггере, и из сваггер-описания генерируются заглушки с исходным кодом с готовым транспортом и валидацией. А не наоборот.
Не работал с таким потоком, работал с указанным автором source -> spec (причём в .NET с этим было ноль проблем).
Что, в вашем варианте, происходит при обновлении сервиса? Скажем, я добавляю поле в модель. Я должен добавить его в спецификации и у меня автоматически обновится соответствующая модель в исходном коде?
IMO много воды, мало конкретики и реально интересных вещей. Не заметил упоминания темы vendor lock-in, выбора корректной базы данных исходя из load pattern приложения и многих других вещей. Приведённый пример вообще выглядит как маркетинг для клиента.
Решением стала разработка новой микросервисной архитектуры ДБО, в которой каждый микросервис имеет отдельную базу данных, обеспечивая доступность приложения в любой момент. Результаты – в 5 раз меньше сбоев уже на старте, возможность выпускать несколько релизов каждую неделю. При этом сохранение экспертизы на своей стороне позволило банку дальше развивать продукт самостоятельно или с привлечением любого подрядчика.
1. Сомневаюсь, что микросервисы с отдельными базами могут обеспечить доступность всего приложения. Его частей — безусловно.
2. За счёт чего в 5 раз меньше сбоев? Какого рода сбои? Почему отдельные базы сервисы и базы их решили?
3. Про экспертизу на сторона клиента читается как «когда мы меняли архитектуру, мы не нагородили там такого треша, что клиент не смог бы потом поддерживать». Ну, круто.
Хотелось бы более комплексных историй. Например, возьмём, сравнение разных message queues для конкретного юз-кейса. Поэтапно: вот была такая задача, мы решили что нужна очередь, так мы выбирали. Смотрели, скажем, на скорость, на то, есть ли у клиента опыт с этой конкретной технологией, на интеграцию технологии с нашим стеком, etc.
Пока что статья выглядит крайне слабо. Бросаем наших архитекторов на проект, они делают магию, всем хорошо.
Скорее этими причинами будет рантайм, стандартная библиотека и фреймворки, тулинг в виде IDE, систем сборки, мониторинга
Именно так. Как раз поэтому в индустрии доминируют языки, в которых, на мой взгляд, и нет очень даже ценных фич именно в плане языка.
То, что вы упомянули это приятные вещи, но ни одна из них и они все вместе не станут причиной выбрать язык для нового проекта
Это применимо и к функциям, и к замыканиям, и к остальным фичам. Язык со всеми этими фичами, но без рантайма, библиотеки и т.п очень вряд ли будет выбором, если только не нишевым.
Собственно, не понял вашу линию рассуждений. Давайте вы приведёте пример нормальных языков, а мы посмотрим, какие в них есть полезные из ФП фичи и каких условно бесполезных нет.
В случае с медиатр все очевидно, контролер не делает ничего связаного с бизнес логикой
Этого можно добиться и без него. Достаточно обернуть ваш хендлер из примера выше в абстракцию и брать зависимость в контроллере на неё, а не на ISomeRepositoty и ISomeService. Таким образом, контроллер будет явно в своём конструкторе говорить, сколько бизнес-операций он совершает. Если много — дробим.
На моей практике контроллеры с 5+ операциями встречались относительно редко, а если и встречались — эта проблема решается не тем, что мы просто скрыли весь код за медиатором.
Не холивора ради, я искренне не понимаю, почему скрыв код за неявной фабрикой хендлеров мы считаем, что он стал лучше. Сложность класса-то от этого не поменялась, он как делал Х вещей, так и делает их, только теперь об этом не узнать.
Соглашусь, лично мне местами изменения кажутся сомнительными, особенно сравнивая с Scala, где те же case classes выглядят как-то попроще. С nullability вообще грустно, но что поделать, наследие.
Насчёт синтаксиса было смешно: data class решили упростить до просто record, таким образом в ближайшее время планируют public record Person. На структуры не работает, но если таки допилят и для них, то обновят и надо будет писать public record class Person. В обсуждении этого дела успели набрать ~50 комментов .
Первый, зачем было инициализировать все остальные зависимости? Все ресурсы на их инициализацию были потрачены в пустую
Если дело именно в оптимизации инициализации — я бы рассматривал это в последнюю очередь. Красивый и производительный код по моему опыту часто противоречат друг другу. Если сильно хотите — эти зависимости можно сделать ленивыми.
Второй, как мне помогло знание того, что этот контролер требует 12 зависимостей? Как по мне, оно только ввело в заблуждение.
Ну, у меня логика простая — явное лучше неявного. Соответственно я вижу 10 зависимостей и понимаю:
1. Возможно, контроллер плоховато написан и его стоит переписать.
2. Да, у него 10 зависимостей, но у него нет 11 и 12.
В случае с медиатр вы видите красивое IMediatr, контроллер до сих пор делает кучу вещей, только это абсолютно не очевидно.
Про Service Locator:
Не совсем понял что имеется виду. Можете уточнить?
Есть такой паттерн, который предполагает что вместо того, чтобы брать зависимость от сервиса, вы берёте зависимость от «локатора», который умеет эту зависимость доставать. В итоге с точки зрения конструкторов (наиболее частый способ DI в моей практике) мы имеет IServiceLocator везде, но зато в каждом методе мы можем волшебно забрать себе хоть 10 сервисов.
Подробнее можно глянуть, например, тут.
Пишу 20 лет на ФП и никаких проблем ФП мне не принес. И сериализация и ОРМ все отлично работает.
Вы пишете 20 лет на языке, в котором изначально не было полноценных иммьютабл структур данных и средств работы с ними, и у вас ни один из компонентов экосистемы не имеет с ними проблем? Искренне завидую, у меня всё не так просто. Не подскажете, что за язык?
Все нормальные языки уже давно большую часть ценных идей впитали.
Ради интереса, какие это идеи и какие языки? Я работал с C#, VB, Java и там не хватает очень многих вещей, которые есть даже в примитивнейших F#/Scala, не говоря уже про более развитые языки.
Дабы не быть голословным, несколько примеров из C# (часть этих вещей уже есть, но появились очень-очень недавно):
1. Non-nullable types by default (Optional, Maybe, etc) — огромное количество ошибок у нас возникает как раз по причине NPE. Наконец появилось в последнем C#, Java не смотрел.
2. Exhaustive pattern matching and discriminated unions — очень помогают для описания раздельных состояний. Пока не завезли.
3. Records (Scala's case classes) — в разы уменьшают количество бесполезного кода при описании структур. Также не завезли, есть 3P решения.
гораздо легче прочитать 100-строчный файл, чем продираться через 5000-строчный.
Разве современные ide не умеют в сворачивание тела? С трудом представляю себе, чтобы я хотел посмотреть на список методов контроллера и доблестно скроллил через код этих методов.
хранимые процедуры, которые и содержат всю бизнес логику?
Подскажите, пожалуйста, что вы понимаете под бизнес логикой. Как правило, в это понятие входит не только взаимодействие с базой и, лично по моему опыту, вызывать сторонние сервисы в разы проще из кода приложения, особенно учитывая, что вам хотелось бы иметь там retry policy, логирование, метрики и прочее.
Встречал у коллег подход, где хранимки использовались исключительно чтобы экономить на траффике и не слать весь запрос по сети, но это скорее исключение из правил.
При этом исключается возможность случайно создать контролер с 10 зависимостями в конструкторе, что происходит почти всегда в особо больших проектах.
Становится ли от этого легче? Теперь вместо 10 зависимостей у контроллера 1 зависимость медиатр и по конструктору нельзя даже предположить, что делает и чего не делает контроллер. Напоминает service locator, не находите?
Да ладно, правда что-ль? Ну вот серьезно, неужели упомянутые вами же статьи типа … монады в картинках не дали вам никакого практического понимания?
Лично мне — возможно какое-то и дали, но назвать это пониманием можно лишь с натяжкой. Точно так же, как прочтение про абстрактный паттерн фабрика позволяет понять, что «ну он что-то там создаёт», но не позволяет прочувствовать, где, как и когда его полноценно применять, особенно если сложность проекта выше, чем манипуляции с числами и вводом пользователя.
До сих пор не могу сказать, что понимаю монады с математической точки зрения, но как условный паттерн программирование начал их понимать исключительно после того, как сам написал несколько примитивных и на практике посмотрел на разницу кода с ними и без них. Возможно, это мне не хватает воображения и абстрактного мышления, но я всячески приветствую подобные статьи и очень надеюсь, что со временем ФП будет всё больше и больше проникать в индустрию.
Правда, не могу сказать, что всё так радужно, ведь ФП приносит новые проблемы. К примеру, иммутабельные структуры (поправьте, если не прав) требуют наличия линз или схожих механизмов для удобной работы с ними. В языке, где их изначально нет, получается интересная ситуация, когда вроде как иммутабельные структуры это хорошо и все согласны, но вот фреймворк сериализации с ними не работает, ОРМ — не работает, генератор фейковых данных для юнит и интеграционных тестов — не работают.
Программист пишет больше или меньше кода, и баги допускает тоже программист.
С одной стороны соглашусь, но в целом логика опасная. Если язык позволяет мне на этапе компиляции увидеть, что я забыл обработать null ref — при прочих равных этот язык лучше. Можно заставить программиста по несколько раз пересматривать свой код, городить стены тестов, но зачем?
Напомнило, как у нас были проблемы с внесением изменений в один конкретный сервис, в котором архитектура отличалась от остальных. Авторы сервиса в ответ предложили «просто писать без багов». Спасибо, но лучше я буду считать себя глупым и невнимательным разработчиком и напишу так, чтобы потом поддерживать было легче.
Ну вот у меня две десятки: ноут с про версией и стик с хз какой версией.
Про версия, насколько я помню, сама по себе не значит, что обновления не будут качаться. Загляните в групповые политики.
Вот, к примеру, мои настройки — есть нотификации про обновления, но сама ничего не качает и не ставит, хоть по несколько недель жди.
Opt-in nullability таки завезли и можно пользоваться, правда она местами косячно работает: требует shut-up операторов, неудобно работать с nullable value types, которые появились раньше. Однако, польза всё равно заметна.
chersanya
В F# — нет null (в 99% случаев, на практике он может прилететь из того же C#). Но, к сожалению, F# и не мейнстрим язык.
Что ещё печальнее, я искренне не думаю, что это помогает борьбе с реальным расизмом. Получается, мало того, что мы не решаем настоящую проблему, мы ещё и создаём новые. Хотелось бы верить, что я ошибаюсь, переименование бранчей кому-то помогает и не превратится со временем в цензуру всего и вся.
Абсолютно согласен, в идеале докинуть сверху consumer-driven contracts.
Спасибо за обсуждение.
Самописного кода у вас там нет? Боюсь, как бы генератор его не потерял.
Абстрактно соглашусь, но на практике как часто вам нужно менять модель и не менять сам код АПИ? Грубо говоря, если я добавил новое поле к условному заказу, то мне и обрабатывать его надо, так что бекенд работа всё равно присутствует.
Не работал с таким потоком, работал с указанным автором source -> spec (причём в .NET с этим было ноль проблем).
Что, в вашем варианте, происходит при обновлении сервиса? Скажем, я добавляю поле в модель. Я должен добавить его в спецификации и у меня автоматически обновится соответствующая модель в исходном коде?
1. Сомневаюсь, что микросервисы с отдельными базами могут обеспечить доступность всего приложения. Его частей — безусловно.
2. За счёт чего в 5 раз меньше сбоев? Какого рода сбои? Почему отдельные базы сервисы и базы их решили?
3. Про экспертизу на сторона клиента читается как «когда мы меняли архитектуру, мы не нагородили там такого треша, что клиент не смог бы потом поддерживать». Ну, круто.
Хотелось бы более комплексных историй. Например, возьмём, сравнение разных message queues для конкретного юз-кейса. Поэтапно: вот была такая задача, мы решили что нужна очередь, так мы выбирали. Смотрели, скажем, на скорость, на то, есть ли у клиента опыт с этой конкретной технологией, на интеграцию технологии с нашим стеком, etc.
Пока что статья выглядит крайне слабо. Бросаем наших архитекторов на проект, они делают магию, всем хорошо.
Именно так. Как раз поэтому в индустрии доминируют языки, в которых, на мой взгляд, и нет очень даже ценных фич именно в плане языка.
Это применимо и к функциям, и к замыканиям, и к остальным фичам. Язык со всеми этими фичами, но без рантайма, библиотеки и т.п очень вряд ли будет выбором, если только не нишевым.
Собственно, не понял вашу линию рассуждений. Давайте вы приведёте пример нормальных языков, а мы посмотрим, какие в них есть полезные из ФП фичи и каких условно бесполезных нет.
Этого можно добиться и без него. Достаточно обернуть ваш хендлер из примера выше в абстракцию и брать зависимость в контроллере на неё, а не на ISomeRepositoty и ISomeService. Таким образом, контроллер будет явно в своём конструкторе говорить, сколько бизнес-операций он совершает. Если много — дробим.
На моей практике контроллеры с 5+ операциями встречались относительно редко, а если и встречались — эта проблема решается не тем, что мы просто скрыли весь код за медиатором.
Не холивора ради, я искренне не понимаю, почему скрыв код за неявной фабрикой хендлеров мы считаем, что он стал лучше. Сложность класса-то от этого не поменялась, он как делал Х вещей, так и делает их, только теперь об этом не узнать.
Ну, так, что я про это и уточняю в своём посте:
Соглашусь, лично мне местами изменения кажутся сомнительными, особенно сравнивая с Scala, где те же case classes выглядят как-то попроще. С nullability вообще грустно, но что поделать, наследие.
Насчёт синтаксиса было смешно:
data classрешили упростить до простоrecord, таким образом в ближайшее время планируютpublic record Person. На структуры не работает, но если таки допилят и для них, то обновят и надо будет писатьpublic record class Person. В обсуждении этого дела успели набрать ~50 комментов .Если дело именно в оптимизации инициализации — я бы рассматривал это в последнюю очередь. Красивый и производительный код по моему опыту часто противоречат друг другу. Если сильно хотите — эти зависимости можно сделать ленивыми.
Ну, у меня логика простая — явное лучше неявного. Соответственно я вижу 10 зависимостей и понимаю:
1. Возможно, контроллер плоховато написан и его стоит переписать.
2. Да, у него 10 зависимостей, но у него нет 11 и 12.
В случае с медиатр вы видите красивое IMediatr, контроллер до сих пор делает кучу вещей, только это абсолютно не очевидно.
Про Service Locator:
Есть такой паттерн, который предполагает что вместо того, чтобы брать зависимость от сервиса, вы берёте зависимость от «локатора», который умеет эту зависимость доставать. В итоге с точки зрения конструкторов (наиболее частый способ DI в моей практике) мы имеет IServiceLocator везде, но зато в каждом методе мы можем волшебно забрать себе хоть 10 сервисов.
Подробнее можно глянуть, например, тут.
Вы пишете 20 лет на языке, в котором изначально не было полноценных иммьютабл структур данных и средств работы с ними, и у вас ни один из компонентов экосистемы не имеет с ними проблем? Искренне завидую, у меня всё не так просто. Не подскажете, что за язык?
Ради интереса, какие это идеи и какие языки? Я работал с C#, VB, Java и там не хватает очень многих вещей, которые есть даже в примитивнейших F#/Scala, не говоря уже про более развитые языки.
Дабы не быть голословным, несколько примеров из C# (часть этих вещей уже есть, но появились очень-очень недавно):
1. Non-nullable types by default (Optional, Maybe, etc) — огромное количество ошибок у нас возникает как раз по причине NPE. Наконец появилось в последнем C#, Java не смотрел.
2. Exhaustive pattern matching and discriminated unions — очень помогают для описания раздельных состояний. Пока не завезли.
3. Records (Scala's case classes) — в разы уменьшают количество бесполезного кода при описании структур. Также не завезли, есть 3P решения.
Разве современные ide не умеют в сворачивание тела? С трудом представляю себе, чтобы я хотел посмотреть на список методов контроллера и доблестно скроллил через код этих методов.
Подскажите, пожалуйста, что вы понимаете под бизнес логикой. Как правило, в это понятие входит не только взаимодействие с базой и, лично по моему опыту, вызывать сторонние сервисы в разы проще из кода приложения, особенно учитывая, что вам хотелось бы иметь там retry policy, логирование, метрики и прочее.
Встречал у коллег подход, где хранимки использовались исключительно чтобы экономить на траффике и не слать весь запрос по сети, но это скорее исключение из правил.
Становится ли от этого легче? Теперь вместо 10 зависимостей у контроллера 1 зависимость медиатр и по конструктору нельзя даже предположить, что делает и чего не делает контроллер. Напоминает service locator, не находите?
Лично мне — возможно какое-то и дали, но назвать это пониманием можно лишь с натяжкой. Точно так же, как прочтение про абстрактный паттерн фабрика позволяет понять, что «ну он что-то там создаёт», но не позволяет прочувствовать, где, как и когда его полноценно применять, особенно если сложность проекта выше, чем манипуляции с числами и вводом пользователя.
До сих пор не могу сказать, что понимаю монады с математической точки зрения, но как условный паттерн программирование начал их понимать исключительно после того, как сам написал несколько примитивных и на практике посмотрел на разницу кода с ними и без них. Возможно, это мне не хватает воображения и абстрактного мышления, но я всячески приветствую подобные статьи и очень надеюсь, что со временем ФП будет всё больше и больше проникать в индустрию.
Правда, не могу сказать, что всё так радужно, ведь ФП приносит новые проблемы. К примеру, иммутабельные структуры (поправьте, если не прав) требуют наличия линз или схожих механизмов для удобной работы с ними. В языке, где их изначально нет, получается интересная ситуация, когда вроде как иммутабельные структуры это хорошо и все согласны, но вот фреймворк сериализации с ними не работает, ОРМ — не работает, генератор фейковых данных для юнит и интеграционных тестов — не работают.
Не затруднит ли вас привести конкретный пример с динамический типизацией, которая позволит вам менять дизайн быстрее, чем со статической?
С одной стороны соглашусь, но в целом логика опасная. Если язык позволяет мне на этапе компиляции увидеть, что я забыл обработать null ref — при прочих равных этот язык лучше. Можно заставить программиста по несколько раз пересматривать свой код, городить стены тестов, но зачем?
Напомнило, как у нас были проблемы с внесением изменений в один конкретный сервис, в котором архитектура отличалась от остальных. Авторы сервиса в ответ предложили «просто писать без багов». Спасибо, но лучше я буду считать себя глупым и невнимательным разработчиком и напишу так, чтобы потом поддерживать было легче.
Про версия, насколько я помню, сама по себе не значит, что обновления не будут качаться. Загляните в групповые политики.
Вот, к примеру, мои настройки — есть нотификации про обновления, но сама ничего не качает и не ставит, хоть по несколько недель жди.
Opt-in nullability таки завезли и можно пользоваться, правда она местами косячно работает: требует shut-up операторов, неудобно работать с nullable value types, которые появились раньше. Однако, польза всё равно заметна.
chersanya
В F# — нет null (в 99% случаев, на практике он может прилететь из того же C#). Но, к сожалению, F# и не мейнстрим язык.