如果你不在湖能否漂亮的开发出软gQ你又ؓ(f)何要耗费生命d发Y件呢Q?/P>
2.思考！你的工作
Think! About Your Work
x(chng)自动N仪，接管操作。不断地批评和评C的工作?/P>
3Q提供各U选择Q不要找y脚的借口
Provide Options, Don't Make Lame Excuses
要提供各U选择Q而不是找借口。不要说事情做不刎ͼ说明能够做什么?/P>
4.不要容忍破窗?BR> Don't Live with Broken Windows
当你看到p糕的设计、错误的决策和糟p的代码Ӟ修正它们?/P>
5.做变化的催化?BR> Be a Catalyst for Change
你不能强qh们改变。相反，要向他们展示未来可能?x)怎样Qƈ帮助他们参与Ҏ(gu)来的创造?/P>
6.C大图?BR> Remember the Big Picture
不要太过专注于细节，以至忘(sh)(jin)查看你周围正在发生什么?/P>
7.使质量成为需求问?BR> Make Quality a Requirements lssue
让你的用户参与确定项目真正的质量需求?/P>
8.定期Z的知识资产投?BR> Invest Regularly in Your Knowledge Portfolio
让学?fn)成Z(fn)惯?/P>
9.批判地分析你d的和听到?BR> Critically Analyze What You Read and Hear
不要被供应商、媒体炒作、或教条左右。要依照你自q看法和你的项目的情况d信息q行
分析?/P>
10.你说什么和你怎么说同样重?BR> It's both What You Say and the Way You Say it
如果你不能有效地向他Z达你的了(jin)不v的想法，q些x(chng)毫无用处?/P>
11.不要重复你自?BR> DRY - Don't Repeat Yourself
pȝ中的每一知识都必须h单一、无歧义、权威的表示?/P>
12.让复用变得容?BR> Make It Easy to Reuse
如果复用很容易，Z׃(x)d用。创造一个支持复用的环境?/P>
13.消除无关事物之间的媄(jing)?BR> Eliminate Effects Between Unrelated Things
设计自、独立、ƈh单一、良好定义的目的的组件?/P>
14.不存在最l决{?BR> There Are No Final Decisions
没有决策是浇铸在矛_上的。相反，要把每项决策都视为是写在沙W上的Qƈ为变化做?BR> 计划?/P>
15.用曳光弹扑ֈ目标
Use Tracer Bullets to Find the Target
曛_弹能通过试验各种事物q检查它们离目标有多q来让你q踪目标?/P>
16.Z(jin)学习(fn)而制作原?BR> Prototype to Learn
原型制作是一U学?fn)经验。其价值ƈ不在于所产生的代码，而在于所学到的经验教训?/P>
17.靠近问题领域~程
Program Close to the Problem domain
用你的用L(fng)语言q行设计和编码?/P>
18.估算Q以避免发生意外
Estimate to Avoid Surprises
在着手之前先q行估算。你提前发现潜在的问题?/P>
19.通过代码对进度表q行q代
Iterate the Schedule with the Code
用你在进行实现时获得的经验提炼项目的旉标度?/P>
20.用纯文本保存知识
Keep Knowledge in Plain Text
U文本不?x)过时。它能够帮助你有效利用你的工作。ƈ化掉时和试?/P>
21.利用命o(h)shell的力?BR> Use the Power of Command Shells
当图形用L(fng)面无能ؓ(f)力时使用shell?/P>
22.用好一U编辑器
Use a Single Editor Well
~辑器应该是你的手的延Q确保你的编辑器是可配置、科扩展和可~程的?/P>
23.L使用源码控制
Always Use Source Code Control
源码控制是你的工作的旉机器--你能够回到过厅R?/P>
24.要修正问题，而不是发出指?BR> Fix the Problem, Not the Blame
bug是你的过错还是别人的q错Qƈ不是真的很有关系--它仍然是你的问题Q它仍然需?BR> 修正?/P>
25.调试时不要恐?BR> Don't Panic When Debuging
做一ơ深呼吸Q思考什么可能是bug的原因?/P>
26.“Select”没有问?BR> "Select" Isn't Broken
在OS或编译器、甚或是W三方品或库中很少发现bug。bug很可能在应用中?/P>
27.不要假定Q要证明
Don't Assume It - Prove It
在实际环境中--使用真正的数据和辩解条g--证明你的假定?/P>
28.学习(fn)一U文本操U语a
Learn a Text Manipulation Language
你用每天的很大一部分旉处理文本Qؓ(f)什么不让计机替你完成部分工作呢？
29.~写能编写代码的代码
Write Code That Writes Code
代码生成器能提高?sh)的生率，q有助于避免重复?/P>
30.你不可能写出完美的Y?BR> You Can't Write Perfect Software
软g不可能完。保护你的代码和用户Q它（他）(j)们免于能够预见的错误?/P>
31.通过合约q行设计
Design with Contracts
使用合约建立文档Qƈ(g)验代码所做的事情正好是它声明要做的?/P>
32.早崩?BR> Crash Early
ȝ序造成的危害通常比有问题的程序要得多?/P>
33.用断a避免不可能发生的事情
Use Assertions to Prevent the Impossible
断言验证你的各种假定。在一个不定的世界里Q用断言保护你的代码?/P>
34.异常用于异常的问题
Use Exceptinos for Exceptional Problems
异常可能?x)遭受经典的意大利面条式代码的所有可L和可维护性问题的折磨。将异常保留l?BR> 异常的事物?/P>
35.要有始有l?BR> Finish What You Start
只要可能Q分配某资源的例E或对象也应该负责解除其分配?/P>
36.使模块之间的耦合减至最?BR> Minimize Coupling Between Modules
通过~写“羞怯的”代码ƈ应用得墨忒x(chng)则来避免耦合?/P>
37.要配|，不要集成
Configure, Don't Integrate
要将应用的各U技术选择实现为配|选项Q而不是通过集成或工E方法实现?/P>
38.抽象放q代码，l节放进元数?BR> Put Abstractions in Code, Details in Metadata
Z般情늼E，细节放在被~译的代码库之外?/P>
39.分析工作，以改善ƈ发?BR> Analyze Workflow to Imporve Concurrency
利用你的用户的工作流中的q发性?/P>
40.用服务进行设?BR> Design Using Services
Ҏ(gu)服务--独立的、在良好定义、一致的接口之后的兵法对?-q行设计?/P>
41.L为ƈ发进行设?BR> Always Design for Concurrency
容许q发Q你会(x)设计出更整洁、具有更假定的接口?/P>
42.使视图与模型分离
Separate Views from Models
要根据模型和视图设计你的应用Q从而以低廉的代码获取灵zL?/P>
43.用黑板协调工作流
Use Blackboards to Coordinate Workflow
用黑板协调完全不同的事实和因素，同时又各参与方保持独立和隔R?/P>
44.不要靠y合编E?BR> Don't Program by Coincidence
只依靠可靠的事物。注意偶发的复杂性，不要把幸q的巧合与有目的的计划Z谈?/P>
45.估算你的法的阶
Estimate the Order of Your Algorithms
在你~写代码之前Q先大致估算事情需要多长时间?/P>
46.试你的估算
Test Your Estimates
对算法的数学分析q不?x)告诉你每一件事情。在你的代码的目标环境中定它的速度?/P>
47.早重构，帔R?BR> Refactor Early, Refactor Often
和你会(x)在华园里除草、ƈ重新布置一P在需要时对代码进行重写、重做和重新架构。要
铲除问题的根源?/P>
48.为测试而设?BR> Design to Test
在你q没有编写代码时开始思考测试问题?/P>
49.试你的软gQ否则你的用户就得测?BR> Test Your Software, or Your Users Will
无情地测试。不要让你的用户Z查找bug?/P>
50.不要使用你不理解的向g?BR> Don't Use Wizard Code You Don't Understand
惛_可以生成大量代码。在你把它们合ƈq你的项目之前，保你理解全部这些代码?/P>
51不要搜集需?-挖掘它们
Don't Gather Requirements - Dig for Them
需求很存在于表面上。它们深深地埋藏在层层假定、误解和政治手段的下面?/P>
52.与用户一同工作，以像用户一h?BR> Work with a User to Think Like a User
要了(jin)解系l实际上如何被使用Q这是最好的Ҏ(gu)?/P>
53.抽象比细节活得更长久
Abstractions Live Longer than Details
“投资”于抽象Q而不是实现?/P>
54.使用目词汇?BR> Use a Project Glossary
创徏q维护项目中使用的专用术语和词汇的单一信息源?/P>
55.不要在盒子外面思?-要找到盒?BR> Don't Think Outside the Box - Find the Box
在遇C可能解决的问题时Q要定真正的约束。问问你自己Q“它必须以这U方式完成吗Q?BR> 它真的必d成吗Q?/P>
56.{你准备好再开?BR> Start When You're Ready
你的一生都在积累经验。不要忽视反复出现的疑惑?/P>
57.Ҏ(gu)些事情“做”胜于“描q?BR> Some Things Are Better Done than Described
不要掉进规范的螺?/P>
58.不要做Ş式方法的奴隶
Don't Be a Slave to Formal Methods
如果你没有把某项技术放q你的开发时间和能力的语境中Q不要盲目地采用它?/P>
59.昂贵的工具不一定能制作出更好的设计
Costly Tools Don't Produce Better Disigns
心(j)供应商的炒作Q行业教条，以及(qing)h标签的诱惑。要Ҏ(gu)工具的h(hun)值判断它们?/P>
60.围绕功能l织团队
Organize Teams Around Fucntionality
不要把设计师与编码员分开Q也不要把测试员?sh)数据徏模员分开。按照你构徏代码的方式构?BR> 团队?/P>
61.不要使用手工程
Don't Use Manual Procedures
shell脚本或批文g?x)一ơ次C同一序执行同样的指令?/P>
62.早测试，常测试，自动试?BR> Test Early. Test Often. Test Automatically
与呆在书架上的测试计划相比，每次构徏试运行的试要有效得多?/P>
63.要到通过全部试Q编码才完成?BR> Coding Ain't Done 'Til All the Tests Run
是q样?/P>
64.通过“蓄意破坏”测试你的测试?BR> Use Saboteurs to Test Your Testing
在单独的软g副本上故意引入bugQ以(g)验测试能够抓住它们?/P>
65.试状态覆盖，而不是代码覆?BR> Test State Coverage, Not Code Coverage
定q测试重要的E序状态。只是测试代码行是不够的?/P>
66.一个bug只抓一?BR> Find Bugs Once
一旦测试员扑ֈ一个bugQ这应该是测试员最后一ơ找到它。此后自动测试应该对其进?BR> (g)查?/P>
67.p是一U编E语a
English is Just a Programming Language
像你~写代码一L(fng)写文：(x)遵守DRY原则、用元数据、MVC、自动生成、等{?/P>
68.把文档徏在里面，不要栓在外面
Build Documentation In, Don't Bolt It On
与代码分ȝ文档不太可能被修正和更新?/P>
69.温和地超出用L(fng)期望
Gently Exceed Your Users' Expectations
要理解你的用L(fng)期望Q然后给他们的东西要多那么一炏V?/P>
70.在你的作品上{
Sign Your Work
q去时代的手Zh在他们作品上{而自豪。你也应该如此?/P>
(g)查清?BR>---------------------------
71.要学?fn)的语言
厌倦了(jin)C、C++和JAVAQ试试CLOS、Dylan、Eiffel、Objectve C、Prolog、Smailltalk或TOM。它们每一U都有不同的能力和不同的“风味”。用其中的一U或多种语言在家里开发一个小目?/P>
72.WISDOMd?/STRONG>
What do you want them to learn? 你想让他们学C么？
What is their interest in what you've got to say? 他们对你讲的什么感兴趣Q?BR> How sophisticated are they? 他们有多富有l验Q?BR> How much detail do they want? 他们惌多少l节Q?BR> Whom do you want to own the information? 你想要让谁拥有这些信息？
How can you motivate them to listen to you? 你如何促(j)使他们听你说话？
73.怎样l持正交?/STRONG> 74.应制作原型的事物 75.架构问题 76.调试(g)查清?/STRONG> 77.函数的得墨忒x(chng)?/STRONG> 78.怎样深思熟虑地~程 79.何时q行重构 80.劈开戈尔q斯l?/STRONG> 81.试的各个方?BR> ·单元试
·设计独立、良好定义的lg?BR> ·使你的代码保持解耦?BR> ·避免使用全局数据?BR> ·重构怼的函数?/P>
·架构
·已有pȝ中的新功?BR> ·外部数据的结构或内容
·W三方工hlg
·性能问题
·用户界面设计
·责Q是否得到?jin)良好定义?BR> ·写作是否得到?jin)良好定义?BR> ·耦合是否得以最化Q?BR> ·你能否确定潜在的重复Q?BR> ·接口定义和各约束是否可接受Q?BR> ·模块能否在需要时讉K所需数据Q?/P>
·正在报告的问题是底层bug的直接结果，q是只是症状Q?BR> ·bug真的在编译器里？在OS里？或者是在你的代码里Q?BR> ·如果你向同事详细解释q个问题Q你?x)说什么？
·如果可疑代码通过?jin)单元测试，试是否_完整Q如果你用该数据q行单元试Q会(x)发生什么？
·造成q个bug的条件是否存在于pȝ中的其它M地方Q?/P>
某个对象的方法应该只调用属于以下情况的方法：(x)
·它自w?BR> ·传入的Q何参?BR> ·它创建的对象
·lg对象
·L意识C在做什么?BR> ·不要盲目地编E?BR> ·按照计划行事?BR> ·依靠可靠的事物?BR> ·Z的假定徏立文?BR> ·不要只是试你的代码Q还要测试你的假定?BR> ·l尼的工作划分优先?BR> ·不要做历史的奴隶?/P>
·你发C(jin)对DRY原则的违反?BR> ·你发C物可以更为正交?BR> ·你的知识扩展?jin)?BR> ·需求演变(sh)(jin)?BR> ·你需要改善性能?/P>
在解决不可能解决的问题时Q问问你自己Q?BR> ·有更Ҏ(gu)的方法吗Q?BR> ·我是在解x(chng)的问题吗？
·qg事情Z么是一个问题？
·是什么它如此难以解冻I
·它必Mq种方式完成吗？
·它真的必d成吗Q?/P>
·集成试
·炎症和校?BR> ·资源耗尽、错误及(qing)恢复
·性能试
·可用性测?BR> ·Ҏ(gu)试自w进行测?BR>
以上内容摘自《程序员?sh)炼之道?/P>