ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / правила написания ПО, style guide, но не для форматирования кода, а для функциональности
25 сообщений из 50, страница 2 из 2
  2  все
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39570663
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Алексей КmaytonРазработчику по большему счету лог не нужен.Наоборот! Ему он нужен больше всего! Это единственная объективная информация, оперируя которой можно понять, что произошло при промышленной эксплуатации программы.

Давайте просто детализируем этот пункт. В Window/C++/DBMS/Crud - приложении.

1) Если возникла прикладная ошибка - то пользователь получает исчерпывающую информацию на экран.
Например - "Ошибка при добавлении формы - Нарушена уникальность индивидуального налогового номера".

Программисту здесь как-бы все ясно.

2) Если возникала системная ошибка общего типа. Эдакий себе непревиденный exception.
Что выводить пользователю на экран? "ORA-12541: TNS: no listener" ? Непонятно. Каталогизировать все
ошибки и дать им смысловые пояснения для пользователя - сложно. Мы уходим в высокий comlexity
самой логики отбивания ошибки. Выводить всё на экран - не совсем безопасно. В стеке и переменных
могут быть т.н. sensitive-data. Логины пароли. Скорее всего надо вывести общее генерализованное
сообщение о проблемах в БД и дать стандартный бланк с телефонами техподдержки.

В этом случае имеет смысл залоггировать ошибку для дальнейшего анализа.

Но для варианта (1) логгинг скорее всего не нужен. Или мы просто дублируем логику приложения в двух местах.
...
Рейтинг: 0 / 0
16.12.2017, 12:33
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39570684
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
maytonАлексей Кпропущено...
Наоборот! Ему он нужен больше всего! Это единственная объективная информация, оперируя которой можно понять, что произошло при промышленной эксплуатации программы.

Давайте просто детализируем этот пункт. В Window/C++/DBMS/Crud - приложении.

1) Если возникла прикладная ошибка - то пользователь получает исчерпывающую информацию на экран.
Например - "Ошибка при добавлении формы - Нарушена уникальность индивидуального налогового номера".

Программисту здесь как-бы все ясно.

2) Если возникала системная ошибка общего типа. Эдакий себе непревиденный exception.
Что выводить пользователю на экран? "ORA-12541: TNS: no listener" ? Непонятно. Каталогизировать все
ошибки и дать им смысловые пояснения для пользователя - сложно. Мы уходим в высокий comlexity
самой логики отбивания ошибки. Выводить всё на экран - не совсем безопасно. В стеке и переменных
могут быть т.н. sensitive-data. Логины пароли. Скорее всего надо вывести общее генерализованное
сообщение о проблемах в БД и дать стандартный бланк с телефонами техподдержки.

В этом случае имеет смысл залоггировать ошибку для дальнейшего анализа.

Но для варианта (1) логгинг скорее всего не нужен. Или мы просто дублируем логику приложения в двух местах.
Пользователь увидит "генерализованное
сообщение", обратится в поддержку.
Поддержка посмотрит логи, отфильтровав их по дате и аккаунту пользователя, и заведёт ишью в Jira, куда приложет запись из лога.
Ишью переведут на разработчиков...

У нас это так работает. И тех вопросов, что Вы предлагаете обсуждать выше, у нас почему-то не возникает.
...
Рейтинг: 0 / 0
16.12.2017, 13:27
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39570689
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Давайте это к автору.
...
Рейтинг: 0 / 0
16.12.2017, 13:56
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39570702
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Автору я уже советовал и Вам тоже возможно будет интересно:

YouTube Video
YouTube Video
...
Рейтинг: 0 / 0
16.12.2017, 14:36
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39570750
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
maytonАлексей Кпропущено...
Наоборот! Ему он нужен больше всего! Это единственная объективная информация, оперируя которой можно понять, что произошло при промышленной эксплуатации программы.

Давайте просто детализируем этот пункт. В Window/C++/DBMS/Crud - приложении.

1) Если возникла прикладная ошибка - то пользователь получает исчерпывающую информацию на экран.
Например - "Ошибка при добавлении формы - Нарушена уникальность индивидуального налогового номера".

Программисту здесь как-бы все ясно.Если мы оформляем прикладные ошибки исключениями, то нам ничего не стоит их залогировать наравне с системными ошибками. Зачем отказывать себе в таком удовольствии? :-) Тем более, что в сложных случаях бывают непонятны место и причины возникновения прикладных ошибок, в этом случае бывает полезно увидеть системные ошибки, которые могут лежать в основе прикладных ошибок. Например, системная ошибка нарушения уникального индекса в БД может быть преобразована в прикладную ошибку вроде: "Сотрудник с таким ИНН уже существует".

mayton2) Если возникала системная ошибка общего типа. Эдакий себе непревиденный exception.
Что выводить пользователю на экран? "ORA-12541: TNS: no listener" ? Непонятно.Тут согласен, системная ошибка может отбить у пользователя желание пользоваться нашей программой. Может стоит её показать, но в приятном оформлении с фотографией "котика"? Не знаю...

mayton Каталогизировать все
ошибки и дать им смысловые пояснения для пользователя - сложно.Я бы сказал невозможно.

maytonВ этом случае имеет смысл залоггировать ошибку для дальнейшего анализа.Да, именно об этом я и упомянул в предыдущем сообщении. Видимо мы друг друга неправильно поняли. :-)

maytonНо для варианта (1) логгинг скорее всего не нужен. Или мы просто дублируем логику приложения в двух местах.Повторюсь, если нам это ничего не стоит, то можно и залогировать, хуже не будет.
...
Рейтинг: 0 / 0
16.12.2017, 16:49
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39570767
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
maytonНо для варианта (1) логгинг скорее всего не нужен. Или мы просто дублируем логику приложения в двух местах.И вот ещё что. Если мы говорим о GUI приложении, то MessageBox, отображающий сообщение об ошибке на экране, можно рассматривать как одну из разновидностей хранилищ лога, наряду с хранилищами, пишущими данные лога в файл, БД и т. п. При такой организации отображения сообщения об ошибке никакого дублирования, вроде как, нет.
...
Рейтинг: 0 / 0
16.12.2017, 17:46
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39570804
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Алексей КЕсли мы оформляем прикладные ошибки исключениями, то нам ничего не стоит их залогировать наравне с системными ошибками. Зачем отказывать себе в таком удовольствии? :-)Логика, построенная на исключениях - моветон.
...
Рейтинг: 0 / 0
16.12.2017, 20:32
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39570817
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
maytonДавайте просто детализируем этот пункт. В Window/C++/DBMS/Crud - приложении.Повторю уже сказанное: логи пишутся так, чтобы по ним можно было отлаживаться.
Вот буквально. Есть проблема, которая воспроизводится только у клиента и обязательна к решению. Единственный источник сведений о проблеме - лог-файл.
...
Рейтинг: 0 / 0
16.12.2017, 20:56
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39570888
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
skyANAАлексей КЕсли мы оформляем прикладные ошибки исключениями, то нам ничего не стоит их залогировать наравне с системными ошибками. Зачем отказывать себе в таком удовольствии? :-)Логика, построенная на исключениях - моветон.

Это не просто моветон, рубить по рукам тупым топором!
...
Рейтинг: 0 / 0
17.12.2017, 05:00
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39570889
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Basil A. SidorovПовторю уже сказанное: логи пишутся так, чтобы по ним можно было отлаживаться.

В смысле отлаживаться? Зачем? Хороший качественный лог позволяет найти причину ошибки, если надо ещё отлаживаться, то либо это хреновый лог, построенный на стектрейсах исключений (этим болеют в основном ленивые либо неопытные программисты), либо отсутствие возможности получить контекст исполнения из лога (неумение пользоваться структурными логами с вложенными контекстами).

Да и как предлагаете отлаживаться, в случае если у программистов нет доступа к реальным данным, и получить их даже ради отладки -- исключено в принципе?
...
Рейтинг: 0 / 0
17.12.2017, 05:07
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39570997
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hVosttВ смысле отлаживаться? Зачем?
У тебя что, слово "отлаживаться" ассоциируется исключительно с отладчиком и пошаговым исполнением?..
...
Рейтинг: 0 / 0
17.12.2017, 14:35
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571005
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
hVosttBasil A. SidorovПовторю уже сказанное: логи пишутся так, чтобы по ним можно было отлаживаться.

В смысле отлаживаться? Зачем? Хороший качественный лог позволяет найти причину ошибки, если надо ещё отлаживаться, то либо это хреновый лог, построенный на стектрейсах исключений (этим болеют в основном ленивые либо неопытные программисты), либо отсутствие возможности получить контекст исполнения из лога (неумение пользоваться структурными логами с вложенными контекстами).

Да и как предлагаете отлаживаться, в случае если у программистов нет доступа к реальным данным, и получить их даже ради отладки -- исключено в принципе?
По сабжу - почти все ораторы правы. Но я встречал кастомеров которые неохотно предосталяли логи
либо их предоставление было сопряжено с орг. трудностями. Переписка с индусами и т.п. Вобщем
все зависит от того как построено взаимодействие.
...
Рейтинг: 0 / 0
17.12.2017, 15:12
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571144
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
hVosttskyANAпропущено...
Логика, построенная на исключениях - моветон.

Это не просто моветон, рубить по рукам тупым топором!"А судьи кто?" (ц)
...
Рейтинг: 0 / 0
18.12.2017, 05:15
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571151
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Dimitry SibiryakovhVosttВ смысле отлаживаться? Зачем?
У тебя что, слово "отлаживаться" ассоциируется исключительно с отладчиком и пошаговым исполнением?..

Какие ещё есть варианты? Удивите.
...
Рейтинг: 0 / 0
18.12.2017, 06:11
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571152
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Алексей К"А судьи кто?" (ц)

Судьи тут вообще не при чём, это не вопрос фломастеров.
...
Рейтинг: 0 / 0
18.12.2017, 06:11
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571153
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
maytonНо я встречал кастомеров которые неохотно предосталяли логи
либо их предоставление было сопряжено с орг. трудностями

Интересный кейс.. не сталкивался
...
Рейтинг: 0 / 0
18.12.2017, 06:12
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571271
WebSharper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WebSharper
Участник
hVosttDimitry Sibiryakovпропущено...

У тебя что, слово "отлаживаться" ассоциируется исключительно с отладчиком и пошаговым исполнением?..

Какие ещё есть варианты? Удивите.

Просто слово "Отладка" фактически обозначает любую деятельность по устранению ошибок. В том числе вывод логов. См. https://en.wikipedia.org/wiki/Debugging
...
Рейтинг: 0 / 0
18.12.2017, 11:29
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571307
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
WebSharperПросто слово "Отладка" фактически обозначает любую деятельность по устранению ошибок. В том числе вывод логов. См. https://en.wikipedia.org/wiki/Debugging

Да понятное дело пошёл запускать дебаггер и ставить свои жалкие брейкпойнты. Просто нельзя вот так взять и не выкобениться на ровном месте
...
Рейтинг: 0 / 0
18.12.2017, 12:23
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571418
WebSharper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WebSharper
Участник
hVosttДа понятное дело пошёл запускать дебаггер и ставить свои жалкие брейкпойнты. Просто нельзя вот так взять и не выкобениться на ровном месте

Зато теперь вы знаете значение слова, которое употребляете, а это способствует тому, чтобы быть понятым :)
...
Рейтинг: 0 / 0
18.12.2017, 14:35
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571437
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
WebSharperhVosttДа понятное дело пошёл запускать дебаггер и ставить свои жалкие брейкпойнты. Просто нельзя вот так взять и не выкобениться на ровном месте

Зато теперь вы знаете значение слова, которое употребляете, а это способствует тому, чтобы быть понятым :)

В общем и целом, не удивили. И попытка не зачёт.
...
Рейтинг: 0 / 0
18.12.2017, 14:44
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571466
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hVosttДа понятное дело пошёл запускать дебаггер и ставить свои жалкие брейкпойнты.
Ну, удачи тебе с твоими брейкпоинтами в ловле thread races или memory corruption, случающимся из-за пользовательских данных.
...
Рейтинг: 0 / 0
18.12.2017, 15:08
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571507
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
skyANAАвтору я уже советовал и Вам тоже возможно будет интересно:

YouTube Video
YouTube Video
...
Рейтинг: 0 / 0
18.12.2017, 16:00
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571514
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
maytondbpatchв) писать все ошибки в stderr, а не в stdout, не писать в stderr, если демонизированы, писать в syslog

syslog на мой взгляд является ценным ресурсом ОС Linux и я-бы не стал в каждом приложении
его использовать. Нет ничего хуже чем прикладной флуд в системном логе.

Семантический вопрос разделения прикладного и системного я пока оставляю за кадром. Бох вам судья
если вы решили что ваш код системный. Тут важнее осознание значимости момента.

syslog это демон (rsyslogd), а писать он может не только в /var/log/messages, а как настроишь.

нет, ну конечно всяко интереснее чисто в Java-style переизобрасти мир и построить свой чудный велосипед, с базой данных обязательно (отдельная клиника), но....
...
Рейтинг: 0 / 0
18.12.2017, 16:06
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571523
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
skyANAdbpatchпропущено...


И? где открытие? Я вон привел пример того, что в большинстве мест в принципе не принято правильно оформлять логгирвание.

И наверное стоит посмотреть хоть куда-то, чтоб увидеть, как на самом деле принято делать в хороших проектах.
Потому я и спрашиваю - где есть рафинированные правильные проекты и правила.

Смотреть по сторонам на типовой местячковый бардак - никакого смысла вообще нет, это все равно что современную архитектуру изучать по самодельным "пенокурятникам лкуса" и прочие гениальные дачные постройки в округе. Что они могут рассказать?Конференции, митапы и прочие комьюнити. И все материалы конечно же есть в сети.

К примеру поищите доклады Анатолия Кулакова из SpbDotNet Community про структурное логирование и сбор метрика.
Покажите, расскажите коллегам.

митапы? это все смешно. в любой нормальной отрасли есть устоявшиеся прописанные типовые практики, стандартизованные и довольно часто жество требуемые.

нет, ну представь, сейчас каждый строитель-архитектор будет ездить на митапы, узнавать, как правильно перекрытия и несущие стены проектировать, ага. а потом по вентиляции тоже на отдельную конференцию.

а потом давай переделывать уже сданные проекты. красота!
...
Рейтинг: 0 / 0
18.12.2017, 16:12
| Ответить | Цитировать | Написать  
правила написания ПО, style guide, но не для форматирования кода, а для функциональности
    #39571758
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Dimitry SibiryakovhVosttДа понятное дело пошёл запускать дебаггер и ставить свои жалкие брейкпойнты.
Ну, удачи тебе с твоими брейкпоинтами в ловле thread races или memory corruption, случающимся из-за пользовательских данных.

Как же плохо вам живётся
...
Рейтинг: 0 / 0
19.12.2017, 07:08
| Ответить | Цитировать | Написать  
25 сообщений из 50, страница 2 из 2
  2  все
Форумы / Программирование [игнор отключен] [закрыт для гостей] / правила написания ПО, style guide, но не для форматирования кода, а для функциональности
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]