Список як кращий засіб від дебага

На багатьох проектах я бачив душевні спроби впровадити якусь новомодну фичу , поставити все на свіже фреймворк , підключити які-небудь круті бібліотеки , впровадити практики TDD , або нарешті отрефакторіть все для майбутніх поколінь. Але тільки один раз я зустрів тімліда , яка не виявляв стільки інтересу до Фреймворк і примочкам , скільки до грамотного логування . За роки розробки я якось звик, що логи пишуться в довільному порядку - навіть на порталах Нацбанку і Податкової з ними була відверта біда і суцільна відсебеньки .

Список в реальному житті

Одна з основних причин, чому на більшості проектів не приділяється належної уваги логам , - « можна і без них ». Серйозно. Кому вони потрібні? Логування - це коли чоловік приходить додому і кричить дружині : «Олено, я вдома! ». Логирование - це коли дитина, йдучи на вулицю , кричить батькам в іншій кімнаті : « тато, буду ввечері! ». І нарешті, звичайний шкільний щоденник або атестат - чим не лог ? Чи можна добре вчитися без щоденника та атестата ? Запросто . Чи обов'язково , заходячи в квартиру, віщати всім « я вдома»? Ні. Вас , ймовірно, і так помітять через хвилину. Все це логирование - периферійний , другорядний процес, який не виконує ніякої реальної справи . Але тільки до тих пір, поки не з'явиться проблема . Мама , грепні мій щоденник
Якщо в один прекрасний день вашої дитини виганяють зі школи з причини поганої успішності , то можна, звичайно , почати « дебажіть ». Задати дитині пару навідних запитань , дзвякнути вчителям і запитати про успішність протягом року , поспілкуватися з однокласниками і з'ясувати активність дитини на уроках. Зрештою , після невеликого детективного розслідування вам вдасться з'ясувати причину і почати ламати голову над тим, як повернути дитину в школу. Але чи не простіше було регулярно « Грепан » щоденник і атестат ? І батьки Грепан . Для зручності щоденники розкреслені в таблиці, де видно місяць, день тижня, число. Навпроти кожного предмета є місце для оцінки та зауваження , яке пишеться червоним кольором, який зарезервований лише для вчителя. Ці логи непогано оформлені і дозволяють швидко знайти причину , по якій дитину вигнали зі школи . Більше того , щотижневий огляд логів дозволяє побачити тенденції в успішності дитини і заздалегідь почати які -небудь заходи, щоб програма не « впало ». Чому б тоді не приділяти логам на проектах більше уваги ? Чим краще логи, тим менше дебага Звичайно, якщо виникає проблема , то можна кинути пару Exception'ов , включити Debug , відловити все і пофиксить . Можна також додати ситуативні logger.info () або старий добрий System.out.println ( ) . Якщо додаток валиться де-небудь на продакшені , то цілком реально впоратися за допомогою Remote Debug ( хоч і не завжди). Але все це суєта. Грамотно оформлені логи можуть дозволити майже не використовувати Debug . І ці ж логи допоможуть зазирнути в такі глибини додатки, де не ступала нога віддаленого дебага . Тому ми просто зобов'язані зробити логи легкими для читання та удобогрепаемимі .

Принципи грамотного логування:

1 .Список повинні відображати всі важливі події . Наприклад: запуск програми , старт/стоп транзакцій, успішний логін , виникнення помилок і так далі. 2 .Їх має бути легко Грепан . Як варіант , є сенс не тільки подбати про унікальність тих слів/символів , за якими вірогідний пошук, але і виключити часто повторювані слова . Не хотілося б потрапити в ситуацію, коли Грепан потрібно по & lt ; apple.juice.com & gt ;, який згадується в кожному рядку логу . 3 .Додавайте [ TAGS ] для маркування концепцій додатки . Наприклад: [ TRANSACTION ], [ DEVICE ], [ LOGIN ] і так далі. Греп за цими тегами , можна отримати зріз логів по девайсам , транзакциям та іншим процесам , які зазвичай « розмазані » по декількох класах . 4 .Все логи конкретного проекту повинні відповідати певному формату . Наприклад , команда може домовитися використовувати такий порядок: --- & gt ; [ TAG ] текст_сообщенія ### [ IP ] . У реальному житті це було б схоже на :
INFO transaction.ScheduledReportTransactionService --- & gt ; [ TRANSACTION ] starting to execute on schedule ### [ 127.0.0.1 ]
Уніфікований підхід до оформлення логів полегшить їх читання не тільки для самих розробників , але і для тих людей (наприклад , клієнтів ), яким потім доведеться з ними працювати . 5 .Один рядок - одне повідомлення . Варто обмежитися виведенням одного повідомлення на рядок , інакше греп буде не так ефективний. 6 .Логов не повинно бути занадто багато і вони не повинні бути надмірними - зайва інформація буде засмічувати екран. Тільки саме важливе і потрібне . І нарешті, слід свідомо користуватися різними рівнями логування: INFO , WARNING , ERROR , FATAL . На багатьох проектах девелопери повально захопилися рівнем INFO. Може, тому, що повідомлення в logger.info ( ) не виділяються моторошним червоним кольором ? Мухи окремо, котлети окремо - називаючи речі своїми іменами , ми полегшуємо собі діагностику ситуації. Якщо є потенційна проблема - бути WARN'у , якщо це помилка - бути ERROR'у , ну , а якщо ми хочемо дати невинне повідомлення і все добре - включаємо INFO. Ще один плюс на користь інформативних логів : якщо додаток запущено на продакшені і немає доступу до дебагу , саме логи стануть головним джерелом інформації , яка дозволить визначити і пофиксить проблему. Тому краще їх тримати в чистоті і порядку , та на короткому повідку . Якщо у вас є свої фішки , пов'язані з логування , - діліться в коментах .

Опубліковано: 10/12/14 @ 10:55
Розділ Різне

SEO Блог