Какой код должен быть первым, проверять функциональность или валидность?

Question

При кодировании, скажем, формы регистрации с нуля, имеет ли смысл сначала заставить ее работать с ожидаемыми входными данными, а затем вернуться назад, отловить / обработать неожиданные входные данные и устранить ошибки?

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

Является ли один путь предпочтительнее другого, и если да, то почему? Кроме того, есть ли альтернативный способ выполнить эту задачу из двух частей?

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

Answer 1

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

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

Answer 2

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

Пули Tracer хороши, но этот принцип не нужно применять ко всем аспектам проекта.

Answer 3

Одним из способов было бы использование подхода TDD (при условии, что вы пишете модульные тесты). Начните с написания своих модульных тестов, затем работайте над тем, чтобы пройти эти модульные тесты.

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

Answer 4

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

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

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

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

Answer 5

Как только функциональность заработает, вы ДЕЙСТВИТЕЛЬНО вернетесь назад и добавите код проверки?

Большинство из нас хотели бы, но у многих из нас заканчивается время в конце проекта.

Answer 6

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

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

Answer 7

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

Но как вам удобнее, так лучше.

Недостатком моего метода является то, что если вы дезорганизованы, вы можете забыть добавить проверку достоверности или санитарии где-нибудь. И это случается: -)

Answer 8

1. Напишите тест для метода объекта проверки
2. Напишите метод объекта проверки
3. Тест до прохождения

Повторяйте 1-3, пока все методы не будут проверены.

4. Написать форму и подать данные в проверенные и работающие методы объекта проверки.

Используйте ту же процедуру для бизнес-объекта, обрабатывающего проверку данных.

Answer 9

Мне нравится выставить пару функциональных полей, затем выполнить проверки для проверки этих функций, затем проверку для остальных и, наконец, заполнить остальные функции.

Answer 10

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