Ruby on rails 最佳实践：应用程序设计顺序

我可以想到在编写web应用程序时需要创建的许多组件。我知道这可能需要循序渐进地完成，但我想看看您通常以什么顺序处理这些任务安排活动的常规顺序和一些理由。

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

• 故事（即）
• 集成测试（Rspec、Cumber等）
• 功能测试
• 单元测试
• 控制器
• 观点
• Javascript功能

---

问题是，你做每件事都是零碎的吗？（一个故事，一个集成测试，让它通过，进入下一个测试，…）或者先完成一个组件的所有部分，然后进入下一个组件。

我是一个BDER，所以我倾向于从外向内做。在较高的层次上，这意味着首先要确立项目愿景（你会惊讶地发现很少有公司真正做到这一点），确定其他利益相关者及其目标（法律、架构等），然后将事情分解为功能集、功能和故事。故事是我们可以获得反馈的最小可用代码片段，它可能与一个或多个场景相关联。这就是Chris Matts所说的“特性注入”——创建特性是因为需要它们来支持干系人的目标和项目愿景。我认为这是合理的，因为不管你的代码有多好或者测试得有多好，如果一开始是错误的代码就无关紧要了

一旦我们有了故事和场景，我倾向于先编写UI，然后是支持它的类。-我们是用Java编程的，所以您可能不得不用Rails做一些不同的事情，但原则仍然存在。我倾向于在有实际行为需要描述的时候开始编写单元测试——也就是说，一个类的行为根据其上下文和以前发生的事情而有所不同。通常情况下，第一个类实际上是控制器，我倾向于使用静态数据填充它，以使UI成形。我将编写第一个单元测试来帮助我摆脱静态数据

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

---

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

回答得好，这种事情正是我想要的，“你做什么，为什么做”。