写在岁末年初

 

写在岁末年初<o:p></o:p>

<o:p> </o:p>

<st1:chsdate w:st="on" year="2006" month="12" day="1" islunardate="False" isrocdate="False">2006-12-1</st1:chsdate><o:p></o:p>

<o:p> </o:p>

       无意间，在外面做实际开发业已一年。记得那套进第一家公司前花了3个小时完成的面试题，记得那家公司的两个老板面试我的那三个小时，记得刚进那家公司在Linux下安装Bugzila和Open-XChenge熬过的那十来个深夜，记得第一次给同事们做的JUnit的培训……

       大学四年，浪掷千金藏得百余本纷繁庞杂的各类书籍，学识上略洗铅华。曾国藩可以把他还是贫寒学子时积聚的两箱诗书赠送对其芥蒂颇深的幕僚以示安抚，我自叹弗如。心态上或许更像余秋雨散文中守护天一阁的那个家族。这也是为何前老板一而再提出底价买下我所拥有且对公司有用书籍时，我内心中滋生异样的反感。

       大学四年，最真切的感受是，学习的效率和成果随着每个学期的过去而成指数级的向上串升。这样的感受对于并非才俊的我，自然意味着另一面的缺失——疏离的人际关系。上天是很公平的。

想起了最近网上沸沸扬扬的金旭亮与袁峰关于高等教育掀起的论战，我能理<st1:personname w:st="on" productid="解金旭亮">解金旭亮</st1:personname>老师的那恨铁不成钢的苦心。也赞同袁峰所说，要捍卫理论之根基。<st1:personname w:st="on" productid="金旭亮">金旭亮</st1:personname>老师的.NET相关著作确实很好。但他在博客中的言语，细想或许如反驳者说的那样，许多界定，诸如“好的代码”、“合格的程序员”，缺乏明确的量化和评估的标准。只是这么凭着一个大的方向，说这么走会让你成才！但具体如何成的才？成多大的才？代价是什么？都一概懵懂无畏。这样大而全而不细分得失的指导原则在我们生活中不在少数：一、去英语角可以提高英语水平。二、多和高年级的师兄接触可以更快学到更多的技术。三、参加学生会、当班长以后找工作可以更容易。四、考上大学将来能有更好的前途。这些都是抽象而诱惑的广泛传教。你我都不是荷兰赌徒，任何非理性的投入只会让你陷入更深的黑暗。换作经济学的术语讲，做任何事情都有它对你来讲独特的机会成本。你选择了去英语角，或许你就错过了在教室里上英语自习的时间，并且你还要冒着和你交流的对方前来的动机不纯，其口语很差等等潜在的风险。你和高年级的学生接触更多，你的机会成本可以是阅读书籍，自行解决技术问题的机会等。而且要冒着你接触的人其实业并不怎么样，彼此互相吹嘘而不着实务等危险。赘述如许，想表达的是，当我们在自己人生的选择上时，我们能否从更多的感性走向理性呢？引入一些商人般的精明与慎重。面临一个选择给出粗略的类似：重要\不重要，紧急\不紧急；SWOT分析之类的划分呢？或者更进一步的去评价一个个人动作所带来的利益与风险？

我能理<st1:personname w:st="on" productid="解金旭亮">解金旭亮</st1:personname>老师希望试图总结自己，给学生们提出一个学习的捷径，使他们少走弯路。但像.NET这样的技术在课堂里讲，难免使这样的教育偏向大专、高职化。在那样的课堂上就是只讲具体的技术，鲜有涉及艰深的理论。而对于我们这个把高等教育作为经济增长点的过渡，大量的学生扩招，学生素质的急剧下滑，致使出现了本科教育出来的计算机本科生常常抱怨还不如高职专科学生所学有用这样普遍的抱怨(联想起了某年国内甲A联赛出现的输球才能保级，赢球反而降级的情景)。在本科的课堂上详细讲授这些，无疑只是对学生授之以鱼，只能宣告是对学生自我求学能力缺失的妥协。

个人感悟上，以为，当以实务为然！实务？什么是实务？实务是编译原理语法、语义、语用中的语用；实务是于渊大胆实践动手实现OS的情怀；实务是Don Box的书籍中每章最后的“我们到哪儿了”；实务是Rod Johnson从其从医的妻子那里得来的“循证架构”；实务是XP中“可执行的代码是最好的文档”；实务是Jim Gray、Anders Hejlsberg的人生轨迹所昭示的技术实践引领理论发展。

不断啃食卷帙浩繁的编程语言的语法书，不是实务。如果能看看从Robert Meyers掀起的Effective系列书籍，那么对于语法之上的语义或许就更能窥见一二。如果能把精力花些在语言本身的惯用法上，如C中的DCL、Ruby中的||、ML中的动态类型系统等等。再进一步即是在设计模式上的话，那么你离语用就不远了。在我目前的理解看来，OO给我们使用的构件并不多，而GoF的设计模式和从其衍生、创新出的众多模式都是对OO的语用总结。但依然值得提防的是，一味守着23种设计模式的照本宣科、滥制书籍，这也不是实务！！！不论是在这个行业，还是在更广泛的意义上，不要迷信。此外，再就是不破不立。

理论与实践，这是任何人都会高谈阔论的辩证二重奏。高校的授课体系，如今被千夫所指，且不管这千夫中有几人理性平和，有几人籍此宣泄。其自身的原因，还是因为该体系太过于理论；授课的讲师没有充足的能力驾驭；没能使学生认识到各个学科之间的必要乃至深刻的联系。从而造成学生看不到学习的理由。一个极端就是学生能很单独的学好每一个理论学科，但实践上，各学科之间的联系上却不能恭维。这似乎是象牙塔里搞学术研究的学究们的通病。正像Jim Gray所言，向B树这样在OS、DB实现上如此重要的数据结构但在世界范围内很少能看到相应对其实践进行详细描述的书籍，大多一带而过。这样的教材会使并不算聪颖的大多数学生（我自己也是 ：<）觉得没有质感！另一个极端则是因为课程的缺乏吸引而学生自身又希望能有所作为，他们会在实践中去追寻成就感。但糟糕的是酿成了厚此薄彼的重实践轻理论的思想。他们或许会在开发一个个重复类似的项目、学习一个个的编程语言、熟悉一个个的IDE的各个操作、使用一个个的编程框架时花费了太多的时间。他们缺失了那些表象下面的本真。抓住了那些快速变化的印象，这样的人做开发会很累，每天都可能要学新的“技术”。好比如今人人都吹Spring、Hibernate、Structs。人人都会说“要是在开发中加上Spring和Hibernate就很强了”。那好，强。那么到底强在哪些地方呢？用过Spring1.8吗？这样的甄别可足以过滤掉<st1:personname w:st="on" productid="东郭">东郭</st1:personname>先生们。但能不当东郭决不是终极目标，今天有Spring，明天可能有Summer。不理解IoC和AOP的本质，不理解程序语言自省的原理和相应Reflect概念，又谈何对Spring的深入认识和把握呢？这就好比使用满天飞的full-stack框架，但却未曾读过Martin Fowler的《企业应用架构模式》，那是一种致命的缺失。不知晓“工作单元”、“前端控制器”等独立于特定框架的深刻模式总结，那么在使用相应的框架上时，难免会显得有些心力单薄。说到程序语言，那么身处业界一线的Don Box呼吁的是大家能回头去看看SCIP这样鞭辟入里的课程。

在我个人的理论与实践的拔河中，我要感谢像《程序语言实践》、《事务处理》这样的跨越各个学科的书籍。不破不立！它们的自成体系的同时，在传统的各个学科之间牵起了“神奇”的联系！这是我们这类不够聪颖的学生多么如饥似渴的线索。它们能帮助我们真正建立自己完整的知识脉络。更重要的是在这些联系中，能够学到去发现联系的能力——一如授之以渔！

回到老话上，理论、实践皆不可偏废。做研究、搞开发犯不着相互鄙夷。向Jim Gray、Anders Hejlsberg这样的大师们看齐，那么学识成长之路，定会从然自若，无限未来可能。