《The Pragmatic Programmer》摘要

今天全部整理完毕了。心中最大的感觉就是两个字：科学，其次是专业，最后是规范。竖起铁栅栏，不是要局限你的思维，而是让你规避不必要的常见错误，让你可以更自由地、更集中精力地发挥自己的才能，做一个更高效、more pragmatic的程序员。

*******************************************************************************************************************************************

书中加方框的都是作者的经验，简洁、精辟、实用，所以我觉得记下来比较好。中文是自己的理解： ­

­

Chapter 1 —— A Pragmatic Philosophy ­

1. Provide Option, Don't  Make Lame Excuses. ­

别找借口，这是你自己的责任 ­

­

2. Don't Live with Broken Windows. ­

一但发现错误要即时纠正，否则它会扩大 ­

­

3. Be a Catalyst for Change ­

学会打动别人接受你的观点，有时要用点Stone Soup的Trick ­

­

4. Remember the Big Picture ­

着眼大局，别为小利所动 ­

­

5. Make Quality a Requirements Issue ­

清楚什么时候可以收工，永远没有完美 ­

­

6. Invest Regularly in Your Knowledge Portfolio ­

做什么都得这样！！！ ­

­

7. Critically Analyze What You Read and Hear ­

辩证思维，学会更改思考 ­

­

8. It's Both What You Say and the Way You Say It ­

学会交流，加强交流，仅仅是提问就有可能帮你得到答案 ­

­

Chapter 2 —— A Pragmatic Approach ­

1. DRY — Don't Repeat Yourself ­

最基本的原则，避免最大的“臭味” ­

­

2. Make It Easy to Reuse ­

重用，不仅是Lazy，而且是Design ­

­

3. Eliminate Effects Between Unrelated Things ­

尽可能使设计Orthogonality （但按Bjarne Stroustrup的理论，“正交性应该作为第二位的原则——放在对于有用性和效率的最基本考虑之后”） ­

­

4. There Are No Final Decisions ­

用户的决策总会变，所以你的软件要Reversible ­

­

5. Use Tracer Bullets to Find the Target ­

Tracer Bullets是一个粗而全的框架，加以refine便可使用；Prototype着眼于最终系统，一旦展示但失去价值。我想还是原文说得清晰：Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. ­

­

6. Prototype to Learn ­

Prototyping is a learning experience. ­

­

7. Program Close to the Problem Domain ­

选择适应问题领域的语言 ­

­

8. Estimate to Avoid Surprises ­

做好充分的、数字化的估计 ­

­

9. Iterate the Schedule with the Code ­

估计->编码->反馈->再估计，形成迭代过程，你对计划会越来越有信心 ­

­

Chapter 3 —— The Basic Tools ­

1. Keep Knowledge in Plain Text ­

任何时候Plain Text都不会过时 ­

­

2. Use the Power of Command Shells ­

绝不能只会用鼠标。But if you do all your work using GUIs, you are missing out on the full capabilities of your environment. ­

­

3. Use a Single Editor Well ­

在所有系统都能用的强大的Editor，如Emacs, vi, CRiSP, Brief... ­

­

4. Always Use Source Code Control ­

Even if you are a single-person team on a one-week project. ­

Even if it's a "throw-away" prototype. ­

Even if the stuff you're working on isn't source code. ­

­

5. Fix the Problem, Not the Blame ­

说啥好呢？ ­

­

6. Don't Panic ­

特别适合我 :P ­

­

7. "select" Isn't Broken ­

程序出了错不要首先去责怪系统程序、APIs。（select是Solaris的一个系统函数） ­

­

8. Don't Assume It — Prove It ­

测试优先 ­

­

9. Learn a Text Manipulation Language ­

作者盛赞了Perl，并且说如果想用OO的话，就用Python，吼吼！ ­

­

10. Write Code That Writes Code ­

也太专业了 ­

­

Chapter 4 —— Pragmatic Paranoia ­

1. You Can't Write Perfect Software ­

当然，所以要有计划 ­

­

2. Design with Contracts ­

如果@pre满足，那么可以保证@post ­

­

3. Crash Early ­

千万不要等到发布后Crash，想方设法让它在设计时Crash ­

­

4. If It Can't Happen, Use Assertions to Ensure That It Won't ­

没有“不可能”，所以你要为“不可能”用Assertion ­

­

5. Use Exceptions for Exceptional Problems ­

而对“可能”用Error Handler ­

­

6. Finish What You Start ­

“在外面混，总有一天要还的”，哈哈 ­

­

Chapter 5 —— Bend, or Break ­

1. Minimize Coupling Between Modules ­

不用说了，低耦合是永恒的目标 ­

­

2. Configure, Don't Integrate ­

将软件做成为可配置的，进一步解耦 ­

­

3. Put Abstraction in Code, Details in Metadata ­

使程序更鲁棒，无需重新编译，共享一套程序引擎，使用不同metadata，来适应不同的项目。 ­

­

4. Analyze Workflow to Improve Concurrency ­

解时间耦合(Temporal Coupling) ­

­

5. Design Using Services ­

用Services来取代Components，因为Services是Independent, concurrent objects behind well-defined, consistent interfaces. ­

­

6. Always Design for Concurrency ­

我们可以more easily meet scalability or performance requirements and benefit of a cleaner design. ­

­

7. Separate Views from Models ­

MVC(Model-View-Controller)模式（thy：=Observer+Mediator模式）另可参看The CORBA Event Service ­

­

8. Used Blackboards to Coordinate Workflow ­

使对象彻底解耦，providing a forum where knowledge consumers and producers can exchange data anonymously andasynchronously. ­

­

Chapter 6 —— While You Are Coding ­

1. Don't Program by Coincidence ­

其实做什么事都是这样，不能靠瞎蒙（blindfolded），要有根据，有试验 ­

­

2. Estimate the Order of Your Algorithms ­

绝对不能让程序的运算复杂度是指数阶的。 ­

­

3. Test Your Estimates ­

①“光说不练假把式” ­

②只有当算法成为性能瓶颈时才有必要去改进算法 ­

­

4. Refactor Early, Refactor Often ­

等项目成形了再想重构就几乎不可能了 ­

­

5. Design to Test ­

测试驱动开发 ­

­

6. Test Your Software, or Your Users Will ­

所以还是自己来干吧 ­

­

7. Don't Use Wizard Code You Don't Understand ­

不是不能用，而是只有深刻理解了Wizard生成的代码之后才能用，不要成为它的奴隶。 ­

­

Chapter 7 —— Before the Project ­

1. Don't Gather Requirements —— Dig for Them­

不要浮于需求的表面，而是要能够深究其内在，要能区分出Requirements, Policy, Implementation之间的差异。最好能在需求的背后记录下需求的原因。­

­

2. Work with a User to Think Like a User­

做自己软件的用户，则更能从用户的角度去考虑问题。这一点我倒是很有体会，应该到目前为止我写的软件基本上都是给自己用的。­

­

3. Abstraction Live Longer than Details­

Y2K问题就是个很好的例子，当初如果不是用两位数字来表示时间而是用DATE这个抽象概念的话，解决Y2K问题会轻松许多。­

­

4. Use a Project Glossary（专门词典）­

在一个项目内保持术语上的统一，如client还是customer，可以使大家更加默契。­

­

5. Don't Think Outside the Box —— Find the Box­

这里作者是对一句buzz-phrase的新解（Thinking outside the box）。首先，什么是outside the box？作者举了个例子：Can you connect all of the dots in the following puzzle and return to the starting point with just three straight lines - without lifting your pen from the paper or retracing your steps?­

                                         。              。­

­

 

                                         。              。­

因为我以前见过相关的问题，所以我比较快的得出了答案，否则我也不知道我会怎么想。­

其次，我觉得作者这里有点“强说新词”的味道。人家原意说outside the box，当然已经首先finded the box了，不然他怎么知道已经outside the box？­

­

总之作者的意思就是要另辟蹊径去解决那些impossible puzzles。­

­

6. Listening to Nagging Doubts —— Start When You're Ready­

开始动手之前让直觉告诉你有没有哪些地方尚未准备充足，什么时候可以动工。就像跳水运动员在跳板上张开双臂，waiting for the perfect moment to jump（我很喜欢这个比喻！）­

­

7. Some Things Are Better Done than Described­

在规格上别太抠细节。原因有三：首先，你不可能涵盖所有的细节。其次，语言本身的表达能力是有限的。最后，这将会产生straightjacket effect（不知道咋翻，意思就是给编程几乎没留下自由发挥的空间）。­

­

所以与其在规格细节上做文章，不如Look at prototyping, or consider a tracer bullet development.­

­

8. Don't Be a Slave to Formal Methods­

在项目规划上，有这样一些方法：Structured Programming, chief programmer teams, CASE tools, waterfall development, the spiral model, Jackson, ER diagrams, Booch clouds, OMT, Objectory, Coad/Yourdon, UML。他们不断地被取代，只有Structured Programming活得最长了。­

­

正规方法有三大弊病：首先，它通常是图表与支撑词的组合，但它们对最终用户一点用也没有。其次，因其专业化，使得不同层次的开发小组之间难以沟通和交流。最后，We like to write adaptable, dynamic systems, using metadata to allow us to change the character of applications at runtime.­

­

正规方法应该用，但不能盲目地用，它只是我们开发工具箱中的工具之一。如果在仔细分析之后决定使用它们，那就用吧，but remember who is in charge。­

­

9. Expensive Tools Do Not Produce Better Designs­

一个Pragmatic Programmer应该批判地看待各种方法，对不同的部分分别使用最好的方法，最后将它们融为一个整体。­

­

Chapter 8 —— Pragmatic Project ­

1. ­Organize Around Functionality, Not Job Functions

在小组的分工上也要讲求Orthogonality。

 

2. Don't Use Manual Procedures

让编译、生成代码、回归测试、Build、Final Builds、Administrivia（生成相关Web站点）、Approval Procedures都能够自动化。省事只是一个side-effect，自动化的真正涵义是DRY，是让控制更集中。

 

3. Test Early. Test Often. Test Automatically.

这也是TDD的原则，持续测试，持续集成，同时更重要的是：持续重构！

 

4. Coding Ain't Done 'Til the Tests Run

设计要足够地解耦，这样测试就可以在无GUI的情况下进行。而且可以很好地适应不同的GUI库。

 

5. Use Saboteurs(搞破坏者) to Test Your Testing

一个正式的项目中应该专门指定一名Saboteur。

 

6. Test State Coverage, Not Code Coverage

为此测试数据一定要精选！

 

7. Find Bugs Once

发现Bug就一定要解决它，不能再留到下次。Once a human tester finds a bug, it should be the last time a human tester finds that bug. 所以要适当修改测试数据做好回归测试。

 

8. Treat English as Just Another Programming Language

要将代码和文档看作是相同模型的两个不同的视图（model / view）。

 

9. Build Documentation In, Don't Bolt It On

再一次是对DRY原则的重申。JavaDoc、DOC++、DocBook

 

10. Gently Exceed Your Users' Expectations

谁说人老美都是直肠子？人比咱们还懂得中庸之道呢！

 

11. Sign Your Work

不能有羞于将代码或者设计签上自己名字的想法。首先代表你勇于担负起自己的那份责任。更重要的是，你应该为你的工作而自豪（可能是你个人的，也可能是一个小团队的。XP就鼓励对代码共用所有权）。我想还是原文更有气魄：

We want to see pride of ownership. "I wrote this, and I stand behind my work." Your signature should come to be recognized as an indicator of quality. People should see your name on a piece of code and expect it to be solid, well written, tested, and documented. A really professional job. Written by a real professional.