架构设计和制定开发计划

完成需求搜集，在正式进入写代码之前，需要花一段时间设计软件高层架构和制定开发计划。这是一个准备阶段。这个阶段的主要任务是设计一个初步合理的软件架构，对具体开发任务进行人员分配，以及制定落实到比较小时间单位的（比如周）开发进度计划，让之后的软件实现工作进行地更合理、更有条理。

 

软件高层架构设计的主要任务是合理分割整个软件系统，使软件结构更自然、更易扩展，更能适应不断的变化，同时也为开发团队今后进行有效的并行开发创造条件。

对软件高层架构设计，要遵循真正的面向对象的分析和设计（OOAD）原则。正确的面向对象分析设计，强调以三个不同层次的视角（Perspective）：概念层（Concept），接口层（Specification），实现层（Implementation），来认识整个系统。在不同阶段用不同的视角来分析系统，可以使我们获得更合理的系统抽象；在不同阶段以不同的视角来处理不同的系统细节，可以使我们在某个特定阶段必须处理的信息量合理地大大减少，从而让我们有限的思维能力和记忆能力更有效发挥功用。此所谓好钢用在刀刃上。提高我们做出正确决定的机会。特别是对于一个比较复杂的软件系统，如果没有合理的思维层次，如果我们从一开始就必须处理所有的实现细节，势必极大地增加我们思考的难度，就会导致“一叶障目”，“只见树木不见森林”的情况。

 

我们分析整个系统，应该首先从概念层入手。概念层是最高的视角。所谓概念，就是对软件功能进行合理的抽象，把软件功能在最大结构上，合理地映射到我们的软件架构中。创造合理的概念，对软件系统进行最自然的分割。在概念层，我们看到的是命名的类和类之间的交互关系。类名代表了类的责任（Responsibility）。这个阶段设计的类是最粗略的、最大结构的。只要把系统最本质的责任分配好、把这些最基本类之间的关系定义清楚，就行了。不要过早的陷入各个类的接口和实现细节。在概念层，我们回答的是系统要做什么（What）。

在设计系统有哪些类以及类之间的关系时，“高内聚低耦合”是衡量我们的类结构是否合理的重要原则。高内聚低耦合的类结构，具有更好的可扩展性和可读性，从而具有更强的生命力。

高内聚（High Cohesion）是指一个类所具有的责任和功能要高的相关性，从而一个类的改动尽量源于单一原因。高内聚的反面是低内聚（Low Cohesion），如果一个类承担了多个不相关或者关联性不强的责任，话句话说，管的事太多，特别是管的相互无关的事太多就造成低内聚。其结果是这个类的实现不容易稳定下来，因为有很多潜在的原因触发它被改动。又由于关联性不高的代码绞在一起，每次修改都充满风险。经常是改好了一个功能的Bug，却给其他功能引入了新的Bug。

低耦合（Loose Coupling）是指一个类不需要跟不必要的类交互来完成其责任。低耦合降低类的可见性，从而使系统的变动和扩展限制在尽量小的范围内，避免不必要的牵一发而动全身的改动。相反，高耦合（Tight Coupling）的类结构让类之间充满不必要的千丝万缕的联系，当遇到不可避免的改动，很难找到优雅、简单的修改解决方案，使整个系统的可扩展性大大降低。

设计模式（Design Pattern）是前人经验的总结，是真确的OOAD原则，如从概念层入手、高内聚低耦合等原则在特定场景的经典应用。通过学习、研究、和应用设计模式可以让我们领略到真正面向对象系统的设计之美。而且设计模式被赋予了众所周知的名字，如Factory, Observer, State, Bridge, Adaptor等等，逐渐成为软件设计领域的“行话”。使用这些“行话”可以极大地方便交流和讨论。所以在软件开发活动中，特别是在软件大结构设计中，多参考设计模式，多使用设计模式的名字来注解我们设计的类结构可以极大地提高交流的效率。

在考虑一个软件系统的可扩展性时，要注意不要走极端。换句话说，要注意平衡类结构的灵活性和由此带来的额外代价，避免不必要的灵活性和可扩张性。应该依据我们对系统的理解，对整个系统可能的演化方向做出合理的预测。对发生概率极小或者根本不会发生的扩展性，我们不能想当然地认为应该加入系统。中国古代的中庸哲学或许是做取舍的最好态度，记住过犹不及。

 

完成概念层的设计后，我们进入接口层。根据类所承担的责任，设计其接口。所谓接口就是类的公有方法（Public Method）。在设计接口时，我们也可以遵循一定的思维层次，首先确定其方法名。方法名要尽量清晰的表示这个方法的功能。至于每个方法的详细输入输出参数和返回值，如果对于表示大结构不是必须的，也可以忽略。在接口层，我们回答的是系统如何做（How）。除了公有方法，其他私有方法和属性可以暂缓考虑，可以不出现在架构设计阶段的类图中。

 

实现层视角是关于如何把我们设计的类和功能通过编写特定编程语言的程序加以实现。下一章将讨论软件实现的问题。

 

关于软件架构设计，最后必须指出，尽管我们在需求搜集阶段对软件功能有了较深理解，又经过了对软件大结构的设计，但是我们这时获得的认识可能还不是完全正确的，在今后的具体实现过程中，当所有细节都跃然出现时，可能有些软件结构还需要做调整。所以对待这个阶段架构设计的态度应该是，既不要因为预计到现在的设计不一定完全正确而一直长时间地停留在设计阶段，也不要因为想到今后会再调整而不认真对待，要做到恰到好处。还是中庸的态度。

 

在目前这个开发准备阶段，另一个重要任务就是制定开发计划，包括确定模块开发顺序，分配开发任务和安排开发进度。

 

确定模块开发顺序：

前面的软件架构设计，分割了系统，为我们制定合理的、支持并行开发的模块开发顺序，创造了条件。确定模块开发顺序的原则一般是底层模块先开发，重要功能的模块先开发。底层模块先开发为上层模块提供开发支持，否则上层模块的开发者需要自己搭建假的底层模块，费时费力。重要模块先开发是遵守“做最重要最紧急事情”的原则。一个软件的所有功能不可能都同等重要的，一定有对用户来说更重要更经常用到的功能，对这样子的功能，我们要首先安排人力物力实现。其实在迭代的开发模式中，每一次迭代周期需要完成的功能，都应该是按照“最重要最紧急”的原则来挑选，使得用户最关心、对用户最有价值的功能，在早期被开发出来。这样做至少有一个好处，当预计的项目开发时间用完了，不得不以减少功能来加快软件发布时，砍掉的功能都是相对不太重要的，因为最重要的在项目早期或者前期已经实现。这样使我们到了项目后期安排、调整开发计划更灵活，而不会到了末了才发现用户最需要的，或者软件的最大卖点没有实现，那样项目延期就成了唯一的选择。

 

人员安排：

开发人员安排的原则是根据项目需要和开发者个人的爱好，给每位开发者安排尽量平均的与其能力相适应的开发任务量。另外，为了在整个开发过程中进行有效的代码审查，最好成对的安排开发任务。所谓“成对”就是每一个具体功能除了一位主创人员，还要一位副创人员。主创人员负责该功能的设计实现，副创人员审查主创人员的设计实现，副创人员最后要到达对该模块跟主创人员相似的熟悉程度。我们都知道代码审查的好处，但是要进行真正有效的代码审查，审查者需要具备相当程度的模块知识才能使审查不致流于形式。让开发人员结成相对固定的开发和审查关系，就可以使审查者从一开始就对要审查的模块具有相当的知识，从而保证了审查的效果。

 

制定详细的开发计划：

开发计划应该详细到比较小的时间单位，比如周。开发计划应该保证整个开发周期有一个比较好的节奏。好的开发节奏对开发过程很重要。整个开发周期将以迭代的方式组织。具体的迭代形式，在后面相应章节介绍。按照迭代周期，设定多个里程碑，作为整个开发周期的检查点。

在这个阶段的开发计划要与开发人员一起制定，最后制定的计划一定要得到开发人员的认可，也就是要得到开发人员的承诺，大家都认可这个计划是现实的。

最后还需要指出，跟软件架构设计一样，这个阶段的开发计划会随着开发的进行不断调整。调整的依据是每次迭代的真实完成情况。