《程序员应该知道的97件事》读书笔记<一>

偶然间看到了《程序员应该知道的97件事》这本书，并不是什么新书（只是我之前没有看过而已），不过里面写的内容还是不错的，简单有效，阅读起来颇有共鸣。奇怪的是中文版网上已经很难买到了，下载了英文版阅读了下，还没读完，先写一点（只针对印象比较深的规则）：

 

【Act with Prudence】

网上搜的翻译是“三思而后行”，内容讲解的是不要积累“技术债务”：如果你发现了什么问题需要调整（重构），但是由于工期的原因来不及做，想想“哦，下次再说吧”，这样就形成了债务。这样做实际上是风险比较高的，并不是说一定不能这样做，而是如果你这样做了，务必要想着有一天要把这些债务给还了。

我自己参与的很多项目，实际上都没有还债，结果可想而知，也不知道他们过的怎么样了。。。

前两年负责的一个项目，已经积累了很多债务而不能自拔了，我申请了几个月的时间做重构（很多无用的代码，设计严重不合理，部分代码很难理解），遗憾的是并未得到审批（答复是延后，，，再延后），拖了一年多之后，我已经不再负责那个项目了，哎。。。。

 

对债务0容忍，做小范围的重构，我认为是比较合理的做法（和作者的观点是一致的），如果已经很久没有这样做了，确实还债很困难。

 

【Apply Functional Programming Principles】

应用函数式语言。在学习Java8的时候，我才对函数式语言有了些许了解，原本认为函数式语言之所以被重视起来只是因为多核计算的优势（函数式语言因为没有副作用，所以在多核计算上优势是比较明显的）。但作者认为并不是这样：学习函数式语言之后能够让你即便是非函数式语言的编程过程中也能受益匪浅，比如传输透明性。

举例：如果你写的一个类包含这样一个操作：将一个List类型的数据直接返回给调用者（并没有使用Collections.unmodifiedList包装），这种情况的并发控制就会非常复杂了（虽然一些设计思想里面也提到过这个原则，但是我想函数式语言的精通者肯定不会做这种事情的）

 

题外话：我学习Java8 Lamda表达式的时候觉得有点吃力，不知道为什么要提供这样的机制，到底能够带来哪些好处，后来学习了一下Lisp语言（有本书叫《计算机程序构造和解释》），有一种豁然开朗的感觉。

 

【The Boy Scout Rule】

翻译过来叫童军规则，标题其实挺难懂的，但是做法我觉得非常好：就是每次Check In的时候，你需要确保本次Check in要比Check Out的代码好一些（哪怕只好一点点），至少不会变坏。这样积累下来，你的代码就会越来越好，如果每次都是赶时间或者自己比较懒，则会越来越糟糕。

 

【Check Your Code First Before Looking to Blame Others】

责怪他人之前首先检查自己的代码：我发现几乎所有的程序员（特别是非资深程序员）都有这个毛病，夸张的都会代码编译不过马山怀疑是不是Eclipse有Bug了，实际上90%的问题都出现在自己身上。大概10年之前我听过一个笑话：说是”程序员通常认为老婆是别人的好，代码是自己好“，说的有点流氓，但是后一句还是有道理的。

讨论的时候经常会听见诸如：”这个Bug肯定和我没关系“、”我这块代码不会有问题的“之类的论断，结果很快就被事实推翻了，但是依然如故。。。。。。

在我看来改掉这个毛病是成为资深程序员必备的条件之一。

 

先写这么多吧，打字太累。