Agile Web Development with Rails 翻译(八)

Agile Web Development with Rails 翻译(八)

第五章 Depot应用程序

我们浪费时间在简单测试应用程序上，这不会帮着我们发薪水的。所以让我们真正地做些事。让我们创建个基于Web的商店购物车应用程序叫“Depot”。

2006年4月16日更新

这世界还需要其它的购物车应用程序吗？不，不会，这不能阻止开发者写它们，我们的与它们有什么区别吗？

认真地说，我们的购物车将展示很多Rails开发的特性。我们将看到如何简单地创建维护页，链接到数据库的表，处理会话，和创建表单。在下面八章，我们也会接触到外围的话题，如单元测试，安全和页面规划。

 

5.1 递增式开发

 

我们将以递增式开发这个应用程序。我们将不试图在我们开始编码前指定每件事情。相反，我们尽可能多地完成说明后再开始，然后立即创建一些功能。我们将在设计与开发上一步步循环着做。

编码风格并不总是可用的。它要求与应用程序的用户紧密合作，因为我们想在继续之前能得到反馈信息。我们可能犯错误，或者用户发现它们想要的与实际上做的有差别。这不是问题的原因—尽早地发现我们的错误，会减少修正错误的时间。所以这种开发风格在我们继续之前，还要有大量的修改。

因为个原因，我们需使用一个工具来修改对我们心智的处罚。如果我们决定我们需要给数据库的表添加个新列，或修改页之间导航，我们需要能够做到这些，并且不会修改大量代码或配置。如你所见，当你需要处理这些修改时，Ruby on Rails就会大放光芒—它的思想是敏捷开发环境。

 

5.2 Depot是用来做什么的

 

让我们大概地记下用于Depot应用程序的轮廓大纲。我们将查看高级别使用案例并起草web页的流程。我们也试着给出应用程序需要的数据。

 

使用案例

 

一个使用案例就是一个有关某些实体如何使用一个系统的声明。顾问们发明了这个短语是因为它们想要更多的钱—花哨的语汇总是比简单的词汇更符合商业要求，即使简单的更有价值。

Depot的使用案例是简单的。我们开始只区分两种不同的角色或演员：买方和卖方。

买方使用Depot来浏览我们可以出售的产品，选择一些产品，然后申请需要创建一个定单的信息。

卖方使用Depot来管理用于出售产品列表，并等待处理定单，然后将定单发货。(卖方还使用Depot来印制钞票)。

现在，这就是我们需要的所有细节。我们现在该进入到”管理产品意味着什么”和”准备发货的定单的内容”阶段。如果此处的细节不是很明显，我们会继续探讨，直到我们认为知道消费者的工作是什么了为止。

谈到反馈信息，让我们不要忘记确保我们最初的使用案例是按客户要求做的。

 

页流程

 

Dave 说过：我总是想在我的应用程序中有个main页的想法，并且用户大概地知道如何使用它们。在开发的早期，这些页流程还不很全面，但它们还是会帮助我们关注，需要做什么和知道事情如何做的次序。

有些人想使用Photoshop，或Word，或HTML来仿制web应用程序的页流程。我想使用笔和纸。它非常快速并容易给客户演示。

 

 

 

 

 

 

图5.1是我的第一个买方的流程草图，它是很传统的。买方看到一个分类页，从哪里它一次可选择一种产品。每个被选择的产品将添加到购物车中，然后购物车在每次选择之后被显示出来。买方可以使用分类页面继续浏览，或者它付款并买下购物车内的产品。在付款期间我们捕获内容和支付细节，然后显示一个收据页。我们也不知道我们如何处理付款，所以这些细节在流程图中很含糊。

图5.2显示了卖方的流程，也是相当地简单。在登录后，卖方看见它可以创建或浏览产品的菜单，或者是已发货的定单。一旦浏览一个产品，卖方可以选择编辑产品信息或删除这个产品。

 

 

 

发货操作很单纯。它显示每个还没有发货的定单，一个定单一页。卖方可以选择跳过下一个，或可以为定单发货，通过使用适当的页信息。

The shipping function is clearly not going to survive long in the real world, but shipping is also one of those areas where reality is often stranger than you might think. Over specify it upfront, and we’re likely to get it wrong. For now let’s leave it as it is, confident that we can change it as the user gains experience using our application.

 

数据

 

最后我们需要知道的事是我们用来工作的数据。

注意我们没有使用单词如，计划或者分类。我们也没有谈到数据库，表，关键字等等。我们只是简单地谈数据。在开发这个舞台上，我们不知道我们会使用什么，有时候一个无格式文件可能比数据库更实用。

基于使用案例和流程，我们工作上用的数据似乎与图5.3类似。再一次用笔和纸画些草图。

 

 

 

 

数据图表上的工作引起些问题。当用户建立它们购物车时，我们需要有地方保存它添加的产品列表，所以我添加了一个购物车。但是购物车除了用于临时存放这个清单之外，它似乎还应该做些事情—我还想不到能用它在保存什么有意义的东西。为了能反映出这种不确定性，我放了一个问号在草图的购物车旁边。我假设这种不确定的东西会随着开发的深入得到解决。

高层数据也会带来应该放置什么信息到一个定单这样的问题。再一次，我选择先放下它—我们在开始显示给客户时重定义这个特性。

最生，你可能已经注意到，我们在商品项目数据中有重复的产品单价。这儿我想插一句，“开始时，要尽可能让它简单”。如果一个产品的单价更改了，那个单价的更改不应该反映到当前已打开定单的商品项目中来，所以每次产生的定单内的每个商品项目都需要反映产品的单价。

Again, at this point I’ll double check with my customer that we’re still on the right track. (当我画这些草图时，我们的客户与我座在同一间屋子里。)

 

5.3 开始编码

 

现在，可以做下来与客户做些初步的分析，我们准备开始开发了！我们将从我们原有的三张图开始工作。但是快速启动它们会是最好的机会—因为我们得到反馈时，它们可能会变得过时了。有趣的事，这种方式不会花费我们太长的时间—如果你不能花很少时间创建它们话，它很容易抛出别的东西来。

下一章，我们将基于我们现理解来开发应用程序。但是，在开始之前，我们必须回答一些问题，我们首先应该做什么？

我想与客户一同工作。在这种情况下，我们向她指出，我们现在很难开发出任何东西来，除非我们能知道系统中有什么基本的产品。所以我建议花些时间来找出最初的产品管理功能。