6.2 架构设计

    撰写详细设计是一个逐步细化、深入的过程。没有人能一次就设计出完美的东西，需要及时的沟通，包括与客户的反馈，与其他项目组成员的讨论，这样有助于降低开发时偏离需求的风险。也就是说，在开发之前题，是建立在设计者的想法有客户的确认和开发人员的理解的基础之上设计撰写人必须与系统分析员反复讨论，以透彻理解用户需求；

    一项需求可能有多种方式实现，设计者必须与系统分析员确定该需求将采用何种方式实现，将达到何种效果，以消除将需求映射为设计的歧义；讨论过程中还可能会发现需求有不完备甚至错误的地方，在需求重新确定后设计者需修正设计。设计文档必须写清楚各个模块/接口/公共对象的定义，列明程序的各种执行条件与期望的运行效果，还要正确处理各种可能的异常。此外设计文档应该遵循一定的写作模式与版面风格，使用统一的术语或惯用语，使得小组成员很容易理解。以上这些活动综合起来将是一个很细致、很耗时的工作过程。就个人所知，一些公司的详细设计通常是由程序主管或少数核心的程序员撰写的，他们通常也是系统架构的主要作者或维护者。因为他们在开发团队中技术最为精湛，对架构最为熟悉，他们最有资格评价现有架构是否能适应新的用户需求，采用何种方式实现需求对架构的冲击最小。但是由少数人来负责所有的详细设计可能造成开发过程中的瓶颈甚至是设计的错误。当任务比较集中的时候，设计者可能忙得透不过气，而负责实现的同事反而在等米下锅，比较清闲。于是为了让自己不成为拖累进度的“罪人”，某些设计者就会采用一种快捷方式来交付设计：他们会与系统分析员进行初步的讨论，然后撰写一份粗糙的但仍然叫做详细设计的文档，把它交付给负责实现的同事，再通过讨论、即时通工具、电子邮件等方式解答对方提出的疑问。但由于详细设计本身不完备，他们不得不花费更多的时间和精力与负责实现的同事沟通；而且他们却很可能忘了把这些交流的成果更新到详细设计中去！（或许是他们太忙，没有足够的时间，又或许是他们认为既然产品已经实现，那么详细设计也就不必维护了。）其结果很可能是当产品开发出来后，我们才发现它跟用户要求的完全两样！原本在详细设计阶段就应该发现的需求漏洞与在那时应该确定的技术方案在实现阶段甚至测试阶段才暴露出来，而这时大家往往有木已成舟的感觉，改动的难度比设计阶段高数倍甚至十倍以上，毕竟任何再牛的人都有自己的局限。

    对于以上问题我提出全员设计，全员设计的含义就是把详细设计的工作进行适当地分解，把它们分摊到小组内其它同事身上，让大家都参与设计。这可以说明如下：

    当一组用户需求基本确定下来后，程序主管需要估计需求的相关性、需求的优先级、设计的难易程度、设计的工作量等，将该组需求分解为一或多项设计任务，并指定给适当的同事。参与设计的每个人必须负责至少一项设计的撰写任务。设计者从系统分析员处获得详细的用户需求，并与系统分析员反复沟通以透彻理解用户需求。他还要分析系统架构及产品的已实现与/或已规划部分，理解架构的设计理念，理解产品不同模块之间的协作关系，理解架构与产品之间的约束和依赖。当然对系统架构和产品的分析不可能穷尽每一个细节，只要分析与即将开发的模块相关的内容即可。

    一项设计任务，它可能需要多个程序员完成。比如用户界面或网页由某位或某组同事负责，而业务逻辑组件则由另一位或另一组负责，数据库部分则又由其它同事负责。设计者必须考虑他们的立场，以各方面都相对容易理解的方式写清楚主要的模块/接口/对象定义，明确相应的调用规则与主要逻辑处理。如果某项设计任务所涉及的内容太专业化，设计者并不熟悉相关的内容（比如某位C#程序员并不熟悉如何编写一个存储过程），他可以用描述性的文字说明该部分的设计要求，并知会相关的同事补充。其它同事在补充时可以对这些描述性的文字重新整理，以更加确切地表达设计内容，更符合文档的书写惯例。在设计文档完成后，设计者必须把他提交给程序主管或由程序主管指定的程序员审阅。个人推荐由其它程序员而不仅仅是程序主管来审阅。不用担心等待多个人的审阅意见是否可能导致一份设计滞留很久。大家可以并行地工作，不必是A审阅后才能B审阅。可以交叉审阅，即A的设计由B、C审阅，B的设计由A、C审阅等。审阅意见可以用多种方式（如讨论、即时通工具、电子邮件）反馈给设计者，设计者负责汇总这些意见并修正设计。以个人的经验而言，通常设计交付审阅后半天内就可以收到反馈意见了。设计经过反复地修正直至没有人再提出修正意见，这时就可以由程序员实现了。以个人的经验而言，一份设计通常两、三轮反馈后就可以定稿了。如果多次反馈后仍不能定稿，极有可能是：

    a)需求尚未明确，各个方面（包括客户、系统分析员或设计者）对需求的看法不统一

    b)技术或系统架构存在严重的限制，无法用较方便的方式实现