Правило нулевой проблемы (PZR) в программировании 

В 1992 году Ариен Мак и Ирвин Рок описали психологический феномен, когда люди не видят неожиданных вещей, происходящих прямо у них на глазах.

Наш мозг устроен избирательно. Это помогает нам выполнять нашу повседневную работу. Но это также означает, что мы упускаем вещи прямо на виду.

Явление непреднамеренной слепоты влияет на различные аспекты нашей жизни. Например, мы почти на 100% слепы, когда дело касается рекламных плакатов. Мы все знаем, что они есть, но не обращаем на них внимания.

Точно так же это явление влияет на нашу работу как разработчиков программного обеспечения. Поэтому важно убедиться, что важные вещи действительно видны нам.

Независимо от того, используете ли вы Visual Studio Code или WebStorm, каждая из этих IDE предлагает уведомления о проблемах на вкладке «Проблемы» и подчеркивает фрагменты кода, представляющие риск.

Дело в том, что мы их больше не видим. Это ловушка, в которую попадают многие из нас. Достаточно просто игнорировать одну ошибку или предупреждение в течение нескольких часов, и наше внимание ко всем новым предупреждениям резко падает.

В конце концов, мы просто игнорируем вкладки проблем и подчеркнутый код, потому что нет необходимости публиковать идеально работающее решение.

Я работал над этой проблемой много лет, и сегодня я хочу поделиться с вами методом ее решения.

Метод представляет собой правило нулевой проблемы (PZR). Как и Inbox Zero, он помогает повысить производительность, справиться с проблемами, производительность и душевное спокойствие. Как правило, Inbox Zero помогает улучшить работу с электронными письмами, что делает работу с ними отличной.

3 правила Problem Zero Rule

Чтобы применить правило нулевой проблемы к вашему поведению кодирования, вы должны применить эти три правила:

У вашего кода никогда не должно быть проблем.
Вкладка "Проблемы" должна быть чистой в 100% случаев
Никакая часть вашего кода не должна быть подчеркнута

Это означает, что каждый раз, когда вы работаете с кодом, вы должны быть уверены, что с этого момента он не вызывает никаких некритических проблем.

Сделав это, вы перестанете игнорировать предупреждения IDE и начнете рассматривать их как полезный ресурс для улучшения вашего кода, а не будете игнорировать их.
Как начать?

В вашем коде может быть много предупреждений. Так что потребуется некоторое время, чтобы привести его в порядок. Вот несколько советов, как это сделать:

Исправить легко исправляемые предупреждения
Если у вас нет времени исправлять другие предупреждения, но они не критичны, добавьте ESLint или TSLint игнорируя комментарий
Сделайте своим обычным делом удалять эти строки с течением времени, чтобы в конечном итоге вы не игнорировали комментарии и не испытывали проблем

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

Во-первых, вы должны восстановить зрение в отношении потенциальных проблем, прежде чем вы сможете действительно с ними работать.

Я настоятельно рекомендую использовать Правило нулевой проблемы в вашей практике кодирования. Вроде небольшие дополнительные усилия, но оно того стоит. Позже вкладка «Проблемы» и подчеркивания с предупреждениями вернут вам время, но помогут вам лучше писать код и тратить меньше времени на отладку.

Кроме того, вы будете полностью удовлетворены написанием на 100% ясного и правильного кода и пустым списком проблем. Ощущение, которое можно испытать при работе с серьезными проблемами программирования.