最近把”A Pragmatic Programmer: From Journey man to Master”复习了一遍。这本书是2010年差不多六年前买的中文版，之前读过一遍。这次阅读似乎比之前的感触更多了一些，我想还是写下来加深下印象，希望能够更好地指导自己的实际行动。其实很多道理都很简单，或许是大道至简，或许不同的是是否能够用于指导实际的行动。
第一章主要是作为务实的程序员的基本原则。首先是要诚实地面对自己的不足，所谓 “The greatest of all weaknesses is the fear of appearing weak.”。然后对工作和自己的责任感，提供选择而不是借口。在记住Big picture的同时Don’t Live with Broken Window, 保持追求更好的心态的同时又知道什么时候适可而止。要坚持学习“An investment in knowledge always pays the best interest.”保持自己知识和能力的多元化。还有就是有批判的思维对待自己看到听到的，不是一味的接受。最后是强调沟通的重要性和基本的技巧。知道自己的观点，了解自己的听众，注意沟通的时机和方式。
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?
第二章主要是介绍务实的一些常用方法。包括增强正交性，避免重复，提高可重用性，其中提到测试可以做一个检验正交性的一个很好的途径。然后是保持构架的灵活性，实现可撤销性，比如一个系统换用不同的数据库。在许多未知因素的情况，曳光弹(Tracer Bullets)来帮助定位目标，通过快速构建框架让用户能够及早看到能工作的东西，同时对于开发者也是一个能够在其中工作的环境和一个集成的平台，更能感受到工作的进度。和原型开发不同，曳光弹是在产品中使用的代码，而原型开发则是实验性着的，是应该扔掉的代码。之后是接近领域编程(Program Close to the Problem Domain), 可以实现小型的领域语言自动生成代码。最后这一章节提到了估算的重要性，通过理解系统，分解系统，追踪自己的估算来提高下一次估算的准确性。
第三章是建议的基本工具，所谓工欲善其事，必先利其器。建议包括使用纯文本来保存知识，熟悉Shell, 用好一种编辑器(Emacs VS VI :-), Not Notepad)，使用代码版本控制系统。在调试时保持”Fix the problem, Not the Blame”, 和”Don’t Panic”的心态。最后建议是学习一门文本操纵语言，以及在必要的时候构件代码生成器(Write Code That Writes Code).
第四章注重实效的偏执(Paranoia)。首先要坚信自己不可能写出完美的软件(You Can’t Write Perfect Software), 所以要防御性编程，按照合约设计。在出现问题时候Crash Early, 正确使用断言（不可能发生的情况）和异常(Use Exception for Exceptional Problems), 最后对于程序资源的管理要有始有终。
第五章 Bend, or Break是关于保持代码灵活性的技巧，首先是要使耦合降低到最少，Put abstraction in code, details in metadata 实现动态配置。然后是时间上的解耦提提高并发行。”Analyze Workflow to Improve Concurrency”. 最后是解耦的一些常见模式，包括Observer Pattern, Model-View-Controller pattern, 还有不太理解的用黑板协调工作流。
第六章是关于Coding时候的一些建议，包括”Don’t Program by Coincidence”, 总是意识到自己在做什么，按照计划行事，测试代码和假定，把事件花费在高优先级的事情上。理解算法效率，然后是重构的一些建议，包括”Refactor Early, Refactor often”，重构时候不要增加新的功能。接着是测试的重要性，”Design to Test”。最后是”Don’t Use Wizard Code You Don’t Understand”, 这让我想起了当年的VC6的MFC，后来专门读一本都没有太弄明白。
第七章Before the Project, 首先是关于需求的建议，所谓完美不是没有什么需要增加的，而是在没有什么需要去掉时候达到的。在需求分析阶段，要想用户一样去思考，不是搜集需求而是挖掘它们。要注意倾听自己反复出现的疑虑，不要过于Rush. 还有就是对于有些事件行胜于言(Some Things Are Better Done that Described)。
第八章是注重实效的项目。包括围绕功能，而不是工作职务来组织项目，然后是要使自动化无处不在，包括编译，发布，测试。测试要全面(Test State Coverage, Not Code Coverage), 使(Find Bus Once), 最后建议温和地超过用户的期望，同时”Sign your work”，一个注重实效的程序员一定是乐于接受挑战，勇于承担责任的人。
回头想一想，其实很多道理很是简单，但所谓大道至简。所谓要成为一个好的程序员，其实所需要的道理也多不了多少，只不过，当水平不够的时候，永远不能认识到那些朴素道理的重要。能不能让正确的原则知道正确的行动本身，其实就是区分是否是高手的一种显著标志，这些需要通过不断的有意识的强化实践和反复提醒，坚持学习，努力！
下一本书是”Soft Skills: The software developer’s life manual”.