Чрезмерно защитное программирование

В статье, про которую я писал вчера, Аксель говорит о том, что он не фанат опционального чейнинга (obj?.prop - пропозал в будущий стандарт JS) и даёт ссылку на статью "Overly defensive programming" Карла Витулло, которая раскрывает идею того, почему чрезмерные проверки по всему коду это не очень хорошая практика.

Если мы пишем в коде слишком много защитных проверок (например, const p = obj && obj.p;) и подавляем возможные ошибки, то это может служить признаком того, что мы не знаем, какие гарантии предоставляют используемые сервисы и сторонние библиотеки. В итоге это может приводить к непонятным ошибкам. Лучше всего заблоговременно разобраться в данных и кинуть ошибку как можно ближе к тому месту, где она произошла, не забыв залогировать. В статье есть хороший пример. Какое сообщение вам будет понятнее: Warning: Failed prop type: The prop 'a' is marked as required in 'Thing', but its value is 'undefined'. или Uncaught TypeError: Cannot read property 'b' of undefined? Кажется, что ответ очевиден. Как альтернативу проверкам можно использовать статическую типизацию, которая просто не даст коду собраться, если какие-то контракты были нарушены.

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

https://medium.com/@vcarl/overly-defensive-programming-e7a1b3d234c2

← На главную