【修炼九】总设/概设/详设

2013.6.2

设计能力是技术人员水平的主要象征之一，项目组的技术人员跋涉了前面的各个阶段，终于迎来了由他们自己主导的时间。优秀系统的总设、优秀的模块的概设追根到底是设计人员的自己能力的展现，这要求他们有足够的视野，经验和思考。项目管理在设计阶段主要起到的作用是：

1、帮助设计经验不足的组员进行缺陷预防，保住设计质量的底线

2、给予经验丰富的专家以明确的目标，以便进一步提高设计的质量

3、降低返工的风险

按照项目的五要素，设计阶段分为以下阶段(图片可放大网页看)：

1、干系人期望-目标

      在项目流程中划分总设，概设，详设的主要目的是：

      总设：根据架构和需求将系统划分为多个功能和基础模块，并定义清这些模块的交互方法及接口。

      概设：模块概要设计是将模块拆分成多个子模块，并定义清子模块间的交互方法及接口。

      详设：将每个子模块的内部逻辑，流程图，甚至伪代码理清，为后续的编码直接服务。

      在设计阶段常见的干系人：

      1）主管/产品经理：他们主要期望产品的稳定性及扩展性，通常一个设计被大家认可，至少要包含这两方面中一个因素。 

           基础功能的稳定性能够迎来客户的好感，而扩展性能够降低后续再次开发的工作量，会被主管和产品经理所期望。稳定性通常在产品需求中会进行要求，

           扩展性往往是可以获得亮点的突破口。

      2）技术支持人员/客服人员：他们期望系统及模块能够被方便的调试排查问题，即设计的可维护性。

      3）测试团队：测试期望开发在设计阶段能够考虑清自动化测试的方案，以便能够降低执行测试及回归测试的工作量。

      4）项目经理/主管：在总设阶段能够抽出公共代码以便降低当前版本的风险及工作量，同时能够为后续的项目提供帮助。

      

2、沙盘-思路

      1） 开始前挂牌讲解好的设计及槽糕的设计

      能够做好一件事情的前提是，要当事人能够清晰“好”的判断标准是什么？如果要超预期，首先要当事人了解到“期望”是什么？因此对于新员工或是设计经验还不足的组员，能够帮他们理清“怎么样的设计才算是一个好的设计”至关重要，这样他们才能够在正确的方向上投入他们的精力。而做这件事情的一个最好的办法，就是开始设计前讲解当前部门或公司里的典型好的设计及坏的设计，如此这样能够让大家在出发前得到一个方向上的共识。需要注意的是：槽糕的设计教育的意义往往用处比好的设计更大，因为好的设计需要积累和灵感，而槽糕的设计往往是可以避免的，一个中规中矩的设计不是一个很高的要求。

      2）健壮性分析

      对整个系统及关键模块做健壮性分析往往非常有必要。因为当系统或关键模块遇到异常往往会给客户带来巨大的影响，甚至是不可恢复的损失。健壮性分析的主要的方法是罗列可能遇到的异常场景及系统或模块应该做出的处理如何。

      例如：给客户提供用户认证的模块应该至少应考虑如下异常场景：

                1）当系统内存不足时，如何保证认证的优先级

                2）当进程出现假死后，如何检查出来，防止长时间无法影响认证请求

                3）程序崩溃时，如何快速恢复进程

                4）设备掉电或程序崩溃时，如何保证已经通过认证的客户，不用全部重新认证

                等等

      

       3）扩展性分析

       扩展性对于可预计会经常变化的业务模块尤为重要。达成好的扩展性的方法是通过“高内聚，低耦合”，将业务代码和逻辑代码分离来实现。好的扩展性可以大大降低后续的开发成本，对于持续化的项目非常重要。

       例如：做一个抓包的协议分析软件（譬如：wireshake），它的扩展性主要在于

               1）后续可能会有更多的协议需要分析

               2）后续可能会有更多的包分析结果的呈现方式

               将这两部分做成插件式加载则是非常恰当的设计

      

      4）可维护性分析（自动升级等）

        可维护性设计通常包含两部分;

         a、当系统或模块出现故障时是否容易排错

         这里便要求系统或模块设计便提供方便的排错方法，以上面提到的用户认证为例:

         例如：日志分级，我们可以将用户认证步骤分为12个步骤，并将每个步骤打印一条日志，则方便追踪问题。

                    内存打印，从后台输入参数可以将指定用户或所有用户当前的内存状态打印出来。

         b、当系统或模块出现故障时，修复成本及风险是否可控

         对于做产品的企业，一个故障排查出来后，通常外面在使用有问题的产品的客户已经很多，这时候能否方便，快速的更新则非常重要。而能否方便和快速，取决于系统或模块的可维护性。

          例如：一个产品本身有自动升级功能，当前排查的故障在于网络流量更新，导致插件功能失效，同时主程序对插件有强校验，这时候我们就可以快速得将新的插件更新到网络上。

      5）自动化测试分析

          好的设计应该从一开始就为自动化测试进行考虑。一个系统或模块能够方便编写出基本功能的自动化测试案例对于质量是件非常有益的事情。以协议分析软件为例，我们可以设计如下的自动化方法：

         a、编写一个工具可以生成指定协议的数据包 

         b、系统可以从文件中直接load数据包，进行协议分析，并且自动校验是否与输入期望的结果相符

      6）方案选型评审

         在设计开始之前，设计者应该将自己的想法及方案讲述给专家，方案选型的文档不要求复杂，可以是一封邮件，可以是一张图，但是做了这件事，能够避免设计大量返工。不得不说在工作中，经常发生一些诸如此类的感慨：“这件事怎么想成这样？” “这个肯定要重做了”等，这些都是没有做好基本思路确认的问题导致的。

3、计划制定

      设计阶段的评审工作量是非常大的，如果此时项目组需要很多外部专家的把关，则需要提前和这些专家协商出一个时间并统一制定出一份评审计划，以防止评审时间延拖，导致下一个阶段的工作无法完全启动。

4、风险管理

     1）太重技巧，过度设计

     不得不说确实存在这样一些同事喜欢滥用或是说过度追求设计模式，本来一个不复杂的模块，生生要套上几个设计模式，搞得继承，多态一大堆，代码可读性大大下降。所以这里要需谨慎，事实往往证明经常夸夸其谈设计模式、方法的人，通常或多或少都有过度设计的毛病。因此对不熟悉的组员，不能仅根据其言行，便主观降低他的设计风险。

     2）逻辑不周全，设计不足

     相对于上个风险来说，对于一些设计经验不足的同事，往往习惯把一件事情看得简单化，导致编码阶段有很多意想不到的“惊喜”发生。经过好的详设后编码应该波澜不惊，不能有大波大浪。对于这些组员时，有一个基本的设计方面的流程约束就显得很必须了。  例如：详设必须把主要的函数都画出流程图，经过评审。

5、团队管理

     1）新员工有师徒制

     新员工往往没有什么设计理念，这时候不仅仅是评审和理清思路就可以解决问题的。这时候他们需要更加细致的指导，因此给他们安排一个师父，就很必要了。

     2）评审时指定负责的专家

     大家很多时候对于和自己没有直接关系的事情，会抱着得过且过的状态。在设计文档评审时，也有可能发生这样的情况。因此在评审前明确哪个专家需要对设计负责，会对质量把关非常有益处。

     3）严格执行计划

     经过估算后，设计阶段已然有明确的计划。制定项目计划时我们要尽量民主，但是当计划制定下来后，要维护其严肃性，不能一味的调整。

     例如：有计划延期，无法调整时需要加班解决，也是在情理之中的，否则项目计划很快会成为一纸空文。