经常听到有人说微软的技术变化太快持续性不好让程序员追得很累。这种观点在微软技术社区内部和外部都有出现似乎是一个不争的事实。但从我追随.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 ObservablePDC 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在这方面有更进一步的发展。同样我阅读了GCDGrand Central Dispatch的文档之后发现它和.NET 4.0中的TPLTask Parallel Library任务并行库解决的是相同的问题其实现思路也有许多相同之处例如都是主要通过描述“任务”如任务内容及依赖关系来避免程序员直接使用线程避免复杂的同步问题并由系统来负责对任务的调度。有时在推特上我时常可以看到一些Cocoa的开发者津津乐道于block及GCD对于并行开发所带来的诸多便利——于是我想这个早已不该是新闻了嘛。我现在还知道未来C#还会在这方面有更多便利它在Anders Hejlsberg的带领下再一次走到了领先的位置。微软的技术大都容易入门但这并不影响这些技术深厚的底蕴您在学习时应该了解这种底蕴。例如您在学习C#时不应该只关注它的表面特性而要知道“为什么Anders会设计这样的特性”。我认为一个优秀的C#程序员应该对函数式编程有一定程度的理解。当您学习Reacive Framework时应该顺便去了解一下响应式编程。同样我看到社区里有一些关于TPL的文章但认为它们还是没有把握到精髓。事实上这些精髓都不是秘密微软对各种原理几乎都不做保留。例如微软免费提供了《Patterns for Parallel Programming》等资料详细解释了并行编程中的诸多模式以及它们在TPLC#与VB或是F#中的实现方式这些都体现了微软在设计这些语言或类库时的思路。微软在构建这些技术的时候并非无中生有都是事先设计好使用场景的。例如用Task应对任务并行用PLINQ应对数据并行毫不草率堪称经典。此外TPL的设计者Joe Duffy是业界大牛他写过一本《Concurrent Programming on Windows》描述了大量关于TPL的实现细节例如无锁数据结构的编写方式Work Stealing如何改善局部性等等。您了解了这些内容以后我想GCD对您来说可能也只是换套API而已应该也不算是件难事儿。我一直认为就算微软明天给外星人一锅端了我也能很快进入其他技术领域并很快达到较高级的程度。但是如果您每次都只了解一些表面自然很容易觉得天崩地裂。盲目追赶那也只是恶性循环而已。我一直强调“眼界”微软技术不断为我打开新视野这些技术的设计者都在各种场合提到其他技术对他们的影响。因此学习了C#和F#我对于PythonRubyScalaHaskell都产生了浓厚的兴趣我不会像许多Java程序员认为Java语言已经足够了或是像许多Ruby程序员那样认为自己领先于其他程序员我能时刻保持Keep StupidKeep 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其中提供了WPFWF和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对于个人提高来说也是大有帮助的。就写到这里吧。希望对您了解微软技术以及如何学习微软技术能够有所帮助。