质量管理在一个正在运行的项目里很重要。我2016~2018年所在的老项目(2011年)就曾经面临质量危机，它是公司收益非常大的项目，危机是不得不解决的。
危机原因：技术债务堆积数年，开发已经陷入举步维艰的地步，大部分的技术同学一周都得忙两天时间修复线上bug。
危机解决方法：小步快跑地重构崩坏的代码，对于不方便修改的代码，直接开发一套新的兼容代码，旧的代码让其尘封起来。
解决关键：所有的小步快跑都要寻找反馈来证明有效；相信工具和自动化；
项目的是周更新的，迭代速度很快，有利于项目的改动快速得到反馈，甚至说每一个人的努力都可能在下一周得到回应。我那时在团队里以上线晚上的加班时间为自己的反馈，假如超过12点而原因是研发进度问题，则优先解决最重要的研发瓶颈问题。17年花了半年时间不断地重构，重构获得更多的时间后，又可以进行新一轮更难、持续时间更长的重构，团队重新进入良心的循环，最终技术债务逐渐基本还清，17年下半年版本质量重新稳定了。
后来我补充思考了一些关于防止项目质量重新陷入崩坏的问题。
1、在技术团队中强调代码的不仅仅是正确与否，有优劣之分，由于项目是快速迭代的，所以代码的可读性和稳定性优先于代码的性能问题。保证每个技术同学都知道这个原则，敢于对违反这个原则的代码自行进行重构（还得培训相关重构知识）。
2、在技术团队中，补充规范和文档、注释，把之前重构出来的成果以肉眼可见的形式留存下来，要求是一个实习生按照文档操作不会踩到坑。

现在该项目已经又继续稳定运行了两年多，最重要的成就感莫过于自己留下的框架和规范还有用地指导着新同学去继续这个支持这个项目。

现在新的项目依然有很多质量的问题需要处理，但是要处理的维度更高了，新项目的问题不仅仅是代码质量问题，而是更多是团队问题，这是我19年下半年最大的挑战。希望两年后回望也有我今日回望17年的成就感吧。