程序员修炼之道 -- 阅读笔记

终于要离开学校了，终于有时间可以静下来看看之前导师推荐的书籍。之前有看到说《程序员修炼之道》是对程序员影响最为深刻的书， 就从它开始吧。用这个还算可以的音响听着音乐，看书很惬意啊。 顺便吐槽下京东，我买了本地有货的三本书，三天了我还没见到。这效率实在是fuck。 第一本书的第一章是电子版上看的，还好我有kindle。这里基本上说的是沟通方面的。我发现我的沟通确实有点问题，不太主动，表达含糊。之前只和ultramanhu交流比较多，可能是多年的默契吧，表达清楚意思不怎么费劲。现在的一起合租的xboy（和qboy很像啊），和他交流经常文不对题，开始我总以为他习惯岔开话题，但是后来发现在其他有些人身上也出现过这种问题。看来我的表达力确实有问题，一直说ben大神的表达力低下，其实他只是我这种更恶化一些罢了。不管怎么说，之前看到过个视频，我觉得很有道理，对世界的理解应该是 “知其然 — 知其所以然 – 知其知其所以然 – 知其知其所以然所以然”。别人也是属于世界的一部分，了解别人看待事物和自己不一样、了解别人看待事物的角度、了解别人为什么和自己看待事物的和自己不一样，都是自身对这个世界的理解。同样，自己要表述的意思让各种各种各样的人有理解并且有兴趣听也是自身表达能力的一种体现。Maybe，这就是我大学生活孑然一身（不完整啊）的原因吧。T_T “注重实效的哲学”，其中最重要的部分当属那个WISDOM离合诗了吧。

EN	CN
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 canyou motivate them to to listen to you?	你如何使他们听你说话？

做到这些不容易啊，一些通用的建议是“知道你想说什么”、“了解听众”、“选择时机”、“根据不同场合选择风格”、“让听众参与”、“倾听”、“回复他人”。这些说起来简单，我发先做起来一点也不简单。组织语言不是意见容易的事，另外实际我之前在学校的几次演讲少有让听众参与的部分，一般都是最后的例行提问，另外我发现几次头脑风暴的分享效果也不好，至少没能把大家的兴趣调动的很高，这些还都是搞技术的人呢，可以预见，非技术人员就更困难了。

倾听看似很简单，实际并非如此，我发现我在听别人说话的时候有些时候有打断别人的冲动，这点ultramanhu尤为明显，虽然我也知道这很不礼貌。另外之前看《人性的弱点》，上面说一个人总是希望自己被重视，听别人说完也是一种重视。最后，在回复他人这一点上，我老爹之前和我提过一次。但是我发现我还是容易忘记，上次一个同事发我东西我就忘了回了，这也算尊重他人的一种吧，果然我不擅长表达。

“注重时效的途径”，这章开始是编程方面的了，一开始就提到一个原则:DRY(Don’t Repeat Yourself)。在写代码做项目的时候，经常会碰到重复，重复主要有强加的重复、无意的重复、无耐性的重复和开发者之间的重复。强加的重复我觉得是最容易发生的，也是被动发生的。写项目的时候写到后期，总会发现还有很多重复或这类似的代码和定义，虽然说在细节上各有不同，甚至包括注释和文档的重复，这里的建议是申明文件(.h)注释仅包含接口，实现文件(.cpp)包含实现方法的注释，我之前学校的VEP程序就存在复制注释的情况，这是最典型的强加的重复。另外，无意义的重复，我的理解是，一些无意义的包装方法，比如我在tx的上一个项目的Singleton基类，由于本身是返回指针，又参考了boost的实现方式，就实现了boost库里的那种返回引用和const引用的接口。事实上整个项目没有用到过，纯属浪费，而且会按之前tx的导师edwinzhu说的，对一个功能提供多钟方法，只会是使用者混淆。无耐性的重复则是为了快速编码而复制代码，又让我想起了我们之前项目里的数据层，各种复制的代码。不过最后是给我用继承和函数模板尽量地合并了。最后就是开发者之间的重复，这是干程序员的最容易犯的问题了，经常看到别人写的不好就想自己重写一份，比如刚才提到的Singleton基类，最初就是重写一遍和比我们部门其他一个项目的单件类做了些拓展，允许对构造和析构函数进行保护。Boost确实是个强大的库啊，不能直接用，搞得这些很实用的功能的要自己实现确实让我有点小不爽。

这里还提到个词是“正交性”。这个词我喜欢，终于有个专业的词让我和别人说Windows工具多么不好用，Linux的命令各种NB了。正交说白了就解耦，说复杂不复杂，说简单不简单的东西。后面还提到个曳光弹，这个翻译有点…，这本书有一大亮点是翻译得很给力，但是这里是我觉得翻译得最别扭的地方。以前我倒是很少考虑先完成雏形，再根据反馈修正的。另外还提到了估算，我发现我估算水平还很不够，估算的东西很不准，一般都会多估出时间，然后开发过程中如果发现有一个新的疑难点就回另外话挺多时间去解决。

以前没注意到assert有多么重要，现在倒是更深入理解了一点。毕竟数据很重要，有时候宁愿崩溃也不要出现异常操作，这就是“早崩溃”的意义所在，不能造成连锁的异常反应。所以现在开发的项目中，我把BOOST的断言和静态断言库提取出来了，并且封装了一层，实现了伪断言，即在Debug模式是断言，在Release模式是throw一个异常，然后上层捕获，记录错误日志里。这主要是有些服务不能让他崩溃掉。 在我第一次接触单件模式的时候觉得这东西不错，但是慢慢的也发现问题了，第一是解耦问题。确实一旦使用了单件模式很容易耦合度很高，这个需要注意。第二就是线程安全问题，单件就意味着多个进程都访问的一个资源，这样的话进程安全也很麻烦。特别是这种很基础的库。因为线程安全问题，我之前写的单件模式基类被我重构过两次，现在感觉仍然不是很完美，没有做到第一次使用时创建，以至于会拖慢启动速度，但是比较简单，支持动态载入。

后面的靠巧合编程和测试的部分，本来我觉得没什的。而且我觉得前一个似乎没什么好说的。直到我最近的项目在开发过程中加入了大量的单元测试，当然我还是没花那么多时间测试，没有做很完整的边缘测试用例。然后必然的发现了一些小问题。但是意外地发现了一个大问题。还好发现的早，我几乎改了一大半的内部内存结构，代价不是很大。如果在运行中或者在编写上层代码的时候发现那就麻烦了。

在这之后的需求方面的描述里，基本的需求表示方式我很早就知道了。但是有一点很重的是需求理解问题。这个问题我已经在N个地方听过N个不同的版本，核心部分都一样。就是不同专业背景的人、不同生活环境的人，对同一问题的描述是不同的。这样会导致在需求传递过程中的信息的变形。导致客户描述的是A，PM描述的是B，策划或产品描述的是C，程序员实现的D，实际客户想要的是E的情况出来。所以开发人员需要不断地和他人交流和确定真正的需求。不然就很容易做出自以为很NB但是完全没有实用价值的废物。比如，客户可能会和你说，我要每天下午5点去倒垃圾；PM就会说，做一个系统和一个智能垃圾箱，可以设定一个时间，每天到那个时间以后控制垃圾桶去自己清理掉；程序员可能实现了一个NB的系统，每天到时间了可以做某个动作，这个动作已经实现的一个功能是倒垃圾，而且花了大把精力在垃圾分类、垃圾桶清洗什么的上面。而实际上，人家客户只是要一个闹钟，每天到时间提醒一下“该倒垃圾了”而已。

这本书里，全篇都没离开DRY原则，我发现这点我还做得不错。前面写得略凌乱，还有一些部分因为还没有切身体会所以理解不是很深刻。以后碰到了在补全吧，暂时就写到这里。这确实是本不错的书，值得所有程序员一读。