本文已参与「新人创作礼」活动，一起开启掘金创作之路。
Incremental Development
渐进式开发：我们将逐步开发这个应用程序。在我们开始编码之前，我们不会尝试规范所有的东西。相反，我们将制定足够的规范让我们开始，然后立即创建一些功能。我们会尝试想法，收集反馈，然后继续进行另一个小型设计和开发的循环。这种编码风格并不总是适用的。它需要与应用程序的用户密切合作，因为我们希望在使用过程中收集反馈。我们可能会犯错误，或者客户端可能一开始要求一样东西，后来又想要不同的东西。原因是什么并不重要。我们越早发现自己犯了一个错误，修正这个错误的成本就越低。总而言之，随着这种开发方式的发展，我们会发生很多变化。
What’s with turbo_method::delete?
Destroy 链接包含了 turbo_method:: delete 参数。这个参数决定了在ProductsController 类中调用哪个方法，也影响了使用哪个 HTTP 方法。
浏览器使用 HTTP 与服务器通信。HTTP 定义了一组浏览器可以使用的动词，并定义了每个动词 什么时候可以使用。例如，一个常规的超链接使用 HTTP GET 请求。GET 请求被 HTTP 定义为 一种检索数据的方式，因此不应该有任何副作用。以这种方式使用方法参数表明这个超链接应该 使用 HTTP DELETE 方法。Rails 使用这个信息来决定控制器中的哪个操作来路由这个请求。
注意，当在浏览器中使用时，Rails 将 HTTP POST 方法替换为 PUT、 PATCH 和 DELETE 方法，并在进程中添加一个额外的参数，以便路由器能够确定原始意图。无论哪种方式，请求都 不会被网络爬虫缓存或触发。
Picking Good Fixture Names
与一般的变量名一样，希望尽可能保持 fixture 的名称不言自明。当你断言产品(: valid _ order _ for _ Fred)确实是 Fred 的有效订单时，这增加了测试的可读性。这也让你更容易记住你应该对哪个 fixture 进行测试，而不需要查询 p1 或者 order4。获得的 fixture 越多，选择好的 fixture 名称就越重要。所以，早点开始会让你以后舒服。 但是，我们该怎么处理那些不能很容易地得到一个不言自明的名字，比如给 fred 的有效订单呢?
选择自然的名字，这样就可以更容易地将它们与一个角色联系起来。例如，用 christmas _ order 代替 order1。使用 fred 而不是 customer1。一旦你养成了使用自然名字的习惯，你很快就会编造一个小故事，讲述张三是如何先用他无效的信用卡支付订单，然后用他有效的信用卡支付，最后选择把它们全部寄给李四。
Association-based stories are key to remembering large worlds of fixtures with ease.
基于关联的故事是轻松记住大型装置世界的关键。
