ruby-on-rails - 最佳实践 : Order of application design

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

3年前关闭。




Improve this question




我可以想到很多在创作 Web 应用程序时需要创建的组件。我知道它可能应该逐步完成，但我想看看您通常以什么顺序处理这些任务。布置您通常的事件顺序和一些理由。

我想到的一些可能的组件或部分:

故事(即 pivotaltracker.com )

集成测试(Rspec、Cucumber、...)

功能测试

单元测试

Controller

浏览量

Javascript 功能

...

问题是， 你做的每件事都是零碎的吗？ (一个故事，一个集成测试，让它通过，进入下一个，...)或者先完成一个组件，然后再进入下一个。

Answer 1

我是 BDDer，所以我倾向于由外而内。在高层次上，这意味着首先建立项目愿景(您会惊讶于很少有公司真正做到这一点)，确定其他利益相关者及其目标(法律、架构等)，然后将事情分解成功能集、功能和故事.故事是我们可以获得反馈的最小可用代码，它可能与一个或多个场景相关联。这就是 Chris Matts 所说的“功能注入(inject)”——创建功能是因为它们需要支持涉众目标和项目愿景。 I wrote an article about this a while back.我证明这是合理的，因为无论您的代码多么好或经过良好测试，首先它是否是错误的代码都没有关系。

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

首先做 UI 可以让我及早从利益相关者那里获得反馈，因为它是用户将与之交互的 UI。然后我从“快乐路径”开始——让用户做最有值(value)的事情——然后是异常(exception)情况、验证等。

然后我尽我最大的努力说服我的 PM 让我们尽早发布我们的代码，因为只有当用户真正掌握它来玩它时，你才会发现你真正做错了什么。