计算机科学箴言集

这是摘抄自《编程珠玑II》第六章的一些比较有趣的话，加上了一些自己的感想或理解。

编码篇

1. 回归测试能将测试区间减半。
   —Larry Bernstein，贝尔通信研究院
2. Π秒就是一个纳世纪。
   —Tom Duff，贝尔实验室
3. 如果还没想清楚，就用蛮力算法吧。（自己想了之后，蛮力之前，请别人帮自己想想）
   —Ken Thompson，贝尔实验室
4. 避免不对称结构。
   —Andy Huber，Data General公司
5. 你用英语都写不出来的东西就别指望用代码写了。
   —Peter Halpern，贝尔实验室
6. 如果代码和注释不一致，那很可能两者都错了。
   —Norm Schryer，贝尔实验室
7. 如果你发现特殊情况太多，那你肯定用错方法了。（保持简单的设计，解决一般性问题，比解决特殊问题更容易）
   —Craig Zerouni，Computer FX公司（英国伦敦）
8. 先把数据结构搞清楚，程序其余部分自现。（所有的算法，都与相应的数据结构配套，选择一种合适的数据结构，好的算法才可能出现）
   —David Jones，荷兰阿森
9. 代码写得越急，程序跑得越慢。（先思考，看看是否有更好的算法，编码的过程写出便于编译器进行优化的代码）
   —Roy Carlson，威斯康星大学

用户界面篇

1. 【最小惊异原则】尽可能让用户界面风格一致和可预测。（人们的习惯是很难突然改变的，如果用户做到了，很可能是不愉快地做到的，更可能的是用户根本不想去做；如果要让用户等待，要么告知用户还要等待多久，要么主动让用户忘了等待这件事）
2. 计算机生成的输入通常会让一个原本设计接收手工输入的程序不堪重负。（嗯，这肯定不是在说程序崩溃，而是计算机输入太快了）
   —Dennis Ritchie，贝尔实验室
3. 80%的表单会要你回答没有必要的问题。（保持简单的设计吧）
   —Mike Garey，贝尔实验室
4. 不要让用户提供那些系统已经知道的信息。（计算机能做的事，就别用手工做了，即使那些手工不是你的）
   —Rick Lemons，Cardinal数据系统公司
5. 所有数据集的80%中，有95%的信息量都可以用清晰的图表示。
   —William S. Cleveland，贝尔实验室

调试篇

1. 在我所有的程序错误中，有80%是语法错误。剩下的20%里，80%是简单的逻辑错误。在剩下的4%里，80%是指针错误。只有余下的0.8%才是困难的问题。
   —Marc Donner，IBM沃森研究中心
2. 在系统测试阶段找出并修正错误，要比开发者自己完成这一工作多付出两倍的努力。而当系统已经交付使用之后找出并修正一个错误，要比系统测试阶段多付出9倍的努力。因此，请坚持让开发者进行单元测试吧。
   —Larry Bernstein，贝尔通信研究院
3. 不要站着调试程序。那会使得你的耐心减半，而你需要的事全神贯注。
   —Dave Storer，艾奥瓦州锡达拉皮兹
4. 测试只能证明程序有错误，而不能证明程序没有错误。
   —Edsger W. Dijkstra，德克萨斯大学
5. 别在注释里陷得太深——注释很可能会误导你，你要调试的只是代码。（所以最重要的要理解要解决的问题是什么，那样就可以知道代码和注释哪个更可靠）
   —Dave Storer，艾奥瓦州锡达拉皮兹
6. 新系统的每一个新用户都可能发现一类新的错误。（新用户发现错误不是坏事，说明你的用户正在增加，如果想要更多，愉快地修复吧）
   —Brian Kernighan，贝尔实验室
7. 东西没坏，就别乱修。
   —罗纳德.里根，加州圣巴巴拉
8. 【维护者箴言】如果我们没有能力修好它，我们就会告诉你他根本就没坏。（最好别这样，最起码指出错误在哪里，或明确给出正确的使用方式）
   —Walt Weir，美国陆军中校
9. 修正程序的第一步是要先重视这个错误。（然后理解这个错误，接下来才是修正）
   —Tom Duff，贝尔实验室

性能篇

1. 【程序优化第一法则】不要优化。
2. 【程序优化第二法则——仅对专家适用】还是不要优化。
   —Michael Jackson，Michael Jackson系统公司
3. 对于那些快速算法，我们总是可以拿一些速度差不多但是更容易理解的算法来替代它们。（如果可以，为什么不呢）
   —Douglas W. Jones，艾奥瓦大学
4. 在一个非I/O密集型的程序中，超过一半的运行时间是花在不足4%的代码上的。
   —Don Knuth，斯坦福大学
5. 在一些机器上，间接寻址比基址寻址更慢，所以请把结构体或记录中最常用的成员放在最前面。
   —Mike Morton，马萨诸塞州波士顿
6. 在优化一个程序之前，请先用性能监视工具找到程序的“热点”。
   —Mike Morton，马萨诸塞州波士顿
7. 【代码规模守恒定律】当你为了加速，把一页代码变成几条简单的命令时，请不要忘了增加注释，以使源码的行数保持为一个常量。
   —Mike Morton，马萨诸塞州波士顿
8. 如果程序员自己模拟实现一个构造比编译器本身实现的那个构造还要快，那编译器作者也太失败了。
   —Guy L. Steele，Jr.，Tartan实验室
9. 要加速一个I/O密集型的程序，请首先考虑所有的I/O。消除那些不必要的或冗余的I/O，并使余下的部分尽可能地快。
   —David Martin，宾夕法尼亚州诺里斯敦
10. 大多数的汇编语言都有循环操作，用一条指令进行一次比较分支；尽管这条指令是为循环设计的，但在做普通的比较时也往往能派上用场，而且很有效。
    —Guy L. Steele，Jr.，Tartan实验室

文档篇

1. 【否定测试】如果一句话反过来就必然不成立，那就根本没必要把这句话放进文档。
   —Bob Martin，AT&T公司
2. 当你试图解释一条命令，一个语言特性或是一种硬件的时候，请首先说明它要解决什么问题。
   —David Martin，宾夕法尼亚州诺里斯敦
3. 【一页原则】一个{规格说明、设计、过程、测试计划}如果不能在一页8.5英寸×11英寸的纸上写明白的话，那么这个东西别人就没办法理解。
   —Mark Ardis，王安公司
4. 纸上的工作没结束，整个工作也就还没结束。

软件管理篇

1． 系统的结构反映出构建该系统的组织的结构。
—Richard E. Fairley
2． 别坚持做哪些没用的事。（通用语）
3． 【90-90法则】前90%的代码占用了90%的预定开发时间，余下的10%代码又花费了90%的预定开发时间。
—Tom Cargill，贝尔实验室
4. 只有不到10%的代码用于完成这个程序表面上的目的，余下的都在处理输入输出，数据验证、数据结构维护等家务活。
—Marry Shaw，卡内基-梅隆大学
5. 正确的判断来源于经验，然而经验来源于错误的判断。（别怕错误）
—Fred Brooks，北卡罗来纳大学
6. 如果有人基本做出了你想要的东西，你就没必要自己写一个新程序。就算你非写不可，也请尽可能多地利用现有的代码。（嗯，工作中可以这样，如果是要学习理解，自己动手吧）
—Richard Hill，惠普公司（瑞士日内瓦）
7. 代码能借用就借用。（若理解了可以这样）
—Tom Duff，贝尔实验室
8. 与客户保持良好的关系可以使生产率加倍。
—Larry Bernstein，贝尔通信研究院
9. 把一个现有成熟程序转移到一种新语言或者新平台，只需要原来开发的十分之一的时间、人力、成本。
—Douglas W. Jones，艾奥瓦大学
10. 那些用手做就已经很快了的事情，就别用手做了。
—Richard Hill，惠普公司（瑞士日内瓦）
11. 那些能用计算机迅速解决的问题，就别用手做了。
—Tom Duff，贝尔实验室
12. 我想写的程序不只是程序，而且是会写程序的程序。（这个目标很激动人心，值得追求，想偷懒，先变得更勤快）
—Dick Sites，DEC公司
13. 【Brooks原型定理】计划好抛弃一个原型，这是迟早的事。（迭代初期生成的产品应该是最终系统的一部分，我更倾向下一条）
—Fred Brooks，北卡罗来纳大学
14. 如果开始就打算抛弃一个原型，那恐怕你得抛弃两个。
—Craig Zerouni，Computer FX公司（英国伦敦）
15. 原型方法可以使系统开发的工作量减少40%。
—Larry Bernstein，贝尔通信研究院
16. 【Thompson望眼镜学徒定理】先做一个4英寸镜片的9（望远镜），再做一个6英尺镜片的，这比直接做6英尺镜片更省时间。
—Bill McKeeman，王安公司
17. 拼命干活无法取代理解。（理解问题，然后理解问题，然后一边干活，一边理解）
—H. H. Williams，加州奥克兰
18. 做事应该先做最难的部分。如果最难的部分无法做到，那还在简单的部分上浪费时间干嘛？一旦困难的地方搞定了，那你就胜利在望了。
19. 做事应该先做最简单的部分。你开始所预想的简单部分，做起来可能是很有难度的。一旦你把简单的部分都做好了，你就可以全力攻克最难的部分了。（先做简单的事情利于理解问题）
—Al Schapira，贝尔实验室

其他

1. 【Sturgeon定律】毫无疑问，90%的软件都没什么用。这是因为对任何东西而言，90%都是没什么用的。
   ——Marry Shaw，卡内基-梅隆大学
2. 对计算机撒谎是要受到惩罚的。
   ——Perry Farrar，马里兰州
3. 如果不要求系统可靠的话，它可能做任何事情了。
   ——H. H. Williams，加州奥克兰
4. 一个人的常量就是另一个人的变量。（这句话在生活中不也可以用吗？）
   ——Susan Gerhart，Microelectronics and Computer Technology公司
5. 一个人的数据就是另一个人的程序。
   ——Guy L. Steele，Jr.，Tartan实验室
6. 【KISS法则】用最简单、最笨的方法做事。（崇尚简单，但别被“笨”字骗了，思考创造性的方法吧，大智若愚不是做出来的，而是看起来的样子）

结语

别轻信那些看似聪明的法则。（选择一些能说服自己的法则去实践，法则是可以相悖的，但是不应该因为它们的存在而摇摆自己的决策）
——Joe Condon，贝尔实验室