经常听到有人说微软的技术变化太快，持续性不好，让程序员追得很累。这种观点在微软技术社区内部和外部都有出现，似乎是一个不争的事实。但从我追随.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?#与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对于个人提高来说也是大有帮助的。

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

建议继续学习：

1. Silverlight与微软技术（上）：微软抛弃Silverlight了么？    (阅读：1992)