程序员、工程师用不同的编程语言写出源代码，去实现项目的需求、功能，为客户带来价值。极少客户会直接看到源代码，但源代码却是程序员的重要产出，可以视为产品的一部分。代码的质量自然会影响最终产品的质量。好的代码是好产品的基础，将来产品维护、更新升级都从中获益；差代码则绝对是定时炸弹，即使短期没有发作，公司或组织在未来也很可能付出高昂的代价。
代码质量很容易被组织所忽略。第一，“老大”往往只关心功能是否实现，客户又不看代码；第二，代码质量提高很难立竿见影，“老大”看不到明显的产出（作用体现在将来，团队的能力也需要一定时间培养，如设计能力、组织架构能力等）；第三，质量的量化有些困难，工具往往只能是辅助。因为这些原因，公司或组织只有在质量问题非常严重时，才会给予高度关注。可往往此时已为时已晚，代码已然“臭不可闻”，维护成本高企，团队苦不堪言。如果这时产品还有维护价值，组织自然会拨出更多人力物力，原来一个人的代码，可以5个人一起改。如果没价值，那就推倒重来。表面看很爽，可烂代码对新写代码的贡献可能也不大，无奈之举背后实则是大量成本的损耗（以前的资源白花了）。
代码质量一定是开发团队的问题吗？我觉得不全是。开发团队成员的素质自然很重要，可如果老大一定要把2个月的活，压到一个月来完成，工程师是怎样一种状态，想想也知道，能把功能做完就好，还谈什么思考高可扩展的设计；如果需求老是改来改去，工程师早上写的测试用例，晚上就要废掉，那还有什么动力去写新的测试。总之，”老大“或管理层要知道有代码质量这回事，它也不是免费的，要给足重视。
代码质量的标准是可调整的，而且允许”补交作业”。对一个初创公司，当某项目一个月不完成，公司就死了，代码质量的优先级当然就很低。公司这时要让团队知道，相信工程师也会理解此时是所谓非常时期，手法自然也要”非常“。但如果之后，继续忽视代码质量，没有把前期的技术债务清掉，当一个个隐患被相继埋下。等未来再遇到”2个月的活需一个月赶完“的危机，可能就无论如何都完成不了的了。优秀的团队会未雨绸缪，在项目开始时就把合适的代码质量的要求写进项目规约中，如多少单元测试覆盖，多少新增Major静态分析问题，多少平均函数复杂度。项目经理也要时常的监督质量的看板。
以下结合平时工作，总结几条团队如何提高”代码质量“的要点，
统一的代码书写规范
有时挺形式，可团队要共同遵守的规矩很多，书写的规矩就是起点。要在以前，我绝想不到书写规范会统一。可我们团队经过很长时间的努力，现在人人可以遵守，旧代码也在不断改进中。有了规矩，就似某种共同的价值观，作用潜移默化，不单单只是代码规整了，好读了这些简单。
一个题外话，书写习惯真是可以改变的，我在前面的博客就说过，现在看到”4字节Tab“就觉得不舒服，相信很多人看到“2字节Tab”也很不爽吧。
架构与设计
众所周知，好的设计非常重要，未来的好扩展性、好维护性很多来自好的设计。架构设计源于对需求的理解，根据项目需要，选择合适的主架构。架构定了，代码的主布局（大的职责划分）就被箍住了。功能细节的设计也要重视，多开几次评审会议讨论UML图，仔细分析类的职责和类与类的联系，多想想使用时的场景，并引入合适的设计模式。
代码重构
多年的经验告诉我，随着需求的变迁，像自然规律一样，代码会慢慢变烂发臭。可以与之对抗就是重构(Refactory)。Refactory并不是要把代码“重回工厂”，而是时常运用各种技巧对代码进行自省和改进，不断将对产品功能新的理解注入到代码模型中。详见《重构》。重构有时是小步快走，如重写的名字，提个函数啥的，这种最安全；有时动结构时，要大踏步，这时要小心，依靠团队找出好的方案。这时你也会看到高覆盖度Unit Test Cases的强大支撑。没Unit Test，那你要更小心了。
团队培训
团队人员经验不同，素质也参差不齐，没什么好办法，要加强培训。
培训并不是说一定要去找外部机构，便宜的公开课很多是套话，和实际情况有距离；高级的订制课又太贵。还是应该多依靠团队自身，老员工帮新员工，新员工请教老员工，没有比这再自然的作法了。新员工得到了知识，老员工也会有更多的思考，两者都加强了。时间长了，大家的能力都会提高。
团队Lead则应鼓励大家的加强沟通，组织各种形式的交流分享会。
代码评审
现在我对Code Review的理解，学习和交流为主，找BUG和问题在次。一个简单的道理，你的代码每天被一个有20年经验的人看，那会是种什么感觉，你肯定期待着一些高级的反馈。就是经验相当的人相互Review代码也会有帮助，想想当你把很烂的代码让别人看，难道不觉得丢人吗？
代码评审费时吗？当然。如果团队中所有人都找那个最牛的人看代码，估计再牛的人也扛不住。那就分散开好了，有些关键的、拿不准的、有技术难点的改动找牛人看，其它的就分散开，反正时间找了，牛人的经验总会慢慢流到组里所有人，不要急于求成，把牛人累死在半道上。一次代码提交就找一个Partner帮你看看。
杜绝Copy/Paste
不再累述，详见绝不要拷贝代码
TDD
单元测试无数次的帮助我们找到代码中的BUG、没有改全的地方、糟糕的设计（设计的不好，往往不好写测试）等等。Unit Test绝对值得每个团队拥有。
代码质量平台
Sonarqube是各种数据参数集成的地方。我时常把它比成一个苦口婆心的教练，只要你一上传有问题的代码他就在你背后絮叨，想不烦就老实改了吧。此外，Sonarqube还有很多很多强大的功能，详见它家主页吧。
在我们团队的引领下，公司很多团队都要使用Sonarqube，去检测Python，C/C++的代码。好工具就是好用。
以上文字皆有感而发，可能也没有总结全，以后想起来再补上吧！ 😀
