經常聽到有人說微軟的技術變化太快，持續性不好，讓程式設計師追得很累。這種觀點在微軟技術社群內部和外部都有出現，似乎是一個不爭的事實。但從我追隨.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——這是

在相容性方面，某些技術領域的程式設計師就有更高的“覺悟”。例如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對於個人提高來說也是大有幫助的。

就寫到這裡吧。希望對您瞭解微軟技術，以及如何學習微軟技術能夠有所幫助。