决定软件质量的三个方面

万物之始,大道至简,衍化至繁。

软件质量问题的出现

为了支持业务的快速发展，我们优先完成功能的开发，代码质量经常会被抛下，为此我们逐渐积累了技术债务。之所以称之为债务，是因为其减少了本次开发时间，虽然软件可能在当前能正常运行，但增加了后续修改维护代码的的难度，导致后续开发维护需要加入更多的时间利息。

积累的技术债务越多，我们可以认为软件质量越差。为了减少技术债务，提高质量。可以从两个方面出发：

对于及时偿还债务，我们关键是发现债务，并及时排期偿还修复。

有三方面因素决定了债务产生的速度：团队水平、开发时间及管控机制。对应到降低债务产生速度的做法为：

这三个方面的最短板决定了软件开发的质量上限,而债务可以认为是当前代码与理想代码的质量差异，提高了当前代码质量就减少了债务的产生。

提高团队水平

因团队水平关系，写出来的代码必然存在质量的上限，这个上限越低写出来的代码与理想代码的差距越大。

那如何提高团队的技术水平呢？可以从三个方面出发：

一个人想获取某方面的知识时，最廉价的方法就是读书以及上 找资料。书本能够让我们建立起对某项事物的系统认知，而上 找资料则可以补充书本中未能详尽或者描述表达不清的内容。

上述是最廉价建立系统认知的方法，但并非最快速获得初步认知的方法。最高效快速获得认知的方法应该是面授、演讲。因为面授演讲时的内容会得到提炼简化，只保留核心，同时有疑问时无需多次阅读书本或者从 上寻找资料，从导师处可直接获得答案，提高了知识的传播效率。

上面两种做法结合起来，我们可以让不同的人去了解不同领域的知识，然后各自在固定的会议上分享交流，这样能较快速且廉价地提升团队水平。

知识的传递也不一定通过书本或者人，通过工具、流程等也能传递知识。如通过IDE的辅助插件如SonarLint，FindBugs等工具可以在编程时实时提供编程规范指导，帮助同步优化代码，传授知识。又如代码Review过程，其能帮助参与各方交流编程技巧及规范 。

对于团队有用的知识，特别是业务知识，需要持续沉淀形成文档，这样才能让新人快速接受、让老人迅速回顾，具体的做法可以是维护一个统一的Wiki，格式目录可以由专人统一，但内容大家都可以填写完善。

保证版本开发时间

代码质量除了受团队能力影响外，也受可用的开发时间影响。开发时间越少，质量上限越低，与理想状态差距越大，债务越多。

影响开发的时间因素可能有：

影响因素很多，如果要让这些因素都不拖后腿的话，我们只能逐步细细地打磨完善。如工作量评估要分解到位才能合理评估、开发要倒逼业务提前完善需求、进入开发后变更要严格控制等。

举一个时间影响质量的例子。临近上线前，业务要求增加需求，那么我们有可能无法采用结构化的方式修改代码，只能用当前影响最小的补丁代码形式进行修改，代码的碎片化让后来人难以理解对应修改的逻辑，维护成本加大，形成了技术债务。

建立恰当的管控机制

团队技术水平高，开发时间充分是否就能够开发出高质的软件呢？

我们人具有惰性，有拖延症，并不是每个人都有代码强迫症。有时候即使知道怎么修改才是合适的，时间也相对充裕，也有可能往阻力最小的方向走，用当前阶段最省事的代码而不是最合适的代码完成我们的开发。

因此我们需要引入监督机制。监督可以是人工的，可以是通过工具自动的，也可以是人工与工具结合。使用工具自动化进行监督可以节约人力，并保证流程，但其对应的开发也需要成本。以下是管控机制的一些参考：

总结

提升团队技术水平、保证开发时间并辅以适当监督，能提高我们新开发代码的质量，减少债务的产生。而对历史债务登记并排期则能让我们持续消除历史债务。

无论系统的遗留债务有多少，当我们坚持上面的操作使得债务产生的速度小于我们债务清理的速度时，我们终将得到一个可维护可扩展的系统。