《代码整洁之道》心得总结

原书摘录

1. 软件质量，不但依赖于架构及项目管理，而且与代码质量紧密相关

2. 质量是上百万次全心投入的结果——而非仅归功于任何来自天堂的伟大方法。这些行为简单却不简陋，也不意味着简易。相反，它们是人力所能达的不仅伟大而且美丽的造物。忽略它们，就不成其为完整的人。

3. 我可以教你骑自行车的物理学原理。实际上，经典数学的表达方式相对而言确实简洁明了。重力、摩擦力、角动量、质心等，用一页写满方程式的纸就能说明白。有了这些方程式，我可以为你证明出骑车完全可行，而且还可以告诉你骑车所需的全部知识。即便如此，你在初次骑车时还是会跌倒在地。编码亦同此理。

4. 代码逻辑应当直截了当

5. 尽量减少依赖关系，使之便于维护；

6. 性能调至最优，

7. 整洁的代码简单直接。整洁的代码如同优美的散文

8. 整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。

9. 整洁的代码应可由作者之外的开发者阅读和增补。它应当有单元测试和验收测试

10. 整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地

11. 重要性排序：能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽量少的实体，比如类、方法、函数等。

12. 弟子们沉浸于创始人的授业。他们全心师从某位师傅，排斥其他师傅。弟子有所成就后，可以转投另一位师傅，扩展自己的知识与技能。有些弟子最终百炼成钢，创出新招数，开宗立派。

13. 任何门派都并非绝对正确

14. 读与写花费时间的比例超过10:1。写新代码时，我们一直在读旧代码。既然比例如此之高，我们就想让读的过程变得轻松，即便那会使得编写过程更难。
    注:可读性的重要性

15. 如果每次签入时，代码都比签出时干净，那么代码就不会腐坏。清理并不一定要花多少功夫，也许只是改好一个变量名，拆分一个有点过长的函数，消除一点点重复代码，清理一个嵌套if语句。

16. 名副其实说起来简单。我们想要强调，这事很严肃。选个好名字要花时间，但省下来的时间比花掉的多。注意命名，而且一旦发现有更好的名称，就换掉旧的。这么做，读你代码的人（包括你自己）都会更开心。变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你，它为什么会存在，它做什么事，应该怎么用。如果名称需要注释来补充，那就不算是名副其实。

17. 魔术数 注:魔法数字就是莫名其妙出现的数字，不知道含义，影响可读性 我用#CSDN#这个app发现了有技术含量的博客，小伙伴们求同去《编程领域名词：魔法数值、魔法数字、魔法值》, 一起来围观吧
    https://blog.csdn.net/weixin_33919950/article/details/89832722?utm_source=app&app_version=4.5.0

18. 沟通是专业开发者的头等大事。

19. 你今天编写的功能，极有可能在下一版本中被修改，但代码的可读性却会对以后可能发生的修改行为产生深远影响

20. 2002年启动FitNesse项目时，我和开发团队一起制订了一套编码风格。这只花了我们10分钟时间。我们决定了在什么地方放置括号，缩进几个字符，如何命名类、变量和方法，如此等等。然后，我们把这些规则编写进IDE的代码格式功能，接着就一直沿用。这些规则并非全是我喜爱的；但它们是团队决定了的规则。作为团队一员，在为FitNesse项目编写代码时，我遵循这些规则。

21. 学习第三方代码很难。整合第三方代码也很难。同时做这两件事难上加难。如果我们采用不同的做法呢？不要在生产代码中试验新东西，而是编写测试来遍览和理解第三方代码。JimNewkirk把这叫做学习性测试