我们可以将程序代码的质量整理为：

    编号 重要性 审查项

    7.1 ★ 避免将正常值和错误标志混在一起返回，返回值尽量用做成功失败检查

    7.2 ★ 在函数体的“入口处”，对参数的有效性进行检查

    7.3 ★ 避免滥用assert

    7.4 ★ 避免return语句返回指向“栈内存”的“指针”或“引用”

    7.5 如果参数是指针，且仅作输入用，则应在类型前加const

    7.6 尽量采用“const &”方式来传递对象

    7.7 参数的书写完整，禁止只写参数的类型而省略参数名字

    7.11 避免省略函数返回值的类型

    7.12 函数名字与返回值类型在语义上一致

    7.13 使用const提高函数的健壮性

    7.14 函数的功能要单一，不要设计多用途的函数

    7.15 避免函数带有“记忆”功能。相同的输入应当产生相同的输出

    注：表格中列出的内容仅作为示例，根据企业和项目的实际情况，可以补充完善。

    四、 循序渐进的质量提升

    （一） 质量提升的基础

    产品的质量是最容易被识别的，产品的开发过程的质量却不容易被识别和发现。

    由于质量分布于具体的过程，过程需要良好地衔接起来才能够协调工作。工件的管理作为软件开发工作中的基础性工作，起到了关键性作用。而这方面在传统制造业已经积累丰富经验（全面质量管理（TQM）是比较经典的一个！）

    一般情况下，软件开发组织至少具备三个职能组：产品组（或需求组）、程序组、测试组，而配置管理组往往被忽略。在很长的一段时间里（有的企业至今仍未建立配置管理组织），大多数小型软件开发企业对资产管理的理解不够全面，认为只要管理好当前已编译好的产品就足够了，用户使用说明书、设计文档、程序代码、第三方组件（产品）几乎都是只储存于个人计算机硬盘上，企业没有专门的储存空间的相应的完善的管理机制，值得一提的是，开发流程（工序流程）也需要纳入资产里面。

    开发团队的工件得不到好的管理，使得团队工作经常性地遇到：找不到文档、死文档越来越多、版本错误的问题。而这些问题是造成了开发团队的工作效率和质量大降重要原因之一。工件的管理在较大规模的团队中更为重要。工件是团队协作的主要依据，也可以作为沟通的桥梁！

    我们总是强调沟通的重要性，却在沟通上出了最多的问题和浪费了最多的时间！

    所以，提升软件产品的质量，首先应当做好配置管理工作，识别软件资产内容、对软件资产进行有效的管理，提供必要的开发环境支持，减少不必要的文档检索时间，快速地获取到正确的文档（或代码），加快项目的迭代过程，提高迭代频率。

    （二） 全员参与的质量提升

    软件产品的质量是全面的。

    正因为它需要经历若干个开发过程和若干个专业人员，其质量特性之间也可能存在较大的差异，需要不同的控制方法和具备相关技能的检验人员。如需求质量和程序代码的质量，前者需要非常了解用户需求，与用户接触密切，以及具有对市场的把握能力。后者则需要掌握程序编写技术、调试技术、设计能力和项目开发经验。在实际项目实践中，当然不可以按照“需求分析”分配“需求测试人员”，“系统设计”分配“系统测试人员”这样的形式去投入和安排资源，但是我们可以针对项目自身的特点（比如哪个环节的工作质量比较差，容易出错）来加强人员培训和投入人力资源。我们更加趋向于提升各生产环节的人员自身的工作质量，因为这样更及时发现问题和解决问题，更加符合经济性原则。

    （三） 建立专职质量提升组织

    组织是工作有序进行的基本保障。

    项目管理团队热衷于制定制度和规范，规范和制度的执行效果却很少关注。

    建立一个过程改进小组，有利于制度的规范的实施，这个小组可以定期向项目管理团队提供项目状态报告（如评审会议情况、需求变更情况、每周产品缺陷趋势图、任务完成状态图、工作质量状态报告）。这样可以做到项目管理团队在第一时间获悉存在的问题和及时地解决问题。过程改进小组的工作职能并不一定要与CMMI描述的那样，我们可以根据实际情况定义它的工作职能，而且这个定义也是一个动态、持续改进的过程。