《程序员修炼之道》书评、感受及快速参考_程序员修炼之道 翻译得怎么样

转自：http://blog.csdn.net/suwei19870312/article/details/6266046

在《代码大全》的"赞誉"中，有个叫John Robbins的同学认为《代码大全》应该每年都被读一遍。我觉得这样的建议，对于本书也同样适用。

本书的很多观点与论述都是基于作者多年的经验与实践，而这种东西，是很难轻易写在书上让你理解的，更不要说获取了。只有自己亲身的经历或者体会后，才能完全读懂这本书背后的哲学，才能把那一个个的点串成一条线。 而经验是逐步积累起来的，所以，每年阅读一次都可以给你新的体会，除非，你已经完全明白了。

就我而言，读下来感觉是：
1. 读懂了，而且我们就是这么做的。如"shell游戏"，"源码控制"，"源程序设计"。。。
2. 读懂了，但由于某些原因我们没完全那么做的。"按合约设计"，"重构"。。。
3. 读懂了，但以前没意识到的。"强力编辑"，"等你准备好"。。。
4. 没读懂，如"黑板"。。。

当然，还包括那些我不知道的"我不知道"的内容。所以，一年后再读一遍对我肯定还是有好处的。

关于翻译，感觉有太多的直译：
1. guru，mantra这些专有名词的直译倒还可以接受（但是不是缺乏一个译注？或者干脆不要译）；
2. Demeter法则的翻译相当唐突！！！而同样有个Liskov法则，却保留了英文表示~~~
3. 一些英文里的习语，或者特定于文化的用法，直译过来很是困惑，如"吃鱼"，"国王的人马"等，最好是译者能理解后以译注的方式说明一下。（当然，这个对译者要求较高，直接读英文版并不能解决这个问题）

但总的来讲，对核心内容阅读影响不大。

第1章 注重实效的哲学
---------------------------
1 我的源码让猫给吃了
责任感与勇气，要为自己行为后果负责，勇于承认自己的弱点与过错，而不是寻找无聊的借口。

2 软件的熵
"熵" 是某个系统中"无序"的总量，那么"软件的熵"就是软件系统中无序的总量，根据"破窗户"原理，如果你容忍了软件中一个设计或者代码的瑕疵，软件的熵必然会迅速增长，直至"软件腐烂"。
一个和"破窗户"类似的故事是：一个小旅馆中的卫生间老是被旅客弄得又脏又乱，于是老板娘想了个办法，先把卫生间打扫的干干净净，然后再在台盆上插上一支花，显的十分干净与温馨，旅客们都不忍心破坏这么美好的环境，从今以后，该旅馆的卫生间总是干干净净的。
给你的代码这种别人不忍心破坏的环境。

3 石头汤与煮青蛙
石头汤：即使你不掌握任何资源，只要你有一个好的想法，你也能成就一件事，或者一番事业。
煮青蛙：项目在不知不觉中失去了控制，却没有人察觉到 --- 没有大局观! 记的公司的Niu曾经说过：既要埋头做事，又要抬头看路。很朴实，却也很精辟。

4 足够好的软件
在软件的质量，需求及资源（人员与时间）中作权衡时，我们一般认为质量是不可妥协的一个元素，把这三个因素作为三角形的三个顶点，为了保证三角形面积不变，当需求增加时，我们必须增加人手或时间；当时间或者人员减少时，我们也必须减少需求。
但这里告诉我们，把软件的质量作为需求的一部分，因为需求是来自用户的，对于质量的要求自然也是用户说了算，如果用户基于市场，或者期限的考虑，可以接受有一些"毛边"的软件，你也别傻愣着。追求完美是个不错的理念，但要知道何时止步：那就是用户觉得足够好。况且，及早接触用户，可以给你十分宝贵的反馈。

5 你的知识资产
像投资金融资产一样投资知识。
养成自己的学习方法与技巧，建立自己的知识管理体系。

6 交流！
交流的重要性不言而喻，如果你经常与他人，尤其是其他组的人打交道的话，这个感受会更加深。
我想理解交流的目的很重要：交流不是为了表达你自己，不是为了说服他人，也不是为了指责与推脱，而是为了比较和谐的把事情解决。所以你要懂得倾听，要有耐心，要有礼貌，表达要清晰，态度要明确~~~

第2章 注重实效的途径
----------------------------------
7 重复的危害
重复的危害在于维护的负担。
DRY原则首先在于拒绝重复；其次在于鼓励可复用性。
总是在一些代码中看到好几份PI常量、ASSERT宏的定义，这种重复是相当低级、不负责任的，为什么不在用之前先搜索一下呢？ 就好像你在论坛提问前，先要搜索一下是否该问题已经问过一样。

8 正交性
不知道为什么造这么一个名词出来，在我看来，这就是独立性，内聚性，就是尽可能的减少组件间的相互依赖。

9 可撤消性
就是抽象性，想在D3D和OpenGL中切换，想在Oracle和 SQL Server切替换？用自己的接口封装其基本概念！

10 曳光弹
迭代开发，并通过不断的反馈进行调整。最近在实施的 Scrum，其实是同样概念的开发方法。

11 原型与便笺
原型是为了探索，为了验证。原型比较适用于研究型的项目，而曳光弹，则比较适用于方案比较明朗的项目。原型是用完就扔的代码，这里你可以忽略所有规范，为的只是最快的建立验证系统的原型。
其实，在曳光弹方法中，对于一些局部的任务，也可以采用原型方法来验证。

12 领域语言
什么是领域语言，我的感觉就是比以编程语言更加直接、高级的方式来实现功能。我的经验中，用过一些：
    1. 通过一个xml文件来配置系统的UI，系统实现了一个解析器会在运行时解析该文件创建UI
    2. 用一个perl脚本把一个reg文件解析为一个头文件，然后编译进代码中，该解析过程会在prebuild时间中调用
    3. 其实，我觉得通过系统API完成的工作，也算是领域语言。

13 估算
其实，生活中，工作中到处都是估算。你去买个菜大概要多少时间，做个晚饭要多少时间，洗个澡要多少时间~~~~ 完成这个模块的分离要多少时间。 估算需要知道：要完成什么，怎么完成，怎样才算完成。书中有个观点感同身受：你估算的单位会对解读造成影响。（秒？分？。。。还是年）。
要提高估算的能力，关键在于多估算，多反馈。这样有两个好处：
    1. 每次根据你的估算与实际花费，找出差异，你的考虑会越来越全面。
    2. 估过的项目多了，很多时候你就可以依靠之前的经验了。


第3章 基本工具
-----------------------
14 纯文本的威力
纯文本是跨平台，跨时间（不会过时）的最佳、最简单的表示法，而且易于理解与对比。有一个常见的误解，就是觉得二进制比文本表示要安全，其实这只是更加晦涩难懂而已，要说安全，加密才是正解。
程序源代码、资源文件、html、xml、注册表文件等等，用的都是纯文本，如果你要设计一个自己的文件格式、优先考虑纯文本，除非你有存储空间与效率上的考虑。

15 shell游戏
虽然Windows下的 shell不如*nix的强大，但是对于自动化一些日常的操作已经足够了，比如我们经常会用一些bat文件来自动化配置。尤其是，当你配合shell命令和Perl这种超强的文本处理语言，你会觉得如鱼得水。 这两年的代码重构工作中，领教了不少Perl + Shell的威力！

16 强力编辑
用熟用精一种编辑器，的确是相当好的建议。工欲善其事，必先利其器。平时在windows下N++用的比较多一些，最近考虑切换使用一种更强大、跨平台的工具，比如Emacs或者Vi。 
其实这个道理可以说的更宽泛一些，对于经常在IDE中工作的人，精通其工作的IDE，如VS就相当有用了，其效率的提升应该是成倍的。

17 源码控制
这个年代，相信只要是写软件的，肯定都用了SCM，我们公司用的是 Perforce，很多开源项目用SVN、Mercury、或者git之类的，而CVS有逐渐没落之势。"源码让猫吃了"的情形，只发生在我大学写的程序中~~~

18 调试
关于调试的方法论介绍，扩展阅读可以是这本书《Debugging》:http://book.douban.com/subject/3228993/。
里面"橡皮鸭"这个故事可以作为一个提醒点来提醒自己：在请教别人之前，先把问题向橡皮鸭解释一遍。其实很多时候，当你把问题理顺了，答案也就自然有了。 有过这样的经历吧：当你向同事说完你的问题后，你马上意识到了该如何解决~~~~而此时可能对方那是还没明白你在问什么 --- 这就是橡皮鸭的作用。

19 文本操纵
操纵文本时一种乐趣。这种乐趣是我在发现了perl以及正则表达式的强大后才体会到的。我运行shell命令然后用perl解析其输出；我可以在几分钟内解析30000多个源文件并以一种复杂的方式修改代码。那时，你会觉得自己很强大~~~
很难想象，没有perl和正则表达式的日子，我是怎么过来的。

20 代码生成器
这其实是特殊的文本操纵，目标在于自动化工作与避免重复。Wizard其实就是一种代码生成器，Doxygen也算是一种，虽然其生成的是代码的文档。在工作中，我们做过根据一个原始的reg文件，产生一个头文件，以编译到代码中。

第 4章 注重实效的偏执
---------------------------------
21 按合约设计
在写函数的时候，入口处 assert输入参数，出口处返回该调用是否成功是最基本的。只是我们没有比较正式的将其称为前条件、后条件并注释出来。当然，也会在入口，出口处检查某个状态是否成立，这应该就是这里指的"不变项"。我想，明确这些概念，可以让我们在写代码的时候有比较清晰的思路来保证函数的规范性。实现一个函数的时候先思考一下，它的合约是什么呢~~~

22 死程序不说谎
当程序中有致命错误时，直接crash会是比较好的选择。因为这样是以最明确的方式报告了错误，便于修正。如果试图掩盖这种错误，虽然程序还是运行着，却有着潜在的危险。比如C++中两次迭代的异常会导致程序crash，如果你试图在析构函数中吞下第二个异常，其实是掩盖了错误，而不是解决了问题。
与其苟延残喘的活着，不如给他痛痛快快的来一刀吧!

23 断言式编程
这是防御式编程的重要组成部分，如果你觉得"不可能"发生，那就用断言确保它不会发生。当然，注意这里是"不可能"发生，很多初学者很容易认为在失败的时候就assert，比如流程：为打开一个文件，如果不存在，则先创建它。那么在第一步打开文件失败时，很多人会错误的使用一个 assert，而其实，这是"可能"的情况。

24 何时使用异常
对于错误处理的方式，异常处理比返回值判断的好处在于：减少了条件判断；把错误处理的代码集中到了一起。但是我们工作中用的最多的，还是返回值处理。
在异常处理中，一个很重要的措施是保证异常抛出时，资源能被正确的释放掉，在C++中，我们可以用RAII，而在C#，或者Java中，我们可以利用finally语句。

25 怎样配平资源
关于资源管理的章节
几个原则吧：
    1. 谁分配谁释放
    2. 先分配的后释放 --- 以防后分配的对先分配的有引用
    3. 在代码不同的地方以相同次序分配资源 --- 避免死锁

第5章 弯曲，或折断
----------------------------
26 解耦与得墨忒耳法则
迪米特法则（Law of Demeter），意译的话是"最少知识原则"。这里采用如此奇怪的音译显得很唐突。
解耦包含逻辑解耦与物理解耦，其实关键就是一个：最少知识原则。能不知道的就尽量别知道，能不依赖的就尽量别依赖。当你写代码是发现需要再include一个头文件时：三思。

27 元程序设计
基础点讲，就是不要硬编码；
提升点讲，就是指软件的配置信息，尽量保存在在注册表中，或者配置文件中，可以动态配置
再提升点，就是软件设计中我们要封装变化，比如封装在接口之后，但如果可行，封装到代码之外才是最灵活的。

28 时间耦合
主要讲并发，要考虑并发，就要考虑：
    1. 单个操作是否足够独立
    2. 多个操作是否可以并行。
不要只考虑程序中并发，看看你的工作中，你们团队中工作流程的并发要求。

29 它只是视图
MVC模式，我觉得是观察者模式的一种特殊情况。通过接口实现了具体类之间的解耦，并实现了发布/订阅的工作模式。
这个大家应该都很熟悉的。

30 黑板
是更进一步的解耦，连Item29中需要的共同接口都解掉了。
但没怎么看明白~~~

第6章 当你编码时
---------------------------
31 靠巧合编程
知其然，知其所以然；
能工作，要知道为何能工作；会失败，要知道为何会失败。不要靠巧合去七拼八凑。

32 算法速率
用大O表示法来分析算法的效率。培养一种直觉，对一些常见的算法，一看流程就能说出其大O表示，如冒泡排序O(n^2)，遍历O(n)。里面提供的一张图挺不错的：
http://www.flickr.com/photos/dbger/4488865262/

33 重构
我并不同意很多书中宣称的一定要重构，以及他们的理由。重构始终是一种艺术，你要在理想与现实之间做出一个权衡。
《重构》那本书介绍了许多重构的方法。但其实我们更需要的是一个比较可靠、高效的重构器，至少C++方面做的还不够好，VS本身未提供多少，而VA插件的重构功能相当有限。

34 易于测试的代码
易于测试的代码会有非常简洁的接口，非常明确的约定，从而也有更好的质量。这是从比较细节的，代码的角度来看的。而从软件角度来看，就应该提供完善的log机制与诊断功能，这样才能在客户环境下精确的定位错误。

35 邪恶的向导
如果你只是为了编写一个测试程序，你可以不理解想到产生的代码；但是如果你需要基于向导创建一个软件，理解向导产生的代码就显得十分必要了。我想这也是为什么《深入浅出MFC》如此风行的原因吧，大家其实都意识到这个问题了。

第7章 在项目开始之前
----------------------------------
36 需求之坑
试图在想在项目初期弄清需求其实是不太可能的，因为那时即使是用户，也不清楚所有的需求，因为用户对需求的理解也是一个循序渐进的过程。我比较认同Scrum中的做法，逐步迭代，让用户参与整个的过程，给出反馈，这其实也是帮用户弄清了其需求。
了解用户为何要做某件事情的原因，而不是其目前做这件事情的方式。因为其可能一开始就错了，因为你可能有更好的方式 --- 你才是提供方法的那个人。 
同理，在你帮助别人解决问题时，也要记得挖掘其根源，而不要跟着其方式往下走，因为他有可能从一开始就错了。

37 解开不可能解开的谜题
Think out of the box。
转换一下思路，很有可能就会柳暗花明。

38 等你准备好
我们似乎很容易走在两个极端。有的时候我们太激进，还没想好就开始coding了；而有的时候却爱拖延，迟迟不肯动手，总觉得还没准备好。自己属于哪种情况，问问内心其实很容易判断，关键是如何克服自己去正确的做事。

39 规范陷阱
有些规范描述起来相当复杂，但做起来却十分简单。让PD费劲的在spec上写下来，再让开发费劲的去理解，实在是一种浪费。这也是在Scrum中引入User Story好处：通过交流就能解决的问题，就不要费劲去写什么spec了。毕竟，spec不是目的，只是一种手段。

40 圆圈与箭头
没有过时的方法，也没有最优的流程，关键是看你如何摸索出一套适合你们项目于团队的流程。光追求某种先进的方法，只是流于表而疏于本。again，流程不是目的，只是一种手段。


第8章 注重实效的项目
----------------------------------
41 注重实效的团队
注重实效的方法适用于个人，同样适用于团队：不要留破窗户；温水煮青蛙；交流；不要重复你自己；正交性；自动化。 其中，对于项目团队的组织，以功能划分最佳，这样才具有较好的正交性。开发归开发，QA归QA，PD归PD，然后必然频繁的跨团队交流，我们公司目前正从这种方式慢慢转向Scrum团队：QA, 开发，PD同属一组，交流的效率能得到很大的提高。

42 无处不在的自动化
这方面，我有两条信条：
    1. 机器能做的事情，人就不要做
    2. 凡是有固定规律的事情，都可以被自动化。
软件开发中的很多过程都能被自动化，我认为自动化繁琐的工作有两个好处：一个机器做的快而好，而且可重复；二是将繁琐的手工工作转化成编写自动化的程序，容易产生成就感。

43 无情的测试
关于测试的相当不错的论述。
自动化测试基础之上发现的bug，要为其添加case，不停的"把网收紧"。
但其中对于测试先行（TDD）没有特别的介绍，事实上，TDD是被认为是相当可行的一种编程方法学。

44 全都是写
写注释、写文档。。。关键点还是在于：
    1. 不要重复
    2. 自动化
比如你需要某个DLL中的函数导出列表，不要自己维护一份（不要重复），而是写个工具从DLL中提取出来（自动化）。

45 极大的期望
知道用户的"期望"，不要无法达到，也不要超出太多。"温柔的超出用户的期望"或许是最好的策略。
人的承受力是有个range的，不要太低，也不要太高~~~ 呃，或者，物极必反吧。

46 傲慢与偏见 
Sign You Work!!!
让别人知道这是你的作品：荣辱与共！这会催生一种自豪感与责任感。
如果你不敢在代码中签上你的名字，问问自己的内心：为什么?

1. 关心你的技艺
Care About Your Craft
如果你不在乎能否漂亮地开发出软件，你又为何要耗费生命去开发软件呢？

2. 思考！你的工作
Think! About Your Work
关掉自动驾驶仪，接管操作。不断地批评和评估你的工作。

3. 提供各种选择，不要找蹩脚的借口
Provide Options, Don't Make Lame Excuses
要提供各种选择，而不是借口。不要说事情做不到；说明能够做什么。

4.不要容忍破窗户
Don't Live with Broken Windows
当你看到糟糕的设计、错误的决策和糟糕的代码时，修正他们。

5.做变化的催化剂
Be a Catalyst for Change
你不能强迫人们改变。相反，要向他们展示未来可能会怎样，并帮助他们参与对未来的创造。

6. 记住大图景
Remember the Big Picture
不要太过专注于细节，以致忘了查看你周围正在发生什么。

7. 使质量成为需求问题
Make Quality a Requirements Issue
让你的用户参与确定项目真正的需求。

8. 定期为你的知识资产投资
Invest Regularly in Your Konwledge Portfolio
让学习成为习惯

9. 批判的分析你读到的和听到的
Critically Analyze What You Read and Hear
不要被供应商、媒体炒作、或教条左右。要依照你自己的看法和你的项目的情况去对信息进行分析。

10.你说什么和你怎么说同样重要
It's Both What You Say and the Way You Say It
如果你不能有效地向他人传递你的了不起的想法，这些想法就毫无用处。

11. 不要重复你自己
DRY -- Don't Repeat Yourself
系统中的每一项知识都必须具有单一、无歧异、权威的表示。

12. 让复用变得容易
Make It Easy to Reuse
如果复用很容易，人们就会去复用。创造一个支持复用的环境。

13. 消除无关事务之间的影响
Eliminate Effects Between Unrelated Things
设计自足、独立、并具有单一、良好定义的目的的组件。

14.不存在最终决策
There Are No Final Decisions
没有决策是浇铸在石头上的。相反，要把每项决策都视为写在沙滩上的，并为变化作好计划。

15.用曳光弹找到目标
Use Tracer Bullets to Find the Target
曳光弹能通过试验各种事物并检查他们离目标有多远来让你追踪目标。

16. 为了学习而制作原型
Prototype to Learn
原型制作是一种学习经验。其价值并不在于所产生的代码，而在于所学到的经验教训。

17.靠近问题领域编程
Program Close to the Problem domain
用你的用户的语言进行设计和编码。

18.估算，以避免发生意外
Estimate to Avoid Surprises
在着手之前先进行估算。你将提前发现潜在的问题。

19.通过代码对进度表进行迭代
Iterate the Schedule with the Code
用你在进行实现时获得的经验提炼项目的时间标度。

20.以纯文本保存知识
Keep Knowledge in Plain Text
纯文本不会过时。它能够帮助你有效利用你的工作，并简化调试和测试。

21.利用命令shell的力量
Use the Power of Command Shells
当图形用户界面无能为力时使用shell

22.用好一种编辑器
Use a Single Editor Well
编辑器应该是你的手的延伸；确保你的编辑器是可配置、可扩展和可编程的。

23.总是使用源码控制
Always Use Source Code Control
源码控制是你的工作时间的机器----你能够回到过去。

24. 要修正问题，而不是发出指责
Fix the Problem, Not the Blame
Bug是你的过错还是别人的过错，并不是真的很有关系----他仍然是你的问题，他仍然需要修正。

25.调试时不要恐慌
Don't Panic When Debuging
做一次深呼吸，思考什么可能是bug的原因。

26."Select"没有问题
"Select" Isn't Broken
在 OS或编译器、甚至或是第三方产品或库中很少发现bug。Bug很可能在应用中。

27.不要假定，要证明
Don't Assume It-Prove It
在实际环境中----使用真正的数据和边界条件----证明你的假定。

28.学习一种文本操纵语言
Learn a Text Manipulation Language
你们每天的很大一部分时间处理文本，为什么不让计算机替你完成部分工作呢？

29. 编写能写代码的代码
Write Code That Writes Code
代码生成器能提高你的生产效率，并有助于避免重复。

30. 你不可能写出完美的软件
You Can't Write Perfect Software
软件不可能完美。保护你的代码和用户，使它（他）们免于能够预见的错误。

31.通过合约进行设计
Design with Contracts
使用合约建立文档，并检查代码所做的事情正好是他声明要做的。

32.早崩溃
Crash Early
死程序造成的危害通常比有问题的程序要小的多。

33.用断言避免不可能发生的事情
Use Assertions to Prevent the Impossisble
断言验证你的各种假定。在一个不确定的世界里，用断言保护你的代码。

34.将异常用于异常问题
Use Exceptions for Exceptional Problems
异常可能会遭受经典的意大利面条式代码的所有可读性和可维护性问题的折磨。将异常保留给异常的事物。

35.要有始有终
Finish What You Start
只要可能，分配某资源的例程或对象也应该负责解除其分配。

36.将模块之间的耦合减至最少
Minimize Coupling Between Modules
通过编写 "羞怯的"代码并应用得墨忒耳法则来避免耦合。

37.要配置，不要集成
Configure, Don't Integrate
要将应用的各种技术选择实现为配置选项，而不是通过集成或工程方法实现。

38.将抽象放进代码，细节放进元数据
Put Abstractions in Code, Details in Metadata
为一般情况编程，将细节放在被编译的代码库之外。

39. 分析工作流，以改善并发性
Analyze Workflow to Improve Concurrency
利用你的用户的工作流中的并发性。

40.用服务进行设计
Design Using Services
根据服务----独立的、在良好定义、一致的接口之后的并发对象----进行设计。

41.总是为并发进行设计
Always Design for Concurrency
容许并发，你将会设计出更整洁、具有更少假定的接口。

42.视图与模型分离
Separate Views form Models
要根据模型和视图设计你的应用，从而以低廉的代码获取灵活性。

43.用黑板协调工作流
Use Blackboards to Coordinate Workflow
用黑板协调完成不同的事实和因素，同时又使各参与方保持独立和隔离。

44.不要靠巧合编程
Don't Program by Coincidence
只依靠可靠的事物。注意偶发的复杂性，不要把幸运的巧合与有目的的计划混为一谈。

45.估计你的算法的阶
Estimate the Order of Your Algorithms
在你编写代码之前，先大致估算事情需要多长时间

46.测试你的估计
Test your Estimates
对算法的数学分析并不会告诉你每一件事情。在你的代码的目标环境中测定他的速度。

47.早重构，常重构
Refactor Early, Refactor Often
就和你会在花园里除草、并重新布置一样，在需要时对代码进行重写、重做和重新架构。要铲除问题的根源。

48. 为测试而设计
Design to Test
在你还没有编写代码时就还是思考测试问题。

49.测试你的软件，否则你的用户就得测试
Test Your Software, or Your Users Will
无情地测试。不要让你的用户为你查找bug。

50. 不要使用你不理解的向导代码
Don't Use Wizard Code You Don't Understand
向导代码可以生成大量代码。在你把它们合并进你的项目之前，确保你理解全部这些代码。

51.不要搜集需求----挖掘它们
Don't Gather Requirements - Dig for Them
需求很少存在于表面上。它们深深地埋藏在层层假定、误解和政治手段下面。

52. 与用户一同工作，像用户一样思考
Work with a User to Think Like a User
要了解系统实际上将如何被使用，这是最好的方法。

53.抽象比细节活得更长久
Abstractions Live Longer than Details
"投资"于抽象，而不是现实。抽象能在来自不同的现实和新技术的变化的"攻击"之下存活下去。

54.使用项目词汇表
Use a Project Glossary
创建并维护项目中使用的专用术语和词汇的单一信息源。

55.不要在盒子外面思考----要找到盒子
Don't Think Outside the Box - Find the Box
在遇到不可能解决的问题时，要确定真正的约束。问问你自己："它必须以这种方式完成吗？它真的必须完成吗？"

56.等你准备好在开始
Start When You're Ready
你的一生都在积累经验。不要忽视反复出现的疑虑。

57.对有些事情"做"胜于"描述"
Some Things are Better Done than Described
不要掉进规范的旋涡----在某个时刻，你需要开始编码。

58. 不要做形式方法的奴隶
Don't Be a Slave to Formal Methods
如果你没有把某项技术放进你的开发实践和能力的语境中，不要盲目地采用它。

59.昂贵的工具不一定能制作出更好的设计
Costly Tools Don't produce Better Designs
小心供应商的炒作，行业教条、以及价格标签的诱惑。要根据工具的价值判断它们。

60. 围绕功能组织团队
Organize Teams Around Functionality
不要把设计师与编码员分开，也不要把测试员与数据建模员分开。按照你构建代码的方式构建团队。

61.不要使用手工流程
Don't Use Manual Procedures
Shell脚本或批文件会一次次地以同一顺序执行同样的指令。

62.早测试，常测试，自动测试
Test Early. Test Often. Test Automatically
与呆在书架上的测试计划相比，每次构建时运行的测试要有效的多。

63. 要通过全部测试，编码才算完成
Coding didn't Done Until All the Tests Run
就是这样。

64. 通过"蓄意破坏"测试你的测试
Use Saboteurs to Test Your Testing
在单独的软件副本上故意引用 bug，以检验测试能够抓住它们。

65.测试状态覆盖，而不是代码覆盖
Test State Coverage, Not Code Coverage
确定并测试重要的程序状态。只是测试代码行是不够的。

66.一个bug只抓一次
Find Bugs Once
一旦测试员找到一个bug，这应该是测试员最后一次找到它。此后自动测试应该对应其进行检查。

67.英语就是一种编程语言
English is Just a Programming Language
像你编写代码一样编写文档：遵守DIY原则、使用原数据、MVC、自动生成，等等。

68.把文档建在里面，不要拴在外面
Build Documentation In, Don't Bolt It On
与代码分离的文档不太可能被修整和更新。

69. 温和地超出用户的期望
Gently Exceed Your Users' Expectations
要理解你的用户的期望，然后给他们的东西要多那么一点。

70. 在你的作品上签名
Sign Your Work
过去时代的手工艺人为能在他们的作品上签名而自豪。一夜应该如此。

 

 
检查清单

71.要学习的语言
厌倦了C、C++和JAVA?试试CLOS、Dylan、Eiffel、Objective C、Prolog、Smalltalk或TOM。他们每一种都有不同的能力和不同的"风味"。用其中的一种或多种语言在家里开发一个小项目。

72.WISDOM 离合诗
What do you want them to learn?                       你想让他们学到什么？
What is their interest in what you've got to say?    他们对你讲的什么感兴趣?
How sophisticated are they?                           他们有多富有经验？
How much detail do they want?                         他们想要多少细节？
Whom do you want to own the information?              你想要让谁拥有这些信息？
How can you Motivate them to listen to you?           你如何使他们听你说话？

73.怎样维持正交性
设计独立、良好定义的组建。
使你的代码保持解藕
避免使用全局数据
重构相似的函数

74.应制作原型的事物
构架
已有系统的新功能
外部数据的结构或内容
第三方工具或组建
性能问题
用户界面设计

75.架构问题
责任是否得到了良好定义？
写作是否得到了良好定义？
耦合是否得以最小化？
你能否确定潜在的重复？
接口定义和各项约束是否可以接受？
模块能否在需要时访问所需数据？

76.调试检查清单
正在报告的问题是底层bug的直接结果，还是只是症状？
Bug 真的在编译器里？在OS里?或者是在你的代码里？
如果你向同事详细解释这个问题，你会说什么？
如果可以代码通过了单元测试，测试是否足够完整？如果你用该数据单元测试，会发生什么？
造成这个bug的条件是否存在于系统的其他任何地方？

77.函数的得墨忒耳法则
某个对象的方法应该值调用属于以下情形的方法：
它自身
传入的任何参数
它创建的对象
组件对象

78.怎样深思熟虑地编程
总是意识到你在做什么
不要盲目地编程
按照计划行事
依靠可靠的事物
为你的假定建立文档
不要只是测试你的代码，还要测试你的假定
为你的工作划分优先级
不要做历史的奴隶

79.何时进行重构
你发现了对DRY原则的违反
你发现事物可以更为正交
你的知识扩展了
需求演变了
你需要改善性能

80.劈开戈尔迪斯结
在解决不可能解决的问题时，问问自己：
有更容易的方法吗？
我是在解决正确的问题吗？
这件事情为什么是一个问题？
是什么使它如此难以解决？
它必须以这种方式完成吗？
它真的必须完成吗？

81.测试的各个方面
单元测试
集成测试
验证和校验
资源耗尽、错误及恢复
性能测试
可用性测试
对测试自身进行测试