低成本编程
这篇书评可能有关键情节透露
软件开发除了要能达到目标，还要尽量减少成本。
怎样减少成本？这里抛开人员分配，任务安排等项目管理方面的不管，有哪些呢？除了明确准确的需求（减少无效编程），良好的设计（更巧的达到目标 less makes more）外，我想就是编码质量。编码的成本分开发成本与维护成本，后者成本又是远高。
维护代码主要花在理解和修改上，所以好的代码应该容易理解。这就是本书的核心思想。代码最重要的读者不是机器，而是人，他应该让人快速理解，轻松维护，容易扩展。
代码应当易于理解，怎么来度量？chapter1提出了“可读性基本定理”，那就是“代码的写法应当使别人理解它所需的时间最小”。并且这个“理解”有个很高的标准。如果一个人真的理解了你的代码，他就应该能改动它、找出缺陷并明白他是如何与其他部分交互的。这个人，可能是别人，也可能是你自己，甚至是6个月之后的你。多问几次自己“别人会理解吗？”
易于理解的代码，怎么来做到？
1)把信息装到名字中（名字也是一条小小的注释）
好的名字应当描述变量的目的或者他所承载的值。
2)使用不会误解的名字（准确表明高层次意图（你心里是怎么想的），而不是明显的细节）
3)审美
（e.g. 用空行把大块代码分成逻辑上的段落；选择有意义的顺序来组织代码；按“列”对齐让代码更容易浏览）
4)写好注释
4.1 什么是好的注释？
我以前的想法是，代码本身应该能比较清楚的表达了how，所以注释作为补充，更多的是说清楚why和what，因为后两点无法从代码本身直接得知，尤其why很可能无法得知。
后来听了ms一个director的session，接受了一个NO Guess的观念。即，你的代码应该明确直接，让人容易看到；别人看不懂不理解，就容易改错甚至直接被遗弃。
这本书的观点让我眼前一亮。即，"注释的目的，是尽量帮助读者能了解得和合作者一样多"。你写代码的时候，你的脑海中有很多有价值的信息。"当其他人读你的代码时，这些信息已经丢失--他们看到只是眼前的代码"。这个看法模糊我原先提到的how what why的信息分类，而是从便于理解角度来评估，更准确。
4.2 什么不需要注释
阅读注释会占用阅读代码的时间，并且每天注释都会占用屏幕上的空间，所以要物有所值。
什么样的不需要写呢？
"不要为那些从代码本身就能快速推断的事实写注释"
什么样的需要写？
“记录你的思想”（为什么写成这样而不是那样，“为代码的瑕疵写注释”），“站在读者的角度”（“公布可能的陷阱”，““全局观”注释”，“总结性注释”（e.g.为一个函数级别写“全局观”注释,让读者在深入细节前就知道该函数的住址））
我尤其赞同的是：“在文件/类级别上使用全局观注释来解释所有部分是如何一起工作的”，"用注释来总结代码块，使读者不会迷失在细节中"
4.3 注释写不出来？
不管心里想什么，先把它写下来
读读这段注释，看看有没有什么地方可以改进？
不断改进
5)简化循环和逻辑
需要记忆或者思考的东西越少，越容易理解。使者最小化代码中的“思维包袱”。
5.1让控制流更易读
比如，减少嵌套深度，最好改写成“线性”的代码。通常提早返回可以减少嵌套。
5.2拆分难思考巨大超长的表达式
一个简单办法是引入“解释变量”或者“总结变量”来代表较长的子表达式。有时需要反向思考问题。
5.3变量
5.3.1变量越多，需要记忆或者跟踪他们的动向就越难：减少不能改进可读性的变量，减少没有价值的中间变量或者临时变量。
5.3.2变量的作用域越大，需要跟踪的越久：让你的变量对尽量少的代码可见（缩小作用域）。还有一种方式是“把大的类拆分成小一些的类”。这种方法只有在这些小一些的类事实上相互独立时才能发挥作用。如果你只是创建两个类来互相访问对方的成员，同一时刻需要记忆或者理解的东西并没有减少，那你什么目的也没有达到。
5.3.3变量改动得越频繁，越难以跟踪他的当前值：只写一次的变量最好；就算不能做到，那么让变量在较少的地方改动仍有帮助。
6)重新组织代码
6.1抽取出那些与程序主要目的“不相关”的子问题
什么是“不相关”的子问题？它完全是自包含的，并不知道其他程序是如何使用它的。典型的是一些纯工具代码。
抽取出他们之后，读者可以“关注高层次目标”。此外，他们自成一体后改进他变得更容易了，因为“他完全地从项目的其他部分中解耦出来”。
总结一下就是“把一般代码和项目专有代码分开”，他可以使“程序员关注小而定义良好的问题”。
6.2 重新组织使代码一次只做一件事情
6.3 把想法变成代码
“如果你不能把一件事解释给你祖母听的话，说明你还没有真正理解他”
相对着一个同事一样用自然语言描述代码要做什么；注意描述中所用的关键词和短语；写出与描述所匹配的代码。
如果你不能把问题说明白或者用词语来做设计，估计是缺少什么东西或者什么东西缺少定义。把一个问题（或想法）变成语言真的可以让它更具体。
6.4 少写代码
你所写的每一行代码都是要测试、文档和维护的。通过重用库或者减少功能，你可以节省时间并且让你的代码保持精简。
6.4.1质疑和拆分你的需求（别费神了 你不会需要他）
消除不必要的功能，不要过度设计；
重新考虑需求，解决版本最简单的问题，只要能完成工作就行
6.4.2熟悉你周边的库
别让代码太“重”
7)测试代码的可读性
测试代码可以看作非正式的文档，它记录了真实代码如何工作和应该如何使用。他应当具有可读性，以便其他程序员可以舒服的改变或者增加测试。
7.1创建最小的测试声明
隐去对使用者不重要的，以便重要的（高层次描述）更突出。每个case最高一层越简明越好，最好输入输出可以用一行代码来描述。实现定制的“微语言”，是个好办法。
7.2让错误消息具有可读性
怎样减少成本？这里抛开人员分配，任务安排等项目管理方面的不管，有哪些呢？除了明确准确的需求（减少无效编程），良好的设计（更巧的达到目标 less makes more）外，我想就是编码质量。编码的成本分开发成本与维护成本，后者成本又是远高。
维护代码主要花在理解和修改上，所以好的代码应该容易理解。这就是本书的核心思想。代码最重要的读者不是机器，而是人，他应该让人快速理解，轻松维护，容易扩展。
代码应当易于理解，怎么来度量？chapter1提出了“可读性基本定理”，那就是“代码的写法应当使别人理解它所需的时间最小”。并且这个“理解”有个很高的标准。如果一个人真的理解了你的代码，他就应该能改动它、找出缺陷并明白他是如何与其他部分交互的。这个人，可能是别人，也可能是你自己，甚至是6个月之后的你。多问几次自己“别人会理解吗？”
易于理解的代码，怎么来做到？
1)把信息装到名字中（名字也是一条小小的注释）
好的名字应当描述变量的目的或者他所承载的值。
2)使用不会误解的名字（准确表明高层次意图（你心里是怎么想的），而不是明显的细节）
3)审美
（e.g. 用空行把大块代码分成逻辑上的段落；选择有意义的顺序来组织代码；按“列”对齐让代码更容易浏览）
4)写好注释
4.1 什么是好的注释？
我以前的想法是，代码本身应该能比较清楚的表达了how，所以注释作为补充，更多的是说清楚why和what，因为后两点无法从代码本身直接得知，尤其why很可能无法得知。
后来听了ms一个director的session，接受了一个NO Guess的观念。即，你的代码应该明确直接，让人容易看到；别人看不懂不理解，就容易改错甚至直接被遗弃。
这本书的观点让我眼前一亮。即，"注释的目的，是尽量帮助读者能了解得和合作者一样多"。你写代码的时候，你的脑海中有很多有价值的信息。"当其他人读你的代码时，这些信息已经丢失--他们看到只是眼前的代码"。这个看法模糊我原先提到的how what why的信息分类，而是从便于理解角度来评估，更准确。
4.2 什么不需要注释
阅读注释会占用阅读代码的时间，并且每天注释都会占用屏幕上的空间，所以要物有所值。
什么样的不需要写呢？
"不要为那些从代码本身就能快速推断的事实写注释"
什么样的需要写？
“记录你的思想”（为什么写成这样而不是那样，“为代码的瑕疵写注释”），“站在读者的角度”（“公布可能的陷阱”，““全局观”注释”，“总结性注释”（e.g.为一个函数级别写“全局观”注释,让读者在深入细节前就知道该函数的住址））
我尤其赞同的是：“在文件/类级别上使用全局观注释来解释所有部分是如何一起工作的”，"用注释来总结代码块，使读者不会迷失在细节中"
4.3 注释写不出来？
不管心里想什么，先把它写下来
读读这段注释，看看有没有什么地方可以改进？
不断改进
5)简化循环和逻辑
需要记忆或者思考的东西越少，越容易理解。使者最小化代码中的“思维包袱”。
5.1让控制流更易读
比如，减少嵌套深度，最好改写成“线性”的代码。通常提早返回可以减少嵌套。
5.2拆分难思考巨大超长的表达式
一个简单办法是引入“解释变量”或者“总结变量”来代表较长的子表达式。有时需要反向思考问题。
5.3变量
5.3.1变量越多，需要记忆或者跟踪他们的动向就越难：减少不能改进可读性的变量，减少没有价值的中间变量或者临时变量。
5.3.2变量的作用域越大，需要跟踪的越久：让你的变量对尽量少的代码可见（缩小作用域）。还有一种方式是“把大的类拆分成小一些的类”。这种方法只有在这些小一些的类事实上相互独立时才能发挥作用。如果你只是创建两个类来互相访问对方的成员，同一时刻需要记忆或者理解的东西并没有减少，那你什么目的也没有达到。
5.3.3变量改动得越频繁，越难以跟踪他的当前值：只写一次的变量最好；就算不能做到，那么让变量在较少的地方改动仍有帮助。
6)重新组织代码
6.1抽取出那些与程序主要目的“不相关”的子问题
什么是“不相关”的子问题？它完全是自包含的，并不知道其他程序是如何使用它的。典型的是一些纯工具代码。
抽取出他们之后，读者可以“关注高层次目标”。此外，他们自成一体后改进他变得更容易了，因为“他完全地从项目的其他部分中解耦出来”。
总结一下就是“把一般代码和项目专有代码分开”，他可以使“程序员关注小而定义良好的问题”。
6.2 重新组织使代码一次只做一件事情
6.3 把想法变成代码
“如果你不能把一件事解释给你祖母听的话，说明你还没有真正理解他”
相对着一个同事一样用自然语言描述代码要做什么；注意描述中所用的关键词和短语；写出与描述所匹配的代码。
如果你不能把问题说明白或者用词语来做设计，估计是缺少什么东西或者什么东西缺少定义。把一个问题（或想法）变成语言真的可以让它更具体。
6.4 少写代码
你所写的每一行代码都是要测试、文档和维护的。通过重用库或者减少功能，你可以节省时间并且让你的代码保持精简。
6.4.1质疑和拆分你的需求（别费神了 你不会需要他）
消除不必要的功能，不要过度设计；
重新考虑需求，解决版本最简单的问题，只要能完成工作就行
6.4.2熟悉你周边的库
别让代码太“重”
7)测试代码的可读性
测试代码可以看作非正式的文档，它记录了真实代码如何工作和应该如何使用。他应当具有可读性，以便其他程序员可以舒服的改变或者增加测试。
7.1创建最小的测试声明
隐去对使用者不重要的，以便重要的（高层次描述）更突出。每个case最高一层越简明越好，最好输入输出可以用一行代码来描述。实现定制的“微语言”，是个好办法。
7.2让错误消息具有可读性
- 作者: [美] Dustin Boswell / [美] Trevor Foucher
- 出版: 机械工业出版社
- 定价: 59.00元
- 装帧: 平装
- 页数: 240
- 时间: 2012-7-10