Источник: Статья “Программист-защитник сильнее энтропии” от FunCorp на Habr.com

Date: 2019-11-24

Программист-защитник в любой момент и в любом месте кода ожидает появления потенциальных проблем и пишет код таким образом, чтобы заранее от них защититься. А если от проблемы нельзя защититься, то хотя бы сделать так, чтобы её последствия и влияние на пользователей были минимальными.

Вспоминается эффект FlashForward из голливудских блокбастеров, когда главный герой видит грядущую катастрофу и остаётся предельно спокойным, потому что заранее знает, что она произойдёт, и имеет от неё защиту. Идея защитного программирования в том, чтобы защититься от проблем, которые сложно или вовсе невозможно предвидеть. Программист-защитник ожидает появления ошибок в любом месте системы и в любой момент времени, чтобы предотвратить их до того, как они нанесут ущерб. При этом цель не в том, чтобы создать систему, которая никогда не падает, это всё равно невозможно. Цель в том, чтобы создать систему, которая падает изящно в случае любой непредвиденной проблемы.

Давайте разберёмся подробнее, что входит в понятие «падать изящно».

• Падать быстро. В случае непредвиденной ошибки все операции должны завершаться сразу же, особенно если последующие вычисления тяжёлые или могут привести к порче данных.
• Падать аккуратно. Если возникла ошибка, программа должна освободить все ресурсы, снять локи, удалить временные и наполовину записанные файлы, закрыть соединения. Дождаться завершения критических операций, прерывание которых может привести к непредсказуемым результатам. Либо безопасным способом аварийно завершить эти операции.
• Падать явно и красиво. Если что-то сломалось, сообщение об ошибке должно быть простым, лаконичным и содержать важные детали из того контекста системы, где возникла ошибка. Это поможет команде, которая отвечает за систему, максимально быстро разобраться в проблеме и исправить её.

Но у вас может появиться вопрос.

Зачем тратить время на проблемы, которые могут возникнуть в будущем? Сейчас же их нет, код работает просто идеально. К тому же проблемы могут и вовсе никогда не произойти. Ведь профессионалы не занимаются инженерией ради инженерии (YAGNI — You aren’t gonna need it)!

Главное — прагматизм

Эндрю Хант в книге «Программист-прагматик» даёт следующее определение защитному программированию — «прагматическая паранойя».

Защищайте свой код от:

• собственных ошибок;
• ошибок других людей;
• ошибок и сбоев в других системах, с которыми интегрирована ваша;
• ошибок железа, сред и платформ, на которых работает ваше приложение.

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

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

Никому не доверяйте

Данные пользователей по умолчанию ненадёжны. Пользователи часто неверно понимают то, что нам (как разработчикам системы) кажется очевидным. Ожидайте на входе некорректные данные и всегда проверяйте их.

Также проверяйте объём входных данных. Может быть такое, что пользователь отправляет их слишком много. При этом, с точки зрения бизнес-логики, это корректный сценарий. Но он может привести к слишком долгой их обработке. Что с этим можно сделать? Например, запустить её асинхронно, в случае если объём входных данных превышает определённый порог и специфика бизнеса позволяет обработать данные в фоновом режиме.

Настройки программ (например, конфигурационные файлы) также подвержены появлению в них некорректных данных. Часто настройки программ хранятся в JSON, YAML, XML, INI и других форматах. Поскольку всё это текстовые файлы, стоит ожидать, что рано или поздно кто-то что-то в них поменяет, и ваша программа станет работать некорректно. Это может быть как конечный пользователь, так и кто-то из вашей команды.