Спасибо. У меня вот в инструкциях осталось от советских времен… «категории 1-4 для программистов», написано что должна аттестовать комиссия. Но оба моих начальника сказали, забей, у нас тут нет людей чтоб вас аттестовать. А так действительно движения по лестнице на ФГУП нет, ты студентом придешь и будешь техником-программистом, а с дипломом будешь инженером-программистом, ну может вырастешь до руководителя группы, а потом до начальника бюро, но начальником отдела уже не станешь.
А с категориями было бы здорово, человек бы стремился к улучшению, зная о поощрении материальном если категорию открыл. Интересно, что на производстве это осталось для рабочих, например у работников ОТК и токарей есть разряды, они за них получают разные зарплаты. А программисты — так программисты. В итоге каждый ходит и лично выбивает себе ЗП, а мотивацию приходиться из энтузиазма личного черпать.
Таблицы не переименовываются. Создается временная схема, в ней создается нужная таблица. Соединение работает на указанной схеме. Т.е. каждый тест работает со своей схемой, потому можно хоть два теста на одной таблице запустить, например проверку вставки, List и удаление — они будет независимы по данным.
Да мы вставляем этот код для логированния, но все равно мы не всегда пишем лог с уровнем DEBUG. Т.е. обычно для приложений, чтобы логи не раздувались лог ведется на уровне ERROR и при возникновении подозрения на ошибку пользователь выставляет лог на DEBUG и пытается повторить ошибку, после чего разработчик по потоку событий пытается понять, что произошло и почему. Конечно так не всегда, в некоторых приложениях обязательно каждый чих знать.
Короче я прихожу к выводу, что общеподходящего решения нет. Как сказал мне мой друг «У нас на проекте 5 разных реализаций логгеров, т.к. приходили разные разработчики и каждому нужно было что-то свое».
Где-то хватит и Debug, Info для приложения. А где-то нужно вести структурированные логи, где уровни могут быль лишь мелкой деталью.
Второй случай — это как исключение, которое отловил обработчик ошибок высшего уровня и выдал пользователю 500 Ошибка обслуживания, а для разработчика записал в лог подробности (стек).
Мы уведомляем клиента о всех сбоях в операциях, которые не удалось восстановить программе без помощи клиента и нужно его действие.
Т.е. есть разделение на публичные ошибки и приватные так сказать?
Я такое видел Gin-gonic, там автор предлагает пользователю отдавать ошибки помеченные как публичные, а приватные нет.
В вашем примере получается как бы «неважная ошибка», не та «важная», которую пользователю показать бы.
В логе их по смыслу только отличать получается можно, т.е. они все будут ERROR.
Мне кажется такая «неважная ошибка» должна быть вовсе не ошибка, a DEBUG сообщение, или Info, в котором видно прогресс операции, т.к. выходит для цельной операции это как бы не сбой, а нормальная ситуация, которую код обрабатывает. А если после 5 попыток не удалось, тогда это реально сбой операции и об этом нужно пользователя уведомить.
Мне кажется термин «ошибка» слишком широко трактуется, следует разделять error/bug.
Разработчики допускают ошибки(bugs) при написании кода и в программе затаивается дефект. И даже если дефект не нашли и о нем никто не знает, он все равно есть! Сидит и ждет своего часа. И когда пользователь натыкается на ошибочный код, происходит сбой(error).
Мы сообщаем пользователю о чем? О сбое. Сбой может быть восстановимым или фатальным.
При восстановимом сбое, пользователь например получит сообщение «Устройство не отвечает на запрос», пользователь сам решает, что он будет делать при этом сбое.
Стоит ли это писать в лог? Ведь это нормальное поведение программы, этот сбой обрабатывается, пользователь видит сообщение на экране.
Я считаю, в лог тут эту ошибку нужно писать через Debug, и в продакшн их быть не должно, при отладке, да они должны быть. Пользуясь структурированным логгировнием, я бы записал «type=ProcessFlowError processFlow=DeviceConnect и сообщение».
Как это записать в лог — решение разработчика. Кто-то может запишет как уровень Info, а кто-то Warn, а кто-то Error. Это уже детали реализации.
О фатальном сбое нам сообщает вылет/неожиданное завершение работы программы. Мы увидим или сообщение в консоли, или в логе «Неожиданное завершение программы: <тут стек>»
Тема интересная, но перевод утерял множественное число много раз(поток вместо потоки, например). Выглядит как машинный перевод.
А с категориями было бы здорово, человек бы стремился к улучшению, зная о поощрении материальном если категорию открыл. Интересно, что на производстве это осталось для рабочих, например у работников ОТК и токарей есть разряды, они за них получают разные зарплаты. А программисты — так программисты. В итоге каждый ходит и лично выбивает себе ЗП, а мотивацию приходиться из энтузиазма личного черпать.
Меня как раз интересовало, что думает по этому поводу читатель, т.к. у меня однозначного отношения к этому утверждению не сложилось.
Короче я прихожу к выводу, что общеподходящего решения нет. Как сказал мне мой друг «У нас на проекте 5 разных реализаций логгеров, т.к. приходили разные разработчики и каждому нужно было что-то свое».
Где-то хватит и Debug, Info для приложения. А где-то нужно вести структурированные логи, где уровни могут быль лишь мелкой деталью.
Мы уведомляем клиента о всех сбоях в операциях, которые не удалось восстановить программе без помощи клиента и нужно его действие.
Я такое видел Gin-gonic, там автор предлагает пользователю отдавать ошибки помеченные как публичные, а приватные нет.
В вашем примере получается как бы «неважная ошибка», не та «важная», которую пользователю показать бы.
В логе их по смыслу только отличать получается можно, т.е. они все будут ERROR.
Мне кажется такая «неважная ошибка» должна быть вовсе не ошибка, a DEBUG сообщение, или Info, в котором видно прогресс операции, т.к. выходит для цельной операции это как бы не сбой, а нормальная ситуация, которую код обрабатывает. А если после 5 попыток не удалось, тогда это реально сбой операции и об этом нужно пользователя уведомить.
testbase.ru/235
Мы сообщаем пользователю о чем? О сбое. Сбой может быть восстановимым или фатальным.
При восстановимом сбое, пользователь например получит сообщение «Устройство не отвечает на запрос», пользователь сам решает, что он будет делать при этом сбое.
Стоит ли это писать в лог? Ведь это нормальное поведение программы, этот сбой обрабатывается, пользователь видит сообщение на экране.
Я считаю, в лог тут эту ошибку нужно писать через Debug, и в продакшн их быть не должно, при отладке, да они должны быть. Пользуясь структурированным логгировнием, я бы записал «type=ProcessFlowError processFlow=DeviceConnect и сообщение».
Как это записать в лог — решение разработчика. Кто-то может запишет как уровень Info, а кто-то Warn, а кто-то Error. Это уже детали реализации.
О фатальном сбое нам сообщает вылет/неожиданное завершение работы программы. Мы увидим или сообщение в консоли, или в логе «Неожиданное завершение программы: <тут стек>»