一个代码应该首先检查哪些功能或有效性?

在我看来,最好的办法是得到一个体面的第一版工作,它可能不会完全处理所有的意外情况,但是深思熟虑和模块化。然后您可以返回并完善逻辑,以便通过测试。

在现实世界中,这种方法是有回报的,因为当有一些事情需要处理时,你更有可能是高效的和有兴趣的,而不是仅仅停留在试图找出你头脑中的所有边缘情况并在开始时处理它们。

一种方法是采用TDD方法(假设您编写单元测试)。从编写单元测试开始,然后努力让这些单元测试通过。

在我看来,用户界面工作应该是最后一步,因为在后端功能上可能有很多工作要做。

我强烈支持首先编写验证器。一旦你有了一些看起来有效的东西,你就很难回去添加验证器了。通过首先编写验证器(但不一定要处理它们引发的异常),您可以确保完成了它们。它也给了你一个很好的机会去思考你所期待的——这可以帮助你思考你以后需要处理的特殊情况。

曳光弹是很好的,但是这个原理不需要应用到项目的每一个方面。

1. 为验证对象的方法编写测试
2. 编写验证对象的方法
3. 测试直至通过

重复1-3,直到测试所有方法。

4. 编写表单并将数据输入到测试和工作验证对象方法中。

对处理数据后期验证的业务对象使用相同的过程。

我总是喜欢先对功能进行编码,然后再添加验证。在我看来,大多数编码都是在开发环境中完成的,在您处理数据时,没有人会提交数据。

但无论你对哪种方式感到舒服都是最好的。

我的方法的缺点是,如果您没有条理,可能会忘记在某个地方添加有效性或卫生检查。它确实发生了:-)

如果不是太多的工作,我将从基本输入验证开始。尤其是日期或标识符,如订单号。放松验证比收紧验证更容易。基本输入验证可以在后台进一步节省大量调试时间。

另一方面,假设您所说的是支持多种语言的美观的启用了javascript的验证。在这种情况下,最好编写一个简单的第一个版本,并在此基础上开发后端。当输入表单开始接近最终版本时,您可以对其进行润色。

一旦您使功能正常工作,您真的要返回并添加验证代码吗?

我们中的大多数人都想这样做,但在项目结束时,我们中的许多人都没有时间了。

我不确定设计这种或那种方法是否优越…虽然利克曼先生说,制造出功能性的部分,然后回去做边缘案例的单调工作更有成效,但我不确定我怎么看。

如果您允许不允许的值(即您的功能代码没有预料到的值)进入,那么使用功能代码是没有用的(甚至是危险的)。

相反地,如果不以某种方式处理使其通过的值,那么伟大的边界检查是无用的。

在一个生产环境中,如果您没有同时涵盖有效性和功能性,那么您实际上没有什么可以显示的。你做这些事情的顺序真的应该是个人偏好的问题。如果你不觉得自己有创造力,只想做一些乏味的事情,那么就写下代码的有效性检查部分。如果你刚刚找到了完美的算法来做你在咖啡休息期间需要做的事情,坐下来写下功能部分,稍后再回到边界检查。

我喜欢放置一些功能性的字段,然后对该功能性进行验证检查,然后对其余的功能性进行验证,最后填充其余的功能性。

如果您将代码分解为“模型”和“用户界面”,那么其中一些代码更容易理解,但基本上需要一个设计选择:您的模型对象将要 假定 正确输入并将责任放在用户界面上,或者 测试 正确输入。

现在,我,作为一个腰带和吊带的家伙,我倾向于回答这个问题“是”:模型将检查领域 尽管 无论如何都应该检查输入。但是在任何情况下,一旦你做出决定,你就有了答案:如果域检查是定义的一部分,你应该构建它并用所有其他部分测试它。如果将域检查与功能分离,请分别构建和测试它们。

我看到过太多的数据库,人们忽略了验证方法,所以我投票赞成先进行验证。