忽然想到这个话题，是因为读书、思考、生活的一篇BLOG：代码质量与文档质量。当然如果庄子[注1]只是说代码质量或（比较）文档质量，我也就不会有什么想法了。可是该文一开始就上升到了“项目质量”的高度，在吸引了足够的眼球之后，又偷偷的把“项目质量”的概念换成了“代码质量”。

    首先要说的是“项目质量”和“代码质量”。同样都是XX的质量，自然具有相同之处，但这相同之处也仅就“质量”而止。无疑代码是项目产品的组成部分，所以 我们也就把代码的质量看做项目产品质量的组成部分（注意我们谈到项目时实际指的是项目的最终产品，在这里我并没有偷换概念。）。由此可见，用代码质量来指 代项目（产品）质量，有以偏概全的嫌疑。

    其次是“代码质量”和“文档质量”。迄今为止，我还没有见过没有任何文档的项目，事实上文档也是项目产品的一个组成部分。尽管代码和文档在“出品”的时间 上有差别，但最终它们都是项目产品的组成部分。由此我们可以说代码质量和文档质量都是项目产品质量的组成部分，在这一点上它们是没有先后、高低差别的。就 文档来说，它是人们沟通的工具，本身是不应该做为直接的代码质量控制工具的。文档质量和代码质量之间是平等的关系，不应该顾此失彼。

    至于人为因素造成的质量控制上的失误，根本不应该由某种机制来承担。Qualified persons do qualified things.

    上面所说的仅是庄子一些逻辑上的不严密。当然不能反对庄子提出的项目质量、代码质量和文档质量，因为任何人工制品都有质量的要求。但从软件的角度看，这些“质量”都是孤立的，没有一个完整的产品概念，这些“质量”之间就缺乏联系，尽管它们对于用户来说就是一个整体。

    通常对质量的研究都是首先把质量本身划分为多个要素或组成因素，从而希望从多个不同的方面来对质量进行控制。比如把产品质量分为产品移交、产品运行和产品 改进三个方面，对应到软件又可以进一步分为可移植性、可重用性、可靠性、可用性、性能、模块性、可扩展性、可修改性等等。

    在对质量本身进行分析后，它才形成可指导、应用于生产过程中的原则，从而达到对质量的控制和把握。而一个成熟的过程控制机制，必然已经充分考虑了质量的要 求，并以质量为其最终目标。当我们考虑选择一个合适的软件过程控制机制时，也要注意这个问题。

    [注1]：庄子即读书、思考、生活。