Является ли программирование Belt and Braces хорошей практикой или просто создает ненужную сложность? - PullRequest
14 голосов
/ 20 апреля 2009

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

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

Пессимистическая сторона меня решила, что Пояс и Брекеты никогда никому не причинят вреда, и это не помешает снова проверить форму в случае, если в моей логике формы есть ошибка.

Но тогда я не знал, что вставить, если проверка не удалась. Если я сделаю что-то вроде этого:

if (! form.isValid()) {
  displayErrorMessage();
}

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

Опция на другом конце шкалы:

if (! form.isValid()) {
  throw new RuntimeException("This should never happen!");
}

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

Итак, в конце концов я получил:

assert form.isValid();

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

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

Мне было бы интересно услышать, что вы делаете в подобных ситуациях.

( Редактировать : вопрос в том, как лучше всего обеспечить, чтобы форма возвращала действительные данные. Предположим, что выходные данные формы снова проверены, прежде чем они попадут в базу данных, и так далее. )

Ответы [ 9 ]

5 голосов
/ 20 апреля 2009

Исходя из моего опыта, код "на всякий случай" иногда является признаком ленивого программирования. Т.е. я нашел решение, которое в принципе работает, я не уверен, что оно будет работать всегда, поэтому я добавлю код двойной проверки «на всякий случай». Если вы не посылаете ракетные корабли на Луну, этот тип вещей относительно безопасен, но, тем не менее, может быть очень плохой практикой.

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

5 голосов
/ 20 апреля 2009

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

Я оставил оба сообщения на том основании, что если какое-то будущее изменение пропустит проверку элемента управления, оно будет перехвачено при нажатии кнопки ОК.

В моей голове проверка OK - это проверка real , а проверка каждого элемента управления - это сахар, который только улучшает опыт пользователей.

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

1 голос
/ 21 августа 2015

Я собираюсь дать невероятно непопулярный ответ.

Мой ответ: это зависит .

Прежде, чем люди начнут подниматься со своих стульев в негодовании и прибавить лишней пены к своему латте ', чтобы выразить свою ярость, выслушайте меня. an angry programmer punching a screen

Я изменяю пакет ERP, который использует общие файлы. Не смейся, это дневная работа. В любом случае, у системы есть один недостаток в дизайне - она проверяет данные при вводе, а затем всегда предполагает, что они правильные из-за единовременной проверки, как только записывает записи.

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

Теперь поставщик, поставляющий программное обеспечение, в значительной степени работает против поясов и подвесок, потому что, эй, время - деньги, и они собираются продать свой продукт (программное обеспечение). Каждые 15 минут написание дополнительных проверок работоспособности - это 15 минут, которые можно потратить на получение дохода. Но они не попадают в пейджер в 3 часа ночи, чтобы исправить сбои в работе или освободить неприятные тупики. Я делаю.

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

Это пояса и подтяжки? Да. Мне нравится делать это? Нет. Много ли это спасло мое здравомыслие, время сна и сало?

Да. О да ...

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

В противном случае это не нужно.

1 голос
/ 20 апреля 2009

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

  1. Пусть пользователи делают то, что им нравится, а затем проверяют свои результаты на OK. Это может быть отлично для опытных пользователей, позволяя им вводить вещи быстро и постепенно, но оставляет новичков и нечастых пользователей скорее в растерянности.
  2. Проверять каждый элемент управления по мере его ввода или при выходе. Это может быть хорошо, особенно для сложных форм (которые мы, конечно, не должны разрабатывать, правда, но ...!); но плохое выполнение может помешать людям постепенно заполнять формы в своем собственном порядке. Я предпочитаю визуальную индикацию, что что-то не так, если я делаю это.
  3. лишить возможности вводить что-либо неправильно. Это может (почти) быть достигнуто через, например, ползунки для чисел, комбинированные окна для ограниченных скаляров, автоматически проверяемые поля редактирования, которые предотвращают неправильные записи.

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

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

1 голос
/ 20 апреля 2009

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

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

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

1 голос
/ 20 апреля 2009

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

1 голос
/ 20 апреля 2009

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

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

1 голос
/ 20 апреля 2009

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

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

Редактировать : Что касается веб-программирования, то JavaScript обычно используется для проверки перед отправкой входных данных на сервер. Очевидно, этого недостаточно, поскольку пользователи могут отключить JavaScript и обойти эту проверку, поэтому в этом случае необходима проверка на стороне сервера. В любом случае, когда пользователь может злонамеренно или случайно обойти первую строку проверки, необходимо также перепроверить внутреннюю часть. Я думаю, что это меньше проблем в Java, C # и т. Д.

0 голосов
/ 23 декабря 2014

Я думаю, что ремень и брекеты не очень хорошая практика.

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

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

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

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

...