程序员修炼之道

最近发现一本叫做《The Pragmatic Programmer/程序员修炼之道》的书，用了一周左右读完，启发很大，

在这里晒一下自己的读书笔记，谈不上去粗取精，只是给没有时间详细读此书的朋友们参考参考，如有不足，欢迎指教。

 

注重实效的哲学 / A Pragmatic Philosophy
1. Provide Options ，Don’t Make Lame Excuses./ 提供各种选择，不要找蹩脚的借口。
负责的态度。出了问题，要承担责任。
2. Don’t Live with Broken Windows / 不要容忍破窗户。
在这里破窗口指:低劣的设计、错误决策、或是糟糕的代码。发现就要马上修正，即使现在没有时间进行适当的修理，也要用木板把它钉起来，防止造成进一步破坏。
3. Be a Catalyst for Change / 做变化的催化剂
读者可以自己google “石头汤的故事”，此处变化的催化剂就是故事中的士兵。
4. Remember the Big Picture / 记住大图景
不要忽略小的症状，大多数软件灾难都是从微不足道的小事情开始的，常常是小事情的积累破坏了士气和团队，要留心大图景。
5. Know When to Have a Stop / 知道何时止步。
代码也许不完美，但是不要难过担心，它不可能完美。
6. 知识上的投资总能得到最好的回报。     -----------本杰明.富兰克林
如他所说，要定期为自己充电，为自己进行资产投资。
7. It’s Both What You Say and the Way You Say It. / 你说什么和你怎么说同样重要。
除非你能够有效的与他人交流，否则就算你用友最好的主意、最漂亮的代码、或是最注重失效的想法，最终也会毫无结果。

 

注重实效的途径 / A Pragmatic Approach
8. DRY – Don’t Repeat Yourself. / 不要重复你自己
无论是因为环境、自己的无意识、懒惰还是不同开发者之间造成的重复，无论是代码还是注释，都要竭力避免，否则对于以后项目的重构都要带来难以置信的工作量。
9. Make It Easy to Reuse / 让复用变得容易。
你所要做的是要营造一种环境，在其中要找到并复用已有的东西，比自己编写供容易。
10. Eliminate Effects Between Unrelated Things / 消除无关事务之间的影响
简单说来就是高内聚，低耦合。要养成不断批判对待自己代码的习惯，打造正交的系统，提高生产效率、降低项目重构时崩溃的风险。
11. There’re no final decisions. / 不存在最终的决策。
为你的系统设计灵活的架构，做好关键决策变化的准备。简单的例子就如:
系统数据库由SQL-Server变更为Oracle数据库，系统的代码就可能重新编写。
12. Use Tracer Bullets to Find the Target. / 用曳光弹找到目标
在需求不明确时，用所有确定的因素搭建一个临时框架，最快速的把产品呈现在用户眼前。
13. Estimate to Avoid Surprises. / 估算，以避免发生意外。
估算是一种能力，你可以估算项目的进度，你可以知道那些子系统需要优化，而哪些可以暂时放在一边等等。

 

基本工具/ The Basic Tools
14. GUI 好处和坏处
好处: WYSIWYG---What You See Is What You Get.
坏处: WYSIAYG ---What You See Is All You Get.
15. Use the Power of Command Shells / 利用命令shell的力量
通过使用命令Shell，你会惊讶它能是你的生产效率带来怎样的提高。
16. Use a Single Editor Well / 用好一种编辑器
选一种编辑器，彻底了解它，并将其用于所有的编辑任务。不用停下来思考怎样完成文本操作:必须的键击将成为本能反应，编辑器将成为你双手的延伸；键会划过文本和思想时唱起歌来。当然，要确保此编辑器要能在你使用的所有平台上使用。
17. Always Use Source Code Control / 总是使用源码控制
进步远非由变化组成，而是取决于好记性。不能记住过去的人，被判重复过去。
18. Fix the Problem , Not the Blame / 要修正问题，而不是发出指责
Bug是你的过错还是别人的过错，并不是真的很有关系。它仍然是你的问题。
19. Don’t Panic / 不要恐慌
就算你有个神经质的老板或客户在你的脖子后面喘气，也不要惊慌，稳定心态找出问题的根源。
20. Don’t Assume it – Prove it / 不要假定，要证明    
当面对某个让你吃惊的Bug时，你必须重新评估你确信不疑的”事实”，少一些假定，多一些证明。
21. Learn a Text Manipulation Language / 学习一种文本操作语言
我们每天几乎都在使用文本操作语言，与其他语言相比，许多想法都可以通过它简单的实现。
22. Write Code That Writes Code / 编写能编写代码的代码
如果想避免重复订的打字，是自己免于腕部劳损综合征，那么试一试写一个代码生成器吧。

 

注重实效的偏执/Pragmatic Paranoia
23. You Can’t Write Perfect Software. / 你不可能写出完美的软件。
在计算机技术简短的历史中，没有人曾经写出过一个完美的软件。你也不大可能成为第一个。别把时间和经历浪费在追逐不可能实现的梦想上。
24. If It Can’t Happen, Use Assertions to Ensure That It Won’t ./ 如果它不可能发生，用断言确                保它不会发生。
25. Use Exceptions for Exceptional Problems. / 将异常用于异常的问题。
为了避免遭受经典的意大利面条式代码的所有可读性和可维护行问题的折磨。巧妙的使用异常，将大大简化代码的逻辑。
26. Finish What You Start. / 要有始有终
此提示适用于处理资源分配及相关的操作(如文件读写、事务、内存、线程、窗口等)，退出程序时要释放资源。

 

弯曲，或折断/ Bend, or Break
27. Minimize Coupling Between Modules / 使模块之间的耦合减至最少
编写极可能遵守的墨忒尔法则的代码
28. Put Abstractions in Code, Details in Metadata. / 将抽象放进代码，细节放进元数据
元数据(metadata)是关于数据的数据，是对任何对应用进行描述的数据。最常见的例子可能是数据库schema或数据字典。
29. Configure, Don’t Integrate / 要配置，不要集成
目标就是把我们的系统变得高度可配置，诸如算法，数据库产品，界面风格之类都作为配置选项供选择配置。
30. Analyze Workflow to Improve Concurrency. / 分析工作流，以改善并发性。
采用UML活动图的方式，通过分析工作流，处理并发事务，优化事务流程。
31. Design Using Services / 用服务进行设计
我们需要的不是组件，而是服务---位于定义良好的、一致的接口之后的独立开发的对象。
32. Always Design for Concurrency. / 总是为并发进行设计
在设计时考虑了并发，到时我们就可以更容易地满足可伸缩性或性能需求。
33. Separate Views from Models. / 使视图与模型分离
MVC设计模式的核心思想。
34. Use Blackboards to Coordinate Workflow. / 用黑板协调工作流
关于黑板，我的理解还不够，感觉上讲的不是很清楚。希望读者自己可以查一下。粗略的理解黑板是一个类似于”对象论坛”系统，所有需要交互的对象都放在此处，他们动态的互相交互信息。

 

当你编码时/While You Are Coding
35. Don’t Program by Coincidence. / 不要靠巧合编程。
要深思熟虑后编程，不要被目前无错、可运行的代码欺骗，知道每行代码的用处。
36. Estimate the Order of Your Algorithms. / 估算你的算法的阶
Then Test Your Estimates. / 测试你的估算。
注重实效的程序员会设法既考虑理论问题，又考虑实践的问题。
37. Refactor Early , Refactor Often. / 早重构，常重构
代码需要演化: 它不是静态的事物。
38. Test Your Software, or Your Users Will. / 测试你的代码，否则你的用户就得测试。
你对于软件测试的态度，决定了软件的质量。
39. Don’t Use Wizard Code You Don’t Understand. / 不要使用你不理解的向导代码。
因为向导代码最终也会成为你的代码，不懂得向导代码的意思，意味着你不懂自己的代码。
40. Work with a User to Think like a User. /与用户一同工作，以像用户一样思考。
开采需求的过程也是与用户群建立和谐的关系、了解他们对你正在构建的系统的期许和希望的时候。与用户一起坐下来讨论，他们真实的需求。
41. Abstractions Live Longer than Details. / 抽象比细节活的更长久。
关注抽象，避免掉入“只是增加一个新特性”的漩涡。
42. Use a Project Glossary. / 使用项目词汇表
如果用户和开发者用不同的名称至同一个事物，或是更糟，用同一名称指不同事物，这样的项目很难取得成功。
43. Use Saboteurs to Test Your Testing. / 通过“蓄意破坏”测试你的测试。
指定一个项目破坏员，其职责就是取源码树的一份单独的副本，故意引入Bug，并证实测试能抓住它们。
44. Treat English as Just An0ther Programming Language. / 把英语当作又一种编程语言。
通过良好的英语形成良好的文档，在通过实效性原则，把文档应用于代码之中。

 

       以上44条是我从书中摘抄的一些内容，并加些自己的理解，希望对想要成为高效程序员的朋友们有些启发。
       本篇内容均为作者认真整理，转载请表明出处()。谢谢。
       原书封面: