过程质量和结果质量

本身是非常讨厌各种非技术性的流程约束的，因为流程是死的，人是活的。有些问题当你明白了其中的原理之后，其实硬性的过程规定是不怎么符合该项目的特殊性的，反倒“为了流程而流程”，影响项目进度，并且该部分流程性的东西并没有实际的结果产出。

但是，过程约束，是能勒住“质量”这匹脱缰野马的有力缰绳。在参与项目过程中，亲身经历了项目组成员中完全不关注过程质量，认为只要尽快完成项目需求，按期将代码发布上线即可，但是又囿于技能熟练程度和知识范围，导致设计/编码上存在缺陷，甚至提交代码后，build都无法通过种种质量堪忧的情况s。

经历这些情况后，开始对“过程质量”进行反思。实际上，不论对设计开发人员，还是对质量保证人员，过程质量（包括为了质量目的，在研发的各个阶段中存在的一些流程性要求（如CodeReview，覆盖率，静态代码扫描，质量相关的验收必须由测试人员来完成等），是能够弥补经验技能或者设计能力不足的缺陷的。之所以有这些要求也是有前人的经验总结出的大大小小的坑，可以通过这些方式规避。因而每个组织内部都有自己的特定的一些流程，盲目规避或者仇视这些所谓的流程，会引入更大的质量风险。

简单来说，如果够牛X，说自己不用这些过程，也能达到质量标准（注意，不是无bug），那可以省去这些流程，如果不能，还是老老实实按规矩办事，并且，任何以“项目上线时间要求紧”为借口，推脱过程质量的，最后必然为此付出更多的精力和时间去补课。