[[125341]]

我很困惑.

多年來，我一直是一名 .NET / Microsoft 技術棧下面的開發者(從這兒往后我會簡單點叫它 .NET , 而我的意思則是 Windows / ASP / .NET / IIS / SQL Server 等等這些東西. 一個產品家族或者一些產品) ，并不是因為任何“宗教信仰”般的原因, 也不是因為我已經像其他一些人那樣受到企業思維的影響，或者業務范圍的限制d – 而僅僅只是因為機緣巧合，我開始使用 Visual Basic 2 進行了開發, 而后一發不可收拾的使用之后的版本，之前則變成了歷史與回憶.

為 .NET 祈禱
 

常年來我總是讀到一些“很酷”的家伙使用著 Unix / Linux / Ruby / Python，以及一些你能叫得出名字的東西 ; 比方說他們能使用VM快速的解決一個問題; 比方說開源軟件社區如此之龐大，充滿了熱衷奉獻的人們; 比方說他們的工具或者框架是多么的穩定和快速.

不知何故我從未去涉足這些領域. 我的意思是，我并沒有去質疑這些事實，而我總只是看看而已，某種程度上我仍然我行我素， .NET 技術棧是強大、豐富而穩定的，他擁有精湛的工具 (主要是 Visual Studio)，并且還有非常友好的文檔.

特別是近年來，Microsoft以及第三方的庫、工具和框架的爆炸式發展，讓.NET更加的棒. 許多的這些工具“靈感”都源自Linux – 盡管他們的創建者都很少承認這個事實. 一些東西的命名——在順序和重要性方面完全都是隨機的: ASP.NET MVC, Chocolatey, NuGet, Entity Framework, Nancy, Web API, PowerShell, Windows Server Core… 當然還有許多其它“更小”的工具，豐富了整個生態系統，像: NUnit, Resharper, Web Essentials, GitHub for Windows, Dapper, Lucene.Net, Autofac, Cmder，以及成百上千的其它項目. 更別提許多其它源起 .NET 的項目，或者是他們自身的發展版本: Octopus Deploy, Hangfire, Xamarin, SignalR. 我總是感覺在 .NET的世界中我沒有丟掉任何東西 – 工具都有，穩定性也有；年輕人噴它只是為了耍酷，或者至少他們是這樣想的. 在整個這段時間里我***認同的問題是使用 Windows/.NET 生態系統會花費許可費用, 而  *nix 是免費的. 但這一爭論并沒有明確一些東西，因為存在使用免費的東西就不會獲得企業級的支持等等因素. (我知道這個爭論源起子MS的市場營銷策略, 是非常主觀的，而我現在不回去深入糾結這一點.)

某種形式的覺醒
 

盡管如此，我已經看到的是一幅越來越令人擔憂的圖景. Microsoft的代碼不是開放的，而當他們最終開始開源他們幾年以前的一些項目是, 他們也不會 接受代碼的提交請求. *nix中好的庫和框架比Windows的要大很多。 Internet Explorer么? 甚至都沒有讓我開始去強調這一點. 我已經寫好了屬于我的這部分東西. 許多基準測試都聲稱IIS表現要比nginx差. Shell么? 必須告知大家真相: PowerShell 是一個很大的進步，但從使用的穩定性、易用性和速度方面來看他仍然落后于 sh/Bash. Windows 用戶仍舊沒有改變他們對于用鍵盤來操作shell的心態. 所有的指南/教程/Q&A 都是用界面截圖的步驟來向你解釋如何搞定一個IT的任務 – 打開這個程序，點點這里，從列表里面選擇等等. – 而命令行方式的版本則常常就是一行你實際只要復制粘貼和重復使用的能起作用東西, 不會有版本之間丟失步驟，或者改變位置諸如此類 的問題.

一些.Net/Windows的老手開始向*nix遷移，并寫下了博客。這不是什么新鮮事。據我的印象，這個現象從近五年開始顯著。人們提出了各種反對.Net/Windows的觀點，并開始偏愛*unix。一開始，我僅僅認為這是某些極客的觀點：微軟不夠酷，Linux讓我干活更快，Windows根本不安全，微軟沒有開源軟件的優點。我聽到有些人說它們遷移到了LMAP棧，覺得他們自由了。但是我仍然不認同這種觀點，就像我前面說到的，.Net的生態環境更健壯，還在不斷的發展，并且有足夠的支持。

慢慢地，我開始發現某些真相。就像當跟別人爭吵時，你們都不會仔細聽別人的意見。但是當你們靜下心，放下自己的主觀意見，公正地判斷問題的對錯，你就會理解別人的觀點，發現別人的觀點并不是那么站不住腳。

我實踐過很多博客的觀點。 他們中大部分都討論.NET，我的技術來源于此。 但是當你簡單過濾關于軟件設計的博客時，出現的都是企業家精神、精益創業、編程馬拉松的相關文章 – 這些都不是企業動態 – 他們很少談到.NET。 他們不討厭.NET，也不是整天嘲笑.NET。他們只是不關注.NET。 他們用Python/Node/Go/Meteor語言研究自己的東西（我沒有提到RoR，因為最近它不太流行），他們使用精簡版Linux虛擬機或者Docker容器，他們把系統發布到Heroku或者Google AppEngine或者DigitalOcean上一個精簡的Linux虛擬機，就這些。 這并不意味著他們的架構不夠強壯，因為他們確實有數據庫、框架、所有需要的工具，這些都是免費的，并且這些框架/工具很穩定，他們在生產環境中使用這些東西。

如果你看下早期和成熟的創業公司 – 會發現他們的代碼90%（呃，這個精確的數字是我捏造的，但實際數字與此相近）使用Linux技術架構。 在硅谷，很難找到優秀的的.NET工程師。現在，NodeJS（考慮成本，它運行在Linux上，盡管在Windows上它也運行得一樣好）很流行 – 部分原因它是MEAN框架（由 MongoDB、ExpressJS、AngularJS、NodeJS 組成的完整的WEB開發框架）的一部分。 我越來越多地聽到.NET開發屬于過時、傳統的團隊，而真正輕便、敏捷、MVP架構的系統使用MEAN框架（以前叫LAMP，開發PHP的一個框架）開發。.NET革命

另一方面，微軟總部雷德蒙德吹來變革之風，并且這陣風越來越強。 變革開始于微軟開源.NET棧的一些技術，發展于微軟成立開源組織如 Outercurve和 MS Open Tech。我們開始看到這些組織對一些著名的開源項目的重大貢獻，最終微軟開始接受代碼提交 – 開始是并行技術，現在發展到.NET核心類庫，并介紹了下一代.NET vNext。 微軟不再否認Linux的存在。 他們不僅僅接受Linux的存在（我確信在一些重要內部政策的要求下，他們的市場部被迫改變銷售模式），他們甚至在微軟Azure云平臺上提供官方的Linux虛擬機，截至我寫這篇文章，Azure云平臺20%的虛擬機使用Linux系統。 不久的將來Docker也將支持Windows系統。

下一代.NET vNext的宣布使微軟一飛沖天。微軟反復修改.NET代碼來對抗Linux系統和Mac系統 - 不再是用于寫hello world但不能用于產品的Mono工程。最終，.NET工程不再綁定.csproj文件 - 根據物理路徑中的內容，工程可以進行轉化并且完全是可移植的，包括工程運行時使用的.NET框架版本。所有這些快速消除了.NET棧技術和框架之間的鴻溝，這一點我之前提到過。

作為一名.NET愛好者，.NET現在看起來比過去好多了。幾年前，作為一名.NET協作開發的程序員，我感到慚愧，最近我再也沒有這種感覺了。幾個月前，我在Reversim 博客(希伯來文)中詳細地描述了這一點。

再次困惑.
 

一直沒想明白, 到底是 Microsoft 做的太少, 還是起步太晚. 雖然, 在明白它那種傳統又獨特的方式做出來的產品已經失去市場之后,  Microsoft 一直努力的跟上市場的步伐. 但是 Microsoft 的霸氣已然不復存在. 也許它在桌面領域(包括個人桌面系統和商務桌面系統)依然獨占鰲頭, 但是, 很久以前它在瀏覽器領域已經失去優勢.  服務器領域(1, 2), 和開發棧(development stacks)領域也沒有太多的優勢可言. 重點是, Microsoft 還能不能跟上潮流, 阻止開發人員繼續往 Linux 那邊流失, 甚至扭轉整個局面呢?

另外一個問題是, Linux 和 and Mac OS 版的 .NET 能否 100% 實現 Windows 版的功能. 暫且不提 Microsoft 是不是真心給非 Windows 系統提供完全兼容的 .NET. 我認為技術上能不能實現才是個大問題.  雖說我是個資深的 .NET 程序猿, 按理說因該支持 .NET. 但是究竟選擇哪一種技術,  關鍵要看它適不適合手頭的的項目. 就拿我的下一個 web gig 來說, 除非其他開發框架有明顯優勢, 如: NodeJS+Express, Meteor, Go, Python+Django (當然, 這些框架在客戶端或服務端的某些方面有自己的優勢) – 否則, 我真的想不出有什么理由不用 .NET. 我指的是服務端 – 網站應用. 至于客戶端, 那是另外一回事.

如何? 覺得 .NET 有前途嗎? 還是心意已決, 打死不碰 .NET? 現在, 錢(Monetary) 和 IP 不再是問題, *nix 的程序猿會考慮用 .NET 嗎?

英文原文： To .NET or not to .NET, That is the Question

譯文出自：http://www.oschina.net/translate/to-dotnet-or-not-to-dotnet-that-is-the-question