程序猿修炼之道-书评
-----------------------------------------------------------------------------------------------------
第一章 注重实效的哲学：
-----------------------------------------------------------------------------------------------------
1.我的源代码让猫给吃了
启示：要为自己负责
提供各种选择。不要找蹩脚的接口
Provide Options，Don’t Make Lame Excuses
要提供各种选择，而不是找接口。不要说事情做不到：说明可以做什么
2.软件的熵
启示：不要容忍破窗户
Don’t Live with Broken Windows
当你看到糟糕的设计，错误的决策和糟糕的代码时。修正他们
3.石头汤与煮青蛙
启示：做变化的催化剂（战后士兵引食）
4.足够好的软件
启示：让用户參与权衡
5.你的知识资产
启示：投资、发展多元化、管理风险，低买高卖。又一次评估和权衡
6.交流
启示：说什么？了解听众、注意时机、有风格、让用户參与互动
-----------------------------------------------------------------------------------------------------
第二章 注重实效的途径：
-----------------------------------------------------------------------------------------------------
7.反复的危害
启示：DRY 不要反复你自己
DRY - Don’t Repeat Yourself
系统中的每一项知识都必须其有单一。无歧义。权威的表示
8.正交性
启示：坐标轴。类似X与Y轴，互不影响，解耦合
9.可撤销性
启示：不存在终于决策
There Are No final Decisions
没有决策时浇铸在石头上的 相反，要把每项决策都视为是写在沙滩上的，并为变化做好计划
10.曳光弹
启示：用于寻找目标，不是非常懂
11.原型与标签
启示：注重总体、隐藏细节
12.领域语言
启示：易于开发
13.估算
启示：深思熟虑地编程，完毕后总结
-----------------------------------------------------------------------------------------------------
第三章 基本工具：
-----------------------------------------------------------------------------------------------------
14.纯文本的威力
启示：经久不衰，只是时，易測试
15.Shell游戏
启示：操作简单粗暴、功能强大、高效
16.强力编辑
启示：熟练一种IDE
17.源代码控制
启示：可恢复
18.调试
启示：要修正问题，而不是发出指责
Fix the Problem,Not the blame
bug是你的过错还是别人的过错。并非真的非常有关系-它仍然是你的问题，它仍然须要修正
19.文本操作
启示：学习一种文本操作语言。Notepad
20.代码生成器
启示：编写能编写代码的代码
Write Code That Writes Code
代码生成器能提高你的生产率，并有助于避免反复
-----------------------------------------------------------------------------------------------------
第四章 注重实效的偏执：
-----------------------------------------------------------------------------------------------------
21.按合约的设计
启示：使用断言校验你的代码。可是不要把断言作为一种异常处理方式
22.死程序不说谎
启示：早崩溃
Crash Early
死程序造成的危害通常比有问题的程序要小得多
23.断言式编程
启示：校验你的不可能。让断言开着
24.何时使用异常
启示：将异经常使用于异常的问题
Use Exception for Exceptional Problems
异常可能会遭受经典的意大利面条式代码的所有可读性和可维护性问题的折磨。将异常保留给异常的事物
25.怎么配平资源
启示：要有始有终
Finish What You start
仅仅要可能。分配某资源的例程或对象也应该负责解除其分配
-----------------------------------------------------------------------------------------------------
第五章 弯曲或折断：
-----------------------------------------------------------------------------------------------------
26.解耦与得墨忒耳法则
启示：羞怯编码（不向别人暴露你自己，不与太多人打交道）。使模块之间的耦合减至最少
Minimize Coupling Between Modules
通过编写“羞怯的”代码并应用得墨忒耳法则来避免耦合
27.元程序设计
启示：要配置，不要集成
Configure,Don’t integrate
要将应用的各种技术选择实现为配置选项，而不是通过集成或project方法实现
28.时间耦合
启示：分析工作流。并改善并发性
Analyze Workflow to improve Concurrency
利用你的用户的工作流中的并发性
用服务进行设计
Design Using Services
依据服务-独立的、在良好定义、一致的接口之后的并发对象-进行设计
总是为并发进行设计
Always Design for Concurrency
容许并发，你将会设计出更整洁，具有更少假定的接口
29.它仅仅是视图
启示：公布|订阅 模式，MVC 模型、视图、控制分离
30.黑板
启示：用黑板来组织框架图，就像侦探用黑板破案
-----------------------------------------------------------------------------------------------------
第六章 当你编码时：
-----------------------------------------------------------------------------------------------------
31.靠巧合编程
启示：不要靠谦和编程
Don’t program by coincidence
仅仅依靠可靠的事物。注意偶发的复杂性，不要把幸运的巧合与有目的计划混为一谈
32.算法速率
启示：估算你的算法的阶
Estimate the Order of Your Algorithms
在你编写代码之前，先大致估算事情须要多长时间
測试你的估算
Test Your Estimates
对算法的数学分析并不会告诉你每一件事情。在你的代码的目标环境中測定他的速度
33.重构
启示：反复、非正交、过时、性能不好。
早重构，常重构
Refactor Early , Refactor Often
就和你会在花园里除草，并又一次布置一样，在须要时对代码进行重写，重做和又一次架构，铲除问题的根源
34.易于測试的代码
启示：单元測试、为測试而设计
Design to Test
在你还没有编写代码时就開始思考測试问题
35.邪恶的向导
启示：不要使用你不理解的向导代码
Don’t use wizard code you don’t understand
向导可以生成大量代码，在你把他们合并进你的项目之前，确保你理解所有这些代码
-----------------------------------------------------------------------------------------------------
第七章 在项目開始之前：
-----------------------------------------------------------------------------------------------------
36.需求之坑
启示：不要搜集需求-挖掘它们
Don’t Gather Requirements - Dig for them
需求非常少存在于表面上，他们深深地埋藏在层层假定。误解和政治手段的以下
与用户一同工作，以像用户一样思考
Work with a User to Think like a user
要了解系统实际上将怎样被使用，这是最好的方法
抽象比细节活得更长久
Abstractions Live Longer than Details
“投资”于抽象，而不是实现。抽象能在来自不同的实现和新技术的变化的“攻击”之下存活下去
37.解开不可能解开的谜题
启示：一定有更easy的方法
38.等你准备好
启示：等你准备好再開始（倾听反复出现的疑虑）
Start When You’re Ready
你的一生都在积累经验，不要忽视反复出现的疑虑
39.规范陷阱
启示：对有些事情“做”胜于“描写叙述”
Some things are better done than described
不要掉进规范的螺旋 - 在某个时刻，你须要開始编码
40.圆圈与箭头
启示：不要做形式方法的奴隶
Don’t be a slave to formal methods
假设你没有把某项技术放进你的开发实践和能力的语境中。不要盲目採用它
昂贵的工具不一定能制作出更好的设计
Costly tools don’t produce better designs
小心供应商的炒作、行业教条、以及价格标签的诱惑、要依据工具的价值推断它们
-----------------------------------------------------------------------------------------------------
第八章 重注实效的项目：
-----------------------------------------------------------------------------------------------------
41.注重实效的团队
启示：不要留破窗户、主动监视环境变化、不要反复、要正交
42.无处不在的自己主动化
启示：一切都要自己主动化，要自己主动。不要手动。
43.无情的測试
启示：早測试、常測试、自己主动測试
Test Early . Test Often . Test Automatically
与呆在书架上的測试计划相比，每次构建时执行的測试要有效得多
通过“蓄意破坏”測试你的測试
Use saboteurs to test your testing
在单独的软件副本上有益引入bug，以检验測试可以抓住他们
測试状态覆盖。而不是代码覆盖
Test state coverage,not code coverage
确定并測试重要程序状态，仅仅是測试代码行是不够的
44.全都是写
启示：把英语又一种编程语言、文档与代码相同重要，放一块。不要把文档栓在外面
45.极大的期望
启示：温柔地超出用户的期望
Gently exceed your users’ Expectations
要理解你的用户期望，然后给他们的东西要多那么一点
46.傲慢与偏见
启示：在你的作品上签名
Sign Your work
过去时代的手艺人为能在他们的作品上签名面自豪、你也应该如此
-----------------------------------------------------------------------------------------------------
个人总结：
-----------------------------------------------------------------------------------------------------
1.编程步骤：构思（理清思路）、编码（埋点关键日志）、审查（细致审查逻辑流程代码 ）、測试、复查
2.不要恐慌。再急也不要写烂代码。
（十万火急：要写。请用钉子把这个地方钉住标记下来，之后立马修复）
3.编程是一种技艺，一种须要用心学习的技艺
4.81条圣经。须要经常回想，慢慢吸收，让其融入灵魂。
5.圣经81条全是手工打上去的（打了3个小时左右。建议不要COPY。手动敲打），就是为了让自己影响深刻。铭记于心。
6.不要死磕在技术上，有时候须要跳出来站在用户的角度思考，可以降低非常多不必要的开发。
-----------------------------------------------------------------------------------------------------
编辑器推荐：Emacs、VI
学习新技术：Makefile、Shell、批处理文件
文档编辑推荐：Notepad、DocBook
书籍推荐：
1.Surving Object - Oriented Projects ： A Manager’s Guide
2.Art of Computer Programming
3.Unix 编程艺术
4.面向对象开发的基本原理（Object-Oriented Software Construction,2nd Edition）
5.Design Patterns
6.Analysis Patterns
7.The Mythical Man Month
8.Dynamics of Software Development
9.More Effective C++ 35个改善编程与设计的方法（侯捷）
10.Effective C++ 改善程序与设计的55歌详细做法（侯捷）
11.代码整洁之道
12.重构：改善即有代码的设计
13.代码大全
-----------------------------------------------------------------------------------------------------
圣经条例：
-----------------------------------------------------------------------------------------------------
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 Knowledge 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.让复用变得easy
Make It Easy to Reuse
假设复用非常easy，人们就会去复用 。
创找一个支持复用的环境
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 Impossible
断言验证你的各种假定，在一个不确定的时间里，用断言保护你的代码
34.将异经常使用于异常的问题
Use Exception for Exceptional Problems
异常可能会遭受经典的意大利面条式代码的所有可读性和可维护性问题的折磨，将异常保留给异常的事物
35.要有始有终
Finish What You start
仅仅要可能，分配某资源的例程或对象也应该负责解除其分配
36.使模块之间的耦合减至最少
Minimize Coupling Between Modules
通过编写“羞怯的”代码并应用得墨忒耳法则来避免耦合
37.要配置，不要集成
Configure,Don’t integrate
要将应用的各种技术选择实现为配置选项，而不是通过集成或project方法实现
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 View 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.使用项目词汇表
User 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.环绕功能组织团队
Organic Teams around functionality
不要把设计师与编码员分开，也不要把測试员与数据建模员分开。依照你的构建代码的方式构建团队
61.不要使用手工流程
Don’t use manual procedures
shell 脚本或批处理文件会一次次地以同一顺序执行相同的指令
62.早測试、常測试、自己主动測试
Test Early . Test Often . Test Automatically
与呆在书架上的測试计划相比，每次构建时执行的測试要有效得多
63.要到通过所有測试。编码才算完毕
Coding ain’t done ’Til All the Tests Run
就是这样
64.通过“蓄意破坏”測试你的測试
Use saboteurs to test your testing
在单独的软件副本上有益引入bug。以检验測试可以抓住他们
65.測试状态覆盖。而不是代码覆盖
Test state coverage,not code coverage
确定并測试重要程序状态。仅仅是測试代码行是不够的
65.一个bug仅仅抓一次
Find bugs once
一日測试员找到一个bug，这应该是測试员最后一次找到它，此后自己主动測试代码应该对其进行检查
66.英语就是一种编程语言
English is just a programming language
像你编写代码一样编写文档，遵守DRY原则，使用元数据、MVC、自己主动生成等等
67把文档建在里面，不要权在外面
Build Documentation in , Don’t bolt it on
与代码分离的文档不太可能被修正和更新
68.温柔地超出用户的期望
Gently exceed your users’ Expectations
要理解你的用户期望，然后给他们的东西要多那么一点
70.在你的作品上签名
Sign Your work
过去时代的手艺人为能在他们的作品上签名面自豪、你也应该如此
检測清单
-----------------------------------------------------------------------------------------------------
71.要学习的语言
厌倦了C、C++和Java？试试CLOS、Dylan、Eiffel、Object C、Prolog、Smalltalk或TOM。
它们每一种都有不同的能力和不同的“风味”。用当中的一种或多种语言在家里开发一个小项目
72.WINSDOM离合诗
What do you want them to learn ? 你想让他们学到什么？
What is their interest in what you’ve got to say ?
他们对你讲的什么感兴趣？
How sophisticated are they ? 他们有富有经验？
How mush detail do they want ? 他们想要多少细节？
How can you motivate to listen to you ? 你怎样促使他们听你说话？
73.怎么维持正交性
1.设计独立、良好定义的组件
2.使你的代码保持解耦
3.避免使用全局数据
4.重构类似的函数
74.应制作原型的事物
1.架构
2.已有系统中的新功能
3.外部数据的结构或内容
4.第三方工具或组件
5.用户界面设计
75.架构问题
1.责任是否得到了良好定义？
2.协作是否得到了良好定义？
3.耦合是否得到最小化？
4.你是否能确定潜在的反复？
5.接口定义和各项约束是否可接受？
6.模块是否能在须要时訪问所需数据？
76.调试检測清单
1.正在报告的问题是低层bug的直接结果，还是仅仅是症状？
2.bug真的在编译器里？在OS里？或者在你的代码里？
3.假设你向同事详解这个问题。你会说什么？
4.假设可疑代码通过了单元測试、測试是否足够完整？假设你用该数据执行单元測试。会发生什么？
5.造成这个bug的条件是否存在于系统中的其它不论什么地方？
77.函数的得墨忒耳法则
某个对象的方法应该仅仅调用属于以下的情形的方法：
1.它自身
2.传入的不论什么參数
3.它创建的对象
4.组件对象
78.怎么深思熟虑地编程
1.总是意识到你在做什么
2.不要盲目地编程
3.依照计划行事
4.依靠可靠的事物
5.为你的假定建议文档
6.不要仅仅是測试你的代码。还要測试你的假定
7.为你的工作划分优先级
8.不要做历史的奴隶
79.何时进行重构
1.你发现了对DRY原则的违反
2.你发现事物可以更为正交
3.你的知识拓展了
4.需求演变了
5.你需求改善性能
80.劈开戈尔迪斯结
在解决不可能解决的问题时，问问你自己：
1.有更easy的方法吗？
2.我是在解决正确的问题吗？
3.这件事情为什么是一个问题？
4.是什么使它如此难以解决？
5.它必须以这样的方式完毕吗？
6.它真的必须完毕吗？
81.測试的各个方面
1.单元測试
2.集成測试
3.验证和校验
4.资源耗尽、错误及恢复
5.性能測试
6.可用性測试
7.对測试自身进行測试
