（转载）答复：我不会OOO，仍然可以XXX

出处：http://blog.csdn.net/absurd

按照《审死官》里的读法，标题可以读着：答复：我不会圈圈圈，仍然可以叉叉叉。圈圈叉叉并不特指某个东西，而是一个通配符。代表诸如：我不懂 COM 原理，仍然调用 COM 组件。我不懂数据结构，仍然可以写程序。我记不得常用 API ，仍然照样用 IDE 。如此等等。

 

我 是个爱好和平的人，不喜欢和别人口诛笔伐，几乎从来没有写过主动攻击别人的文章。亚里斯多德说，我爱更老师，更爱真理。让我套用为，我爱和平，更爱真理。 若只是为了一已之私利，我不会写这篇文章的。这里阐明一些个人认为正确的观点，想和所有有兴趣的朋友讨论一下。但就事论事，不要进行人身攻击，没有必要引 发一场口水战。

 

那 些朋友说的也是事实，这不懂某些知识，确实仍然可以做相关的工作。这让我想起一个小故事：记得上大二时，认识了一位开家电维修店的教授，我想跟他学电器维 修。他同意了，条件是要我坚持看两年时间的电路图。我找了一本长虹电视机的电路图，看了几天，发现太难了，两周过去了，一个也没看明白。

 

我 找到那位教授，说，为什么要看电路图，小学生连欧姆都不知道是什么，更别说看懂电路图了，他们为什么也可以修家电？你不想教我就算了，干嘛要让我看两年时 间的电路图。教授回答说，小学生能和教授相比吗？对小学生来说，书上有的案例，他可以修，与案例有一点差别，他就摸不着头脑了。而教授，对电器里面电路清 清楚楚，不管是哪里坏了，什么现象，把几个关键点的电压电流一量，就找到问题的根源了。

 

用 Window 当然不需要了解操作系统原理，用浏览器当然不需要明白文档对象模型，把 excel 嵌入到 word 里也不需要知道 OLE ，用 PhotoShop 的人不需要熟悉图形学，用 VS 2005 的人不需要精通编译原理。这没有错，对用户而言，他们不需要知道他们不必知道的东西，这是用户友好性，值得提倡。而作为一个软件工程师，你应该明白操作系统原理，应该了解编译原理，应该熟悉相关的东西。

 

我不想说别人浮躁，我自己也很浮躁，说别人浮躁只是五十步笑百步而已，这个年头谁不浮躁呢 ? 但从实用的观点来说，不知道某些知识，并不值得引以自豪。理论有没有用，要不要弄清楚某个原理，要不要记住最常用的 API 。这都是仁者见仁，智者见智的问题。后面列举一些的个人经验，合则取之。

 

从 毕业后到现在，我一直带在身边的书，只有一本数据结构。前前后后，为了学习的目的，我把里面大部分数据结构和算法写过三遍，这还不包括工作中零零散散写过 的。开始是只是为了熟悉其原理，后来开始想怎么把代码写得更优雅一点，组织得更合理一些。这反反复复耗了我大量业余时间，事实证明这些时间没有白费。后来 的经验告诉我，差不多所有程序，都是由这些基本算法和数据结构组合起来的。对这些基本算法和数据结构掌握得比较扎实，不但自己写程序可以更快，阅读别人的 程序也更容易。如果你还坚持说，不懂数据结构仍然可以写程序。我会说，你永远没有别人写得快，没有别人写得好，程序没有别人的快，没有别人的稳定。

 

后 来我又花了不少时间去学习设计模式。设计模式不是时髦，而是实用的东西，绝不止几个概念而已。我不但认真的读完了那本书，为了实践，总是找机会去用它们， 那怕只是自己写个小程序，也不忘与设计模式挂钩。现在再看那些程序，或许有些丑陋，但正是那些练习让我熟练的掌握了设计模式。如今我再也不会动则就用设计 模式了，因为我知道了什么地方该用，什么地方不该用。回想起来，设计模式在很多地方它帮我的大忙。如果你还在说，不懂设计模式，仍然可以写程序了。我只能 替你感到惋惜，这么好的东西，你却固执的视而不见。

 

以前公司一个产品是基于 Apache 的，我只是负责维护 mod_proxy 模块。我的任务是修改它，让它支持 HTTPS 。不去研究 apache 的架构，不去阅读其它部分的代码，我仍然可以完成的这个任务。但我利用大量业余时间去研究 apache 的架构，去阅读 HTTP 协议，我明白了它的并发模式，明白了它的配置机制，明白了它的模块加载机制，明白了它的 LOG 机制，明白了作为一个服务器的基本架构。这对于完成自己的任务是有帮助的，更重要的是从中学到的知识，对后来的工作也有帮助。刚到深圳时，在新一家公司，我的第一个任务是开发一个自动编译服务器，整个过程都是自动化的，还是支持多用户排队编译。与 apache 相比，这自然是小菜了，包括需求分析、设计编码和用户手册，不到十天时间就搞掂了。

 

有段时间我维护 html tidy ，那本是 w3 开发的一个小工具，功能是用来修复 HTML 网页中的错误，并输出到一个 XHTML 文件。它相当于一个 HTML 语言解析器，用到编译原理的知识。而我对编译原理了解不多，如果凑合着修改 BUG ， 问题也不大。我还是选择了学习编译原理，至少花了半年业余时间学习相关理论，自己又写了几个微型语言的解释器，感觉自己成半个编译原理专家。我发现这些知 识非常有用，特别是状态机，对于字符串处理非常方便。又利用编译原理写过一些代码产生器，用它们来产生那些类似而又不同的代码，为我节省了大量的时间。如 果当初我固执的认为理论没有用，一定错过了这样一件强大的武器，那是多么可惜的事情啊。

 

我维护过一个 XMLTransformer ，它的功能是调用 xerces 的函数把 XML 和 XSLT 文件解析成 DOMTree ，然后调用 xalan 的函数把这两颗 DOMTree 转换成一个 HTML 文件。其实只要知道 xerces 的接口，不明白 xerces 的内部工作机制，完全可以胜任自己的工作。我还是花了不少时间去研究 xerces 的代码，此时我还没有看过《设计模式》，看了 SAX 解析器的代码，我明白了 Builder 模式，后来屡试不爽，用这种方式，我写一个解析 apache 配置文件的模块，一个解析 INI 配置文件的模块，一个解析 XML 配置文件的模块，还有一个 LRC 歌词解析器。你看，时间没有白费吗。

 

有段时间老大让我去写 microwindow 的控件测试程序，我花了不少时间去研究 microwindow 的实现，明白了它消息机制，明白了各个控件的实现机制，记住了各个控件的风格、消息、通知，总结出它们的规律，写了一个通用的测试程序。不但提前完成了那个任务，这对于后来我用 win32 SDK 写程序帮助也很大。因为熟悉常用的控件和 API ，编程速度大为提高，出错几率也大为降低。

 

我也曾去研究过 Wine 的代码，主要是想知道 COM 的实现原理，这完全是为了满足我的好奇心。看似无关紧要的知识，也后来竟然派上了大用场。为了简化进程间通信机制，我们在一个嵌入式系统中，实现一套进程间通信机制，大大简化了进程间的过程调用，成为那个平台的基本架构之一。同样是因为兴趣，我研究了 gdb 和 ptrace 的实现，学习到的知识也在后来的工作中派上了用场。

 

还有很多这样的例子，说这些无意炫耀自己，我只想说明这样一个事实：书到用时方恨少。很多知识，知道比不知道好，知道了至少就多一种选择，甚至可能在你意想不到的时候派上用场。

 

作为程序员，固执的不去学习，或者因为门户之见而把自己限于一个小范围，个人认为不是明智之举。一句话，知道它们，我们可能做得更好，不知道它们，决不可能做得更好！