Comments 16
забыли cut, вероятно.
Мне кажется, любую сколько-нибудь сложную систему просто невозможно построить без логирования. Другое дело, что не нужно логирование прятать от пользователя.
Мне кажется, это вы про свой софт. А когда заглядываешь в уже сделанное кем-то ранее, удивляет, почему там иначе. Вот в продукте, который достался в прошлом году мне — иначе. Не буду оглашать компанию-разработчика, там уже из тех программеров давно никого не осталось.
UFO just landed and posted this here
Первая часть (про модульность) недоступна. Можете достать ее открыть? (:
Про логирование можно еще полторы статьи написать.
Хотелось бы сказать, что иногда STDERR и STDOUT слишком мало, ибо нужно сортировать сообщения по теме, а потом отдельно эти темы просматривать.
Я, конечно знаю, что существует grep|sed|awk и т.п., и даже люблю эти утилиты, однако считаю, что иногда удобно просто взять и распечатать файл через tail -n XX или tail -f. Вот тогда на помощь приходит логирование каждой отдельной темы в свой файл.
Приведу пример:
1. обновление данных
2. обновление кода
3. обновление графики .{jpg,gif,png}
4. экспорт данных
5. обработка данных ( тут можно еще побить на отдельные темы )
6. диагностика поддержания работоспособности П.О. (и тут можно на каждый аспект отдельный файл)
При логировании очень полезен шаблон проектирования «Наблюдатель».
1. Тот за кем нужно наблюдать может рассылать сообщения в никуда, если за ним никто не наблюдает.
2. Один наблюдатель может подглядывать за несколькими темами сообщений (объектами, аспектами, добавить свое)
3. За одной темой может следить несколько наблюдателей, каждый из которых может по разному на сообщения реагировать (писать в файл, слать в Jabber и т.д.)
В этом плане рекомендую посмотреть на Logger в стандартной библиотеке Python — ИМХО мега юзабельно!
Хотелось бы сказать, что иногда STDERR и STDOUT слишком мало, ибо нужно сортировать сообщения по теме, а потом отдельно эти темы просматривать.
Я, конечно знаю, что существует grep|sed|awk и т.п., и даже люблю эти утилиты, однако считаю, что иногда удобно просто взять и распечатать файл через tail -n XX или tail -f. Вот тогда на помощь приходит логирование каждой отдельной темы в свой файл.
Приведу пример:
1. обновление данных
2. обновление кода
3. обновление графики .{jpg,gif,png}
4. экспорт данных
5. обработка данных ( тут можно еще побить на отдельные темы )
6. диагностика поддержания работоспособности П.О. (и тут можно на каждый аспект отдельный файл)
При логировании очень полезен шаблон проектирования «Наблюдатель».
1. Тот за кем нужно наблюдать может рассылать сообщения в никуда, если за ним никто не наблюдает.
2. Один наблюдатель может подглядывать за несколькими темами сообщений (объектами, аспектами, добавить свое)
3. За одной темой может следить несколько наблюдателей, каждый из которых может по разному на сообщения реагировать (писать в файл, слать в Jabber и т.д.)
В этом плане рекомендую посмотреть на Logger в стандартной библиотеке Python — ИМХО мега юзабельно!
Прекрасное правило. Я к нему к большому сожалению шёл своими граблями, работая в очень сильно молчаливом проекте — при введении неправильных данных в форме, а их там порой было более двух десятков, в случае опечатки или ещё какой случайной напасти, максимум что выдавалось: «Ошибка данных». Каких? чего? Где? А порой попадалось так, что программа вообще всё проглатывала и потом неправильно считала, вылетала и не хотела работать (я пришёл уже в проект и мне рассказывали, что раньше там везде так было). В данном случае на фразу «Молчание — золото» возникали ассоциации с золотухой (уж простите). Потом, когда эти очевидные вещи поправили и пользоваться стало удобнее, как пользователям, так и нам, программерам (отсекался целый пласт ошибок из-за неправильных входных данных), пришло понимание о том, что нужно вести и логи для непользовательских действий — об этом-то и статья. Но как же долго я к этому шёл: это и выдавание на отладочной версии как можно более информативных сообщений о том, что внутри что-то не так, потом переход к ведению текстовых логов через создание дополнительных классов с единым интерфейсом, чтобы информацию от предыдущей версии на основе всплывающих сообщений не потерять и внедрить в новую концепцию сохранения логов, потом всякие штучки и финтифлюшки наприкручивал для очистки, сигнализации и пр.! О боже, какое же долго всё же пришлось идти… Зато какой опыт!
Реквестирую продолжение. Пожа-а-а-алуйста!
Sign up to leave a comment.
Искусство программирования под Unix (и не только). Часть седьмая, «правило прозрачности»