пока ещё P = NP не доказали вроде, чтобы утверждать, что если решение занимает месяц, то и его верификация тоже будет месяц) так то можно шаги ИИ проверить и на сколько он из них сделал правильные выводы, это гораздо проще, чем с нуля самому делать
А как вы себе это представляете - сделать что-то полезное (судя по примерам - это должно быть что-то большое), прям процесс весь? Если большое, то это не один же человек делает и не бесплатно. Кто-то должен это большое захотеть, потом профинансировать, потом оранизовать всё - или это тоже всё IT-ки должны сами, самоорганизоваться? Ну ок, как-то оранизовались, что-то сделали, nginx, tg, приложения для доставки, такси, IDE - но что потом с этим происходит - оказывается что за границей это нужнее/легче развивается/не душится (а внутри страны потом вообще звонки банят). Либо талантливые специалисты понимают, что за границей больше перспектив в их сфере (возьми то же железо) оказывается - в этом всём тоже сами IT-ки виноваты?
Европа разная, Испания дальше от этого всего возможно просто (в т.ч. гограифчески), прибалтийские страны, Норвегия, например, не пустят к себе при пересчении границы шенгена (в тот же круиз с заездом в Норвегию не попасть). С посылками в/из РФ тоже могут возникнуть проблемы, что под санкции попадает груз. Банковские переводы через границу Шенгена чаще под проверки попадают даже при небольших суммах
Тут по полгода банально не можешь базового сениора найти на позицию
Тут для полноты картины нужно уточнить, что ищете сеньёра в команду, где ещё и мидлы и джун есть/планируют тоже набираться и ищите из-за роста команды, а не на замену. Ведь всё так? Да?
Замечательно и где противоречия с моими высказываниям?
Как минимум считаю полезным читающим видеть как сформулировано официально у ms, в противовес вашему утверждению что рекомендуют «Используйте исключения, они эффективны для большинства ваших задач», а дальше каждый для себя решит, что ему ближе.
Это уже не Normal Flow
Да, тут возможно не на кого сослаться для определения, хотя в тех же проектах-примерах ms, как eshop, NotFound через исключения не кидают. Ну и в целом если представить, что у нас добавление товара в корзину возвращает NotFound когда товар закончился (что случается давольно часто), чем это не normal program flow
Это у вас в Java исключения хотя бы часть сигнатуры методов. Без этого, переиспльзование бизнес логики с исключениями в новом endpoint-е потребовало бы изучить все слои, что и где там может стрельнуть, и это все замапить в http коды + OpenAPI - то ещё удовольствие
сложность не в задани перечня возвращаемых значений в каждом endpoint-е, а в контроле соотвествия, что всё, что в едином обработчике возвращается, перечислено в каждом endpoint-е (при этом скорей всего там будет с десяток возможных вариантов, но каждый endpoint может вернуть только подмножество этих кодов)
Пока нет Result-а из коробки предпочитаю создавать явно типы как:
internal abstract record CreateResult
{
public sealed record Success(SomeModel Model) : CreateResult;
public sealed record NotFound : CreateResult;
public sealed record WrongOperation : CreateResult;
}
который используется в controller-е как:
CreateResult result = await _service.Create(...);
return result switch
{
CreateResult.Success data => TypedResults.Ok(data.Model),
CreateResult.NotFound => TypedResults.NotFound(),
CreateResult.WrongOperation => TypedResults.BadRequest(),
_ => throw new ArgumentOutOfRangeException(result.GetType().Name, "Unexpected result type")
};
Если объявление CreateResult и использование в разных сборках, то дефолтный branch в switch нужен пока, к сожалению, но это отдельный вопрос
а теперь представьте, что нужно генерировать OpenAPI, чтобы клиент понимал, какие коды возможны, а у вас все NotFound и пр. в едином обработчике.
Result тут как ни как хорош. Плюс рекомендация не использовать исключения для не исключительных ситуаций (NotFound, Conflict в конкурентных системах уже становятся далеко не исключительными), скорей бы discriminated unions завезли (или как они там сейчас называются)
те, кто в теме - те в теме: у нас в сфере преобладают интроверты, да и просто взгляните вокруг, на коллег, многие сеньёоры с 5+ опыта не готовы брать джунов (ну или если берут - сколько мы негативных отзывов даже на хабре о таких наставниках слышали). Да есть исключения, плюс кто-то с опытом воспитания детей (хотя тоже искажённым - напрямую не переложить опыт). Просто это всё звучит так, как "я инженер, я во всём разберусь, хоть холодилник починить, хоть стажёров поучить, хоть на сцену выступать" - на поверхностном уровне - да, возможно, но не надо умалять каждое из направлений, на которое люди по 5 лет учатся (чтобы стать джунами в свей сфере)
всё хорошо, вот только бы такие желающие менторить ещё и имели педагогический опыт или хотя бы талант, что-то сомневаюсь, что таких много. А так конечно да - можно себе практики педагогической добавить забесплатно, другой стороне польза от этого, правда, сомнительная)
тут ощущение, что не только 3d фильмов стали мало снимать, но и просто стали гораздо меньше снимать после ковида. Вот бы на первой гистограмме ещё и количество 2d увидеть
Да, внешнее api, я понял, в use case у вас транзакция. С несколькими сохранениями на use case понятно, но тоже нарушает принцип 1 транзакция на запрос ну или всеми нелюбимые саги нужны, чтобы либо все сохранения прошли, либо ни одного
чем анализировать требуемый уровень изоляции для каждого use case
Как раз необходимость анализировать каждый кейс при UoW пока не доказана, у нас во вселенной с ORM у всех все работает без этих анализов, зато с оптимистическими блокировками и обновлениями только изменившихся полей моделей из коробки и не тормозит ничего, переходите на темную сторону)
Там - это при использовании DDD с Serializable транзакцией на весь use case или в Transaction Script? :-)
Там - это без повторения всего use case и даже без изменения модели в памяти (как я процитировал ранее), оба примера модель меняют и весь кейс повторяют
потребоваться дополнительные хаки
в DDD как раз рекомендуют не создавать агрегаты из воздуха, а чтобы один создавал другой, так что всё по канонам)
ждём когда prompt inversion нормально заработает, будет забавно почитать промты, которые стояли за статьями на хабре)
пока ещё P = NP не доказали вроде, чтобы утверждать, что если решение занимает месяц, то и его верификация тоже будет месяц)
так то можно шаги ИИ проверить и на сколько он из них сделал правильные выводы, это гораздо проще, чем с нуля самому делать
А как вы себе это представляете - сделать что-то полезное (судя по примерам - это должно быть что-то большое), прям процесс весь? Если большое, то это не один же человек делает и не бесплатно. Кто-то должен это большое захотеть, потом профинансировать, потом оранизовать всё - или это тоже всё IT-ки должны сами, самоорганизоваться?
Ну ок, как-то оранизовались, что-то сделали, nginx, tg, приложения для доставки, такси, IDE - но что потом с этим происходит - оказывается что за границей это нужнее/легче развивается/не душится (а внутри страны потом вообще звонки банят). Либо талантливые специалисты понимают, что за границей больше перспектив в их сфере (возьми то же железо) оказывается - в этом всём тоже сами IT-ки виноваты?
Европа разная, Испания дальше от этого всего возможно просто (в т.ч. гограифчески), прибалтийские страны, Норвегия, например, не пустят к себе при пересчении границы шенгена (в тот же круиз с заездом в Норвегию не попасть). С посылками в/из РФ тоже могут возникнуть проблемы, что под санкции попадает груз. Банковские переводы через границу Шенгена чаще под проверки попадают даже при небольших суммах
Тут для полноты картины нужно уточнить, что ищете сеньёра в команду, где ещё и мидлы и джун есть/планируют тоже набираться и ищите из-за роста команды, а не на замену. Ведь всё так? Да?
Как минимум считаю полезным читающим видеть как сформулировано официально у ms, в противовес вашему утверждению что рекомендуют «Используйте исключения, они эффективны для большинства ваших задач», а дальше каждый для себя решит, что ему ближе.
Да, тут возможно не на кого сослаться для определения, хотя в тех же проектах-примерах ms, как eshop, NotFound через исключения не кидают. Ну и в целом если представить, что у нас добавление товара в корзину возвращает NotFound когда товар закончился (что случается давольно часто), чем это не normal program flow
У нас черным по белому написано так
Do not use throwing or catching exceptions as a means of normal program flow, если уже критически относится. При этом эти наши кейсы из бизнес логики ведущие к возвратам тех же NotFound - normal program flow
Это у вас в Java исключения хотя бы часть сигнатуры методов. Без этого, переиспльзование бизнес логики с исключениями в новом endpoint-е потребовало бы изучить все слои, что и где там может стрельнуть, и это все замапить в http коды + OpenAPI - то ещё удовольствие
сложность не в задани перечня возвращаемых значений в каждом endpoint-е, а в контроле соотвествия, что всё, что в едином обработчике возвращается, перечислено в каждом endpoint-е (при этом скорей всего там будет с десяток возможных вариантов, но каждый endpoint может вернуть только подмножество этих кодов)
Пока нет Result-а из коробки предпочитаю создавать явно типы как:
который используется в controller-е как:
Если объявление
CreateResultи использование в разных сборках, то дефолтный branch в switch нужен пока, к сожалению, но это отдельный вопроса теперь представьте, что нужно генерировать OpenAPI, чтобы клиент понимал, какие коды возможны, а у вас все NotFound и пр. в едином обработчике.
Result тут как ни как хорош. Плюс рекомендация не использовать исключения для не исключительных ситуаций (NotFound, Conflict в конкурентных системах уже становятся далеко не исключительными), скорей бы discriminated unions завезли (или как они там сейчас называются)
те, кто в теме - те в теме: у нас в сфере преобладают интроверты, да и просто взгляните вокруг, на коллег, многие сеньёоры с 5+ опыта не готовы брать джунов (ну или если берут - сколько мы негативных отзывов даже на хабре о таких наставниках слышали). Да есть исключения, плюс кто-то с опытом воспитания детей (хотя тоже искажённым - напрямую не переложить опыт). Просто это всё звучит так, как "я инженер, я во всём разберусь, хоть холодилник починить, хоть стажёров поучить, хоть на сцену выступать" - на поверхностном уровне - да, возможно, но не надо умалять каждое из направлений, на которое люди по 5 лет учатся (чтобы стать джунами в свей сфере)
всё хорошо, вот только бы такие желающие менторить ещё и имели педагогический опыт или хотя бы талант, что-то сомневаюсь, что таких много. А так конечно да - можно себе практики педагогической добавить забесплатно, другой стороне польза от этого, правда, сомнительная)
тут ощущение, что не только 3d фильмов стали мало снимать, но и просто стали гораздо меньше снимать после ковида. Вот бы на первой гистограмме ещё и количество 2d увидеть
Так а если часть не сохранится, какая разница transaction script у нас или нет, неконситетность будет в базе же?
Конечно, нет select же в транзакции - нет проблем. Ну и никто даже теоретически пример не смог придумать, почему не сработает и в какой ситуации
Да, внешнее api, я понял, в use case у вас транзакция. С несколькими сохранениями на use case понятно, но тоже нарушает принцип 1 транзакция на запрос ну или всеми нелюбимые саги нужны, чтобы либо все сохранения прошли, либо ни одного
Страдать не приходится, когда I/o есть в use case update-а? Его же нужно как-то вне транзакции разместить, но всё ещё в use case?
Как раз необходимость анализировать каждый кейс при UoW пока не доказана, у нас во вселенной с ORM у всех все работает без этих анализов, зато с оптимистическими блокировками и обновлениями только изменившихся полей моделей из коробки и не тормозит ничего, переходите на темную сторону)
Там - это без повторения всего use case и даже без изменения модели в памяти (как я процитировал ранее), оба примера модель меняют и весь кейс повторяют
в DDD как раз рекомендуют не создавать агрегаты из воздуха, а чтобы один создавал другой, так что всё по канонам)