Любой, кто писал программы, знает, что код по своей природе подвержен ошибкам. Есть так много вещей, которые могут пойти не так: пользователи вводят неверные значения, код, который выполняется на основе неправильных предположений, приводит к сбою программного обеспечения, и этот список можно продолжить.
По-настоящему плохой образ мышления в программировании — это предполагать, что все всегда «сработает», что объекты и данные будут присутствовать и быть доступными, хотя на самом деле это может быть не так. Объект, который, как вы думали, будет присутствовать, внезапно перестал правильно извлекаться. Если ваш код зависит от этого объекта данных и падает, как только эти данные становятся нулевыми, то ваш код ненадежен и недостаточно надежен.
Когда я только начинал программировать, я всегда делал такие предположения в своем коде — ожидая, что объект будет моим вводом, а затем обрабатывал этот объект, не будучи уверенным, что ввод всегда будет таким, как я сначала ожидал. Но через некоторое время стало совершенно очевидно, что мой код хрупок и его ничто не охраняет.
Изучение концепции защитного программирования очень помогло мне и поможет любому новому разработчику. Короче говоря, концепция заключается в том, чтобы гарантировать, что программное обеспечение будет вести себя правильно, даже если ввод неверен.
Одной из наиболее распространенных ошибок, которую получают программисты, является исключение null, которое обычно возникает при попытке доступа к свойствам объекта, который имеет значение null. Примером этого может быть, когда мы извлекаем объект из ресурса, а затем предполагаем, что объект будет возвращен правильно.
Один из наиболее полезных подходов, позволяющих избежать ошибок такого типа, — использовать подход «сбой-сначала» или «сбой-ранний», что просто означает: досрочно выйти из функции, если ввод неверен, и остановить выполнение. Мы делаем это с помощью защитных предложений или операторов if, которые проверяют правильность входных данных, прежде чем мы перейдем к остальной части реализации. Это не позволяет нам продолжить выполнение недопустимого состояния.
Другой полезный подход — использовать утверждения внутри методов. Концепция утверждений распространена в модульном тестировании, но мы можем использовать тот же подход и в нашей реальной реализации кода. Когда мы выполняем какой-то побочный эффект, мы утверждаем, что эффект имел место. Например, при обновлении значения в базе данных мы обычно получаем статус успеха. Возврат этого состояния обеспечит уверенность в том, что операция была выполнена успешно, вместо того, чтобы предполагать, что обновление было успешным, хотя на самом деле это не так. Мы в основном утверждаем, что казнь прошла успешно.
Этот защитный подход к программированию сделает ваше программное обеспечение намного безопаснее, потому что оно будет выполняться только на основе уверенности, а не ложных предположений.
Вы никогда не можете быть уверены, что пользователь введет правильные значения. На самом деле, вы даже не можете доверять себе или коду, который пишете. Вы можете где-нибудь написать метод, который возвращает значение, а затем вызвать этот метод в другом месте, предполагая, что ваш метод всегда будет вести себя правильно. Если вы затем создадите какую-то зависимость от этого метода, то технически вы настроите свой код на катастрофу.
Я предпочитаю код с защитными предложениями и дополнительными проверками, которые обеспечивают безопасность, коду, который кажется аккуратным и чистым, но подверженным ошибкам и хрупким. Иногда «глупый код» является наиболее стабильным, поскольку он делает что-то только на основе определенных значений.
