编写可阅读代码的艺术 (10~15)

六 13th, 2013

第三部分 重新组织代码

 

10. 抽取不相关的子问题

工程学就是把大问题拆分成小问题,再把这些问题的解决方案放在一起。本章的建议,积极的发现和抽取出不相关的子逻辑。

10.1 纯工具代码

有一组核心功能,大多数程序都会用。如操作字符串,文件读写类

10.2  其它多用途代码

10.3  创建大量通用代码

10.4  项目专有的功能

10.5  简化已有的接口

简单而且强大

10.6  按需重构接口

10.7  过犹不及 (不要盲目的不断抽取)

总结:把一般代码和项目专有代码分开

 

11. 一次只做一件事

核心思想:应该把代码组织得一次只做一件事情。本章是给代码做整理碎片的工作

11.1  任务可以很小

11.2  从对象中抽取值

 

12. 把想法变成代码

12.1  清楚的描述逻辑,可以用自然语言描述

12.2  了解函数库是有帮助的

12.3  把这个方法应用于更大的问题

  • 1. 用自然语言描述解决方案
  • 2. 递归的使用这种方法

13. 少写代码

核心思想:最好读的代码就是没有代码

13.1 别费神实现那个功能–你不会需要它

13.2 质疑和拆分你的需求

仔细检查你的需求,把它消减成一个简单的问题,用很少的代码来实现。

13.3 保持小代码库

13.4 熟悉你周边的库

 

第四部分:精选部分

 

14. 测试与可读性

14.1 使测试易于阅读和维护

测试代码的可读性与非测试代码的可读性是同样重要的。

14.2 使这个测试更可读

普遍的测试原则:对使用者隐去不重要的点,以便更重要的细节会突出。

14.3 让错误的消息具有可读性

  •  1. 更好版本的assert()
  •  2. 手工打造错误消息

14.4 选择好的测试输入

核心思想:使用一组简单的输入,它能完整的使用被测代码

  •  1. 简化输入值
  •  2. 一个功能的多个测试

14.5 为测试函数命名

  • 1. 被测试的类
  • 2. 被测试的函数
  • 3. 被测试的场景或bug

不要使用test1,test2这类,一个简单的测试函数名就是将上面这些信息拼凑在一起。可能在加一个Test_前缀。

14.6 对测试比较好的开发方式

TDD

14.7 走得太远

  • 1. 牺牲真实代码的可读性,只为使能测试
  • 2. 着迷100%的覆盖率
  • 3. 测试成为产品开发的阻碍

15. 设计并改进“分钟/小时计数器”

一个具体的例子

 

~~~~EOF~~~~





除非注明,本站文章均为原创。本文基于 BY-NC-SA 协议进行授权,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名 metaboy(包含链接).

本文链接地址: http://blog.wangyuxiong.com/archives/52005

订阅本站:http://www.wangyuxiong.com/feed

分类: 读书笔记         标签:
目前还没有任何评论.

无觅相关文章插件,快速提升流量