微軟是如何重寫C#編譯器並使它開源的
譯者：王亮
作者：Mads Torgersen (C# Language PM at Microsoft)
原文： ofollow,noindex" target="_blank">http://t.cn/EPOG96O
Roslyn 是 C# 和 Visual Basic.NET 的開源編譯器的代號。以下是它如何在過去十年微軟公司最暗淡的環境中開始，併成為開源、跨平臺、公共語言引擎的，這一切都是為了 C#（和 VB，下文同）。
當我在 2005 年加入微軟的時候，第一次談話就開始討論了關於 Roslyn 將來會是什麼樣子——那時還是 .NET 2.0 釋出之前。那次談話是關於用 C# 重寫 C#。這是程式語言的一種常規做法，是語言成熟一個標誌證明。但是還有一個更實際和重要的動機：我們作為 C# 的創造者並不是用 C# 程式設計，而是用 C++ 程式設計！每天用 C# 工作讓你對 C# 有不同的看法：這是“dogfooding”的力量。（譯註：dogfooding 是內部試用或內部測試的意思。）
客戶依賴新編譯器的行為與舊編譯器將完全相同。為 C# 編寫新的編譯器意味著嘗試 bug-for-bug 地適配舊的編譯器 。
重寫客戶多年來一直掌握的編譯器的挑戰在於，這些客戶對新編譯器的依賴行為與舊編譯器完全相同。為 C# 編寫新的編譯器意味著嘗試 bug-for-bug 地匹配舊的編譯器。我說的不只是已知的 Bug，而是那些開發人員發現並開始依賴的未知和無意的行為，這些行為常常是在不知不覺中發生的。
多年來，這一挑戰的巨大規模甚至阻止了我們開始這個專案。
另外，雖然使用 C# 編寫的新 C# 編譯器在語言團隊內部會有很多好處，但對客戶的價值主張更具挑戰性：新的編譯器如何幫助現有客戶？也許唯一關心用 C# 編寫 C# 的人是編譯器團隊的成員。
與 此同時，另一個問題卻越來越大：基於 C# 程式碼工作的不同工具之間的重複勞動。除了編譯器，我們的隔壁團隊還在 Visual Studio 中構建對 C# 的 IDE 支援，他們也需要編寫大量的程式碼(當時也是用 C++ 編寫的)來理解 C# 語法和語義。
除此之外，還有越來越多的來自微軟和其他公司的工具，如 StyleCop, CodeRush 等，所有這些工具都必須從簡單的 C#原始碼文字開始實現有意義的基於程式碼的工具。所有這些都有微妙和不同的 Bug，不同的理解層次，不同的妥協和權衡。所有的一切都將花費大量的精力來重新開始：理解程式碼。
到這，最後是我們的價值主張：只需世界上有一個理解 C# 的程式碼庫，每個想在程式碼之上構建工具的人都可以共享它！
到這，最後是我們的價值主張：只需世界上有一個理解 C# 的程式碼庫，每個想在程式碼之上構建工具的人都可以共享它！客戶的價值將來自於可用工具的增加，特別是現有工具的質量。我們將把所有的語言正確性和效能需求都放在一個程式碼庫上，並花費一次精力使其具有一流的質量和廣泛的通用性。我們將建立一個語言引擎！C# 程式碼的統一公共 API：我們將重新定義“編譯器”的含義。
當然，一旦你為龐大的 C# 社群構建了一個 API，那麼它應該是一個用 C# 中實現的 .NET API，這是一種 slam-dunk（譯註：指有大回報的行為）。因此，用 C# 中實現“啟動”C#的舊夢想幾乎只是一個偶然的附帶好處。
Roslyn 誕生於一種開放的思想：共享 C# 的內部工作機制，讓世界以程式設計的方式消費。這本身就是一個大膽的步驟，在這個仍然普遍封閉的文化中。
R oslyn 誕生於一種開放的思想：共享 C# 的內部工作機制，讓世界以程式設計的方式消費。這本身就是一個大膽的步驟，在微軟這個仍然普遍封閉的文化中：我們會免費分享這些智慧財產權嗎？我們會授權那些不所於我們的工具製造商更好地與我們競爭？
關於加強生態系統和成為地球上最好的工具語言的辯論使我們贏得了今天成就。它們關注的是 C# 和 .NET 的長期增長，而不是微軟的短期盈利和資產保護。因此，即使沒有提到開源，註冊 Roslyn 專案的成本和風險對微軟來說也是一個巨大而大膽的步驟。
當然，你不能只做這樣的東西。Roslyn 的設想雄心勃勃，也充滿了技術挑戰，我們花了五年時間才實現，但這是後面的故事。
自從 2009 年正式開始這個專案以來，我們就有了讓編譯器開源的想法，但是微軟還沒有準備好。
在 我們構建初始版本的大部分時間裡，Roslyn 仍然是一個閉源專案。自從 2009 年正式開始這個專案以來，我們就有了讓編譯器開源的想法，但是微軟還沒有準備好。在你的原始程式碼周圍進行私有開發和申請專利的文化代表了微軟自 20 世紀 70 年代以來的工作方式——儘管變化正在發生，但它發生的速度比我們團隊希望的要慢。
事實上，有一段時間，公司似乎在朝著完全相反的方向發展。
Windows 8 專案基本上佔據了整個公司。憑藉其新的程式設計模型，它的觸角深入到開發工具和語言團隊，所有事情都籠罩在極度機密之中，不僅是對外部，甚至也對公司內部亦是如此。例如，我們當時正在開發的 async 特性與 Windows 8 程式設計模型是協調的，我甚至不敢在內部發布它的設計說明，因為我害怕不小心洩露了 Windows 8 的資訊，這會給我帶來麻煩！這為創新創造了一種可怕的氛圍，這顯然對我們開源 C# 編譯器的希望來說並不是一個好兆頭。
最 終，在 Windows 8 執行完畢後，微軟開始轉型，找到了新的方向，朝著新的領導班子和非常不同的核心理念前進：我們今天所知道的微軟。開源運動現在迅速在微軟內部生根發芽。
F# 已於 2010 年釋出，擁有開源許可和自己的基金會—— F# 軟體基金會 。在它周圍成長起來的充滿活力的社群很快成為我們大家羨慕的物件。我們的團隊大力推動為 Roslyn 提供開源生產許可證，以至最終在公司範圍內的基礎設施得以實現。
到 2012 年，微軟建立了 Microsoft Open Tech：專門關注開源專案的組織。Roslyn 在微軟開放技術公司的領導下，正式成為開源軟體。開源是它的一個強有力的候選：開發資源都是內部的和眾所周知的，並且專案本身獨立存在，沒有多少可能產生許可衝突的依賴關係。
2014 年 4 月，在舊金山舉行的微軟開發者構建大會上，Anders Hejlsberg 展示了 Roslyn 是一個開源專案，而 Roslyn 是在 Apache 2.0 許可下通過 CodePlex（已經退役的微軟開源託管平臺）釋出的。
與此同時，.NET 基金會被宣佈為 .NET 專案的大本營，包括 Roslyn。
開源是一股清新的空氣！儘管我們已經開始從 CodePlex 上獲得開源的好處，但微軟仍然存在一些程式上的開放原始碼障礙。今天，開放原始碼是我們在團隊中工作的一個直接而完整的部分。
我們不再把 GitHub 當作一個出版場所——它只是我們工作的地方。
另外在其他方面，公司確實意識到我們不需要控制一切。很明顯，CodePlex 出現在世界上並沒有什麼好的理由，Roslyn 加入了其他的專案，從 CodePlex 遷移到 GitHub，那時它實際上就是開源專案的大本營。不僅原始碼，而且構建它的過程也都在 GitHub 上：我們不把它當作釋出場所——它只是我們工作的地方。
C # 語言設計和編譯器實現過程現在是完全開放，有很多非微軟的人蔘與，包括外部貢獻者構建的整個語言特性。C# 的價值與日具增，不僅體現在功能和 Bug 修復的貢獻，更體現在我們通過開放原始碼提供的即時、每日迴圈反饋所獲得的洞察和過程的改進。
這是一個漫長而瘋狂的旅程，對我來說，這是微軟在過去十年經歷的巨大變化的象徵。Roslyn 的“金塊”是在黑暗中誕生的，它是在開放思想的基礎上發展起來的，如今通過開放原始碼的力量，它已經有了上百萬種不同的用途。
你想親自探索 Roslyn，或致力於 C# 語言設計嗎？請訪問：