было бы интересно посмотреть на большой группе людей, что выбешивает быстрее — разложенные механически по «слоям» файлы ИЛИ необходимость в 99% случаев для каждого файла создавать папку, где он — этот файл — будет там в гордом одиночестве — как в примере у автора
Наверное стоило уточнить в статье, что речь про уровни используемые на продакшн. Trace для отладки я как-то само-собой разумеющимся посчитал. Хотелось заострить внимание на том, что Debug нужен именно для «боевого» применения, т.к. обычно схожие статьи выдают ему роль «только для отладки».
И с его точки зрения Success не тождественно вашему Notice.
Если в моей статье и есть какая-то ценность, то она как раз именно в том, что и с моей точки зрения его Success не равен Notice, так как есть принцип, по которому их относительно легко и однозначно ранжируем.
задача, в которой он, ну вот так вышло, хочет видеть уровень «SUCCESS»
Если вопрос в том, как зеленым строчку с success подсветить, то я не вижу ничего плохого в «подгруппах» событий в рамках одного уровня. По факту, у меня для Info есть как минимум 3 расширения: InfoAsStart, InfoAsFinish, InfoAsSuccess — я бы помечал Success записи флагом, чтобы потом отрисовщики событий могли их разукрашивать в зеленый. И это уже выводится на уровень конфигурирования, т.е. кому надо — видит зеленым, кому не надо — и так сойдет.
Если вопрос именно о принципе, когда хочется акцентировать внимание на условно положительных событиях вместо негативных, то мне кажется это довольно синтетическим сценарием. Внимание человека, наблюдающего за системой, я принимаю за ограниченный ресурс и не вижу смысла выдавать более высокий приоритет тому, на что заведомо не стоит тратить внимание при прочих равных. Может быть такой сценарий и найдется, но это явно будет исключение, а в типичном случае «негативные» событие разумнее рассматривать первыми.
Подписался бы под каждым абзацем. Даже по-своему поразительно, что можно накрутить, имея в распоряжении (в принципе) лишь алгоритмы, структуры и операции ввода-вывода.
Я так понимаю, в новом магазине (c базой данных) без этих старых пережитков, — и отделы стоит назвать «Наливают», «Нарезают», «Насыпают»? А внутри отдела по алфавиту расположить «Бензин», «Бельгийское пиво»… «Зимний бензин», «Темное Бельгийское пиво».
Вы в одном комментарии смешиваете кислое с горячим. В начале пишете про функции, а потом «понимаете» про товарные позиции.
Так смешиваю, или сперва пишу про одно, а потом про другое? Я это называю «аналогия».
Во-первых не «прям ужасно» и по-английски читается часто как обычный текст на языке.
В моем комментарии говорится что "совет, в том виде, котором он дан, ужасен". Это не то же самое, что «читается ужасно».
Имеет право на жизнь оба варианта.
Здесь я как раз согласен, только причина, почему оба варианта имеют право на жизнь, в корне другая, чем просто соглашение команды.
Если Вам действительно хочется понять мою позицию — можете ради интереса глянуть формулу количества информации в сигнале. Сигналы, у которых начало менее вариативно, всегда будут чуток отставать в скорости передачи информации и «догонять» только в самом конце при прочих равных. Если у вас все функции начинаются с get, set, handle, то после получения (прочтения) 'g', 's' и 'h' следующие 2-5 символов несут вам просто ноль информации.
Люди не дурные и чувствуют это интуитивно. Точно так, как нелеп магазин с отделами «Наливают», «Нарезают», точно также будет нелеп завод где вместо Токарного, Фрезерочного, Штамповочного, Кузнечного и что там у них еще, будут цеха «Сталь» и «Алюминий».
В программировании это не так очевидно, потому что как раз очень сильно зависит от домена.
ну тогда остается лишь префиксовать все подряд и надеяться, что не понадобится метод загрузки из базы только имени шоу — getShowName и не понадобится подключать api внешнего сервиса с AI для подбора «продающих» имен шоу — getShowName.
POST /users/{userId}/books/{bookId}/create — добавить книгу пользователю
Пишем «create», думаем «добавить». Не говоря уже о том, что технически это все будет CRUD create операция создания записи о принадлежности книги пользователю, для которой не стоит использовать глагол согласно пункта 1.
… с небольшим «тюнингом». В CRUD операциях 3 из 4 букв — это запись (input). Потому я использую глагол только для пишущих операций, а для чтения — get опускается. В сочетании с самими сигнатурами метод — пишущие в общем случае void — это более чем достаточно
может со второй попытки заметите
В этой фразе ключевое слово «алгоритм», остальное — уточнения. А вы его опускаете в результате, выбрасывая суть.
Мы же по прежнему говорим про код? Можете привести пример, когда в методе или процедуре содержится НЕ алгоритм? Чтобы у меня появился резон добавлять это уточнение — что это именно алгоритм, а не что-то другое.
Мой обычный диалог при код ревью:
— что означает переменная errorFound?
— Это — код ошибки.
— Отлично. Давай то, что ты сказал, и запишем в само имя переменной — errorCode.
— Что означает shouldShowPaginationIfTooManyRecords?
— Что нужна пагинация.
— Отлично. Давай так и запишем — pagination.
— Что означает shouldShowPaginationIfRowHeightIsVeryVeryBig?
— Что нужна пагинация.
— Отлично. У нас уже есть такая — давай эту удалим.
при нормальной архитектуре это будет очевидно из контекста. showName «как название» будет фигурировать на уровне описания структур сущностей, самом низком. showName «покажи» возможен только на уровне UI.
То есть, вместо listOrders, getOrder, updateOrder, вы пишете
ordersList, orderGet, orderUpdate?
Почти, с небольшим «тюнингом». В CRUD операциях 3 из 4 букв — это запись (input). Потому я использую глагол только для пишущих операций, а для чтения — get опускается. В сочетании с самими сигнатурами метод — пишущие в общем случае void — это более чем достаточно. Ваш пример в моем коде будет выглядеть как Orders, Order, OrderUpdate.
Но это режет слух всем
Я вот только что перепроверил, как переведет гугл транслейт фразу «алгоритм обновления заказа», коим и является OrderUpdate method — получилось «order update algorithm». Код описывает алгоритмы и структуры, логично и называть его исходя из этого, нет? Я полагаю, мода на глагольные префиксы торчит из-за путаницы с уровнем UI через CLI. На UI пользователь шлет команды, которые запускают алгоритмы. И для именования команд вроде как в самом деле интуитивней через глаголы.
Как по мне, совет в том виде, в котором он дан для функций — начинать имя с глагола — это прямо вот ужасно. Такой подход еще нормально работает в «общих библиотеках», но при попытке применить к коду, который описывает бизнес-сущности конкретного домена и где их количество (сущностей) растет как снежный ком — это просто издевательство. У меня ни разу не возникало необходимости получить или удалить что-нибудь, чтобы начать свой поиск метода с fetch или delete. Наоборот, всегда пытаешься понять, что доступно (уже написано) для каких-то конкретных сущностей и сообразить, можно ли из этого соорудить, что требуется.
Я прямо вот очень хорошо понимаю теперь, почему товарные позиции в магазинах называются в таком «дурацком» виде, типа «Томат, голландский, весовой» или «Болт, M12, оцинкованный» — поиск в списках, составленных по такому принцип — «сущность — уточнение, уточнение,…, уточнение» просто в разы удобней.
иначе говоря, можно настроить уровни внутри событий, которые по определению требуют немедленного реагирования? ну черт его знает, по мне — выглядит довольно искусственно. суть как раз и была о том, что «критичность» затмевает «уровень», и потому уровнем можно пренебречь в тех случаях
больше похоже, что под «у него» подразумевается все таки автор заглавного комментария ветки — он упоминает компоненты впервые. промежуточные уровни — это второстепенно. суть, которую я хотел вложить, была о строгом мэппинге событий на ожидаемые реакции людей, которые за этими логами обязаны присматривать.
в этом конфиге нет ничего о втором измерении { ..., Component}, о котором речь идет в моем комментарии. Если хотите считать среду за измерение — ну окей, в будет 2d структура {Уровень, Среда} вместо трехмерной {Уровень, Среда, Компонент}.
не совсем понял возможно. но то, что Вы описываете, я делаю простым конфигурированием для стейджа и прод. На стейдже в конфиге все в target="Email", на проде условно minLevel='critical' target = "Пейджер"minLevel='warning' maxLevel='error' target= "НеПейджер". (Я в основном по .NET, потому под «target» имеется ввиду target от Nlog бибилиотеки, для Serilog это 'sink' и т.д.)
Ну да — выбора то не остается в таком случае. Дополнительная отстройка по модулям/компонентам Вам доступна при любой системе записи ошибок. Смотрите, ведь я не хочу сказать никаким образом, что с Вашим подходом что-то не так. Если все упростить, то статья о том, как используя одномерную структуру {Debug ... Critical} добиться того же самого эффекта в плане информирования/реагирования, что и Вы — используя двумерную {Debug... Critical, Component}. Причем цена вопроса с одномерной — нулевая — всего лишь за счет смещения «спектра» значений на одну ступеньку вниз и того факта, что сбои в критичных модулях сами по себе настолько важны, что уже сам уровень ошибки внутри это модуля теряет значение, потому им можно пренебречь.
в Вашей системе уведомление о разовой ситуации сбоя, когда пользователь не смог загрузить условный отчет о продажах — увидел экран смерти, затем тупо обновил страницу, загрузил со второй попытки да и забыл, будет выглядеть точно так же, как с пользователем, у которого Вы списали только что сотню баксов с банковской карты, но система слегла на записи в базу факта оплаты. Мой опыт говорит о том, что такие ситуации имеет смысл различать — уж больно разные реакции у людей на эти ситуации, потребовавшие «немедленной остановки приложения».
Но Вы же понимаете, что это не единственная возможная схема взаимоотношений? Приложение может делать деньги, но не Вам. Контракт на хостинг БД не с вами, а с компанией, которой Вы продаете услуги разработки. В этом и есть суть описанной идеи — в Вашем сценарии это действительно разумно делать критикал — вы теряете деньги. Но как-то глуповато сидеть и ждать, пока кто-то поднимет упавший сервер, от чего Вам ни холодно ни жарко в рамках существующих договоренностей.
p.s. И честно говоря, я не вижу разницы, из-за чего терять деньги — из-за упавшей БД или опечатке в коде, чтобы иметь для них разные уровни.
Вы точно читали сам текст? Потому что он как бы и есть о том, как уйти от проблемы размытости этих уровней засчет переноса точки зрения с сугубо технических деталей проблемы на реакцию людей на нее. Даже пример с БД есть. Если сервер БД, который упал, находится в ведении вообще другой компании-хостера — и Вы сами не можете с ним сделать ни че го — какова же будет Ваша реакция на такой critical — прям вот не покинете офис, пока бестолочи там не соизволят его наконец поднять?
Так. И из этого тогда вроде как получается, что в Вашем проекте даже сообщение об ошибке (не крэш) являются чрезвычайным событием, на которое следует мгновенная реакция команды разработки, которая все бросает и чинит эту проблему. И если Вы можете позволить себе это — т.е. успеваете полностью закрыть причину той ошибки раньше, чем появится новая аналогичная — то это круто, серьезно. Если это так — то в вашем бэклоге сейчас не должно сейчас быть ни единой жалобы от пользователя вроде «Была вот такая ошибка — хотел воспользоваться этой фичей так, как ни одному человеку в голову не придет — почините пжл». А если Вы начинаете выделять «ожидаемые ошибки» как уровень Error — то не кажется ли это странным, что запись об ожидаемом событии имеет более высокий приоритет, чем запись Warning — для неожиданных?
Наверное стоило уточнить в статье, что речь про уровни используемые на продакшн. Trace для отладки я как-то само-собой разумеющимся посчитал. Хотелось заострить внимание на том, что Debug нужен именно для «боевого» применения, т.к. обычно схожие статьи выдают ему роль «только для отладки».
Если в моей статье и есть какая-то ценность, то она как раз именно в том, что и с моей точки зрения его Success не равен Notice, так как есть принцип, по которому их относительно легко и однозначно ранжируем.
Если вопрос в том, как зеленым строчку с success подсветить, то я не вижу ничего плохого в «подгруппах» событий в рамках одного уровня. По факту, у меня для Info есть как минимум 3 расширения: InfoAsStart, InfoAsFinish, InfoAsSuccess — я бы помечал Success записи флагом, чтобы потом отрисовщики событий могли их разукрашивать в зеленый. И это уже выводится на уровень конфигурирования, т.е. кому надо — видит зеленым, кому не надо — и так сойдет.
Если вопрос именно о принципе, когда хочется акцентировать внимание на условно положительных событиях вместо негативных, то мне кажется это довольно синтетическим сценарием. Внимание человека, наблюдающего за системой, я принимаю за ограниченный ресурс и не вижу смысла выдавать более высокий приоритет тому, на что заведомо не стоит тратить внимание при прочих равных. Может быть такой сценарий и найдется, но это явно будет исключение, а в типичном случае «негативные» событие разумнее рассматривать первыми.
Так смешиваю, или сперва пишу про одно, а потом про другое? Я это называю «аналогия».
В моем комментарии говорится что "совет, в том виде, котором он дан, ужасен". Это не то же самое, что «читается ужасно».
Здесь я как раз согласен, только причина, почему оба варианта имеют право на жизнь, в корне другая, чем просто соглашение команды.
Если Вам действительно хочется понять мою позицию — можете ради интереса глянуть формулу количества информации в сигнале. Сигналы, у которых начало менее вариативно, всегда будут чуток отставать в скорости передачи информации и «догонять» только в самом конце при прочих равных. Если у вас все функции начинаются с get, set, handle, то после получения (прочтения) 'g', 's' и 'h' следующие 2-5 символов несут вам просто ноль информации.
Люди не дурные и чувствуют это интуитивно. Точно так, как нелеп магазин с отделами «Наливают», «Нарезают», точно также будет нелеп завод где вместо Токарного, Фрезерочного, Штамповочного, Кузнечного и что там у них еще, будут цеха «Сталь» и «Алюминий».
В программировании это не так очевидно, потому что как раз очень сильно зависит от домена.
ну тогда остается лишь префиксовать все подряд и надеяться, что не понадобится метод загрузки из базы только имени шоу — getShowName и не понадобится подключать api внешнего сервиса с AI для подбора «продающих» имен шоу — getShowName.
Пишем «create», думаем «добавить». Не говоря уже о том, что технически это все будет CRUD create операция создания записи о принадлежности книги пользователю, для которой не стоит использовать глагол согласно пункта 1.
может со второй попытки заметите
Мы же по прежнему говорим про код? Можете привести пример, когда в методе или процедуре содержится НЕ алгоритм? Чтобы у меня появился резон добавлять это уточнение — что это именно алгоритм, а не что-то другое.
— что означает переменная errorFound?
— Это — код ошибки.
— Отлично. Давай то, что ты сказал, и запишем в само имя переменной — errorCode.
— Что означает shouldShowPaginationIfTooManyRecords?
— Что нужна пагинация.
— Отлично. Давай так и запишем — pagination.
— Что означает shouldShowPaginationIfRowHeightIsVeryVeryBig?
— Что нужна пагинация.
— Отлично. У нас уже есть такая — давай эту удалим.
Почти, с небольшим «тюнингом». В CRUD операциях 3 из 4 букв — это запись (input). Потому я использую глагол только для пишущих операций, а для чтения — get опускается. В сочетании с самими сигнатурами метод — пишущие в общем случае void — это более чем достаточно. Ваш пример в моем коде будет выглядеть как
Orders,Order,OrderUpdate.Я вот только что перепроверил, как переведет гугл транслейт фразу «алгоритм обновления заказа», коим и является OrderUpdate method — получилось «order update algorithm». Код описывает алгоритмы и структуры, логично и называть его исходя из этого, нет? Я полагаю, мода на глагольные префиксы торчит из-за путаницы с уровнем UI через CLI. На UI пользователь шлет команды, которые запускают алгоритмы. И для именования команд вроде как в самом деле интуитивней через глаголы.
Я прямо вот очень хорошо понимаю теперь, почему товарные позиции в магазинах называются в таком «дурацком» виде, типа «Томат, голландский, весовой» или «Болт, M12, оцинкованный» — поиск в списках, составленных по такому принцип — «сущность — уточнение, уточнение,…, уточнение» просто в разы удобней.
{ ..., Component}, о котором речь идет в моем комментарии. Если хотите считать среду за измерение — ну окей, в будет 2d структура {Уровень, Среда} вместо трехмерной {Уровень, Среда, Компонент}.target="Email", на проде условноminLevel='critical' target = "Пейджер"minLevel='warning' maxLevel='error' target= "НеПейджер". (Я в основном по .NET, потому под «target» имеется ввиду target от Nlog бибилиотеки, для Serilog это 'sink' и т.д.){Debug ... Critical}добиться того же самого эффекта в плане информирования/реагирования, что и Вы — используя двумерную{Debug... Critical, Component}. Причем цена вопроса с одномерной — нулевая — всего лишь за счет смещения «спектра» значений на одну ступеньку вниз и того факта, что сбои в критичных модулях сами по себе настолько важны, что уже сам уровень ошибки внутри это модуля теряет значение, потому им можно пренебречь.p.s. И честно говоря, я не вижу разницы, из-за чего терять деньги — из-за упавшей БД или опечатке в коде, чтобы иметь для них разные уровни.