原书摘录
-
软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关
-
质量是上百万次全心投入的结果——而非仅归功于任何来自天堂的伟大方法。这些行为简单却不简陋,也不意味着简易。相反,它们是人力所能达的不仅伟大而且美丽的造物。忽略它们,就不成其为完整的人。
-
我可以教你骑自行车的物理学原理。实际上,经典数学的表达方式相对而言确实简洁明了。重力、摩擦力、角动量、质心等,用一页写满方程式的纸就能说明白。有了这些方程式,我可以为你证明出骑车完全可行,而且还可以告诉你骑车所需的全部知识。即便如此,你在初次骑车时还是会跌倒在地。编码亦同此理。
-
代码逻辑应当直截了当
-
尽量减少依赖关系,使之便于维护;
-
性能调至最优,
-
整洁的代码简单直接。整洁的代码如同优美的散文
-
整洁的代码从不隐藏设计者的意图,充满了干净利落的抽象和直截了当的控制语句。
-
整洁的代码应可由作者之外的开发者阅读和增补。它应当有单元测试和验收测试
-
整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地
-
重要性排序:能通过所有测试;没有重复代码;体现系统中的全部设计理念;包括尽量少的实体,比如类、方法、函数等。
-
弟子们沉浸于创始人的授业。他们全心师从某位师傅,排斥其他师傅。弟子有所成就后,可以转投另一位师傅,扩展自己的知识与技能。有些弟子最终百炼成钢,创出新招数,开宗立派。
-
任何门派都并非绝对正确
-
读与写花费时间的比例超过10:1。写新代码时,我们一直在读旧代码。既然比例如此之高,我们就想让读的过程变得轻松,即便那会使得编写过程更难。
注:可读性的重要性 -
如果每次签入时,代码都比签出时干净,那么代码就不会腐坏。清理并不一定要花多少功夫,也许只是改好一个变量名,拆分一个有点过长的函数,消除一点点重复代码,清理一个嵌套if语句。
-
名副其实说起来简单。我们想要强调,这事很严肃。选个好名字要花时间,但省下来的时间比花掉的多。注意命名,而且一旦发现有更好的名称,就换掉旧的。这么做,读你代码的人(包括你自己)都会更开心。变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你,它为什么会存在,它做什么事,应该怎么用。如果名称需要注释来补充,那就不算是名副其实。
-
魔术数 注:魔法数字就是莫名其妙出现的数字,不知道含义,影响可读性 我用#CSDN#这个app发现了有技术含量的博客,小伙伴们求同去《编程领域名词:魔法数值、魔法数字、魔法值》, 一起来围观吧
https://blog.csdn.net/weixin_33919950/article/details/89832722?utm_source=app&app_version=4.5.0 -
沟通是专业开发者的头等大事。
-
你今天编写的功能,极有可能在下一版本中被修改,但代码的可读性却会对以后可能发生的修改行为产生深远影响
-
2002年启动FitNesse项目时,我和开发团队一起制订了一套编码风格。这只花了我们10分钟时间。我们决定了在什么地方放置括号,缩进几个字符,如何命名类、变量和方法,如此等等。然后,我们把这些规则编写进IDE的代码格式功能,接着就一直沿用。这些规则并非全是我喜爱的;但它们是团队决定了的规则。作为团队一员,在为FitNesse项目编写代码时,我遵循这些规则。
-
学习第三方代码很难。整合第三方代码也很难。同时做这两件事难上加难。如果我们采用不同的做法呢?不要在生产代码中试验新东西,而是编写测试来遍览和理解第三方代码。JimNewkirk把这叫做学习性测试