Если Вам нравится программировать - Вы наверняка помните то прекрасное детское кодирование - времен кружка  программирования в школе или первых курсов университета - как в консоль Вы вбиваете одному Вам ведомый набор цифр (через пробел), жмете “ввод” и получаете другой набор цифр. И чувство чистого инженерно-технического экстаза, от того, что Вы заставили машину отсортировать массив или найти путь на графе. Ведь клевое было ощущение? Да, перед этим программа много раз падала и выдавала не то, что нужно, но само по себе программирование было больше похоже на решение интересной головоломки. Как давно Вы испытывали похожее чувство во взрослой жизни, программируя очередную CMS, CRM и ERP или еще какую-нибудь аббревиатуру? Возню в тоннах запутанного кода интересной головоломкой назвать сложно. Возможно, у меня есть идея, как вернуть то чувство. Приглашаю, чтение на 10 минут - зашли и вышли!

Возможно Вам доводилось слышать про протокол журнала событий syslog, в котором можно насчитать аж 8 уровней важности: emergency, alert, critical, error, warning, notice, info, debug. Наверняка Вы, как и я какое-то время назад, думаете, “зачем столько”? А что если я скажу, что количество уровней там просто идеально? И использовать можно все - даже debug - для продакшн. Во всяком случае, каждому из них можно придать формальный критерий. Это особенно иронично для меня самого, так как всего пару месяцев назад я написал статью в духе “зачем так сложно!”. Так что если Вам интересно посмотреть на пример технического “переобувания” или оценить строгий алгоритм ранжирования уровней важности событий в системе - прошу.

Все знакомы с библиотеками логирования. Обычно они предлагают из коробки сразу много "уровней" важности, которым Вы можете записывать сообщения. Обычно в документации к ним можно найти рекомендации - как лучше этими уровнями - Info, Warning, Error, Fatal - пользоваться. Проблема в том, что это все не работает без некоторых дополнительных соглашений и уточнений - все равно возникает путаница и споры "какой уровень правильный". Именно об этих необходимых уточнениях я и хотел бы поговорить.

Наверняка любой, кто занимается программированием, помнит, как в самом начале пути на него обрушивается поток информации об алгоритмах, паттернах и методах разработки. Помнит то самое чувство, когда разобравшись с какой-то свежей или просто новой для себя идеей внутри теплится ощущение "ну вот теперь-то заживем!". А также то чувство легкого отчаяния - после попытки все это применить в реальном проекте, с реальными людьми, с внезапными виражами бизнес логики и постоянным “очень срочно”.

Как же так выходит, что в мире, где большинство проектов укладываются в схему "ввод данных, валидация и сохранение в базу данных" так много проектов скатываются в полную неразбериху? При том, что все разработчики преисполнены знаний об алгоритмах, фреймворках и паттернах, а принципы SOLID на собеседовании отскакивают от зубов. Рискну высказать по этому поводу свое предположение о причине, а также мой личный способ, как с этим можно бороться.