说起质量，程序员都是一把辛酸泪啊。
渐行渐远的质量体系
对于质量，不光每个公司非常重视，很多的国际化组织也非常重视，于是他们纷纷搞出了种种质量体系，于是，大批热衷于考试的同学们又有活干了，于是，大批的培训机构也从心里乐开了花。
渐行渐远的混账质量体系，四代就不愿意多想了，四代还是把目光集中在了实际的项目质量上。如何来衡量软件的质量？这个倒是大家都懂，根据Bug数量嘛！
提起Bug，四代想起一个段子：“问：程序猿最讨厌康熙的哪个儿子。答：胤禩。因为他是八阿哥（bug）”。
确实，Bug的数量客观的反映了软件的质量，所以大量的公司把Bug的数目列入开发人员的考核指标中的做法就不足为奇了。既然这样，为了提高软件质量，我们就减少Bug数目嘛，听起来无比正确，无比英明！甚至还有的兄弟直接提出：应该 0 Bug嘛！可是实际情况是这样的吗？
Bug是怎么炼成的
要真正的了解Bug的意义，需要首先来了解一下Bug的组成。通常来说，实际的项目运作中，开Bug会出现在如下场景中：
1. 软件实际功能与预期的表现不同
这个不需要多说了，实现的功能和设计的不一样，这个是狭义上Bug的全部含义，这也是传统意义上软件质量的全部含义。这帮小子，看我怎么收拾他们，哼！这是大多数项目经理看到这些Bug的第一感觉。
2. 软件缺少一些功能
少一些功能，严格来说，不是软件的缺陷，很多的公司也是采用各种文档和工具来管理这些需求，行不行？非常行！只不过作为一个以敏捷为核心理念的“互联网+”时代的团队，四代觉得不用这么麻烦。
敏捷精神大幅削弱文档的重要性，需求文档可以作为收集需求时的重要方式保存下来。不过对于团队来说，把它们理解后记入Bug也是一个非常灵活的方式，虽然有时候往往也会需要一份详细的设计文档来描述设计细节。
3. 用户对软件功能不满意
这货不是说功能没有，也不是说开发错了，而是开发出的功能与客户的习惯不匹配，不习惯自然就不满意了，于是电话来了，客服MM必须要安慰一下，然后开个Bug提交给研发部门，谁让客户是上帝呢！
不过很明显很多人对上帝的理解有误，认为他钱花了，就是大爷，态度非常强横，更过分的是很多人还没花钱也这么强横。
4. 团队对功能的改进计划
这一部分主要来自团队内部对软件的改进意见，大部分可能是从技术角度来说的，比如重构，架构等。
从长远的来看，代码的质量也严重影响着软件的质量，这里代码的质量可不仅仅包括正确性，更多指的是代码的可读性，传承性，也就是：简单，简洁，简短，灵活。
在四代的经历中，这几乎就是开Bug的几个最主要的动因了。除此以外，还有许多无法纳入正常分类的各种稀奇古怪的问题，大家通常的做法也是开Bug。
纵观上面所有的类型，简单的用一句话来总结就是：Bug是多样的，不仅仅是质量的指标，更为贴切的说，Bug是协同工作的工具。
Bug是合作的工具
这么一说，你还觉的使用Bug数量来衡量开发人员的绩效还有道理吗？
其实在四代的经历中，只要是尝试这么做的团队，几乎都会把开发团队逼急，以致于时常看到开发和测试大撕逼的情形。
四代至今还清晰记得在某年的年会上，某测试团队自编的一个小品。这个小品的场景模仿的就是植物大战僵尸，只不过植物换成了开发团队，僵尸换成了高举着Bug的测试团队。
在一波波Bug的来袭中，开发和测试之间不断斗智斗勇，最终在一大波Bug来袭中，无力回天的开发们终于祭出了最强的技能-Postponed，就是延期处理，于是世界清净了。
四代用大拇指都可以想象得到，演这场戏的时候，测试团队是多么的无奈，而开发对于Bug是多么的抵制。因为Bug代表着绩效不好，代表着实际利益的损失，这就是很多开发团队一听到开Bug就急眼的原因。在这种情形下，Bug代表否定，这就是开发团队的后顾之忧，安全隐患。
而对于斗争的另一方-测试团队来说，一旦Bug数量也成为衡量团队的绩效的指标的话，那么效果立竿见影，开发团队和测试团队立即水火不容，这对于团队来说真的是最为糟糕的事情了。
于是，四代在确立考评精神的那个时刻开始，就立即将Bug排除在外了。这样，开发没有了后顾之忧，测试没有了利益驱动。
而且四代还会不断的强化Bug合作的功效，鼓励大家有什么问题就多开Bug，于是大家可以平心静气的对待Bug了，大家不再害怕Bug了，Bug终于恢复了其本来的面目：合作的工具，质量的表现！
论项目经理技术必须过关
这样一来，很多人一定觉得天可能会塌下来，对于那些滥竽充数的开发来说，没有质量的概念了，那还不就随便搞了，继而，劣币驱逐良币，整个团队就不好了。是吗？很多人一定是这么想的，四代如是说！
在四代的周围存在大量这样的人，事事追求完美的结果，如果不可以就不会去做了。这样的同学总是期待通过考评一件事把所有的绩效问题都解决，也希望通过Bug把所有的质量问题都解决。这样考虑问题往往缺乏系统性，四代以前也是这么思考问题的。
不过，四代现在的思路就是，既然单点发挥了最大的优点，但是有缺点怎么办？那就通过系统的其他点来补充，这就是四代的团队建设理念：以系统代替单点，系统内通过互补来达到平衡！
如果你足够细心的话，你会发现，上述Bug类型中有两类是与代码质量息息相关的，就是第一个和最后一个：功能的缺陷和代码改进计划。对于这两类Bug，代码质量起着至关重要的作用。
于是，对于四代来说，非常大的一部分时间就应该花在代码质量上，而这不仅要求四代本身的代码质量水平要比较高，因为他要判别代码的质量的好坏，而且要求四代拿出一些规范来约束团队的开发流程和测试流程。
从这两个角度来说，做好一个项目的质量管理，至少需要两个方面的准备：技术上的准备和管理上的准备，对于很多的传统的公司来说，需要两个人来完成，一个是技术经理，一个是项目经理。
不过在“互联网+”时代，团队小微化。四代觉得，完全可以由“项目经理一个人来主导，团队配合”来达到这个效果。由于要主导这件事，所以，四代一直坚定的认为：软件项目经理必须首先是一个优秀的程序员，否则他不会深刻的认识到代码对软件质量的巨大影响。
四代见识过太多的这样的半吊子项目经理了，本身技术根本不过关，但是机缘巧合走上了管理的路子，虽然他们也知道质量很重要，但是也就仅仅知道而已了。
他们根本不知道项目的代码可能已经乱的一塌糊涂，他们意识上根本没注意到这个，他们还在满天找些不太靠谱的原因来解释这种现象。稍微好点的项目经理也许还会制定些合作规范来改善外部的条件，殊不知根本原因就藏在项目内部-代码质量，它根本没有被重视！
历史上无数团队或国家的灭亡都归结于一件事：祸起萧墙，软件也是一样。
项目质量保证二重奏
为了保证项目的质量，四代做了两件事：第一件事是制定代码规范和审查机制，这个已经运行，这是从代码上保证，也就是代码质量；另外一件事就是建立团队唯一正式，也是最重要的文档-测试文档，这是从测试和文档上保证，也就是软件质量！
俗话说的好“冰冻三尺，非一日之寒”！代码质量也不是一步达到的，而是经过多次精心的修改而来的，这个过程就是重构！那么重构到底是在干些什么呢？