У программистов есть устойчивое поверие – за скорость работы кода приходится расплачиваться его качеством (понятностью, сложностью, переносимостью, сопровождаемостью). Имхо, так оно и есть на самом деле.
Однако жертвой погони за скоростью может стать не только код. На неделе разгоняя обработку ответов от удаленной системы столкнулся с тем, что изменив схему обработки, переместив большее количество действий на уровень БД, значительно потерял в диагностике происходящего. Ответы приходят в асинхронном режиме, какой-то запоздает, какой-то придет повторно, может даже совсем левый ответ поступить. Раньше обработка была медленнее, я делал больше запросов к БД и точно знал, почему ответ должен быть проигнорирован. А сейчас запросов к БД меньше, выполняются они быстрее, но я вижу только списки актуальных и неактуальных ответов. Причина неактуальности уже недоступна. Чтобы ее сохранить, нужно делать лишние манипуляции с данными, а это потеря скорости, что недопустимо.
Раньше было “ответ такой-то проигнорирован потому-то”, а стало “ответ такой-то проигнорирован”. И все. Такие дела.
PS. Усвоенная мной за последние десять лет мудрость: логов мало не бывает ;)
4 комментария:
Логи, это хорошо... Но это палка о двух концах.
Они замедляют приложение. У вас логи отключаются как-то? детализация регулируется?
Я в своем проекте борюсь с сообщениями. У нас нет другого способа мониторинга. Логи у нас есть, но они существуют для других людей, для администраторов, и для нас не несут почти никакой пользы. :)
А отладочный вывод - пользователям не виден, но когда там много лишнего (для тебя в конкретный момент времени) - это затрудняет расследования.
Здесь проблема в том, что отладочный вывод нельзя отфильтровать по нужным критериям... это проблема.
А еще они загромождают код.
Неоднозначно это все.
>У вас логи отключаются как-то? детализация регулируется?
В принципе, сообщения в логах у нас классифицируются и ранжируются (error/logic, lowest/low/normal/high/highest приоритет). Но на практике это практически никогда не используется при фильтрации. Нам намного чаще приходится добавлять логирование, чем уменьшать его.
Управление логированием выполняется в некоторых компонентах на уровне конфигурации (там можно указывать, какие события подлежат логированию). Но пользуются этими настройками, насколько мне известно, не часто.
Кроме того, уже несколько лет мы включаем в документацию компонента перечень сообщений, которые компонент выдает в лог с небольшими описаниями и перечнем сопутствующей информации.
Это же относится и к скорости разработки ;)
@jazzer:
И к скорости разработки ;)
Где-то слышал афоризм, вроде того, что выжимание каждого следующего процента производительности обходится в два раза дороже.
Отправить комментарий