首页 > Web开发, 动态语言, 挨踢(IT) > 《Agile Web Development with Rails》抄书笔记(04):Depot的概要设计

《Agile Web Development with Rails》抄书笔记(04):Depot的概要设计

2013年4月16日 发表评论 阅读评论 670 人阅读    

《Agile Web Development with Rails》抄书笔记系列

  “《Agile Web Development with Rails》抄书笔记系列”目录

  上一节,我们介绍了Rails的整体架构。实践出真知,如有想更加真实体会Rails的魅力,还是使用Rails自己动手开发一个网站来的更加真真切切!所以,本系列文章从本节开始,带领大家从零开始,做一个购物车系统。另外,这里特别说明一下,本系列的基本内容会跟着《Agile Web Development with Rails》这本书的内容来。(D瓜哥也是初学,想自己玩;水平所限,还玩不转。)D瓜哥也会亲自实践一遍,如果实践中发现什么问题,会努力解决,问题描述以及解决方案都会放在所在章节一起发布出来。扯蛋完毕,转入正文。

  即使我们整天折腾简单的测试程序,它也不会帮我们完成任何实质性的工作。所以,纸上得来终觉浅,绝知此事须躬行。还是真刀真枪的去开发一个网上购物车,名为Depot,来的真切。

  也许你会有疑问,难道这个世界真的还需要开发一个购物车系统吗?但是为什么还有成千上万的程序猿前仆后继的去一遍又一遍重复编写这些代码呢?我们和其他的购物车有什么独特之处吗?

  其实,经过开发购物车这个实践,可以让我们学习很多Rails开发的知识,了解Rails的功能特性。我们将会看到如何创建一个可维护的网页,如何链接数据库中的表,如何处理会话(Session)以及如何创建表单。同时,我们还会接触到一些单元测试、网页安全以及网页布局等知识。

增量式开发(Incremental Development)

  我们将采用增量式开发方法。同时,我们不会在开发之前就把一起都详细说明。相反,我们只需要了解一些必要的需求说明,然后就开始着手开发相关功能。同时,我们还会尝试实现一些想法,然后收集反馈,以一个小的迭代周期进行设计和开发。

  这种编程风格并不是放之四海而皆准的。它要求应用的开发人员能够非常紧密的配合,他们必须根据反馈信息才能确定下一步该如何做。另外,我们也许会犯错,客户端请求到的数据和想要的数据不一样。这时,最重要的发现那里出错了,我们越早发现错误,纠正错误所需的经历也就越少。总之,使用这种开发方式,随着程序的开发,我们会有很多代码需要修改。

  正因如此,我们需要一个良好的工具,而且这个工具要能帮助我们实现我们的想法。一旦我们决定向数据库表增加一列或者修改页面中的导航栏,我们可以迅速找到修改的位置并且不至于因为修改代码而带来一堆麻烦。正如你所见,Ruby on Rails可能非常符合我们快速处理修改的要求,它是一个非常适合进行敏捷实践的开发环境。

  按照这种方式,我们将会创建并维护很多测试代码,这些测试代码可以确保应用按照我们的设想来走。Rails不仅仅支持测试代码的创建,它甚至在你每创建一个Controller时,都会生成一个初始状态的测试代码文件,方便添加测试代码。

  下面我们来说说我们将要创建的应用。

Depot功能简介

  让我们先来看一下Depot的概要设计。我们将从一个比较高的视角来看一下用例(use cases)和网页流程。我们会试着确认这个应用需要什么数据,也可以看看我们那些最初的一些猜想是不合理的。

用例(Use Cases)

  用例就是表示一些实体如何使用一个系统。咨询公司发明各种类型的术语,也许这些术语我们大家都知道,但是这并不是什么好事,浓妆艳抹也许比素面朝天需要花费更多的资源。也许平平淡淡才是福。(这段翻译的有点扯淡,原文理解起来有点费劲。)

  Depot的用例是非常简单的。刚开始,只有两个角色或者参与者:买家或者卖家。

  买家使用这个应用来浏览我们所卖的商品,选择其中的一些购买,同时创建一个订单来收集这些信息。

  卖家使用Depot来维护一个可以出售的商品列表,同时决定哪些订单等待出货,设置那些订单已经出货等。(卖家也可以使用Depot大赚一笔,然后去热带岛屿安度余生。不过,那是另外一本书的主题。)

  我们需要知道就只有这些。我们也可以去深入了解一下如何维护商品信息和一个订单的构成元素都有什么。但是,我们为啥要为这些烦恼呢?如果这些细节不是很明显,我们在给客户演示我们完成的一个迭代时,就会很容易地发现这些细节。

  我们再来谈谈反馈。首先,我们可以询问我们的客户。如果用例是通过收集客户的要求,那么我就可以勾画出用户眼中的应用雏形。

网页流程(Page Flow)

  我们总是喜欢在我们的大脑中勾画出应用的几个页面,然后试图设想出用户的浏览方式。在开发的早期,这些页面流程也许是不完整的,但是它依然可以使我们将主要经历集中在我们首先需要做的事情上以及梳理浏览动作的顺序。

  一些人喜欢在在Photoshop、Word或者HTML中模拟出应用的页面流程。我们喜欢使用铅笔和纸来干这些,这样更快,同时客户也可以参与进来,只有抓起笔,拿上几张纸,我们就可以开工了。

  第一个流程概要图是图6,买家页面流程。相当简单。首先,买家查看目录页面,同时他会选择一些商品。所有被选中的商品都添加到购物车中,购物车页面在每次添加商品都都会显示出来。买家可以使用商品目录页面继续购物,或者购买当前购物车中的商品。在结账时,我们获取买家的联系信息以及付款信息,然后显示接受订单页面。我们不需要知道如何处理付款,所以流程中的相关环境不需要搞的特别清楚。

Figure 6—Flow of buyer pages

  图7,显示的是卖家流程,同样很简单。在登陆后,卖家会看到一个菜单,可以让他创建或者查看商品信息,或者给已经下好的订单发货。当查看一个商品时,卖家可以编辑商品的信息或者直接删除这个商品信息。

Figure 7—Flow of seller pages

  发货选项是非常简单的。它展示还没有发货的订单,每页显示一个订单。卖家可以选择订单进行发货,可以使用页面上的适当的信息。

  发货功能太简单,在现实世界中不能使用,但是发货也是容易让人忽略的地方。即使我们这里提到,我们依然可能会弄错。现在,让我们把这块直接扔一边,相信等随着我们的应用的使用,等积累一定的经验后,我们可以做得更好。

数据(Data)

  最后,我们有必要思考一下要和我们一起工作的数据。请注意,我们这里不适用Shema或者类。我也不提数据库、表、主键等等。我们只是简单地讨论一下数据。在开发中,我们无须知道我们是否使用了数据库。

  基于上面的用例和页面流程,我们大致可以猜测出数据的概图,如图8。同样,使用铅笔和纸可以比工具更简单地画出所有的图。当然,工具是无罪的,使用什么工具都行。

Figure 8—Initial guess at application data

  这个数据图,还带来了一堆问题。当用户买东西时,我们需要将买家所购买的东西保存起来。所以,我们需要添加一个购物车。但是,购物车只有在使用的时候,需要暂时存储起来,其他情况下,几乎找不需要存任何东西。为了记录这个不确定性,我们使用一个问号来标注起来。我们假定在我们实现Depot的过程中,这个不确定性会得到解决。

  伴随着高视角看数据而来的还有一个问题,那些信息应该进入订单中?我们依然把这个问题暂时留下来,将来和和客户的仿佛迭代中,肯定会解决这个问题的。

  最后,你可能注意到,我们在line item中重复存放了一遍商品的价格。这里,我们打破”一切从简单开始”的规则,根据经验,这样也行更好。如果商品的价格改变了,但是目前正在打开订单中商品价格不应该改变;所以,每一个line item商品都应该将下订单时,把商品价格存起来。

  再次强调一遍,我们需要和客户再三确认我所画的图,以保证我们正确理解客户的需求。(当我们画这三幅画时,客户最好就和我们坐在一起。)

一些善意的忠告

  在书中的一切代码都进过了测试。如果你严格遵循书中所述的情景,在Linux、Mac OS X或者Windows上使用推荐版本的Rails和SQLite3,那么一切都会如所述那样工作。然后,偏差总是难免发生。拼写错误是难免发生的,他们可以得到别样的探索,这也值得鼓励。需要注意的是,这有可能会将你带至一个陌生的地方。不要担心:对于常见问题的解决办法会出现在适当的章节中,这样的情形会时常出现。一些额外的提醒也会出现在那里。

  如果书中出现了提示,那么你就应该重启一下服务器。如果你真的遇到问题,重启服务器有时也是一个不错的尝试。

  rakedb:migrate:redo是一个值得关注的神奇指令,更详细的解释在书中的第三部分。它可以恢复或者撤销最后的修改。

  如果服务器不接收表单提交的数据,那么刷新浏览器,再次提交。

开始编码

  在和客户一同,进行了一些初步的分析之后,我们就要开始进入开发阶段。这时,我们已经有一个很好的开端了,我们可以依据刚刚的三幅图来进行开发;但是,随着我们搜集的反馈信息,这三幅图很快就会过时的。这也是我们为什么不花太多精力去画他们的原因,如果我们花的精力较少,我们就可以很轻松地将至扔掉。

  在后面的章节中,我们会根据现在的理解开发这个应用。在开启下一页之前,我们不得不回答一个问题:我们首先应该做什么?

  我们喜欢和客户商定我们工作的优先级。在这里,我们需要指出,只有等商品相关开发完毕,我们才能开始开发其他的。所以,我们决定首先开发一个初级的商品维护版本,跑起来再开发其他的。当然,客户也同意我们的做法。

吐槽

  由于这章没有代码实践,所以都是翻译。木有D瓜哥自己的实践。抱歉!

Typos happen to the best of us, and not only are side explorations possible, but they are positively encouraged.

  这句话如何翻译?希望英语好的朋友能指点一下。实在搞不透这句话的意思。



作 者: D瓜哥,http://www.diguage.com/
原文链接:http://www.diguage.com/archives/10.html
版权声明:非特殊声明均为本站原创作品,转载时请注明作者和原文链接。



如果感觉这篇文章不错,请点击这里的分享按钮,分享到微博等地方去,让更多人受益!
您的支持是D瓜哥最大的写作动力!谢谢!

  1. 2013年5月2日21:27 | #1

    “Typos happen to the best of us, and not only are side explorations possible, but they are positively encouraged.”这句话到意思应该是,犯错对我们来说是非常好到,不仅让我们探索其他到可能,而且能正面鼓励我们解决问题。。。我英语也不咋地,应该差不多就是这个意思,,,,

  1. 2013年4月22日20:45 | #1
  2. 2013年5月1日21:34 | #2
  3. 2013年5月24日16:47 | #3

无觅相关文章插件,快速提升流量