阅读者(十七):编程珠玑,字字珠玑

  • 丁雪丰

2011 年 11 月 21 日

话题:Book Review语言 & 开发架构算法

无论你自称是“程序猿”还是“攻城师”,只要在写程序,都免不了要和算法打交道。说起算法,第一本从你的记忆中检索出的图书是什么呢?是经典的大部头《算法导论》?还是之前大红大紫的《编程之美》?以前它们几乎是同时映入我脑海的,分不清谁先谁后,这两本书我都读过,前者是在学校的算法课上,而后者则是在毕业求职前。

最近,我终于有了一个明确的答案,在这些算法相关的书籍中,最让我爱不释手的是《编程珠玑》这本薄薄的小册子,因为它真正激发起了我对学习算法的热情。不愧是培养了 James Gosling(Java 之父)、Charles Leiserson(《算法导论》作者)等众多大师的“超级大师”的传世之作。与学校里接触的“教材式”的书不同,《编程珠玑》更像是“问答式”的,抛出一个由实际问题简化而来的问题,然后一步步进行分析解答,作者将想要传达给读者的知识与技巧贯穿其中,期间还经常让人发自内心地感叹一下,原来还能这么做。

以书中第 8 章为例,我把问题简单描述为“输入一个长度为 n 的数组 x,求其中任意连续子元素相加的最大和”。最常规的思路就是写一个三层嵌套的循环,算法的执行时间为 O(n3),时间似乎有点长,做点优化,充分利用之前的计算结果,可以节省一层循环,于是得出了一个 O(n2) 的算法。如果引入“分治”的思路,将数组拆开,分别求解,然后再合并起来,这样只需 O(nlogn) 的时间。别以为这样就结束了,终极方案总是出现在最后的,直接从头开始扫描数组,一次扫描得出结果(具体算法请允许我卖个关子),O(n) 时间内就能解决问题,神奇吧。千万不要以为这是专门用来教授算法知识的假想的“教学问题”,这可是源自布朗大学的Ulf Grenander曾经遇到过的真实问题,可见设计一个好的算法是多么重要。

在日常工作中,估计大多数人都不太有机会遇到太复杂的算法,就算遇到了,也可以侥幸依靠强大的计算和存储能力来解决问题。诚然现在的服务器计算能力越来越强,1 个内核可以抵得上从前的几个庞然大物,更何况 CPU 还是多核的,内存都按 GB 计算,但不能因为这样就认为现在算法和数据结构的重要性不如从前了。假设上文提到的问题中不是计算数组元素,而是每次循环需要操作数据库或者调用远程服务,一次操作就要耗时几毫秒,甚至是几百毫秒,那么 O(n3) 和 O(n) 的区别就显而易见了。加服务器不是唯一的解决方案,有时简单地调整算法能让你省下大把的金钱和时间。

再来说说空间的问题,节省空间似乎已经不再重要了,对某些人来说是这样,但不可否认还是存在很多场景,需要锱铢必较,仔细地设计算法和数据结构。嵌入式设备就不说了,来说说眼下流行的 Redis,为了能最大限度地使用好服务器的内存空间,减少浪费,antirez 在编写 Redis 时就煞费苦心地改良数据结构,真的是能省 1 字节算 1 字节。HDFS 和 BigTable 面向海量存储,照理说它们都是不缺空间的主,可是其中还是提供了 LZO、Snappy 等众多压缩算法,用“闲置”的 CPU 运算时间来换取更多的空间……类似的例子还有很多,所以在编写代码时,如果条件允许,请再多考虑一下自己的实现。

多数 Java 程序员应该都有 GC 调优的经历,遇到 GC 过于频繁,耗时太长的情况,通常会对 JVM 的堆配置做调整,如果调整的效果都不明显呢?来看看代码吧,也许对代码稍作修改,优化下算法,就能把陡峭的内存增长曲线将下来了。啊哈,算法!

书中还时不时地回顾下历史,比如二分搜索,相信大多数人都知道是怎么回事,可是你知道么,第一篇二分搜索的论文 1946 年就发表了,可是直到 1962 年才有人写出了第一个完全正确的二分搜索程序,太让人惊讶了,这个可是如今算法教材上的标配啊。还有那些在编码规范中经常出现的最长不要超过 80 个字符,其中 80 的由来原来和早期的打孔卡有关(如果对这个话题感兴趣,可以阅读阮一峰的这篇文章)。

薄薄的《编程珠玑》,两百多页捧在手上完全没有板砖的压力,可以将其作为教材以外的辅助读物,工具书以外的休闲读物,亦或者是和我一样,将其作为睡前读物,每晚睡前读上几页,和算法聊上几句,和数据结构打个招呼。

Book Review语言 & 开发架构算法