梦想风暴

用一个月左右的时间读了《自己动手写操作系统》，这是一本让人读着很过瘾，却也特别累的一本书。

对操作系统的兴趣由来已久，只是一直未能找到入门之径。操作系统教材是个令人生畏的东西，它可以告诉人有什么，却不能告诉人为什么，从那里了解的操作系统有如盲人摸到的象，得到各个部分，却不能拥有整体，加之缺乏实践的支持，理论显得苍白空洞。如Linux般的开源操作系统，虽然可以让人坐拥全部源码，但一来规模庞大，让人不知从何入手，二来源码背后更多的是业务——操作系统和硬件知识，不了解业务的人很难凭一己之力破解源码的奥秘。客观如此，更重要的还是主观的不努力。

《自己动手写操作系统》则为如我一般挑剔的人打开了一扇门，从一点一滴的小处着手，一步步构建出一个简陋的操作系统雏形——Tinix，虽然它还不具备任何实际的价值，甚至算不上一只五脏俱全的麻雀，但对于想走近操作系统的人来说，这已经足够了，如果能够随着它一路走来，至少可以具备更进一步的基础，再去遨游广阔天地，便不会迷失于庞杂的理论与源码之中。

这本书的名字给人的提示是，它是一本以实践为基础的书，因此，阅读之初我便给自己定下了步步紧跟的策略。照着书敲代码也难免出错，再者书中有一些遗漏，只有对比光盘中提供的源码才能发现其中的细微之处，所以，常常是一段代码要花相当长的时间进行调试。实践证明，这种方法需要花费相当的精力，这也是我为什么会认为读这本书很累的原因。但是这种做法对于理解书中内容大有裨益。看明白，做一遍，调试，这是几个截然不同的境界。很多细节的东西，只有经过调试才能发现。即便是自己编写的代码，如果没有经过调试，恐怕也难说真正的理解。

作者在后记中写到，这本书最大的价值在于，它让操作系统的实现这个问题变得具备“可操作性”。正是因为这样，我才可以追随它一步步走来。在这点上，我读到第三章《保护模式》就已经体会颇深了。我曾经读过很多关于保护模式的内容，不过，由于缺乏实验，我只是了解一些概念，却不曾深刻体会。在第三章中，通过一个个简单的小例子，切换至保护模式，设置GDT和LDT，使用分页，中断处理等等书本上的概念活灵活现的展现在我的面前，那些艰涩的概念一下子便得再简单不过了。

市面上关于源码剖析的书很多，但是，即便像侯捷先生这样教育大家编写的《深入浅出MFC》、《STL源码剖析》大多数情况下也只是讲了怎么做，而无法说出为什么，原因很简单，这些书是站在旁观者的角度看问题，而很多问题只有开发者才是真正理解的。所以，这些源码剖析的书有其价值，但深度上还存在相当的欠缺。这本书的作者恰恰是站在了开发者的角度来讨论问题，所以，我们有机会看到了一个思考的过程，而不仅仅是一个结果。这一点从第六章《进程》中时钟中断处理程序的一步步进化便得以管中窥豹。

不得不提一下的是作者的写作功力，读过了许多生涩的技术书籍，这本读起来很舒服的书倒显得有些另类。它属于我心目中期盼的那种“形神兼备”的好书，正是作者相当不错的表达，才是这本书让人享受技术的同时又可以体味阅读的乐趣。当然，其中还是有些技术细节让人昏昏欲睡。

读书，首先要找到适合自己的书，这样我们才能从中有所收获，毕竟，技术书籍中很少能够找到满足所有层次需要的书。《自己动手写操作系统》的定位是一本入门书，显然，它不适合已经过了这个阶段的人，如果因此埋怨这本书档次太低，那就怪不得旁人，因为自己走错了路。

如果你和我一样，对操作系统有兴趣却不得门径，不妨《自己动手写操作系统》。

Tony：tony说设计-实践后的体会

Tony的这篇blog让我想起了自己两年前第一次真正扛起一个项目架构设计的时候，意气风发，一门心思琢磨如何做一个漂亮的架构。不过，翻遍了整篇blog，我没有找到我心中的设计第一要素：正确性。是的，正确性！

曾经的我就是一个为技术而技术的人，当一个项目启动的时候，我首先考虑的就是如何展现自己的功力，如何编写优雅的程序，而忽视了根本性的问题：需求。真正让一个软件产生价值的就是需求。少了需求，软件的意义也就荡然无存了。当一个人做事连自己的目标都搞不清楚的时候，不做错事，已经要感谢上天的眷顾了。没有正确的目标，其它的努力只是让自己在未卜之途上越走越远。有许多部影片为我们展示了邪恶科学家的威力，他们不是不努力，只是弄错了方向。

在设计中，功能性需求的意义要远远超过非功能性需求。非功能性需求多半是为了让自己未来的日子好过一点，少了非功能性的需求，大不了是自己不爽，周遭的同事们不爽，有些糊涂的家伙说不定还会心甘情愿忍受这种折磨。少个功能性的试试，用户不掏钱，老板会给你好看。当然，让自己和用户都满意是我们的最高目标，我们犯不着只顾用户而忽视了自我，再者，功能性的东西可能不会追随我们一生，而非功能性的则可以在日后的日子里让我们不断受益。

所谓设计，对个人而言，就是一个想明白怎么做的过程。如果只是在自娱自乐，想明白之后去做就是了。但是现在我们多半是与人合作，在这种情况下，设计是一个合同。既然要做一个设计师，我们必须考虑如何为别人（这个别人有时包括了自己）分配任务，这时候，我们就用合同——设计规定了双方的权力和义务，这样，在出错的时候，我们才能根据合同找到对应负责人。由此说来，契约式设计（Design by Contract）就是一件顺理成章的事了。设计就是分工，分工的目的就是为了各司其责，不明确的设计也就意味着责任不能对应到人身上。只要设计上存在盲点，我们就有机会遭遇互相推诿。Grady Booch曾经举过一个狗窝和大厦的例子，其实这就是没规矩和有章法的差异。我们通常所说的设计，多半是这种有规矩的设计，为了与人协作的设计。

在我看来，谈到设计，最好的设计标准还是那条经典的“高内聚，低耦合”。了解了这么多的设计手法，体会那么多的设计原则，到最后，基本上都能归结到这条标准上来。设计的过程是一个分分合合的过程，先是把系统分拆，再把功能相近的东西合并，这样就形成了一个模块，有人叫服务、子系统、类、组件、函数、方面……，都是一回事。设计者需要考虑的就是让怎么去做这个游戏，以便让各人能够独立工作而不致于相互影响，这就需要请出“高内聚，低耦合”作为衡量标准。模块之间的合同就是我们常说的“接口”，它可能是函数调用，可能是参数传递，可能是共享数据，也可能是远程调用。总之，有了合同好办事，谁的问题谁负责。
   
Tony有一点说得很好，设计是一种权衡的艺术，只有在不断学习实践中才能培养这种权衡的感觉。不要怕犯错误，只要实现了功能就是对的，设计是一种“只有更好，没有最好”的东西。大多数做设计的人是在为公司服务，这就决定了你想犯大错误都不现实，既然公司为我们提供了这么好的锻炼机会，我们不妨充分利用这些机会，让自己的设计水平不断提升，毕竟本事才是自己的。

关于设计，胡扯了很多，到此为止吧！

刚刚拜读了开复先生的《做最好的自己》，趁着脑中尚存余温，我写下了下面的文字。

我是一个书虫，不愿意让任何好书与自己擦肩而过，加之开复先生在我心目中一贯的良师形象，使得《做最好的自己》成了我当然之选。在我看来，一本好书的价值并不仅仅在于阅读过程的片刻愉悦，更是为人打开一扇通往新世界的大门。在这一点上，《做最好的自己》没有辜负我的厚望。

书中，开复先生提出了“成功同心圆”，即以正确的价值观为核心，辅以积极、同理心、自信、自省、勇气、胸怀六种重要的人生态度作为同心圆的第二层，再以追寻理想、发现兴趣、有效执行、努力学习、人际交流、合作沟六种行为方式通构成同心圆的最外一环。

这本书大多的观点在开复老师先前的文章中已有阐述，对于拜读过那些文章的我来说，这本书并没有太多全新的观点。但这本书的价值就在于，将所有散落于各处的观点系统化，汇集成册，让人一次领略，就如同转瞬之间遍览名山大川一般，痛快！

在阅读过程中，我总会情不自禁用自身与之对比，不经意间，便成就了一次心灵的洗礼。对我而言，这是一次很好的自省，让我对自己的优势与不足有了一个相对清醒的认识，也让我得以重视自己曾经忽略的一些东西。课前的预习可以让人更好的理解老师所讲的内容，同样，仅仅被动接受一本书带给你的内容并意味可以深刻的理解。一本好书，不同的人品味，感受差之甚远。工作的几年，我学会了思考，而这本书上的内容恰好是我近一年多时间里思考的问题，许多道理都是付出相当的代价才得以悟出，无意间的预习让我从阅读中得到了更多的震动。虽然感叹开复先生没有早点完成此书，但转念，即便那时我读到此书，没有一些刻骨铭心的东西，对于开复先生的箴言，我不可能有今天这样的体会。

良师益友对一个人的成长大有助益，但良师益友却可遇不可求，良师尤为如此。可称之为良师的人，大多是在某一领域经验丰富且善于思考者，如此才能高屋建瓴为人指出明路。虽然不遇良师并不妨碍继续前行，但良师的催化作用，可以让人少走许多弯路，加速成长。开复先生便是一位良师，《做最好的自己》算得上这位良师悉心打造的一本好教材，通过它，虽不曾与开复先生谋面，却不妨碍与先生神交，听着先生将一些道理娓娓道来，辅以一个个真实的故事，乐在其中。

尽信书不如无书，简单的照搬书中建议恐怕也不是开复先生希望看到的，毕竟，每个人都有自己的精彩。再好的一本书也不会让人读罢便脱胎换骨，成就一番大事业，它给人带来更多的是一些可以指导我们未来学习工作生活的原则，和一些对待问题的思考方法。

作为一名读者，我感谢开复先生带来了《做最好的自己》。

周末，和一个朋友聊天，谈到了现在有不少软件做得都差强人意，尤其是所谓企业级的产品。在我看来，首先是这些软件并不要求做得那么好，它们只是所谓的赢利工具，我们知道80/20原则，20%的精力就可以赚到80%的钱，何苦再去花剩余80%去争取20%的钱呢？而且，也许操作复杂，也许维护困难，那不正是所谓的“专业人士”一展身手的地方吗？在功利性不那么强的开源领域，通常产品质量要好出许多。我的朋友强调，他做东西目标在于“good enough”，而我做东西的态度则是“尽可能的好”，我不能因为观点不同就轻易否定了他，但我想他似乎忘记了，念书的时候，凡是以及格为目标的同学总是徘徊于补考/重修的边缘，而如果以满分为目标，尽管通常无法到达，但至少可以轻松跳过那条生命线，当然那需要更多的付出。

再有很重要的一点是，自己通常不是自己的客户。我们只是开发者，写出来的程序是给别人用的。我们都听说过这样的说法，如果想做好一个领域的软件，那就要成为一个领域的行业专家。如果不了解这个行业，不在一个真实的环境下亲自使用自己的软件，我们怎么会知道自己写出来的软件是否真得满足人家的需要。回想一下自己的计算机历史吧！总会有那么几个软件让脏话有一种破口而出的冲动。由此我们可以推断，其作者要么干脆很少用这个软件，要么就是一个逆来顺受的家伙。如果不经常使用自己的软件，我们不可能知道那种真实的感受，我们可以拼命的站在别人的角度考虑问题，但那与成为那样的人毕竟有差别，饱汉子怎知饿汉子饥。

孟岩写了一篇文章，探讨了国内公司技术创业的问题，主要是说，这些人选择的方向大多是技术的方向，比如架构、比如组件。且不以英雄论成败，很多时候，技术不是决定性因素。套到这个话题上，他们的选择还是不错的，因为他们本身是做技术的，选择业务作为自己的“行业”，当然，也就是让自己成为了自己的用户，因此，他们可以在自己的日常工作中，时时刻刻的与自己的产品打交道，细微之处，自然可以有深刻的体会。至于能否再上层楼，那是态度和能力的问题了。

其实，程序员除了拥有程序员的身份之外，还有一个很重要的身份——计算机用户。对于我们来说，这可能是仅有的两个不需要我们学习额外“行业”知识的领域了。从这个角度来说，Microsoft、Google、Borland等公司的程序员相对许多程序员要幸福许多，因为他们不需要付出更多的努力就已经是“行业专家”了，这或许是这些公司比较吸引人的又一点原因吧！他们只需要扮演好自己的应该扮演的角色，并不断做得更好。

《Joel说软件》中的第三十篇《在这个国家狗是干什么的》讨论一个类似的话题。当然，如果压根不想做得更好，那就领当别论了。

2004年，Rod Johnson写了一本《Expert One-on-One J2EE Development without EJB》，掀起了一阵反思的浪潮，让软件开发开始从迷信的浮躁中回归。与朋友们戏言，Rod是优秀的一个愤青，他毫不留情指出EJB存在的种种问题，让深受其害的人们大呼过瘾，我之所以给他扣上一顶“优秀”的帽子，是因为他不仅挑毛病，更能有针对性给出解决方案，这就是Spring。在Spring 1.0发布之前，我便已经开始在项目中使用。初时，它在我眼中只是一个辅助软件构造的工具。随着Spring一路走来，实践让我对它越发了解。对我而言，Spring让我对软件开发的理解上了一个层次，也让我越发看清它背后那张宏伟的蓝图。所以，Without EJB中的种种论述，与我心有戚戚焉。

现在看来，Rod带来的不仅仅是技术上的变革，更带来了一种置疑的思潮，那些希望再进一步的人们开始审视自己以往的心路历程，这不，Bruce Tate干脆开始置疑Java，喊出了“Beyond Java”。

Ruby on Rails的开发经历给了他一些思考。在他看来，在Java中，复杂的企业问题也许更容易解决，但是最简单的问题正变得难于解决，而且在Java之外出现了一些有趣的革新，所以，他冀望于让眼光超越Java。顺便说一下，这让我想起了Perl哲学中的一条，“易者易为，难者可为”。

开始思考总是好的，不认识到问题何谈解决问题呢！不过，Bruce干得可没有Rod那样漂亮，他只是把问题提了出来，却没有给出一个完整的解决方案。不过，想来也是，Java庞大的根基可不是轻易可以动摇的，所以，Bruce用的是“beyond”，而不像Rod那样大胆的使用了“without”。

TSS上的大讨论有一个观点很好，“IT进步是演化（evolution）而非革命（revolution）”。进步总是一点一滴积累起来的，认识到问题，改进它，这就是进步，由此看来，Bruce工作的意义并不在于喊出了一个新口号，而是开启了人们对Java现状反思的大门。

仔细观察，我们不难发现，每个年代所谓的主流在带来革新思想之外，还能够提供很好向后兼容：C语言可以与汇编代码很好的融合，C++则完全兼容C语言，Java则通过native接口与C/C++有很好的结合。语言在语法方面的进步只是让编程更容易，真正让语言立足的是广泛存在的程序库，Java之所以可以迅速推广，JDK做了非常好的助推剂。与原主流语言的兼容则可以让新语言在自己尚未健全之前，可以很好借助于原主流起跑，吸引那些原主流语言的用户。从这一点上来看，Groovy是一个很好的承袭了这种模式，直接利用Java现有的库，让它拥有了一个相当不错的起点。

不过，好的东西并不一定成功。很多时候，一些好东西带来的是思想的变革，结果常常是太过超前的思想让人们难于接受，人们最熟悉的例子应该算是虚拟机，Java只是在一个恰当的时候，把从前一个很好的思想拿了过来而已。

普通程序员，与先行者之间还有相当的差距，而一些人总是不愿意让别人动自己的奶酪，结果我们就可以看到一场场精彩的论战，当然敢于置疑Java的Bruce也是难免一战的。

关于技术的选择，我在之前的一篇blog中给出了我的标准，很简单，就是舒服。

TheServerSide的评论
http://www.theserverside.com/news/thread.tss?thread_id=37121

IT Observer的评论
http://www.ebcvg.com/press.php?id=1761

Beyond Java书籍介绍
http://www.oreilly.com/catalog/beyondjava/index.html