1.2 为什么要先做代码质量提升

为什么我们认为代码质量提升是当前亟待解决的问题？这不只是因为这个问题比较严重，更是因为在团队不同角色视角下，问题解决具有可行性。

1.2.1 站在开发者视角

软件开发从业者作为一线研发人员，往往是被动接受命令的角色。在日常产品研发活动中，他们经常遇到各种各样的问题，但大多数情况下感到“羞愧”的事情就是代码质量差。

说得明显一点，一线研发人员必须关注并重视代码质量问题。

1.2.2 站在技术负责人视角

部门技术负责人都是从程序员走过来的，当提到部门人员编写的代码质量差时，自然知道这种脊梁“冒寒气”的感觉。他们会联想：谁何尝不是从一线研发人员走出来的？说我团队人员编写的代码质量差，不就是说我不行吗？

代码质量好坏的评估包含代码规范、代码设计模式、面向对象编程、技术重构等方面。这些评估内容都是技术负责人的核心职责，作为部门技术负责人做不好这些事情，向上是无法交代的。因此，提到提升代码质量，技术负责人会默默支持。

1.2.3 站在CTO视角

CTO应该会将核心能力放在前沿技术研究和战略规划上，天天揪着技术负责人解决代码质量问题，很烦！即使CTO很重视代码质量，但每周看着一直没有改进的低能代码，也会焦虑如何支撑公司亿万级的并发访问量。

CTO心里可能琢磨着为什么技术负责人都不能和自己感同身受，脑海中浮现和技术负责人交涉的画面。

技术负责人：您天天追着赶进度，业务需求都做不完，哪还有时间整改代码质量问题。要给我们点还债时间。

CTO：你们若天天都写高质量代码，还能出现这些问题吗？若你们这些技术负责人每次都严格审查代码，还能有这些面向过程的编码吗？这些事要是天天都需要我去追问，我还能干什么？

既然技术负责人针对代码质量问题避而不谈或避重就轻，CTO就想退出代码质量管理过程，让效能团队来管理并汇报，这样自己可以安心去做其他更有价值的事情。

1.2.4 站在旁观者视角

有人哭，有人笑。

PMO：终于有人帮助推进解决代码质量问题了，项目终于不会逾期了，线上问题也可能会少点。后续在向效能团队要一些数据，也能做些通过度量驱动项目改进的事情了。

产品人员：业务人员终于不用追着我问，研发人员有没有写出有问题的代码了。

测试人员：代码质量提升，提测质量高，我们稍微再测试一下就能上线，终于有精力去做自动化测试了，好省心。

既然代码质量提升能够让大家各安其好，那就让我们效能团队通过专项治理项目来解决。