原文地址： http://book.douban.com/review/5294712/
今天从图书馆借到这本书，下午的时候翻阅了下（真没有细读，下面的吐槽不一定对），于是有些想法，借着这个机会吐下槽，只代表我个人观点，可能有些偏颇。
近一年来一直在看代码，改代码，中间有很多喜悦，也有很多痛苦不足为外人道也。我有时也在思考我们需要什么样的源代码分析文字。
以前读侯捷的《STL源码剖析》，一直笃信书的后封皮上写的“源码之前，了无秘密”，于是看了很多源码。分析到最后给我的感受是，源码不一定要行行俱到，
理论与代码要结合，故如《追踪Linux TCP/IP代码运行》这样的纯贴代码加少量分析的书是很让人生厌，并且头疼的。
多年的经验告诉我，“工欲善其事必先利其器”，故找到好的并适合自己的工具就显得很有必要。个人推荐Source Insight、Doxygen、Understand等多种工具，覆盖阅读，分析，画图，总结等各个环节，这些工具的应用能够让你读代码快速而充分。
工具是为了更好的分析，即然是分析源码，就要有相关计算机的基础知识，设计数据结构、算法、编程语言（各种奇技淫巧）等等。
计算机中有个著名的论断“数据结构+算法 =
程序”，在C++标准库中，标准模板库（STL）的六大概念都是围绕着这个等式来的。在这背后，最重要的是抽象。应该说抽象是计算机各种理论（编程语言、
数据结构等）的基础。能够将一段程序的思想剥离并抽象出来是需要很强的能力的，将一段程序讲得生动更是不容易的一件事情。代码的实现是多种多样的，但是思
想是活的，能够运用思想是种能力的体现。
读源码，首先的是找出核心的数据结构。数据结构的定义与你要完成的功能、算法是息息相关的，所以是最大的抽象，最能体现能力的地方。算法无论最终的结果如何，都会转换到无非是对数据结构的操作，最终都会转换到查找、排序、链表或数组（哈希）的增删查找等操作。
所以，核心数据的结构的表示很重要，在计算机领域用得最多的是面向对象的UML类图。计算机领域发明了UML这样的描述工具也就是为了更好的描述抽象的思想。传统如流程图、数据流图等，这些工具类似于英语成为通用的交流语言，所以分析代码这样简介的图或许是必须的。
分析数据结构的各个域，了解其抽象的含义，其实就是将基本原理娓娓道来的好机会，毕竟原理是原理，需要映射到代码中。
数据结构的分析是静态的分析，数据结构的设计是为了使用，为了生成数据（“数据为王”的时代！），这时我们就要关注变量，变量的何时生成，何时销毁，何时
变化，有哪些操作接口。在这个分析中，需要从全局变量着手。全局变量与全局变量的之间的关系，全局变量的数据流。找出核心的处理过程。这个可以用流程图来
表示，调用关系等标识。
在这个过程中，你需要静态与动态的结合，有时你还需要补充些理论知识（如IA32架构、文件系统等）能够让你理解代码事半功倍。
但是很可惜本书中并没有类似的分析，本书给我最大的感受是类似于实验报告，顺着代码往下走，走不通了，再找些理论知识补补，看哪里可以继续读下去。然后一
切都为这个服务。后面最多加个无关痛痒的总结。这个过程你可以按照作者的思路阅读代码，但是他没法给你那种“原来如此”的感觉，这个要靠你自己去悟。
全书我都没有看到代码的总体框架图，类似于TCP分层一样的图。有的只是硬盘内存这样的设备（形象倒是形象，但是我觉得抽象更重要些）。比如已经有那么多文件系统分析的资料，其实完全可以吸收引用过来，没有必要闭门造车。
对于作者引以为豪的最后一章提出“主奴机制”，英文就是“Master——Slaver”，我接触过的文章中，更多的是翻译为“主从机制”，相应的设备叫“主设备”“从设备”。
书的最后，说恭喜阅读到最后，还建议我们多读几遍，也就是说我们还得重复作者走过的道路。
总之，本书最大的问题在于只是记录了分析源码的过程，但是缺少必要的反刍消化，全局性的框架没有建立起来，而把问题留给了读者。