為什麼我不再用 .NET 框架

　　.NET平臺很棒。真的很棒。直到它不再那麼棒。我為什麼不再用.NET？簡單來說，它限制了我們選擇的能力(對我來說很重要)，轉移了我們的注意力，使得我們向內認知它的安全性，替代了幫助我們認知外面廣闊世界的所有可能性。

　　[繫好安全帶：這個文章的長度幾乎成了一本書…]

　優點

　　首先讓我開始說說.NET做得對的許多事吧，儘管這其中的大多數並不來自.NET本身，但卻是由.NET社群而來。

　　C#

　　C#令人驚歎。我認為它是一個令人驚歎的程式語言。從強大的C語言背景而來，我徹底地喜歡其語法，流和這門語言的所帶來的感覺。當然有我可能改變的事，但總體來說它是一門紮實的語言。並且基於開發人員使用的程式語言如此鉅額的百分比和Windows作業系統的優越性，它是一門眾所周知的語言。

　　ReSharper

　　我也很喜歡Resharper。在JetBrains工作的開發者們都是奇蹟般的人。如果沒有ReSharper和一些相關的工具，我可能並不會如此喜歡C#。

　　BDD and MSpec

　　我也很喜歡簡稱為機器規格(mspec)的BDD風格的框架。它是一個令人驚歎的測試框架，真正支援在測試中使用正確的語言測試本身。在使用mspec之前，我的測試真是一團糟並且很礙我的事。

　　另外，當我們建立GoConvey—基於Golang的BDD測試框架的時候，Mspec對於我的組織來說是一個巨大的靈感和激勵。

　　多語言執行時

　　我認為多語言的CLR(公共語言執行時)的觀念真得使得JVM的世界思考著。我不知道任何非Java的JVM語言在CLR之前，但隨著“公共語言執行時”的到來，我的理解是這使得使用JVM的人們向前進並且最終創造瞭如Scala和Clojure這樣偉大的JVM程式語言。如果我錯了請糾正我。再者，CLR使得Sun公司的人們坐下來並關注它，因為Java有一點陳舊並且隨著Java 8的到來，僅僅現在才在多個方面追趕著。競爭是一件非常好的事。

　　NuGet

　　另一個顯著的例子是NuGet。這個包在Windows中作為一個整體特別是在Windows的開發中，它的管理軼事是糟透的。NuGet解決了很多問題，他們也通過從Python和Ruby借用了很多東西去做了很多正確的事。有改進的餘地嗎？當然。但比起其他一些選擇在這兒或那兒的包升級來說，我還沒有感到使用NuGet有這許多痛楚。

　　Mono

對於Mono的開發者們，我不能不說太棒了。他們所創造的太驚奇了。沒有任何官方支援和不顧潛在的懸在他們頭上的法律問題，他們向前推進並創造了一個居然能替代官方執行時的實現。我已經有一些執行在產品中應用程式，在Mono下執行了幾乎一年而沒有任何問題。它的產品準備好了嗎？這可能取決於你的應用程式(見下文“Mono”)。

　　CQRS 和事件溯源

　　可以認為，關於.NET最好事之一是，它是CQRS的誕生地並有相關的技術：事件溯源。就算這樣，CQRS+ES本身並沒有什麼很新的東西。正如Greg Young將會告訴你的，這是由一堆40年曆史原料為我們重新打包並更名的。對於大型程式碼庫我有些非常嚴重的問題，當我5年前使用CQRS+ES的時候，它完全釋放了我的域。CQRS+ES現在是命名模式的並且其成長是顯而易見的。這可能是因為.NET已經能夠和其他的開發平臺互動共享的原因。除了這個之外，大多數的創新是從外部來的。

　缺點

　　優點先放在一邊，讓我們看看什麼出錯了和我為什麼不再用.NET框架。關於我最近開發平臺的遷移，最能激勵我的事是我可以利用許多最好的部分而丟下不好的部分(如下文所說)。

　　Windows

　　正如前文所述，當面對基於網路的伺服器軟體時，Windows並不是一個好的選手。在我看來，Windows的另一個真正的大問題是傳統的Windows開發者是通常僅僅擅長於Windows，當他們離開安樂窩之後就會很快迷失，這對於Linux開發者來說卻不是問題。計算遠不止是Windows。開發者僅僅能操作單一的作業系統的一個問題是它不可避免得導致Windows的激增。換句話說，Windows生了Windows。沒辦法打破這個迴圈。

　　另一方面，*NIX的開發者通常熟悉多作業系統(Linux，Unix，OSX，Windows等等)，一個作業系統的內部工作原理，不同的分佈(基於Debian和基於Fedora)，視窗管理器，桌面管理器，檔案系統，包管理，編譯，重新編譯，重新打包，命令列“fu”等等。

　　我的一個心病是檔案系統。NTFS並不是系統唯一的檔案系統，對於任何給予的任務它幾乎都不是最好的選擇。ZFS，BTRFS，ReiserFs，ext*等等，有一些很酷的特性。我也很喜歡為了各種高速/透明的磁碟操作，能從BASH建立迴路裝置或者建立RAM裝置。這在Windows中不會發生—如果沒有第三方軟體的話。

　　在AWS雲服務中，啟動一個Windows機器要花掉足足10多分鐘。我大約15-20秒就能啟動一個簡單的Linux機器。當涉及到雲端計算規模，它能夠迅速擴充套件是很重要的，因為當擴充套件很重要時，10-15分鐘就像是永恆的。

　　Visual Studio

　　在我這另一根刺，當屬Visual Studio。我需要一個大大超出預期的 IDE 去做任何開發，這個想法困擾著我。它只是如Windows一樣龐大的資源豬。我有一個核心i7 3770K 3.5GHZ的桌上型電腦，以16GB的記憶體和最大4512GB的固態硬碟去編譯。它差不多刷爆了Windows體驗指數，但Windows+VS仍然很慢。(是的，ReSharper使得它更慢了，但是ReSharper對這來說是值得的。)

　　現在我在MacBook Pro上開發，它比起我的強大的桌上型電腦來說只有更少的CPU馬力，但執行明顯更快，在一個短小的學習曲線之後，UX（使用者體驗）變得無限美好了。事實上，我甚至不再用滑鼠了—我的雙手一直在鍵盤或觸控板上，我可以用手勢操作我的電腦並讓它迴應—不像在Windows。

　　關於VS很酷的一個事是偵錯程式。它的檢視和使用，令人難以置信得方便。每隔一段時間會在監視視窗報告錯誤的值，導致花費更多時間去除錯。同時，這也是很大的負面，因為CLR預設的，多執行緒的世界使得我一開始就需要一個偵錯程式。沒有偵錯程式是一個解脫的體驗，因為它迫使你以另一種方式程式設計。

　　VS同樣也有建立“csproj”和“sln”檔案的壞毛病。我恨這些。當然，C#必須知道編譯什麼和何時編譯。我理解這點。在Golang中，引用在程式碼中使用了很重要的語句。如果它不是.NET中用到的工程檔案，我可能使用簡單的文字編輯器編碼C#，並且對這門語言更流暢。使用git rebase操作時，這些檔案也有導致合併衝突。

　　別讓我開始說換行符的差異。我不能相信直到今天我們還在處理這樣的事。如果VS解決方案檔案以Linux行結束符結束，通過雙擊它並不能載入該解決方案，因為VS解決方案檔案分析器讀不出它來。

　　原始碼管理

　　幸運的是，我早就跳出了微軟陣營的原始碼管理(版本控制系統VSS)。我早在2000年初，在VSS無數次丟失了我的提交之後，就使用了Subversion(譯者注：Subversion是開源的版本控制系統)。之後git(譯者注：git是開源的版本控制系統，內容管理系統等)出現了，我又迷上了它。不幸的是，沒有Windows的介面—對我來說是典型的遭遇。最終有人建立了一個介面，我就用了那個並且沒有回頭。Git是一把非常鋒利的刀，但當你正確運用它的時候，它是一個強大而高效的工具。我曾經在一個小工程中用過TFS(譯者注：Team Foundation Server，工作流協作引擎)，它是一個怪物—和所有來自Redmond(譯者注：美國微軟總部)的產品一樣。它感染了我的專案檔案並且汙染了我的原始碼目錄。真可惡。不，還是謝謝你。給了我任意一天用命令列git…或者可能是SourceTree，如果你需要從GUI得到一點關愛。

　　Mono

　　是的，這是第二次提及Mono。正如Mono本身如此驚豔一樣。在.NET的世界，它仍然二等公民。無論什麼時候我嘗試在Mono上執行任何重要的東西，我通常都在和漏洞作鬥爭。幸運的是，對下載程式碼，查詢問題，傳送請求和在Linux上編譯程式碼我沒有感到不舒服。但是這件事我都記不清做了多少遍了。

　　是的，CLR是個巨大的怪物，並且對一個非官方的應用在不同的作業系統都有相同的行為，簡直是個類似於分開紅海的奇蹟。但事實是，我不得不花費如此多的時間來填補漏洞以使我的程式碼能夠正確執行，實在是很難為其辯護。

　　Mono的特定區域也慢。也許它不是在慢在過載，但對我來說Web伺服器是關鍵所在。並且它非常慢，最後，慢到了最底下—即使是微不足道的東西。我想好訊息是它只能從這兒得到更好的。我也應該提及Mono的開發者可能忘了Linux，比起我可能知道的還多，所以我不能太挑剔。

　　IIS

　　也許IIS在嘗試著為太多的應用程式做太多的事情。它從作為一個web伺服器變為像J2EE應用程式容器一樣的應用程式宿主。它也站在慢速這一邊。我猜如果我需要更高的效能，我應該編寫我自己的web伺服器，但我真的很想只關注我應用程式的程式碼。可能利用Windows事件伺服器將是好的，但nginx(譯者注：一個高效能的HTTP和反向代理伺服器，也是一個IMAP/POP3/SMTP代理伺服器)和其他伺服器只是不喜歡在Windows中生產。

　　虛擬的以JVM為基礎的實現，例如Netty(譯者注：JBOSS提供的一個java開源框架)，很容易處理每秒650K+/的請求量。IIS在執行一個簡單的CLR應用程式“Hello,World!”，處理大約每秒50K的請求量時就會壅塞。(有趣的題外話，參考基準開發者通過TCP套接字建立了一個簡單的C#的web伺服器，它能處理大約每秒120K的請求量。)

　　狹隘的心理

　　前些年有個運動叫做ALT.NET。該運動是全部是關於尋找我們自身之外的更廣闊的開發社群以作為一個整體，並匯聚不同的部分。有趣的是，那是StructureMap、Autofac、NuGet、ASP.NET MVC和許多其它工具的靈感來源。在傳統的.NET的圈子裡，這個運動受到了很多的不屑和鄙視。我把這看作是，作為一個整體的社群普遍的狹隘心理和怠惰的一個極大的例證。(的確，它們中的一些可能會消失，進而以包括Redis，MongoBD還有其它的不同的技術而出現。)

　　有這麼多很棒的方案在那裡。假定微軟已註定是唯一正確之路的想法是荒謬的。如果是這樣的話，我們就都還在使用Visual Studio的設計工具去拖放按鈕和連結元素到一個WebForm的介面上，我們會設定了該按鈕並且依賴ViewState以幫助我們與可怕的HTTP所帶來的恐懼隔開。我從我的一個部署的程式碼庫中最後一個WebForm中擺脫的那一天，是個光榮的值得慶賀的日子。

　　誰又曾想過“網路控制”是個好主意？很顯然我考慮過因為我喝了Kool-Aid(譯者注：卡夫公司出品的飲料，這裡意指明知是註定的或有危險的仍然去做,有負面涵義)並且完全接受它。它狠咬了我。見過2MB的ViewState嗎？

　　[注：當我寫這篇文章的時候，原來的標題，“為什麼我不再用.NET”，意味著整個.NET生態系統。標題感覺有點短於是我更新為“為什麼我不再用.NET框架”。我想.NET作為一個生態系統，包括了所有的工具，工程，平臺，組織還有很多開發者。這就是為什麼有些更廣泛的.NET社群的元素在我的這篇文章中受到抨擊原因。]

　　效能殺手

　　C，Java和C#中典型的多執行緒範例都強烈推薦使用鎖和互斥。對於鎖來說有個隱藏的開銷：它們慢得難以忍受。使用Disruptor(JVM中的無鎖的環形快取[譯者注：實際上就是擁有一個序號指向下一個可用元素的陣列])，你可以很容易得每秒處理20M以上的事件。在.NET中使用規定的“最佳實踐”等任何超過每秒十幾次的傳輸，都被認為是體面又好的效能表現，在這一點上來說你僅僅需要更大/更好/更多的硬體裝置。事實上，我見過第三方客戶端庫(Rabbit，Couch，Mongo等等)中鎖語句遍佈整個程式碼。即使在我的程式碼中沒有任何的併發，預設的和首選的方法都用了鎖。

　　無鎖的、事件驅動的方法允許你大幅降低硬體和資金支出。大部分應用程式可以輕易地執行在兩臺機器上，第二臺機器僅僅在冗餘和失效備援時是必須的，以防因為硬體相關的問題導致第一臺機器不可用的時候起作用。

　　這個問題的另一個方面是呼叫網路和磁碟子系統的傳統方式：同步，阻塞程式碼。如果你需要多個併發的HTTP請求，你需要更多的執行緒。大多數人不知道的是，為維持執行緒多出的1-2MB和上下文切換執行緒的需求，使得CPU核心消耗所有的時間顛簸在上下文切換上而不是做真正的工作。所以現在我們得到了在一個應用程式中數百或數千的執行緒，佔用了RAM，並造成CPU停滯不前。還有個更好的方式。

　　Netty/NIO (JVM)，Erlang，Node，Gevent (Python)和Go都支援使用事件驅動的子系統操作(選擇/epoll[譯者注：Linux核心中的一種可擴充套件IO事件處理機制]/kqueue[譯者注：FreeBSD的可擴充套件的事件通知介面])。這就意味著當等待資料包被tx/rx跨網路的時候，CPU可以自由地去做其它，重要的工作。因為JVM的成熟，Netty可以認為是做這項工作最快的，但我喜歡Go用Goroutines操作這個的方式—它簡單，優雅，很容易推理，沒有像義大利麵條一樣的回撥。

　　SQL Server

　　作為一名.NET開發者，當你開始一個新的工程時，有一些事是你通常會去做的：

• 建立一個新的solution
• 將其部署到Team Foundation Server(譯者注：Microsoft 應用程式生命週期管理 (ALM) 解決方案的核心協作平臺)
• IIS中建立相應的網站入口
• 建立一個新的SQL Server資料庫
• 在solution中關聯Entity Framework(通常是2010年之後建立的工程)
• 開始設計你的資料庫和ActiveRecord實體

　　在大多數情況下這不是編寫程式碼的正確方式。當然它可能在某些情況下有效，但是作為一個“預設的架構”它並不是你想要的。為什麼在我們甚至還沒理解問題領域之前已經做了任何技術上的選擇？這簡直是本末倒置了。

　　微軟的生態系統鼓勵每個人使用SQL Server。在Visual Studio中和SQL Service進行互動或者使用SQL Management Studio(和它的前身，SQL查詢分析器)是如此令人難以置信的容易。這種以資料庫為中心的重點，是欽定的或唯一正確的方式的一部分。它使你更加迷戀微軟。廠商鎖定始終對廠商來說是好的。

　　為什麼我們要如此開發？為什麼我們不更多地考慮應用程式的行為而不是它如何儲存的？現在我所有的專案都使用基於JSON的鍵/值儲存。有了這種功能，我可以選擇任何我想要的儲存引擎，包括SQL Server，Oracle，PostgreSQL，MySQL，Cassandra, CouchDB, CouchBase, Dynamo, SimpleDB, S3, Riak, BerkeleyDB, Firebird, Hypertable, RavenDB, Redis, Tokyo Cabinet/Tyrant, Azure Blobs，檔案系統中的明文JSON檔案等等等等。突然之間，我們能夠開始根據其優點而不是僅僅對其熟悉來選擇儲存引擎了。

　　題外話：在AWS RDS的雲上執行過SQL Server嗎？別這麼做。當然它會工作，但是一些例如複製這樣最簡單的事是不存在的。文章充斥著對SQL Server不能在AWS RDS上工作的引用。

　結論

　　也許我在軟體開發中學到的兩件最重要的教訓是：

• 邊界和封裝的重要性(以多種形式)
• 付出代價以得到正確的模型和抽象

　　許多年前我恨“模型”這個詞。每個人都會把它到處扔，它是一個如此過載的術語，很難理解它的含義和它為什麼這麼重要。就這點來說，我僅僅會說模型是對你想要封裝的現實的一個有限的表示。也許最簡單的例子就是地球儀的墨卡託投影了。這很確切得說明了一件事：導航。如果你在其他的事情上使用它，它並不毫無價值。如果你不專注於付出代價去使模型正確，去封裝商業現實，那麼沒有任何技術能夠拯救你。

　　我對.NET最大的抱怨是，“唯一正確的方式”引導你遠離理想的模型並把你推向關注實現細節和技術缺陷的方向。這樣的關注導致技術實施滲血並且感染模型，最終導致它腐爛變質，因為它不能適應不斷變化的商業需求。當這發生的時候，開發者掙扎著並蹬踢著，如同吸毒者一樣，他們從一個新技術轉向另一個，以期望下一個強大的技術能夠治癒他們的病痛。

　　技術本身並不是靈丹妙藥，相反地，它是關於取捨和選擇。只有正確地理解了商業行為並把它們封裝進結構良好的，易於理解的模型中，以幫助保持技術堆疊在屬於它的地方—作為一個實現細節。

　　And that’s why I left the .NET Framework because it kept reasserting itself and wanting to be more than it was: an implementation detail. 這就是我為什麼不再用.NET 框架，因為它不斷地重申自己(的主張)，不斷地想要比它的本身更多的：一個實現細節。

　　原文連結： Jonathan Oliver   翻譯： 伯樂線上 - EluQ