Всех с наступившим 2011 годом!!! Начнем цикл статей...
Введение
Этот цикл статей родился не просто так. Тема протоколирования широкая (это демонстрирует объем прочитанных статей в интернете, на основе которых вкупе со своим опытом и создан этот материал), и каждый программист решает, как ему удобно отлаживать свои программы. Т.о. количество средств протоколирования растет очень быстро, т.к. постоянно изобретаются велосипеды. Вред подобного «велосипедостроительства» рано или поздно становится понятен каждому разработчику. К сожалению, я не стал исключением, реализовав свою систему протоколирования в нескольких проектах. Цель этого цикла статей – дать разработчику информацию о существующих системах протоколирования. И пусть каждый разработчик сам выбирает готовый инструмент в зависимости от своих потребностей. Если появятся интересы, то можно будет провести тестирования средств и понять, какое из них нам все же по душе.
Так же стоит понимать, что ни одно из средств не может быть панацеей от всех бед. Т.е. скорее всего, для каждого отдельно взятого случая подойдет та или иная система протоколирования.
Определение
Ни для никого не секрет, что при разработке программ, особенно которые будут эксплуатироваться/администрироваться Заказчиком (не программистами), нужно уделять внимание не только функциональности, но и системе протоколирования. Поскольку исследование содержимого файла регистрации ошибок после возникновения неполадок часто позволяет понять их причины.
Протоколирование (Logging, tracing) — хронологическая запись с различной (настраиваемой) степенью детализации сведений о происходящих в системе событиях (ошибки, предупреждения, сообщения) куда-либо (файл, приложение мониторинга и т.д.) для последующего анализа в процессах отладки и тестирования.
Немного истории
Все мы (программисты) при написании того или иного модуля сталкивались с необходимостью отладки в поисках не пойми откуда возникшего бага. В нашем вооружении могут быть продвинутые средства разработки (MS Visual Studio), отладчики, поддерживающие отладку многопоточных приложений и другие чрезвычайно полезные и мощные инструменты, а могут и не быть. Но не смотря на наличие таких мощных инструментов, отладка может превратиться в сущее наказание, например, при отладке многопоточных приложений на не очень мощном компьютере (после получасового путешествия по коду вашего детища вы в который раз жмете F10 и с ужасом летите вместе с выброшенным где-то в глубинах кода исключением на самый верхний уровень, в заботливо подставленный catch. Сообщение исключения говорит вам, что в метод пришли неверные аргументы, но абсолютно непонятно, откуда и каким образом они взялись). Конечно можно, стиснув зубы и вооружившись терпением, бороться с багом…
Но можно и пойти менее затратным путем – это использование средств протоколирования. Я не говорю, что средства отладки плохи. Нет! Они вполне удобны и без них было бы сложно написать нормальное приложение.
Тут мне вспомнилось, как я программировал вообще без отладки, т.к. вообще не знал что это такое :). Писалось медленно, но к удивлению работало. Скорее всего, т.к. там не было чему ломаться :). До того как я начал пользоваться встроенными отладчиками, я начал использовать простые средства отладки: MessageBox (в Windows Form) или printf (в консольных приложениях). Но это было давно… Потом я начал использовать отладчики.
Но сейчас опять появилась тенденция к переходу к средствам протоколирования (не по причине, что разучился пользоваться отладчиками). Протоколирование в большей степени нужно для поиска причин возникновения ошибок, в процессе работы системы, но в меньшей - для отладки приложения (вместо протоколирования в этом случае можно использо-вать юнит-тесты). Иногда протоколирование оказывается единственным доступным инструментом (т.к. не везде можно располагать графическими средствами отладки), который может быть использован, чтобы найти ошибку в критически важных системах, которые не могут быть отключены ни на минуту. Протоколы дают нам информацию, необходимую для воспроизведения ошибки в процессе последующей отладки.
Введение
Этот цикл статей родился не просто так. Тема протоколирования широкая (это демонстрирует объем прочитанных статей в интернете, на основе которых вкупе со своим опытом и создан этот материал), и каждый программист решает, как ему удобно отлаживать свои программы. Т.о. количество средств протоколирования растет очень быстро, т.к. постоянно изобретаются велосипеды. Вред подобного «велосипедостроительства» рано или поздно становится понятен каждому разработчику. К сожалению, я не стал исключением, реализовав свою систему протоколирования в нескольких проектах. Цель этого цикла статей – дать разработчику информацию о существующих системах протоколирования. И пусть каждый разработчик сам выбирает готовый инструмент в зависимости от своих потребностей. Если появятся интересы, то можно будет провести тестирования средств и понять, какое из них нам все же по душе.
Так же стоит понимать, что ни одно из средств не может быть панацеей от всех бед. Т.е. скорее всего, для каждого отдельно взятого случая подойдет та или иная система протоколирования.
Определение
Ни для никого не секрет, что при разработке программ, особенно которые будут эксплуатироваться/администрироваться Заказчиком (не программистами), нужно уделять внимание не только функциональности, но и системе протоколирования. Поскольку исследование содержимого файла регистрации ошибок после возникновения неполадок часто позволяет понять их причины.
Протоколирование (Logging, tracing) — хронологическая запись с различной (настраиваемой) степенью детализации сведений о происходящих в системе событиях (ошибки, предупреждения, сообщения) куда-либо (файл, приложение мониторинга и т.д.) для последующего анализа в процессах отладки и тестирования.
Немного истории
Все мы (программисты) при написании того или иного модуля сталкивались с необходимостью отладки в поисках не пойми откуда возникшего бага. В нашем вооружении могут быть продвинутые средства разработки (MS Visual Studio), отладчики, поддерживающие отладку многопоточных приложений и другие чрезвычайно полезные и мощные инструменты, а могут и не быть. Но не смотря на наличие таких мощных инструментов, отладка может превратиться в сущее наказание, например, при отладке многопоточных приложений на не очень мощном компьютере (после получасового путешествия по коду вашего детища вы в который раз жмете F10 и с ужасом летите вместе с выброшенным где-то в глубинах кода исключением на самый верхний уровень, в заботливо подставленный catch. Сообщение исключения говорит вам, что в метод пришли неверные аргументы, но абсолютно непонятно, откуда и каким образом они взялись). Конечно можно, стиснув зубы и вооружившись терпением, бороться с багом…
Но можно и пойти менее затратным путем – это использование средств протоколирования. Я не говорю, что средства отладки плохи. Нет! Они вполне удобны и без них было бы сложно написать нормальное приложение.
Тут мне вспомнилось, как я программировал вообще без отладки, т.к. вообще не знал что это такое :). Писалось медленно, но к удивлению работало. Скорее всего, т.к. там не было чему ломаться :). До того как я начал пользоваться встроенными отладчиками, я начал использовать простые средства отладки: MessageBox (в Windows Form) или printf (в консольных приложениях). Но это было давно… Потом я начал использовать отладчики.
Но сейчас опять появилась тенденция к переходу к средствам протоколирования (не по причине, что разучился пользоваться отладчиками). Протоколирование в большей степени нужно для поиска причин возникновения ошибок, в процессе работы системы, но в меньшей - для отладки приложения (вместо протоколирования в этом случае можно использо-вать юнит-тесты). Иногда протоколирование оказывается единственным доступным инструментом (т.к. не везде можно располагать графическими средствами отладки), который может быть использован, чтобы найти ошибку в критически важных системах, которые не могут быть отключены ни на минуту. Протоколы дают нам информацию, необходимую для воспроизведения ошибки в процессе последующей отладки.
Комментариев нет:
Отправить комментарий