经常听到有人说微软的技术变化太快,持续性不好,让程序员追得很累。这种观点在微软技术社区内部和外部都有出现,似乎是一个不争的事实。但从我追随.NET平台这近十年的时间里,我并没有明显的感觉。微软的技术的确很多,但至少在.NET领域过渡性做的非常好,我没有任何疲惫之感。微软技术开拓了我的眼界,让我在微软内外许多技术方面越来越少有"新奇"的感觉,一切都是那么自然和稳妥。我现在就来仔细谈谈我在学习微软技术方面的经验与感受。

　　我一直对编程有浓厚的兴趣,上大学前在编程方面的经验主要来自于信息学竞赛,此外就是用一些VB或是Delphi写一些小程序,拿去参加高中的一些名不见经传的小比赛,那点小名次,小打小闹,仅此而已。到了大学里,学习(或自学)了Java,少许LISP,数据结构与算法,操作系统,计算机体系结构,计算机网络,编译原理等最传统的科班课程,但似乎学的不太好,现在想来颇是后悔。此外学过几次C ,但智商有限,几次下来都没有坚持到底,现在也忘得差不多了。可以这么说,我的专业程序员生涯的成长离不开微软与.NET。当然,我热爱各种技术,各方面也学习了很多。我接下来也会说到,技术本就不应该分为"微软"与"非微软"两个部分。

　　我在大学的时候学习和使用的是Java,也用Java参与了一些奇怪的"企业项目"--如上海海关进出口检疫局的什么什么系统(不过那时候我也已经开始接触C# 1.0和.NET了)。后来由于去了微软,自然全面转向.NET。我在微软只待了一年半,但这一年半给我最大的帮助就是让我开阔了眼界,知道技术领域有多么广阔,知道学校里了解的一些东西是多么的不靠谱。可以说在微软的这段时间对我来说是个突破,从那时起我就对各种技术都抱有强烈的兴趣。

　　有人说微软技术发展太快,且时常淘汰很多东西,对此我并不赞同太多。我接触到的说微软技术变化太快的同学,大都是老程序员,他们因为微软将重心放在了.NET上,导致了COM等技术运用场景减少,于是颇为不满。他们时不时"预言"微软以后会抛下.NET,虽然.NET已经发展了近10年,且力度越来越大,所以我称这种"预言"是一种FUD。我是从.NET 1.x/C# 1.0学起的,一直到现在,无论是语言还是基础类库,一切都良好过渡。您在C# 1.0里学到的东西,有哪些在C# 4.0里消失了么?您写的ASP.NET 2.0程序,直接无痛升级到ASP.NET 3.5--这是大众点评网的架构师在分享会上提到的,它的应用规模及复杂度不低于您的项目吧?微软是个对企业应用有许多投入的公司,在过渡和兼容性方面必须做到几乎百分百的保证,这些经验也总结成册,例如获得Jolt大奖的《Framework Design Guildline》,其中不断强调的一点,就是在设计时对兼容性方面的考虑。

　　在兼容性方面,某些技术领域的程序员就有更高的"觉悟"。例如Python 3.0成为了一门不兼容Python 2.x的语言,Rails 3.0也不兼容Rails 2.x。我咨询过几个Rails程序员对此的看法,他们观点十分一致,那就是对Rails 3.0很有好感,至于以前的项目,"没有必要从2.x升级到3.0啊!"。我也支持他们的看法,如果您不喜欢C#里的新特性,那就不用那些特性。如果您不喜欢新框架的功能,那就继续用原来的方式做事情,新的框架也不会对您有影响。我支持Python和Rails项目发展的决定,他们为了前进抛下一些历史包袱,我可以理解。这并不会影响我对Python和Rails的喜爱,它们依然是十分优秀的语言和框架。

　　有人说,微软会淘汰技术,那么对这些技术的投资不就失效了吗?这方面我认为自己有很好的发言权。我之前也提到过,我在社区里的"声望"是靠ASP.NET AJAX积累起来的。但是现在ASP.NET AJAX似乎慢慢地淡出了人们的视线,那么我的投资失败了吗?完全没有,确切地说简直太成功了。ASP.NET AJAX覆盖了浏览器端的JavaScript开发,以及后台对ASP.NET WebForms页面模型的扩展,当然,还包括两者的交互。我一直认为UpdatePanel是前后端交互的经典之作,它通过在前端页面的hook,以及对后端WebForm模型输出的捕获,做到了非常透明的AJAX效果,只可惜由于项目分工,前端开发人员大都喜欢手写的纯客户端模型,因此UpdatePanel不太受人待见。我读过了ASP.NET AJAX的前台代码,由此全方面了解了JavaScript语言和许多前端开发的技术和技巧。我读过了ASP.NET AJAX的后端代码,由此我了解了一个JSON序列化框架可以如何实现出来,体会到了ASP.NET及其WebForms模型丰富灵活的内涵。从ASP.NET AJAX开始,我可以自豪地认为自己"精通"了ASP.NET,对它各方面的扩展可谓如鱼得水。例如,我可以轻易写出一个UpdatePanel上传文件,或是ASP.NET MVC中UpdatePanel的原型,虽不至于成为一个通用的组件及解决方案,但是对于自己项目本身已完全够用(我几乎没有纯"玩闹"而写的扩展,都是源自于项目本身)。后来微软出了ASP.NET MVC,我花两天时间扫视一遍它的源代码,也已经基本掌握了它的原理,使用方式,扩展也罢,一切都那么顺其自然。例如Rails是个优秀的Web框架,包含许多对实际生产非常有效率的特性,但是我在看了这些特性的使用方式之后,几乎都可以立即想象出它在ASP.NET里的实现方式,就例如表现层的片段缓存那样。

　　我一直强调,我并不了解所有的.NET相关的框架,但就我所了解的.NET技术而言,它们都有这样的特征:过渡性很好,自然地,有底蕴的发展。就拿C#来说,C# 1.0中创造了"委托"这个函数的一等公民类型,而在C# 2.0里引入了匿名方法,C# 3.0里强化了函数式编程的理念,成就了这一到目前为止最为经典的C#语言。C# 3.0中引入了Monadic的LINQ语法,几年下来基于LINQ发展了太多太多,如PDC 09中的LINQ to Observable,PDC 10上的LINQ to Azure。社区里如围绕NHiberante的贡献更是数不胜数。微软技术在我看来是十分领先的,这个领先并不一定指它在计算机科学上的创新和突破,而是指它对于这些经典理念与工业生产相结合方面的超前。可能它不如某些朋友心目中LISP那般博大精深,但可以说更直接地在让我在实际生产中体会到了经典的魅力。

　　这样的"领先"给我带来了许多乐趣,也让我慢慢难以从其他技术上感到"惊喜"。例如,一个Java程序员转到Python以后,会感觉生产力有了显著的提高,但就我来说,相当部分的生产力在C#中都有体现,我不会以为生产力低下是"静态语言"的关系。同样,我最近在关注iOS及Mac OS方面的应用程序开发,接触了一些Objective-C,发现它的block就相当于.NET中的委托,而在09年随Snow Leopard引入的block的支持语法早在C# 2.0中就由"匿名方法"特性实现了,更不说C# 3.0在这方面有更进一步的发展。同样,我阅读了GCD(Grand Central Dispatch)的文档之后,发现它和.NET 4.0中的TPL(Task Parallel Library,任务并行库)解决的是相同的问题,其实现思路也有许多相同之处,例如都是主要通过描述"任务"(如任务内容及依赖关系)来避免程序员直接使用线程,避免复杂的同步问题,并由系统来负责对任务的调度。有时在推特上,我时常可以看到一些Cocoa的开发者津津乐道于block及GCD对于并行开发所带来的诸多便利--于是我想,这个早已不该是新闻了嘛。我现在还知道未来C#还会在这方面有更多便利,它在Anders Hejlsberg的带领下再一次走到了领先的位置。

　　微软的技术大都容易入门,但这并不影响这些技术深厚的底蕴,您在学习时应该了解这种底蕴。例如,您在学习C#时,不应该只关注它的表面特性,而要知道"为什么Anders会设计这样的特性"。我认为,一个优秀的C#程序员应该对函数式编程有一定程度的理解。当您学习Reacive Framework时,应该顺便去了解一下响应式编程。同样,我看到社区里有一些关于TPL的文章,但认为它们还是没有把握到精髓。事实上这些精髓都不是秘密,微软对各种原理几乎都不做保留。例如微软免费提供了《Patterns for Parallel Programming》等资料,详细解释了并行编程中的诸多模式,以及它们在TPL(C#与VB)或是F#中的实现方式,这些都体现了微软在设计这些语言或类库时的思路。微软在构建这些技术的时候并非无中生有,都是事先设计好使用场景的。例如用Task应对任务并行,用PLINQ应对数据并行,毫不草率,堪称经典。此外,TPL的设计者Joe Duffy是业界大牛,他写过一本《Concurrent Programming on Windows》,描述了大量关于TPL的实现细节,例如无锁数据结构的编写方式,Work Stealing,如何改善局部性等等。您了解了这些内容以后,我想GCD对您来说可能也只是换套API而已,应该也不算是件难事儿。我一直认为,就算微软明天给外星人一锅端了,我也能很快进入其他技术领域,并很快达到较高级的程度。但是,如果您每次都只了解一些表面,自然很容易觉得天崩地裂。盲目追赶,那也只是恶性循环而已。

　　我一直强调"眼界",微软技术不断为我打开新视野,这些技术的设计者都在各种场合提到其他技术对他们的影响。因此,学习了C#和F#,我对于Python,Ruby,Scala,Haskell都产生了浓厚的兴趣,我不会像许多Java程序员认为Java语言已经足够了,或是像许多Ruby程序员那样认为自己领先于其他程序员,我能时刻保持Keep Stupid,Keep Hungry。我时常不解一些技术人员在我看来莫名其妙的轻视(不是"敌视")微软技术,我认为技术的大千世界何其美好。因此,即便我再是厌恶Java语言,也对JVM和其生态环境敬爱有加。于是,我通过《CLR via C#》对.NET运行时浅尝辄止之后,又通过《Oracle JRockit: The Definitive Guide》深入了解JVM的虚拟机世界。我看过了《Concurrent Programming on Windows》之后,又去阅读了作者推荐的《Java Concurrency in Practice》。

　　如果眼界没有打开,即便您学习的是业界"最先进"的技术,也可能产生偏差。例如时常看到Rails开发人员自豪地说,他们可以从Rails里学习RESTful。由于前段时间我刚巧看了《RESTful in Practice》一书,再结合我对Rails的了解,我实在没有感到这个Web框架在RESTful方法的独到之处。于是他们让我去看Rails 3.0里强大的Routing功能。我看后,才意识到其实他们似乎对于REST的理解有所偏差--REST的精髓在于由Hypermedia驱动的State Transfer,而形如"/article/20"这样的URL,以及映射一些HTTP方法等等,其实远非RESTful架构设计里的关键。RESTful只是要求"每个资源对于一个URI",但并没有规定URI的形式,而且如果客户端直接了解服务器端的URL规格并直接访问,就与REST的"解耦"目标渐行渐远了。事实上,《RESTful in Pratice》一书甚至有建议对URL做些混淆。总体而言,Rails只是对REST架构中的一小部分提供了较好的支持而已,还远不能"从Rails学习REST"。昨天晚上我和REST专家李琨老师谈了我在这方面的理解,他基本赞同我的看法。我庆幸不已,要知道在此之前我还看过《RESTful .NET》一书,但我走向《RESTful in Practice》之后,才意识到前者给我带来了不少错误的观念。幸好,我并没有良好的自我感觉,也没有满足于现状。

　　如果您学习的是.NET,那么打开眼界的一个有效工具便是Mono。Mono及Miguel de Icaza已经不再拘泥于跨平台的.NET这个目标,而是努力在其之上实现大量的开源或商业产品。其中的典型便是MonoTouch和MonoDriod让.NET及C#进入iOS和Android平台,广受喜爱,也已经有越来越多的成功案例。此外,Mono对于开发原生Mac OS应用程序的支持也步入了正轨。我作为一个.NET开发人员,从没有过如此兴奋的感觉。

　　如果您正确地学习了.NET技术,您会发现自己走上了一条良性发展的道路。从另一方面来讲,微软的技术固然多,但作为开发人员我们并不需要了解每项技术。微软在创建一门新的技术的时候,都会讲清楚这门技术所解决的问题是什么,如果与您无关,完全可以不去学习。例如.NET 2.0与3.5之间还有一个3.0,其中提供了WPF,WF和WCF三个框架。我可以坦率地讲,我对它们没有任何了解,但这丝毫不影响我自称是一个优秀.NET技术人员的自信。很多时候,如"疲于追赶"这种事情,我觉得太多程度上都是自寻烦恼了。这样"无中生有"的烦恼还有很多,例如微软给出F#以后,就有人说微软要抛弃C#了。您为什么就不能认为这是一种互补,或者说,给您多了一种选择呢?微软同时发展VB.NET和C#语言好多年了,您一直没有学习VB.NET的烦恼,为什么现在多了一个F#,您又动摇了呢?还有例如近日的Silverlight问题,前篇文章已有详述,不提。

　　许多人会持有这样的观念:整个技术领域分割为"微软"和"非微软"两部分,然后指责"微软"技术不如"非微软"来的丰富。在我看来这种分割方式是十分可笑的,怎么没有人将技术分为"Ruby"和"非Ruby",然后指责"Ruby"技术不够丰富呢?此外,还有一些观点,认为ASP.NET应用程序靠memcached提高伸缩性是种失败,这也是同样的割裂逻辑。为什么PHP和Rails使用memcached就被视为正当手段呢?说起来,memcached是C语言写的,还真不关PHP和Rails什么事情呢。

　　而且,正如我之前说的,微软技术对我的重要价值之一,便是促进了我对各方面技术的浓厚兴趣。无论您是专攻哪种技术的开发人员,如果只是停留在自己这一亩三分地上,这都是不甚可取的。没有人限制微软系的技术人员从其他领域吸取经验,正如一个优秀Ruby程序员肯定也从Ruby外的技术领域吸收了大量精华。说实话,除了政治需要,我实在找不到将微软和开源社区(或是其他社区)对立起来的理由。事实上,我时常感觉,您即便工作于.NET的竞争性平台,学习.NET对于个人提高来说也是大有帮助的。

　　就写到这里吧。希望对您了解微软技术,以及如何学习微软技术能够有所帮助。

　　原文地址:http://blog.zhaojie.me/2010/11/silverlight-and-mi c rosoft-technology-2-microsoft-technology-and-how-t o -learn.html