最好的 Go 框架:沒有框架?
作為Go 語言的團隊領(lǐng)導者這幾年時間，我從初學者那里聽到的最常見問題是“我應該使用什么框架？”。我的想法是使用過去的語言經(jīng)驗去編寫 Go 程序往往會讓結(jié)果變得非常糟糕。
其他的編程語言已經(jīng)建立了 “默認” 的框架。Java有Spring，Python有Django和Flask，Ruby有Rails，C#有ASP.NET，Node有Express，PHP有Symfony和Laravel。但 Go 沒有默認框架，這一點跟其他編程語言完全不同。
并且，很多過來人建議你根本不應該使用框架。到底該怎么辦？
從庫構(gòu)建 Go 服務可能會給人一種構(gòu)建弗蘭肯斯坦的怪物的感覺。
Go 語言哲學
Go 語言有很多框架，但沒有一個提供像其他語言框架那樣的功能集。
這種情況短時間內(nèi)還會持續(xù)。
你可能認為這是因為 Go 語言的生態(tài)更年輕。但更重要的是，Go 是圍繞 Unix 哲學構(gòu)建的，Unix 的哲學要求編寫的程序需要具備以下三要素：
只做一件事，并做好。
程序間協(xié)同工作。
處理文本流，因為這是一個通用接口。
這種哲學起源于 B 編程語言（C 語言的前身）的設計者 Ken Thompson， 并以同樣的哲學思想在 2006 年創(chuàng)建了 Go 語言。
將 Unix 哲學運用實踐中，你會編寫出多個獨立的軟件來做好每一件事，而不是寫出一個巨大的程序去做所有事情。這些例子在 Linux 終端中就能經(jīng)常看到。比如：cat example.txt | sort | uniq。cat從文件中讀取文本，sort對行進行排序，并uniq刪除重復項。所有命令都是獨立的，只做一件事。它源自 Unix 哲學。由于這樣的設計，你可以獨立開發(fā)更小的、自主的命令。
在 Go 中，Unix 哲學在標準庫中隨處可見。最常見的就是最廣泛使用的接口：io.Reader和io.Writer。最好的庫也遵循這一理念。
框架的設計往往是 “反 Unix 哲學而行”。語言框架試圖在一個框架內(nèi)涵蓋所有可能的用例。它們不是為與其他工具一起使用而設計的，而且通常不能重復使用。這意味著不可能將開發(fā)工作轉(zhuǎn)移到其他不兼容的框架。如果一個框架沒有人用，那么針對該框架所有的所有努力都會白費。
對你來說，什么才是真正重要的
每個技術(shù)決策都有代價。你需要選擇項目可以承受的代價， 并從決策中獲得盡量大的收益。當你在做一個項目的簡單技術(shù)驗證 （Proof of Concept）時，最重要的是你可以多快的完成。但如果這是個持續(xù)時間長，涉及多人協(xié)作的大型項目時，這個技術(shù)驗證帶來的代價將會是巨大的。
對于大多數(shù)項目，最需要關(guān)注的是以下幾點：
-
啟動項目的速度
-
完成項目的速度
-
項目適應外來需求變化的能力， 這和上一點息息相關(guān)
讓我們來逐條分析下影響我們決策的因素。
節(jié)省時間
語言框架給出的最大承諾之一是節(jié)省時間。只需一個命令，就能啟動一個可用的項目。語言框架通常提供項目的默認架構(gòu)，這會對入門有點幫助。但與大多數(shù)其他技術(shù)決策一樣，它也有一定的代價。隨著時間的推移，當項目增長時，你會很快碰到該語言框架的約定和限制。語言框架的需求大概率會跟你的項目有區(qū)別。語言框架提供的教學文檔可能適用于簡單的 CRUD 應用程序，但一般無法處理更復雜的場景。?為了和語言框架的限制作斗爭，很容易就會將啟動項目所節(jié)省的時間全部浪費。長期以往，這會給團隊帶來很多挫敗感。
幾年前，我在一家使用某個 Go 語言框架起家的公司工作。公司正在發(fā)展并且不斷的創(chuàng)造新的服務。隨著時間的推移，當我們想要支持更復雜的用例時，我們開始越發(fā)痛苦。不僅如此，長此以往，使用語言框架逐漸成為了產(chǎn)生嚴重 Bug 的主要原因。但擺脫語言框架遠不如想象中容易。
有一次，一些框架組件變得無人維護并且與生態(tài)的其余部分不兼容。我們將不得不去掉它。但是， 該框架中的所有組件之間耦合非常高。從幾十個服務中刪除一個組件非常困難。這需要多團隊協(xié)作，并大概率會帶來一些事故。即使最后我們成功刪除了這個組件，我也不會覺得這是件值得驕傲的事。如果有人早點做出不同的決定，我們就可以更好的利用為了刪除這個組件所花掉的時間。這也是為什么很多公司對開發(fā)團隊不太信任的主要原因。
為幾年前的小決定付出了高昂的代價， 這個故事是個很好的例子。
項目的可維護性
量化項目的可維護性一直以來都是個有爭議的話題——很難比較兩個項目哪個可維護性更高。一些人覺得使用語言框架很好， 使用很方便。但是對于一些復雜的項目，長期使用語言框架會使開發(fā)工作變得越來越困難。并且，還有很多人覺得跟語言框架作斗爭是他們的正常工作。因此很難客觀地衡量框架對項目可維護性的影響。但是，我們可以通過一些手段真正理解它。基于《加速：精益軟件科學和 DevOps》一書。這本書重點描述了如何找出表現(xiàn)最好和最差的團隊的特點。書中提到，想要讓一個團隊表現(xiàn)更好，最重要因素之一是讓項目架構(gòu)的耦合更加松散。
我領(lǐng)導的團隊成員經(jīng)常問我如何知道我們的架構(gòu)是否松散耦合。這里有一個好方法，如果你應用里的組件可以被輕松替換或刪除， 說明這個應用是松散耦合的。但是， 如果大多數(shù)組件都很難被替換，改動一個組件會導致其他地方發(fā)生問題的情況，則說明你的應用耦合很高。
為什么松耦合架構(gòu)如此重要？首先我們需要承認，我們是人， 即使做了最周密的準備，我們?nèi)匀豢赡芊稿e誤。當你選擇了錯誤的框架或庫時，應該很容易替換它而不用重寫整個項目。如果我們想節(jié)省時間，我們應該從長遠來看某些決策是否有收益，而不僅僅是在項目開始時。
考慮一個場景，當你想要完全刪除框架時。它需要重寫大量代碼么？它可以獨立地在多個服務上完成嗎？如果沒有，你可以努力將框架與核心邏輯分開。但當你這樣做時，使用框架被節(jié)省的時間就已經(jīng)開始被浪費了。
替代方案？在沒有框架的情況下構(gòu)建服務
你可能覺得如果不用語言框架的話，構(gòu)建服務會花費很長時間。特別是當你從其他語言轉(zhuǎn)型到 Go 語言時。我懂你的痛。幾年前，當我開始用 Go 語言編程時，我也有過同樣的感覺。這是一種毫無理由的的恐懼。不使用語言框架不代表你需要自己編寫所有代碼。有許多經(jīng)過驗證的庫可以提供你需要的功能。你需要花更多時間做調(diào)研，尋找更好的答案。比如找到并閱讀本文。在整個項目的生命周期中，幾個小時的調(diào)研不算什么。足夠的正確信息帶來的靈活性將讓你很快讓項目回到正軌。
如果你決定不使用框架，你應該怎么做？開頭最大的障礙可能是如何構(gòu)建服務。最簡單的方法是開始時只用一個文件編寫所有邏輯。一切從簡，推遲一些決策，隨著時間的推移改進你的項目。
擁有可用作參考的示例項目會很有幫助。你可以查看我在 GoRemoteFest 上使用 Watermill 演示在 15 分鐘內(nèi)構(gòu)建事件驅(qū)動應用程序時使用的項目 – github.com/roblaszczak/goremotefest-livecoding。這個例子只需要兩個外部庫就可以正常運行。
隨意克隆這個 Git 并測試。為了幫助你處理更具體的用例，下周我們將發(fā)布一篇文章，其中包含可用于構(gòu)建你的 Go 服務的 Go 庫列表。我們已經(jīng)使用它們幾年了。我們還將解釋為什么我們使用這些庫，以及如何知道一個外部庫是否值得使用。
?
在不終止項目的前提下修改項目的某些部分是很實用的。
當你的項目變得更加復雜，并且你已經(jīng)知道你的庫如何協(xié)同工作時，你可以開始重構(gòu)它。你可能不需要很多看起來很重要的框架功能。長此以往，你得到一個更簡單的項目，并最終花了更少的時間去調(diào)研。
如果你正在尋找一些復雜項目的最佳實踐，你應該查看 Wild Workouts - 我們們功能齊全的示例 Go 項目。我們發(fā)布了一本描述我們?nèi)绾螛?gòu)建應用程序的書。
總結(jié)
當一個項目開始時，決定如何構(gòu)建服務是最不應該走捷徑的地方。從長遠來看，錯誤的決定會對團隊的效率產(chǎn)生負面影響，還會影響士氣。在做出錯誤的決策后，你很快就會陷入沉沒成本謬誤陷阱。我們不應該成為解決他們制造的問題的英雄，而應避免制造他們。
讀完此文，你應該了解了使用語言框架的代價并了解如何做出權(quán)衡。你現(xiàn)在可以做出負責任的決定。我希望這篇文章至少能幫助一家公司避免需要經(jīng)歷跨團隊經(jīng)歷幾個月才能完成的的重構(gòu)項目的痛苦。
你是否有任何關(guān)于使用語言框架的恐怖故事？評論里見！
校對 ： iddunk
往期推薦
想要了解Go更多內(nèi)容，歡迎掃描下方??關(guān)注公眾號， 回復關(guān)鍵詞 [實戰(zhàn)群]? ,就有機會進群和我們進行交流
分享、在看與點贊Go?
