最佳实践：应用程序设计的顺序

Question

编写Web应用程序时，我可以想到需要创建的相当多的组件。我知道它应该可以逐步完成，但是我想看看你通常会处理这些任务的顺序。布置你通常的事件顺序和一些理由。

几个可能的组件或部分我已经想到了：

• 故事（即pivotaltracker.com）
• 集成测试（Rspec的，黄瓜，...）
• 功能测试
• 单元测试
• 控制器
• 查看
• JavaScript功能
• ...

的问题是，你做的一切零碎？（一个故事，一个集成测试，让它通过，移到下一个，...）或者先完成一个组件的所有，然后移到下一个组件。

Answer 1

我是BDDer，所以我倾向于在外面进行。在高层次上，这意味着首先建立项目愿景（你会惊讶于很少有公司实际做到这一点），识别其他利益相关者及其目标（法律，架构等），然后将事情分解成功能集，功能和故事。故事是我们可以获得反馈的最小可用代码片段，它可能与一个或多个场景相关联。这就是Chris Matts所说的“特征注入” - 创建特征，因为它们需要支持利益相关者目标和项目愿景。 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让我们释放我们的代码提前，因为只有当用户真正掌握了它才能玩，你才能发现你真的做错了什么。