Я понимаю, что автор использовал именно корень от пи, а не что-то другое. -1 шаг на то, чтобы разобраться как работает формула.
Вообще, я согласен, что бывают случаи, когда не нужны именованные переменные. Обычно, это формулы, из других источников. Например конвертация цветов из RGB в HSV не требует объяснения, что это за переменные, но требует ссылки на то место, откуда они взялись. Я сам писал классификатор роста, которые превращал рост в "низкий", "средний" и "высокий" на верхней и нижней границы среднего роста. Константы были получены от заказчика и забиты в код как есть, без названий типа "верхняя граница низкого роста", т.к. из кода было всё очевидно.
В то же время, я против потери информации. Если использовали формулу из внешнего источника - добавь ссылку в комментарии. Если подобрал коэффициенты и хз почему они работают - добавь комментарий. Если коэффициентами в формуле можно поиграть - занеси их в константы, будет как конфиг. Если число из предметной области, назови его, облегчи труд идущего следом.
А за константы вида twentynine, нужно заворачивать ПР, ибо они не добавляют ничего кроме шума.
Т.е. метод проверяет предусловия и в этом нет ничего плохого, особенно когда либы пишешь. Такое исключение говорит о том, что программисты, которые вызывали код, облажались и приложению не остаётся ничего, кроме как принять этот факт, а программистам поправить код.
В идеальном мере метод описывает свои предусловия через принимаемые типы, но не везде это возможно или вообще целесообразно. Например, на шарпах мы раньше много писали проверок на null в своём коде "на всякий случай", но теперь у нас есть nullable refrence type и по сигнатуре метода сразу видно, можно туда null пихать или нет. А проверка на null теперь ответственность вызывающей строны, которая отодвигается всё дальше и дальше, вплоть до контроллера, который автоматом отдаёт 400 если поле null.
У меня есть заказ и есть процесс отправки заказа в другую систему. Это две разные штуки и их не хочется смешивать. И так получилось, что они 1 к 1.
Часто встречаются примеры, когда есть таблица на 100 колонок, большинство из которых null и большая часть из которых нужна для каких процессов, про которые никто не знает. Вставить туда что-то уже подвиг.
К сожалению, всегда приходится тратить некоторое количество усилий на поддержание порядка в коде. По сути, от кривых рук не спасёт ничего, кроме физических ограничений, аля "вот контракт микросервиса от ребят с большими головами, внутри делай что хочешь, всё равно можно за день будет разобраться и переписать".
Я честно потырил идеи для своих бэкендов из статьи Clean Architecture и не испытываю особых проблем в своих применениях.
А какие абстракции могут протекать? Хочу поупрожняться в том, как я бы это решил.
Я начну: у ентитей есть приватный конструктор, чтобы Dapper мог создать объект из бд.
К сожалению код для машин и для людей требует разного и выглядит по разному. Это противоречие, нам приходится решать выбирая оптимальный вариант по ситуации. Иногда нам нужна поддерживаемость, иногда производительность.
В вопроса иерархия vs свич я обычно следую такому правилу: если набор операций не меняется, делаю иерархию, т.к. можно легко добавить новый тип, если часто дорабатывается набор операций - то свич, который часто выглядит как словарь ключ:операция.
У автора всё гладко получилось, но чтобы он делал, если бы потребовалось вычислять площадь произвольного многоугольника на точках или каких-нибудь параметрических кривых? Я бы хотел, чтобы такой жил в своём отдельном файле и не попадался разрабам на глаза без надобности.
Самая сложная часть - это не структура проекта, а разделение на модули.
Пройдёт совсем немного времени, прежде чем появится папка Common. А потом юзинги на типы из других модулей и мы получим всё тот же ком грязи.
Можно сказать "а вы следите за изоляций модулей, проектируйте домен и всё будет хорошо". Но на практике почему-то так не получается, т.к. требуется дисциплина и небольшие "срезания углов" будут постепенно накапливаться. Изоляция предполагает дублирование, которое сложно обосновать, когда всё рядом и решарпер сам подключает юзинги.
Кроме дисциплины, единственный известный мне путь - это физический запрет смешения кода модулей: тесты архитектуры, чтобы не выкладывалось в случае нарушения архитектуных правил, разделение модулей на сборки, чтобы физически нельзя было подключить лишнее или микросервисы.
Вообще, я за разделение на модули, но без фанатизма, не слишком мелко, т.к. изоляция тоже увеличивает сложность.
Вместо размазывания БЛ мы помещаем ее в объекты бизнес логики Entity, Aggregate
А это видно в примере? Я вот пытаюсь понять в чём и где профит по сравнению с обычное анемичной моделью и до меня не доходит.
Допустим у меня уже есть единый язык и 50 юскейсов. В чём выгода, если юскейсы превратятся в последовательную мутацию промежуточных ДТО (R.O.P имитируем ифами) по сравнению с простым кодом? Я думал, что может в переиспользовании отдельных шагов, но выглядит так, что каждый юскейс под свой конвеер создаёт кучу промежуточных ДТО и они не переиспользуется.
Хотелось бы видеть реализацию какой-нибудь CRUD задачи, когда нужно обновить некую сущность в соответствии с какими-нибудь бизнес правилами. Например: при создании заказа нужно проверить, что средств хватает, сохранить выбранные строчки корзины в заготовку заказа, поставить в очередь задачу на отправку письма о созданом заказе, поставить в очередь задачу на дальнейшую обработку заготовки заказа, удалить строки из корзины.
Я понимаю, что автор использовал именно корень от пи, а не что-то другое. -1 шаг на то, чтобы разобраться как работает формула.
Вообще, я согласен, что бывают случаи, когда не нужны именованные переменные. Обычно, это формулы, из других источников. Например конвертация цветов из RGB в HSV не требует объяснения, что это за переменные, но требует ссылки на то место, откуда они взялись. Я сам писал классификатор роста, которые превращал рост в "низкий", "средний" и "высокий" на верхней и нижней границы среднего роста. Константы были получены от заказчика и забиты в код как есть, без названий типа "верхняя граница низкого роста", т.к. из кода было всё очевидно.
В то же время, я против потери информации. Если использовали формулу из внешнего источника - добавь ссылку в комментарии. Если подобрал коэффициенты и хз почему они работают - добавь комментарий. Если коэффициентами в формуле можно поиграть - занеси их в константы, будет как конфиг. Если число из предметной области, назови его, облегчи труд идущего следом.
А за константы вида twentynine, нужно заворачивать ПР, ибо они не добавляют ничего кроме шума.
Что такое sqrt_of_pi я понимаю, а что такое twentynine не очень. Почему 29, а не 30, например?
А если бы это был какой-нибудь debug assert?
Т.е. метод проверяет предусловия и в этом нет ничего плохого, особенно когда либы пишешь. Такое исключение говорит о том, что программисты, которые вызывали код, облажались и приложению не остаётся ничего, кроме как принять этот факт, а программистам поправить код.
В идеальном мере метод описывает свои предусловия через принимаемые типы, но не везде это возможно или вообще целесообразно. Например, на шарпах мы раньше много писали проверок на null в своём коде "на всякий случай", но теперь у нас есть nullable refrence type и по сигнатуре метода сразу видно, можно туда null пихать или нет. А проверка на null теперь ответственность вызывающей строны, которая отодвигается всё дальше и дальше, вплоть до контроллера, который автоматом отдаёт 400 если поле null.
У меня есть заказ и есть процесс отправки заказа в другую систему. Это две разные штуки и их не хочется смешивать. И так получилось, что они 1 к 1.
Часто встречаются примеры, когда есть таблица на 100 колонок, большинство из которых null и большая часть из которых нужна для каких процессов, про которые никто не знает. Вставить туда что-то уже подвиг.
К сожалению, всегда приходится тратить некоторое количество усилий на поддержание порядка в коде. По сути, от кривых рук не спасёт ничего, кроме физических ограничений, аля "вот контракт микросервиса от ребят с большими головами, внутри делай что хочешь, всё равно можно за день будет разобраться и переписать".
Я честно потырил идеи для своих бэкендов из статьи Clean Architecture и не испытываю особых проблем в своих применениях.
А какие абстракции могут протекать? Хочу поупрожняться в том, как я бы это решил.
Я начну: у ентитей есть приватный конструктор, чтобы Dapper мог создать объект из бд.
— В репе есть что-нибудь, что в случае утечки могло бы нанести удар по репутации заказчика?
— Да, код.
С точки зрения "пиши при вызове await" никакой проблемы с изучением нет.
Не помню, когда в работе мне нужно было что-то сложнее чем Task.WhenAll и Task.WhenAny.
Через него, главное расширенный режим поиска включить (левый нижний угол)
К сожалению код для машин и для людей требует разного и выглядит по разному. Это противоречие, нам приходится решать выбирая оптимальный вариант по ситуации. Иногда нам нужна поддерживаемость, иногда производительность.
В вопроса иерархия vs свич я обычно следую такому правилу: если набор операций не меняется, делаю иерархию, т.к. можно легко добавить новый тип, если часто дорабатывается набор операций - то свич, который часто выглядит как словарь ключ:операция.
У автора всё гладко получилось, но чтобы он делал, если бы потребовалось вычислять площадь произвольного многоугольника на точках или каких-нибудь параметрических кривых? Я бы хотел, чтобы такой жил в своём отдельном файле и не попадался разрабам на глаза без надобности.
Я из списка делаю массив с помощью замены
\r\nна",\r\n", потом, правда, ещё приходится добавить начальную и конечную кавычку.Самая сложная часть - это не структура проекта, а разделение на модули.
Пройдёт совсем немного времени, прежде чем появится папка Common. А потом юзинги на типы из других модулей и мы получим всё тот же ком грязи.
Можно сказать "а вы следите за изоляций модулей, проектируйте домен и всё будет хорошо". Но на практике почему-то так не получается, т.к. требуется дисциплина и небольшие "срезания углов" будут постепенно накапливаться. Изоляция предполагает дублирование, которое сложно обосновать, когда всё рядом и решарпер сам подключает юзинги.
Кроме дисциплины, единственный известный мне путь - это физический запрет смешения кода модулей: тесты архитектуры, чтобы не выкладывалось в случае нарушения архитектуных правил, разделение модулей на сборки, чтобы физически нельзя было подключить лишнее или микросервисы.
Вообще, я за разделение на модули, но без фанатизма, не слишком мелко, т.к. изоляция тоже увеличивает сложность.
А это видно в примере? Я вот пытаюсь понять в чём и где профит по сравнению с обычное анемичной моделью и до меня не доходит.
Допустим у меня уже есть единый язык и 50 юскейсов. В чём выгода, если юскейсы превратятся в последовательную мутацию промежуточных ДТО (R.O.P имитируем ифами) по сравнению с простым кодом? Я думал, что может в переиспользовании отдельных шагов, но выглядит так, что каждый юскейс под свой конвеер создаёт кучу промежуточных ДТО и они не переиспользуется.
Хотелось бы видеть реализацию какой-нибудь CRUD задачи, когда нужно обновить некую сущность в соответствии с какими-нибудь бизнес правилами. Например: при создании заказа нужно проверить, что средств хватает, сохранить выбранные строчки корзины в заготовку заказа, поставить в очередь задачу на отправку письма о созданом заказе, поставить в очередь задачу на дальнейшую обработку заготовки заказа, удалить строки из корзины.