最近在思考研发团队质量的问题，我觉得这是个很有意思的问题，直觉上来看，bug是程序员挖的坑，但从团队的角度来看，却不尽然，接下来我们做一个深入的剖析。
个人问题
程序员的个人能力和经验会有所差异，从人才梯队角度来讲，这是很正常的。当执行的任务难度超出个人能力或经验范围的时候，出bug的概率就会增加。有意思的是，对程序员自己，这个出bug和修复bug的过程可以带来增加个人经验的正向收益。当然也不全是。说到这，我想给bug分两个类：高级bug和低级bug。当你发现程序员之间在兴奋地讨论如何修复某个bug的时候，这个bug往往是高级bug。这种bug已经超出程序员目前的经验范围，但最终被发现和解决。这就好比游戏中组团打boss，一次次团灭后，最后boss终于倒下时候感受到的兴奋感。但对于那些低级bug，程序员往往难以启齿，那是一些非常低级的错误，完全在经验范围内，但却还是出现的bug。当一个程序员反复出现这样低级的bug，那或多或少都有些写代码的坏习惯，比如忽视时区问题的习惯、没有处理NPE的习惯、不写UT的习惯等等。如果坏习惯问题不及时纠正，不仅会使自己的工作量长期增加，而且还会降低个人在团队中的竞争力！麻烦的是很多程序员都无法自己意识到坏习惯问题的严重性。解决这类问题，最好需要建立完善的readiness机制，进阶式的技术培训机制，标准化的代码审核机制，通过流程和制度可以尽可能扼杀低级bug。但对于高级bug，需要有丰富经验的资深程序员，分享他们的经验，我觉得最好的方式是写成文章或者录成视频，这比组织一场现场分享要更高效，从公司角度，如果说花重金聘请的专家是一种投资，那把他们的经验在公司内部传承下来，这样才能带来长期的投资收益。沟通问题
除了个人问题，对于强业务驱动的项目，沟通问题也是一种引发bug的主要因素。在组织结构复杂的大公司内部，这种情况特别明显。首先，分工复杂多变，经常会出现找错对接人或者重复对接的情况，比如某模块，今天是A负责，过几天变成B负责，A和B之间又缺少充分的交接过程，这会导致A和B对特定问题出现不一致的理解，最可怕的是多个人同时负责某个模块，对接的时候，他们各自会下意识地认为其他人会处理，然后就没了结果；其次，信息不对称，自上而下或是自下而上传达不及时、不到位，打个比方，需求方要一个苹果，层层copy不走样后，到程序员这里就成了番茄，最后出来的是一个绿色的产自新西兰的酸度为5的小番茄，而需求方实际要的是红色的甜度为5的新疆阿克苏大苹果！沟通上的壁垒，其实是流程和制度上的不足。客观地说，程序员的沟通能力并不是他们的特长，当他们参与到这样的工作中时，他们要花更多的时间去学习沟通和适应环境，少部分经过这样历练的程序员可以脱引而出成为骨干或者leader，而绝大多数带着挫败感艰难生存，这也确实难为了他们。所以，完善的流程和制度是至关重要的。公司或者团队管理者需要尽可能想办法消除沟通壁垒，让程序员发挥他们最擅长的能力，从而减少因沟通不畅而产生的不必要的bug。量与质的动态平衡
我曾经观察过这样的数据，团队总工作时长和总bug数是成正相关的。这个结论也是显而易见的，一定期限内工作量的增加，势必会对质量产生一定影响。
当然，影响的程度和前面讲的两个问题有很大关系。但我想说的是，业务驱动的项目中，程序员用来使自己修炼技术功底的时间越来越少，这或许也让上述两个问题不断恶化，导致产生的bug数很难呈现下降趋势。可以理解的是，为赢得更多市场和用户，整个行业都处在一个紧迫的状态，明面上虽然不说，但实际上对程序员的要求也宽容到类似流水线上的一环。
但是，在这样的环境下，自驱力差的程序员，要么甘于现状，用“做得多自然错的多”之类的借口麻痹自己，要么错误地认为“苦劳”终可换取个人价值，但往往不断受挫、不断更换环境。我们如何从有限的时间内，挤出足够的时间，来修炼自己的技术功底，这是程序员需要自己反思的。理解这点很重要，因为量的存在是这个行业造就的必然挑战，我们需要在这样的挑战下，与质找到一个平衡点，这个点并不是固定的，我们是需要在一段时间内，通过量来驱动质的不断提升。总之，