Должны ли вы код для защиты вашего приложения от плохих кодеров?

Question

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

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

Теперь, что если в будущем другой разработчик работает над этим приложением, добавляет другое допустимое значение для этого параметра, которое пройдет процесс очистки, но не добавляет соответствующий раздел в файл конфигурации. Помните, я защищаю приложение только от плохих пользователей, а не от плохих кодеров. Мое приложение не будет работать.

С одной стороны, я знаю, что все изменения должны быть проверены перед переходом к производству, и что-то подобное, несомненно, произойдет в ходе достойного сеанса тестирования, но с другой стороны, я стараюсь создавать свои приложения так, чтобы они лучше противостояли сбоям. насколько это возможно. Я просто не знаю, правильно ли включать изменение моего кода коллегами в список потенциальных точек отказа.

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

Что ты думаешь?

Ленивый ... или философски здравый?

Answer 1

«Я просто не знаю, правильно ли включать изменение моего кода коллегами в список потенциальных точек отказа».

Нельзя препятствовать вашим коллегам ломать вещи.

Вы не знаете, для каких новых целей будет поставлено ваше программное обеспечение. Вы не знаете, как это будет изменено в будущем.

Вместо этого сделайте это.

Напишите простое правильное программное обеспечение, запустите его в производство и перестаньте беспокоиться о том, что кто-то что-то "сломает".

Если ваше программное обеспечение на самом деле просто , другие люди могут поддерживать его, не нарушая его.

Если вы сделаете это слишком сложным, они все равно (а) сломают его, несмотря на все, что вы делаете, и (б) возненавидят вас за его сложность.

Итак, сделайте работу максимально простой.

Answer 2

Ленивый ... или философски звучащий?

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

Конечно, вместо добавления большего количества кода, чтобы определить, совпадают ли файл конфигурации и проверка параметров, было бы намного лучше, если бы проверка параметров была основана на файле конфигурации, чтобы было только одно место, где добавляются новые значения несоответствие невозможно.

Answer 3

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

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

Answer 4

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

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

Это документация, как упомянул Стив Б. Я бы просто удостоверился, что он не внешний, так как у него есть тенденция потеряться.

Answer 5

Оба пути хороши, если говорить философски. Я бы сделал суждение, основанное на том, насколько вероятно, что вы думаете, что это произойдет. Если вы можете быть почти уверены, что кто-то нарушит ваш код таким образом, возможно, будет вежливым предоставить проверку, которая перехватит это, когда это произойдет.

Если это не кажется особенно вероятным, то это лишь часть их работы, чтобы убедиться, что они не нарушают код.

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

Answer 6

Я думаю, что будущий разработчик несет ответственность за то, чтобы она не вносила ошибок или точек сбоев в ваш код. Когда вы выходите из проекта (если вообще ?!), то частью процесса подписания должно быть, по крайней мере, то, чтобы код был представлен как можно более свободным от ошибок, тогда это ограничило бы вашу ответственность за будущие проблемы.

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

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

Надеюсь, это поможет.