最佳实践:应用程序设计顺序[关闭]

我是个混蛋,所以我喜欢在外面做。在较高的层次上,这意味着首先建立项目远景(你会惊讶于很少有公司真正做到这一点),确定其他利益相关者及其目标(法律、架构等),然后将事情分解为特性集、特性和故事。故事是我们可以得到反馈的最小的可用代码片段,它可能与一个或多个场景相关。这就是ChrisMatts所说的“特性注入”——创建特性是因为它们需要支持涉众目标和项目远景。 I wrote an article about this a while back. 我证明这一点是正确的,因为不管您的代码有多好或测试得多好,它首先是不是错误的代码都无关紧要。

一旦我们有了故事和场景,我倾向于先编写UI,然后编写支持它的类。 I wrote a blog post about a real-life example here 我们用Java编程,所以你可能需要用Rails来做一些不同的事情,但是这些原则仍然存在。当有实际的行为需要描述时,我倾向于开始编写单元测试——也就是说,一个类的行为因其上下文而不同,这取决于之前已经发生的事情。通常第一个类确实是控制器,我倾向于用静态数据填充它,以使UI成形。我将编写第一个单元测试来帮助我摆脱静态数据。

首先做用户界面可以让我尽早从涉众那里得到反馈,因为用户将与之交互的是用户界面。然后我从“快乐之路”开始——让用户做最有价值的事情——然后是例外情况、验证等。

然后我尽力说服我的PM让我们尽早发布我们的代码,因为只有当用户真正掌握了代码后,你才能发现你真正做错了什么。