当从头开始编写注册表时，首先让它与预期输入一起运行是否有意义，然后返回并捕获/处理意外输入并处理错误？
替代方法是处理输入，检查任何约束并确保它们得到正确处理，然后处理使典型用例正常运行。
一种方式比另一方更好，如果是这样，为什么？另外，还有另一种方法来处理这种由两部分组成的任务吗？
澄清，有效性，我的意思不仅仅是数据验证，包括业务规则，例如“不超过X人可以注册此事件”
答案 0 :(得分：6)
在我看来，最好的办法是获得一个体面的第一版本，它可能无法完全处理所有意外情况，但是是经过深思熟虑和模块化的。然后，您可以返回并完善逻辑，以便您的测试通过。
在现实世界中，这种方法可以获得回报，因为当你遇到一些扭曲的事情时，你更有可能提高效率和兴趣，而不是仅仅因为试图弄清楚你头脑中的所有边缘情况而陷入困境与他们在一起开始。
答案 1 :(得分：3)
一种方法是采用TDD方法（假设您编写单元测试）。首先编写单元测试，然后继续进行单元测试。
在我看来，UI工作最后应该完成，因为你可能有很多关于后端功能的事情。
答案 2 :(得分：3)
我强烈赞成首先编写验证器。一旦你有一些似乎正在工作的东西，回去添加验证器会更加困难。通过首先编写验证器（但不一定要处理它们引发的异常），确保完成它们。它还为您提供了一个很好的机会来思考您期望的确切内容 - 这可以帮助您考虑以后需要涵盖的特殊情况。
Tracer子弹很不错，但原则并不需要应用于项目的每个方面。
答案 3 :(得分：2)
重复1-3，直到测试完所有方法。
对处理数据发布验证的业务对象使用相同的过程。
答案 4 :(得分：2)
我总是喜欢先编写功能，然后再添加验证。看起来很好，因为大多数编码都是在开发环境中完成的，没有人会在你工作的时候提交数据。
但无论你觉得哪种方式都是最好的。
我的方法的缺点是，如果你没有组织，你可能忘记在某处添加有效性或卫生检查。它确实发生了： - ）
答案 5 :(得分：2)
如果它不是太多工作，我会从基本的输入验证开始。特别是对于日期或标识符，例如订单号。放松验证比收紧验证更容易。基本输入验证可以在后端进一步节省大量调试时间。
另一方面，假设你正在谈论支持多种语言的好看的支持Javascript的验证。在这种情况下，你最好写一个简单的第一个版本，并基于此开发后端。您可以在输入表单开始接近最终版本时对其进行润色。
答案 6 :(得分：2)
一旦您的功能正常运行，您真的会回去添加验证码吗？
我们大多数人都愿意，但我们中的许多人在项目结束时都没有时间。
答案 7 :(得分：2)
我不确定这种方式或其他方式的设计是否优越...... Leekman先生说，启动功能部件然后返回并完成边缘情况的繁琐工作更有成效，我'我不确定我是怎么看的。
如果允许不允许的值（即功能代码没有预料到的值），那么使用功能代码是没用的（甚至是危险的）。
相反，如果不能以某种方式处理通过它的值，那么很好的边界检查是无用的。
在生产环境中，如果您没有涵盖有效性和功能性，那么您真的无需展示。你做这些事情的顺序应该是个人偏好的问题。如果您没有创造性并且只是想要做一些繁琐的工作，请编写代码的有效性检查部分。如果你刚刚想出完美的算法来完成咖啡休息时所需要的，请坐下来写下功能部分，然后再回到边界检查。
答案 8 :(得分：1)
我喜欢提供几个功能领域，然后对该功能进行验证检查，然后对其余功能进行验证，最后填写剩下的功能。
答案 9 :(得分：0)
如果您将代码分解为“模型”和“UI”，那么其中一些更容易理解，但基本上需要一个设计选择：您的模型对象是否假设正确的输入并将责任放在用户界面上，或者测试以获得正确的输入。
现在，我，作为一个腰带和吊带的家伙，我倾向于回答“是”的问题：模型将检查域，即使仍然应该检查输入。但无论如何，一旦你做出了这个决定，你就得到了答案：如果域检查是定义的一部分，你应该构建它并用所有其他部分进行测试。如果您将域检查与功能分开，请单独构建和测试它们。
答案 10 :(得分：0)
看过太多人们忽略了验证方法的数据库，我先投票赞成这样做。