提高代码内外部质量的22条经验

原创做品，容许转载，转载时请务必以超连接形式标明文章 原始出处 、做者信息和本声明。不然将追究法律责任。 http://powertoolsteam.blog.51cto.com/2369428/1298688

本文主要关注代码的内部和外部质量，编程的价值观，代码质量的评估标准，整洁代码的匠艺以及如何维护已有的代码。

外部质量：用户所能感觉到的部分，正确性，易用性，效率，可靠性。

内部质量（代码质量）：可维护性，灵活性，可移植性，重用，可读性，可测试性，可理解性。

总结的22条经验以下：

1. 代码分为外部质量和内部质量，好的产品不等于好的代码（Good Software != Quality Code）。

2. 产品的冰山效应：产品经理以及用户关注的部分只是冰山露在水面以上的部分，隐藏在下面的是看不见的更加庞大的部分，那就是咱们庞大的代码。
   

3. 拒绝 PPT 架构师，架构师应当写代码，哪怕这些代码并不 Check-in 到最终的代码库中。一个好的设计不是在凭空产生的，而是通过不断打磨、修改进而得到的。不存在一次设计，程序猿无脑堆砌代码可以完成的好的程序。
   

4. 编程的价值观：沟通、简单、灵活。

5. 代码最重要的功能是传递程序员的设计和思路，其次才是实现的功能。好的程序员应当写出人类可以看懂的代码，而不是机器能理解的代码。

6. 效率不是牺牲清晰性的理由，不可以由于人主观“认为”的一些小伎俩，使用晦涩的代码，企图以此提高性能。应当依赖编译器自己的优化，依赖工具对性能低下的点进行评测，进而进行针对性的优化。

7. 不要试图死磕代码加快速度，找个更加有效的算法可能更加有效。

8. 代码要先作对，在弄快。先使其可靠，再让其更快。先把代码弄干净，再让它变快。

9. Good code is not bad code。坏的代码是能够经过一些指标进行度量的。让坏代码的指标能够被机器固化并时时检查，确保代码不会变得更糟。

10. 函数自己不是用来复用，这和不少“主流的”观点不一样。函数的存在的主要意义在于：划分独立职责，隐藏具体细节操做，使得代码具备可读性，应对扩展的变化，方便进行单元测试。顺带的，偶尔能够用做复用。

11. 函数应当遵循：单一抽象层次原则、短小原则和单一职责原则。

12. 当发现一个函数具备如下特征时，须要考虑抽取函数：
    

    • 过长

    • 嵌套层数过深。

    • 天然分块，须要使用注释描述该程序块

    • 判断条件过于复杂

    • 函数的某些判断分支不断变化

    • 参数过于复杂

    • 逻辑重复

    
    

13. 局部变量应当用途单一

14. 新写代码逻辑，应当关注用户场景和类职责划分，不该当上来就考虑我要使用一个什么模式。这样势必会致使过分设计。模式用做应对变化，当后续版本发生变化时，模式用做重构现有代码。

15. 不断重构，保持代码简洁。

16. 代 码是债务，一个程序员欠下的债务，老是要还的，虽然可能不是由本人还。维护老代码的程序员又被称做代码考古工程师，常常在一大堆糟乱的代码中挖掘最初的用 户需求，每每这些需求淹没在无数的变动历史中。维护老代码是一个费时费力的过程。须要一些技巧减少修改老代码的风险。

17. 程序员应当将整洁的代码风格做为一种习惯，时刻意识到整洁代码的重要性并不断地提升重构技巧。

18. 意图导向编程能够辅助思考，并生成易懂代码。

19. 设计模式自己是用作应对变化的。若是在开发时就想着“我要用模式”，极可能会致使过分设计。在对代码进行重构时，才应当考虑使用设计模式解决问题。

20. 函数名称很重要。

21. 关于注释：

    • 若是能用短小函数描述，则使用子函数替代注释自己。

    • 确保注释和代码表达的意图一致，不然就失去了注释的意义。

    • 在重要的地方写注释，不要注释满天飞，简单的重复代码的功能是毫无心义的。要让每一处注释都有价值。不要过度注释。

    
    

22. 关于什么时候重写代码
    

    • 开发团队要预留20% 的时间用做保持对原有系统的重构。剩余的时间用做开发新功能。

    • 只要有可能，对所要重构的部分进行递增修改，让用户切身感觉到产品的改进，哪怕将工做时间延长。

    
    

    
    

以上经验分享，结合到具体工做，可能有场景须要考虑：

• 近 几年很多研发团队逐步往快速迭代方向转移，其中应当更多地关注目前代码的内部质量，是否有足够的单元测试保证代码的稳定性，是否不断地在进行重构保证代码 的简洁。在快速应对变化的同时，代码不能丝毫打折扣。咱们要常常反思，咱们估计的时间，是否已经考虑给开发团队预留了足够的重构时间？产品经理是否足够的 了解代码目前的质量状态？咱们是否在欠债？

• 对于维护现有代码，咱们常常是直接野蛮的在原有代码中继续累加逻辑，不多考虑重构，致使原有逻辑愈来愈复杂，难以理解。这一点应当受到更多关注。

最后引用一句话，与你们共勉：
知识不在于记住多少，而是在于它出发了你多少的思考。一旦咱们开始反思咱们的代码，代码将再也不同样。

本文出自 “葡萄城控件博客” 博客，请务必保留此出处http://powertoolsteam.blog.51cto.com/2369428/1298688