需求的实践细节需求时期（下）

　　1、"和其它阶段的关系"的再思考。
　　上一篇的末尾我们简单的讨论了细节需求阶段和其它阶段的关系。对于软件过程的各个阶段，不同之处只是注重的焦点不同而已。在业务建模阶段，我们关注于系统的整体需求；在细节需求阶段，我们更关注于需求的细节部分。其它的阶段也是一样，架构阶段，所关注的当然是如何设计出一个合适的架构；到了设计阶段，注意力就转移到了如何设计方面。 当然，焦点的不同，导致了各个阶段所需要的技能和工具也不尽相同。业务建模阶段需要你有整体的把握能力，你可以使用简单的用例图，基本的用户素材等工具。细节需求阶段则要求你能够充分的挖掘需求和进行良好的沟通。相应的，在架构、分析、设计等阶段，也会有不同的需要。

　　各个阶段的实质就是注重点的不同，这对于大多数的软件开发而言都是一样的。不论你采用的过程是传统的，还是迭代的。

2、架构
　　Martin Fowler在他的ISA中写到：
I'm using architecture to mean the important design decisions, the ones that shape most aspects of a software system. These are often the harder decisions to change later on in the project (although often not as hard as people think). As a result these are ones where it's useful to start in the right direction, and thus knowing about architecture is a valuable skill for any software developer.

　　架构并不神秘，无非是一个决策而已，只是这项决策对软件特别重要就是了。软件开发人员可能根本没有主动的进行架构设计，但是他的行为，已经潜移默化的进行了；而还有一些人，总在谈论着架构，但是并不了解这个词的含义。 春运就要到了，学生也要赶着回家。如何选择回家的交通工具就是一个重要的决策。路程的远近、不同交通工具的价格都是显式的，比较容易知道的。而以往的经验也告诉你，火车票比较便宜，但是比较紧张，花费时间较长，整个过程也不舒服；飞机票比较贵，但是容易买到，花费时间少，整个过程很舒服。这时候你就要做出正确的决策，为回家选择一个正确的架构。你可能考虑的因素有哪一些？以下就列出了一些可能的因素：

　　拥挤程度，大家都知道春运时那种情况；
　　购买票的难易程度，火车票需要很早就要预定了；
　　是否有额外的渠道，比如你能够买到飞机的学生票；
　　经济实力，经过了一个学期的花销之后，现在还剩多少生活费；

　　根据这些因素，以及这些因素对你的影响程度，即优先级，你可以自己估算出一个或几个可能的架构方案。而这种架构的选择，直接影响到你之后的行为，也影响到行为的结果。

　　开发软件和买票回家又能有什么区别呢？一样要考虑成本、结果、时间。所不同的只是复杂了：需要专业技能，有很多不确定的因素。

　　那么我这里谈论架构的问题，和需求有什么关系呢？在上面的例子中，大家可以看到架构是根据什么决定的？是因素。因素的本质是什么？就是需求。因素，就是需求。所以，需求决定架构。上一篇中，我谈到说，在进行细节需求之前，一定要定出架构。当然，这时的架构可能只是一张草图。为什么？因为我们已经进行了业务建模，对项目有了一定的认识，对用户的需求也有一定的把握，成本、范围、时间等要素也都清楚了（如果你还不了解这些，请你回到业务建模阶段，你的工作还没有结束）。这个时候，决定架构的因素已经形成了，可以进行架构的设计了。 需求能够决定架构，架构反过来也能够影响需求。最明显的一个例子就是用户界面的设计。虽然用户界面主要来自于需求，但是不同的架构对用户界面也会有影响，例如基于浏览器的客户端，和基于Windows界面客户端能够提供的界面就不同。

　　在XP中，这种的架构设计，被称为Architecture Spike。为什么叫做Spike呢？就是说你需要专研，解决一些主要的问题，但你并不是提供一个完整的解决方案。例如，在项目的初期，如果你对新近的服务器和操作系统不了解，你肯定会花时间去了解，去试用，去测试；如果对数据库不了解，你也肯定会试着使用看看。这种行为，就是Spike。所以呢，架构的设计只是很初步的设计，而不是一个完善、定型了的设计。这一点要注意。

　　架构的选择和开发人员的经验和能力非常有关系。一般来说，它需要开发人员具有相关的经验。提供架构的厂商多如牛毛，如何选择，也是一项学问。比如，数据仓库的平台，选择的品种就很多；而Web Server的选择也是五花八门；操作系统也是一样。这些又都是和架构息息相关的。

　　3、模式
　　武功有招式，下棋有棋谱。不论是招式，还是棋谱，都是针对某一种问题的特定解决方案。在软件开发领域，这种解决方案就被称为模式。

　　"每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心，这样，你就能一次又一次的使用该方案而不必做重复的劳动"[AIS，77]

　　这句话源自模式的鼻祖――Christopher Alexander。而在软件开发领域，最值得一提的著作，就是GoF写的『设计模式』一书。在该书中，作者描述了23种的设计模式，可以说，这些模式奠定了面向对象设计的基础。而另一本值得阅读的著作，就是Martin Fowler所著的『分析模式』。

　　在软件设计中，我们遇到各种各样的问题，我们可能缺乏经验，或能力有限。这非常的正常。但是现实是，我们生产出的代码由于设计方面的缺陷，往往不够清晰，容易出错，难以扩展。相信只要是开发过软件的人，都遇到过这种问题。于是，我们就希望能够看看其他人，是如何处理这种问题的。这里的"其他人"指的可能是技术专家，也可能是经历过同种问题的人，他们对你遇到的问题有能力，有经验来解决。他们提出的解决方案往往是非常成熟的，能够解决你目前遇到的问题，也能够解决你目前尚未遇到的问题。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有