Это расширенный комментарий DavidMcLaughlin о вреде “защитного” кода в ответ на вопрос о разумности отказа от “защитного” программирования.

Во-первых, это соблюдение принципа DRY¹. Вместо рассеивания кода проверки целостности данных по всей системе соберите его в одном месте. Это сделает бизнес-логику более понятной и простой в обслуживании. Если кому-то кроме вас придется разбираться в подпрограмме или классе, не стоит нагружать его десятками строк кода, проверяющего “безопасность” параметров.

Во-вторых, наблюдения показывают, что практика защитного программирования порождает культуру “мета-правил”², которые существуют только в голове у архитектора системы. Если кто-то попытается повторно использовать их модели, высока вероятность утери этих правил (разбросаных по разным контроллерам и сценариям). В наших унаследованных системах это приводило к появлению самых неприятных ошибок. В таких ситуациях без опыта в предметной области не обойтись.

И наконец, защитное программирование обычно само по себе является большим красным предупреждением “в этой системе отсутствует стратегия обеспечения целостности данных”. И не важно, поступают ли данные из реляционной БД или из файла… должен существовать уровень валидации данных, который убедиться в “правильности” данных перед их “безопасным” использованием в остальной системе.

Моя практика показала, что защитное программирование особенно рапространено в системах, использующих СУБД MySQL. MySQL традиционно не имела механизмов обеспечения целостности, доступных в Oracle или в других системах уровня предприятия. В результате появилось целое поколение “экспертов” по MySQL, которые представления не имеют о целостности данных. В данный момент я работаю над системой, в функции которой первые 20 (из 28) строк обеспечивают защиту от появления “осиротевших” записей в БД. Причина? Утилита администратора не умеет делать каскадное удаление записей. Вместо решения проблемы в корне эти 20 строк кода вставлены везде, где требуется безопасный доступ к данным.

Эти примеры можно продолжать, но вывод напрашивается сам собой: защитное программирование один из основных “запахов кода”.