если я включу предупреждения и уведомления на этих живых веб-сайтах, они будут перегружены ими.
У вас всегда должны быть включены предупреждения до самого полного уровня в разработке, тестировании и контроле качества, но не в производстве. На самом деле, если это приложение для собачьего кормления, то есть приложение, которое вы используете сами, то вы должны также включить его в производство.
В основном: включите их в тех случаях, когда человек, который их видит, может что-то с ними сделать (разработчик и разработчик могут исправить их самостоятельно, тестировщик в QA может сообщить об ошибке, и если разработчик также пользователь, тогда он также может исправить это в работе), но не включайте их, когда человек, который видит, не может ничего с ними поделать (пользователь в работе, который даже не знает, как программировать).
В идеале вы также захотите включить обработку предупреждений как ошибок, но это работает, только если их нет с самого начала ;-) Но помните об этом как о цели! Если есть возможность включить / выключить это отдельно для каждого файла, включите его для всех новых файлов и включите для всех файлов без предупреждений, и никогда не выключайте его снова после включения.
Итак, что делать с перегрузкой?
Вы составляете список каждого предупреждения и уведомления, а затем придерживаетесь следующих правил:
- Никогда, никогда, ни при каких обстоятельствах не добавляйте новое предупреждение в список. Каждый новый фрагмент кода, каждое редактирование, каждое изменение, каждый патч, каждый коммит не должен вводить новые предупреждения, он может только их исправлять .
- Каждый раз, когда вы касаетесь фрагмента кода, исправляйте все предупреждения в этом фрагменте кода. (Правило Boyscout: всегда оставляйте место разбивки лагеря в лучшем состоянии, чем вы его нашли.) Таким образом, несущественный код может быть полон предупреждений, но важный код со временем станет чище. «Кусок кода» может быть функцией, классом, файлом. Вы также можете ослабить это правило, чтобы сказать, чтобы исправить хотя бы одно предупреждение. Дело в том, чтобы исправить их, как вы найдете их.
Примечание: оба из них требуют наличия некоторой базы данных журналов и механизма фильтрации журналов. Также обратите внимание, что «база данных журналов» и «механизм фильтрации журналов» могут быть просто текстовыми файлами и grep.
Это важный бит. Без базы данных вы не узнаете, когда добавите новое предупреждение, а без фильтрации у вас все еще будет проблема перегрузки.
Примечание № 2: это работает не только для предупреждений, но и для проверки стиля, показателей сложности, покрытия кода, инструментов статического анализа и так далее. В принципе:
- Не добавляйте новые проблемы.
- Исправьте старые проблемы, когда наткнетесь на них.
Это позволяет легко расставлять приоритеты: код, который часто редактируется и, следовательно, должен легко читаться и обслуживаться, со временем станет лучше. Код, который не затрагивается часто, не станет лучше, но это нормально, потому что никто не должен смотреть на него в любом случае. И , по крайней мере, хуже не станет.
Конечно, ничто не мешает вам выделять время специально для того, чтобы ничего не делать, кроме как выслеживать и убивать предупреждения. Просто так часто, это не выгодно с экономической точки зрения, и это ваша работа, как инженера, помнить об этом. «Инженер - это тот, кто может строить за доллар, а любой дурак - за два».
@.