[读书笔记] 代码整洁之道

书的示例是Java语言编写的,虽说不会影响阅读,但是后面几章讲应用这套方法论的时候,大篇幅的Java代码分析还是挺难受的,而且连java测试框架Junit都要细讲,确实不太合适,对于非Java系的开发者来说,一些内容确是云里雾里。
书的前2/3能够适用全部的开发者,读完有很大收获。后面1/3讲到依赖注入,AOP等内容,这已经是Java的高级理论了,没有基础的读者理解起来还是比较费劲的。还有就是自动化测试是为开发者提供了很好的重构基础,不过这个实践还是需要在大公司才有机会尝试。
以下总结了一些自己阅读时的一些要点,虽然还未来得及切身实践,拜读之时却也颇有感受,这种书还是要反复阅读,实践之后会有更多体会。

代码整洁之道

  • 程序员遵从不了解混乱风险的经理的意愿,也是不专业的做法
  • 整洁的代码只做好一件事
  • NameString会比Name好吗?难道Name会是一个浮点数不成?
  • 明确是王道
  • 类名不应当是动词
  • 给每个类添加“GSD”前缀就不是什么好点子,为什么要搞得IDE没法帮助你?
  • 函数的第一规则是要短小,第二条规则是还要更短小
  • 函数应该做一件事,做好这件事,只做这一件事
  • 对于switch语句,我的规矩是如果只出现一次,用于创建多态对象,而且隐藏在某个继承关系中,在系统其他部分看不到,就还可能忍受
  • 标识参数丑陋不堪,宣布本函数不止做一件事,true or false
  • 当一组参数被共同传递,就像point的x、y那样,往往可以从参数创建对象,从而减少参数数量
  • 最好把try/catch代码块的主体部分不分抽离出来,另外形成函数
  • 我并不从一开始就按照规则写函数,我想没人做得到
  • 别给糟糕的代码加注释——重新写吧
  • 直接把代码注释掉是讨厌的做法,别这么干
  • 你今天编写的功能,极有可能在下一版本中被修改,但代码的可读性却会对以后可能发生的修改行为产生深远影响
  • 类并不简单地用get和set将其变量推向外间,而是暴露抽象接口,以便用户无需了解数据的实现就能操作数据本体
  • 过程是代码便于在不改动既有数据结构的前提下添加新函数,面向对象代码便于在不改动既有函数的前提下添加新类。
  • 对象暴露行为,隐藏数据;数据结构暴露数据,没有明显的行为
  • 当错误发生时,程序员有责任确保代码照常工作
  • 如果无法为某个类命以精确的名称,这个类大概就太长了
  • 系统应该由许多短小的类而不是少量巨大的类组成
  • 通常而言,方法操作的变量越多,就越粘聚到类上(内聚UP)
  • 软件项目的主要成本在于长期维护
  • 对象是过程的抽象,线程是调度的抽象

你可能感兴趣的:(曾经沧海)