读《程序员修炼之道》之笔记

在 读《程序员修炼之道》之我背景 中描述的状态下，我开始了对《程序员修炼之道——从小工到专家》这本书的阅读，也从此刻开始，我决定要坚持将博客写下去了，以前写的东西都心血来潮了就写一次，前不久自己在搜索一个问题的时候，竟然搜到自己写的博客了，当时郁闷的不行，自己写过的东西都忘了。

我看书一直有个习惯，就是看的尽量仔细，尽量理解，希望能一劳永逸。其实这种想法是不切实际的，特别是这种逻辑上的书籍，更是容易让人看了之后茅塞顿开，过了几天就忘之天外的状态。所以决定写下看完之后的感想，以加深理解，同时记录自己的成长经历。

我是从前面的“前沿”和“序”开始看的，这里讲述的就是整本书所要讲述的主题以及能对读者达到的效果。印象很深的一个道理是：编程中手与高手的区别就能不能用正确的原则指导正确的行为本身。本意就是说原则、规范什么的一说出来，大家都懂，但到了真正能用的地方，能自然而然想到并且使用的才是高手，而中手往往需要提醒甚至出错了之后才会想起来。因此整本书都是以Tips的形式来表达中心。

 

第一章 注重实效的哲学

光看标题，我并没看懂这张到底要讲述什么，因为我对哲学两字的概念太过模糊。看过章首的简介之后，也大概明白这章讲的是作为一个程序员所需要具备的基本素质吧。总结本章类容如下：

1、必须为自己的代码负责，不管是代码丢失、代码不规范等引起的问题，都应该自己负责。出问题后主动寻找解决方案。

2、不要轻易容忍不规范的代码，并且尽量不要因为别人的代码不规范，自己也跟着学。最后各种不规范导致项目进度缓慢，后果很严重。

3、如果有什么新的想法，或者和别人讨论问题讨论不出结果，可以简单的动手作出个模型，让对方看到效果，以吸引其为你的想法做贡献。

4、如果时间不允许，不能做到完整的完美软件，那么就提供一个完整的比较完美的软件，抢占市场的同时，也能让用户提供反馈，从而将你的软件引向完美。

5、向经营资产一样去经营知识，定期投入，评估风险，多方面均衡发展。学会批判的思考所学和所闻。

6、学会礼貌而有效的交流，争对不同的听众采取不同的交流方式，也要选择恰当的时机，同时学会倾听和回复。

第二章 注重实效的途径

今天是周末，玩了一天了，看电影和看视频把眼睛都看花了，打算早点睡觉。睡觉之前补上昨天看完的第二章的笔记。

这一章感觉偏向于讲解软件开发所应该遵守的一些原则以及可采取的方法，和软件工程的部分类容相似。

7、重复的危害。这里有一个短语叫DRY（Do`t Repeat Yourself），就是不要重复，讲述了很多方面，包括以下几个方面：

强加的重复：这个不是太理解，具体的例子上觉得就是当使用别人的库时，提供的创建对象的方式等，需要不断的重复使用相同的代码。避免的方式是使用代码生成器，

这样能根据不同的对象进行自动创建。

无意的重复：自己都没有意识到的重复，主要指设计过程中导致的重复。

无耐性的重复：当有相同的代码可以拷贝或者参考时，直接对其引用或稍加修改。这点在做项目赶时间时尤其严重。

开发者之间的重复：各模块之间没有沟通的足够好，导致做了重复的检测等。

8、正交性。就是软件工程中提过的高内聚、低耦合。不管是设计还是实际的编码，都尽量做到低耦合，减少互相依赖，以方便后期修改、测试。

9、可撤销性。做到低耦合的同时，要假设某一模块在更换之后能否和其他某块正常而简单的接上，要想到单独模块的可撤销性。

10、曳光弹。一种项目开发方式，先打通项目需要的流程（可以是整个项目的，也可以是单个模块的），然后逐步填充好细节。这种方式能为后期开发指导方向，并容易看到成果。

11、原型与便笺。原型是指能够代替项目开发所代表的对象，方便描述问题的，稍后可以舍弃的抽象对象。便笺是用来代替记录某一描述对象的模型，我们可以使用若干便笺代替若干对象，来分析问题的可行性，或者组成整体原型进行分析。

12、领域语言。这小节我也看得比较模糊。我领悟到的意思是指，当我们在讨论问题的时候，尽量使用接近当时实际问题的语言进行讨论，这样能站在比较高层的角度去看待问题，同时能避免语言上的歧义分析。

13、估算。估算对于程序员来说，尤其是向着项目经理前进的程序员来说相当重要。这里有两点技巧，第一是给出的结果用一种比较精确的数值表示，这样能增加精确感，比如四分之三秒，就比750毫秒要精确。第二是如果没有信息能很快给出估算结果，就直接回答：“我等会回答你”。当然，最最重要的还是掌握估算技巧和提高估算能力。

 

第三章 基本工具

关于这章，看完之后我心情比较沉重。章首简介中直接就指出：“许多新手程序员一上手就采用单一的强力工具，比如IDE，从此再也离不开其舒适的界面”。这点我深表赞同，其实从很多方面来说，一上来就使用比较高级的工具，往往导致对工具的实质理解的不够透彻，任何一门技术，最好都从牢固的基础学起，以后才能处变不惊。我是大学才接触的编程，最开始接触的是Turb C,，然后半学期之后直接就接触VC6了。那时候还没学编译原理什么的，完全就没弄懂整个PE文件生成的流程。到了现在工作使用的是VS，更进一步远离了那些简单的工具。

在我看来，从这些简单的工具开始学习编程，真的要比直接使用高级工具的好。就好比学过汇编再学C语言一般，调试的时候，能看懂汇编，好处就大大的有。如果可以的话，我要花时间好好从Unix中重头学习下编程。关于一直使用IDE的程序员，推荐博文：IDE 不是程序员的唯一选择 。 接下来还是进行这张的笔记总结吧。

14、纯文本的威力。现代操作文本的工具，没有不支持纯文本的，因此毫无疑问它可以作为很多工具的媒介，甚至作为简单的数据库。

15、shell游戏。我们这代程序员，特别是没有接触过Unix的，对shell命令很有嗤之以鼻个感触，原因就是很多能用鼠标一点就打开的东西，用shell命令得输入半天。我不否认这点，但作为开发人员，尽量去减少手在鼠标和键盘之间的移动，这能大大的提高开发效率，这点也毋庸置疑。我曾经就想过买一款鼠标和键盘集成在一起的键盘。事实上没有几款这样的键盘，原因就是鼠标能做的事情，大多数能通过键盘去实现。相反的，键盘能做的事，鼠标却很少能做到。

16、强力编辑。我现在一写代码，就需要打开VS，并且VS上还必须安装这VA。在我看来，这两者搭配，组合起来的效率比我直接使用文本编辑器如Emacs、Vim等要高的多。我需要语法高亮、自动对齐、自动补全等功能。而这些事实上都能通过Emacs等工具来实现，只是我们要学会使用Emacs而已。有一点尤其重要，如果我要使用一种VS不支持的语言去编程，怎么办？或者如果你只是简单的想要测试一个算法，你是否需要打开VS，新建一个工程去测试？这只是很简单两个例子，具体的能提高生产率的方式，要多的多，因为我本人就昨晚花了点时间研究了下使用那些小工具，所以很多优势我还没能说出个所以然。

17、源码控制。在学校做一个项目的时候，一共四个人，当时一直在想，如果我们四个人同时编码，万一要修改公共的部分，怎么办？直到上班了，才知道还有源码控制这么个工具。说白了，就是建立一个数据中心，记录你修改交由它管理的文件的过程。不管是工作项目，或者你自己的小项目，都可以这么管理。我们公司用的SVN，以前只用过客户端，昨晚研究使用了一下服务器建立（也建立在本机上）。不过目前我还只会把仓库建立在本地上，一旦硬盘坏了，就是个杯具了。等会去找一个能使用网路进行源码控制的工具。

18、调试。关于调试，我就看到我同事桌上有两本windows调试的书，都厚达1000页。可想而知调试也是一门比较难的技术。本书没有讲述具体调试技术，主要讲述的是调试过程中应该注意的事项，包括要追究问题的根源，不要厌恶Bug，如果你写的代码够严谨的话，BUG就是给你提高自己的机会。

19、文本操纵。上次做项目的时候，用到了好多宏，比如判断某个指针为空就break的宏，判断某个函数返回值为false就break的宏等等。另外有时候有必要为源文件写一个固定格式的注释，指明代码用途，版权信息等。有没想过，其实这些工作可以用脚本语言去帮助自动实现，比如一创建新文件，就自动加上了版权申明等格式字符串。书中有个特别好的例子，就是一段代码操作一个数据库，这个数据库现在的字段什么的都是固定的，所以代码里面都是根据字段来操作，如果以后我们修改了数据库字段，那么就需要去修改代码，假如我们使用脚本语言将数据库的字段映射到代码中，这不就一劳永逸么？（始终觉得我描述的不好。 )所以很有必要学一门文本操纵语言。

20、代码生成器。分为被动的和主动的两种。主动的就相当于集成在你需要编译的环境里，每次编译都会更换。被动的需要单独去触发一次，以后就不用触发了。这里的代码生成器就类似于上面文本操纵中举的例子。

 

第四章 注重时效的偏执

        不得不说，老外写的书，翻译成中文，标题让我无法理解。本章主要讲解软解开发过程中为了避免错误所应该采取的措施。

21、按合约设计。不知道是因为这节里面有太多我不懂的术语，还是翻译成中文比较拗口。这节是本章最长的一节，然后大多数陈述的内容我却无法看明白。能够读懂的内容是我们在设计接口的时候，要考虑到使用这个接口的前置条件，以后满足这个条件后的后置条件，还有一个类不变项（不太明白啥意思）。总的来说就是要提供给调用者使用该接口的一些说明，就像使用API一样，很多函数都提供了说明、使用条件等。

22、死程序不说谎。本节是陈述程序出错了之后怎样更好。那就是宁愿让其崩溃也别让它继续运行造成破坏。

23、断言式编程。把我们认为绝对不会发生的条件置于断言中，切记不要把必须执行的代码放在assert中。

24、何时使用异常。异常是我们认为其应该正确，才能继续往下运行时用来防止这种不正确情况发生的处理方式。

25、怎样配平资源。对资源的访问，要遵守谁获取，谁释放的原则，不要跨模块，特别是异常处理的时候，不要因为发生异常而不释放资源。对于嵌套的资源分配，采取按照资源分配相反的方式对其进行释放。