改进软件企业的设计能力的二点建议

    在很多的软件企业中，存在设计环节薄弱的毛病。他们通常的做法是，由公司的设计能力较强的技术人员，给出一个概要的设计，这些概要的设计，往往是相当的概要，也就只是对子系统划分、接口、关键的实体模型的关键属性、系统运行结构等进行定义。做得好的，会做一个类图、时序图什么的。然后这些设计就交给了编码人员。编码人员根据这些设计开始编码，一切好像很顺畅。但是编码人员出来的是什么呢？有二种可能，这个编码人员水平很好，他根据自己对系统的理解，自己增加一些新的设计，或者他发现原有的设计有很多不足的地方，它改进了一下。但是设计人员不知道，这个改进无法作为组织财富在下次设计被采用。另一种可能则是，编码人员的水平一般，他根本不清楚如何细化这些设计产物，只是“依葫芦画瓢”地堆砌代码。

      如何改善这种局面呢？

      第一、架构师要深入到开发组中、深入到编码环节。

      第二、采用设计Workshop，提供设计产物的质量。

     

      在一个项目中，一般会有首席架构师（CSA）和架构师（SA）之分，CSA和SA都需要深入到开发组中，建议的做法是，CSA需要组织SA团队对系统关键模块的设计，以及关键设计问题的进行讨论，确定细节，并跟踪到实现。SA可以直接作为开发小组的负责人，负责详细设计工作。SA需要和编码人员进行日常沟通，要求编码人员对设计所有的疑惑，或者对设计改进建议都必须提给SA确认，不能直接在代码中体现。对于大中型项目或者产品化软件而言，不能采用“代码即设计”的敏捷方法。

      在开发后期，SA或者编码人员会直接把用户的需求变更在代码中实现，而没有通过设计步骤，或者不更新设计文档，这种做法虽然减少了项目的时间成本，但是，由于SA或编码人员对需求理解深度不足，会导致最初的达成一致理解的设计思路被逐渐偏离。而且会导致高层次的设计人员逐渐疏离业务，使设计逐渐脱离实际。

      那么，如何才能进行有效控制出现，编码人员的代码已经编写完成时，才申明自己处于某种考虑没有遵循设计这种情况呢？

      首先，是在角色职责定义上，CSA需要对系统的关键模型、系统/模块划分、关键设计机制、接口等负责，需要保证总体设计文档的更新。SA需要对所承担的子系统/模块的设计负责，需要保证系统实现和设计文档一致，设计文档中没有遗漏实现中的细节。编码人员只需要对代码负责。需要遵循设计文档，对设计文档的变更需要取得SA的认可。

     另外，需要制订定期的Review机制，SA需要负责对代码的Review，CSA负责对关键部分的代码Review，对子系统设计文档的Review。

     最后，我们还可以借助于设计和编码结合的工具，能够让编码实时体现到设计中来，而减轻SA更新设计文档的机械工作。

     对于大中型应用系统或产品化软件而言，一个可运行的系统不是成果的全部，全部的一致的文档加上可运行的系统才是工作的全部。

    

     提供设计能力的第二个方法就是把设计Workshop被确定为开发过程的一部分。在需求分析后，设计评审之前，增进一个设计研讨环节。在需求分析后，CSA/SA/高级编码人员首先一起对需求进行初步的设计研讨，就各自的经验提出各自的方案，并对设计的关键问题达成初步一致，这个初步设计研讨的结论应包括：关键的信息模型的主要属性、关键设计机制或者关键算法，设计模式（或关键类）。负责具体设计工作的SA将这些意见汇总成文。借鉴这些讨论结果，SA最终得出自己的设计文档，CSA评估设计文档的质量，如果达到要求，可以组织评审，如果达不到，需要进行又一次Workshop。

     Workshop和评审的区别在于Workshop是内部人员的活动，评审更多是外部专家参与的。

     设计Workshop可以提高设计质量，对多种设计思路进行比较，选择优解。同时，可以提高SA和高级编程人员的设计水平，并能够让编程人员更进一步的了解设计者的思路和目的。