Пересмотрел пример. Наверно стоит изменить его не на name, а на description. Про речь про то, что в ответе смотря только на название функции я бы ожидал ENUM стандартизированный. А эта функция для отображения названия месяца
Про классы добавил бы что количество классов определяется принципами S и I в SOLID. Один принцип тянет класс в сторону потолстения - другой в похудение. Хороший разработчик определяется как раз - на сколько он смог найти баланс. Но как по мне проблем особых проблем от большого количества классов нет, если есть интеграционные тесты.
1.5 (если применить к примеру 1.2) про тип данных, где она хранится
Я не вижу противоречий.
На счет выделения классов я не совсем понял что вы имеете ввиду. Но предположу что вы предлагаете не делать классы, если какой-то код используется только один раз. На это я вам отвечу, что обьекты и ООП в основном были придуманы для облегчения понимания логики программы. Появляются обьекты которые моделируют обьекты реального мира, чтобы стало понятнее.
Позволю себе не согласиться с тем, что использование классов нужно для группировки. Изобретение ООП связано в первую очередь с понятными абстракциями, схожими с реальным миром. Человеку легче и понятнее с ними работать чем с функциями.
P.S. Наличие интерфейса при одной реализации реализует D в SOLID, то есть позволяет основной бизнес логике не зависеть от деталей (например, делать подключаемые модули)
TraceId - это идентификатор в которому привязаны все логи в рамках одного процесса. Например, вы в контроллере на входе пишете logger.info("Get request with params: ..."), дальше пишете в других местах куда зашел код и что произошло. Где-то вылетел Exception. В Exception handler или в ближайшем коде catch вы пишете logger.error("Catched exception", exception) и в лог у вас пишется стектрейс, так же привязанный к traceId.
То есть когда вы спрашиваете у пользователя traceId вы можете понять - какой флоу он вызвал. С какими параметрами к нам пришел. И что за exception у него вылетел.
На счет версионности - пишите в лог версию сборки приложения (обычно она итак пишется). Из нее понятно какой коммит соответствует времени когда был записан лог.
P.S. Если честно - то мне кажется вам надо посмотреть статью по ключевому слову наблюдаемость / трассировка / логировние потому что на очень долго затянулась переписка.
Мы рассматриваем поддерживаемость / читабельность кода (в первую очередь потому что именно эти показатели влияют на развитие продукта). Использование одного UserInputException с этой точки зрения противоречит этому, потому что когда разработчик читает код без текста ошибки (его нет потому что приложение не запущено) он не может понять его логику.
Что касается общения с внешними пользователями, у нас подход такой: платеж если он завершается не успешно имеет статус Declined. В самом обьекте платежа лежит enum - код ошибки.
Это может быть нехватка денег на карте или неправильные реквизиты, например - то есть то, что мы можем сообщить пользователю. Он может что-то сделать с этим.
Или если внутри системы вылетел какой-то неожиданный Exception - мы обрабатываем его через общий ExceptionHandler и логируем. Пользователю отвечаем технической ошибкой (у нас что-то сломалось) и traceId.
Если у вас есть throw new UserInputException("E111"), то в любом try вы не поймете что именно это за ошибка туда попала при чтении кода. А если UserPhoneException и UserEmailException - то поймете.
Получив такой код начинаешь рыться по форумам поддержки - документации этого ПО. В итоге это обычно приводит к тому, что ошибка в каком-нибудь драйвере видеокарты. Примерно то же самое (только чуть быстрее) было бы если бы я получил ошибку GriphicsDriverException
Мой ответ такой: для каждой неожидаемой ситуации в системе использовать исключение (нормально если их сотня и больше). Это исключение не должно показываться пользователю. Если исключение случилось - значит проблема какая-то которую пользователь не может решить - для общения по этой проблеме используем traceId
Пользователю должны показываться только те ошибки (не исключения), с которыми он может сам что-то сделать (недостаточно денег - используйте другую карту / неправильные реквизиты карты - попробуйте еще раз и тд). Их не может быть 2000 (если так - то вообще что это за софт)
Отличный пример про PSOD. Такого не должно быть впринципе. Если такая ошибка случилась - это должно быть что-то неожиданное и серьезное. Вариантов того, почему это произошло может быть огромное количество. И понимание даже конкретного эксепшна не дает полной картины - что произошло. Поможет только traceId (или логи ошибки со стектрейсом, которые и просят отправить когда падает ПО запущенное на личном компе).
Ошибок которые может решить сам пользователь обычно не очень много, если только в приложении нет бизнес логики как таковой. Чаще всего именно исключения (не ошибки) возникают в бизнес логике. Надо разбираться со стектрейсом - что произошло. Исправлять, заводить техдолги и тд
Это только одна из причин не использовать комментарии. На мой личный взгляд их устаревание сильно важнее. Но кажется, что если комментарии не нужны в 99% при чтении - то они мешают хранясь в коде - даже не смотря на то, что программисты не сильно обращают на это внимание.
Я вроде ответил на ваш вопрос по количеству exception. Для отображения пользователю я вообще не стал бы их использовать.
Для кода приложения можно использовать сколько угодно исключений и фраза "накладно" совсем мне не понятна. Возможно вы пишете код для микроконтроллеров, но тогда непонятно почему вы это делаете на C#
Еще не понял про того - кто добавил этот обработчик ошибки. Несколько людей могут изменить - что-то добавить в любой обработчик. Как вы определяете ответственного за весь класс / обработчик?
P.S. Вы не пользуетесь подходом общего владения кода? Это очень важный подход в крупных компаниях.
Вообще если серьезно - то качественный код часто пишется не с первого раза. Для этого надо написать его через TDD чтобы потом можно было его менять и рефакторить.
Что я ожидал от статьи: концепции типа единого языка (подобие глоссария все-таки было) / ограниченные контексты / аггрегаты.
Что я получил? Валидацию в обьектах похожих на DTO, генерацию UUID снаружи и TDD. А, ну еще 25 мин потраченного времени
Пересмотрел пример. Наверно стоит изменить его не на name, а на description. Про речь про то, что в ответе смотря только на название функции я бы ожидал ENUM стандартизированный. А эта функция для отображения названия месяца
Про классы добавил бы что количество классов определяется принципами S и I в SOLID. Один принцип тянет класс в сторону потолстения - другой в похудение. Хороший разработчик определяется как раз - на сколько он смог найти баланс. Но как по мне проблем особых проблем от большого количества классов нет, если есть интеграционные тесты.
1.2 про что именно хранит переменная
1.5 (если применить к примеру 1.2) про тип данных, где она хранится
Я не вижу противоречий.
На счет выделения классов я не совсем понял что вы имеете ввиду. Но предположу что вы предлагаете не делать классы, если какой-то код используется только один раз. На это я вам отвечу, что обьекты и ООП в основном были придуманы для облегчения понимания логики программы. Появляются обьекты которые моделируют обьекты реального мира, чтобы стало понятнее.
Позволю себе не согласиться с тем, что использование классов нужно для группировки. Изобретение ООП связано в первую очередь с понятными абстракциями, схожими с реальным миром. Человеку легче и понятнее с ними работать чем с функциями.
P.S. Наличие интерфейса при одной реализации реализует D в SOLID, то есть позволяет основной бизнес логике не зависеть от деталей (например, делать подключаемые модули)
TraceId - это идентификатор в которому привязаны все логи в рамках одного процесса. Например, вы в контроллере на входе пишете logger.info("Get request with params: ..."), дальше пишете в других местах куда зашел код и что произошло. Где-то вылетел Exception. В Exception handler или в ближайшем коде catch вы пишете logger.error("Catched exception", exception) и в лог у вас пишется стектрейс, так же привязанный к traceId.
То есть когда вы спрашиваете у пользователя traceId вы можете понять - какой флоу он вызвал. С какими параметрами к нам пришел. И что за exception у него вылетел.
На счет версионности - пишите в лог версию сборки приложения (обычно она итак пишется). Из нее понятно какой коммит соответствует времени когда был записан лог.
P.S. Если честно - то мне кажется вам надо посмотреть статью по ключевому слову наблюдаемость / трассировка / логировние потому что на очень долго затянулась переписка.
P.P.S. Я пользуюсь удобным инструментом копируя с прода записанный стектрейс и вставляю сразу в своей IDEA - это вообще золото - может у вас есть такое же https://www.jetbrains.com/help/idea/analyzing-external-stacktraces.html
Мы рассматриваем поддерживаемость / читабельность кода (в первую очередь потому что именно эти показатели влияют на развитие продукта). Использование одного UserInputException с этой точки зрения противоречит этому, потому что когда разработчик читает код без текста ошибки (его нет потому что приложение не запущено) он не может понять его логику.
Что касается общения с внешними пользователями, у нас подход такой: платеж если он завершается не успешно имеет статус Declined. В самом обьекте платежа лежит enum - код ошибки.
Это может быть нехватка денег на карте или неправильные реквизиты, например - то есть то, что мы можем сообщить пользователю. Он может что-то сделать с этим.
Или если внутри системы вылетел какой-то неожиданный Exception - мы обрабатываем его через общий ExceptionHandler и логируем. Пользователю отвечаем технической ошибкой (у нас что-то сломалось) и traceId.
Если у вас есть throw new UserInputException("E111"), то в любом try вы не поймете что именно это за ошибка туда попала при чтении кода. А если UserPhoneException и UserEmailException - то поймете.
Получив такой код начинаешь рыться по форумам поддержки - документации этого ПО. В итоге это обычно приводит к тому, что ошибка в каком-нибудь драйвере видеокарты. Примерно то же самое (только чуть быстрее) было бы если бы я получил ошибку GriphicsDriverException
Да
А что вы ему покажете если один микросервис системы не смог по сети сходить в другой микросевис?
В лучшем случае просто техническую ошибку. И начать разбираться даже еще до звонка пользователя (триггер на ошибки если это серьезная ошибка).
В худшем случае дать ему стектрейс и скомпрометировать код системы.
Вы не обратили внимание что я написал выше про то, что устаревание важнее (ИМХО)?
Про термины бизнес задачи - все в названия и в код (тут DDD еще проклевывается - общий язык бизнеса и разработки)
Ссылку на статью / новость - кладем в тикет систему и пишем в описание коммита (коммит могут перетереть а коммент оставить)
Мой ответ такой: для каждой неожидаемой ситуации в системе использовать исключение (нормально если их сотня и больше). Это исключение не должно показываться пользователю. Если исключение случилось - значит проблема какая-то которую пользователь не может решить - для общения по этой проблеме используем traceId
Пользователю должны показываться только те ошибки (не исключения), с которыми он может сам что-то сделать (недостаточно денег - используйте другую карту / неправильные реквизиты карты - попробуйте еще раз и тд). Их не может быть 2000 (если так - то вообще что это за софт)
Отличный пример про PSOD. Такого не должно быть впринципе. Если такая ошибка случилась - это должно быть что-то неожиданное и серьезное. Вариантов того, почему это произошло может быть огромное количество. И понимание даже конкретного эксепшна не дает полной картины - что произошло. Поможет только traceId (или логи ошибки со стектрейсом, которые и просят отправить когда падает ПО запущенное на личном компе).
Ошибок которые может решить сам пользователь обычно не очень много, если только в приложении нет бизнес логики как таковой. Чаще всего именно исключения (не ошибки) возникают в бизнес логике. Надо разбираться со стектрейсом - что произошло. Исправлять, заводить техдолги и тд
Это только одна из причин не использовать комментарии. На мой личный взгляд их устаревание сильно важнее. Но кажется, что если комментарии не нужны в 99% при чтении - то они мешают хранясь в коде - даже не смотря на то, что программисты не сильно обращают на это внимание.
Я вроде ответил на ваш вопрос по количеству exception. Для отображения пользователю я вообще не стал бы их использовать.
Для кода приложения можно использовать сколько угодно исключений и фраза "накладно" совсем мне не понятна. Возможно вы пишете код для микроконтроллеров, но тогда непонятно почему вы это делаете на C#
Еще не понял про того - кто добавил этот обработчик ошибки. Несколько людей могут изменить - что-то добавить в любой обработчик. Как вы определяете ответственного за весь класс / обработчик?
P.S. Вы не пользуетесь подходом общего владения кода? Это очень важный подход в крупных компаниях.
Для C# есть библиотека с реализацией MDC https://nlog-project.org/documentation/v4.3.0/html/T_NLog_MappedDiagnosticsLogicalContext.htm - не знаю на сколько она является стандартом. Но скорее всего есть аналоги которые являются стандартом.
Код ошибки и traceId совершенно для разных целей. Первое для наблюдаемости. Второе для того чтобы пользователь мог сам решить свою проблему.
Вообще если серьезно - то качественный код часто пишется не с первого раза. Для этого надо написать его через TDD чтобы потом можно было его менять и рефакторить.
Обычно баталии на счет времени идут по поводу TDD )