Python太慢了、Golang糟透了”：那些關於軟體工程的“宗教”辯論

引言：開發者的世界裡總是充斥著各種各樣的爭論，從程式語言、框架甚至到編輯器、 Windows/iOS系統，都可以成為爭得面紅耳赤的“宗教戰爭”。本文作者針對軟體開發行業的辯論進行了深入研究，探討了這些辯論背後的本質，解釋了他認為好的技術辯論應該是怎樣的。

“ Python 的速度不行。 ”

“都9102年了，還有人不用Java虛擬機器（Scala、Clojure）構建Web App嗎？”

“Mong是最好的資料庫；SQL很差勁，SQL資料庫擴充套件性不行。任何現代工程師都必須熟悉Mongo。”

“Golang糟透了（因為沒有泛型）；誰用誰白痴。”

在我剛剛成為軟體工程師那會，最令我震驚的就是，同行們居然用 “宗教戰爭”這樣的字眼來形容工程層面的爭議。有這麼嚴重嗎？幹嘛那麼大火氣？帶著好奇心，我希望弄清為什麼工程技術辯論會成為“宗教戰爭”，而不像經驗主義或者科學方法層面的其它問題那樣可以安靜平和地進行討論。在親身參與一些討論之後，結果更是讓我萬分不解。

我發現，雖然也用到了不少術語，但多數工程辯論只是情緒性的或者簡單化的產物，與工程效益幾乎沒有關係。透過研究這類辯論，我總結出以下幾項要點，希望幫助大家在未來的對話以及互動當中提高效率。

我的觀點包括：

有效識別出可能降低工程辯論質量的因素（例如討論者與議題存在利益相關、使用炒作 /營銷內容作為工程論據、過多糾結於好或壞的爭論，以及使用大量缺乏實際意義的虛榮性指標等）。評估自己，特別是對所選工具的偏好。評估用於制定工程決策的內容與人員，並思考其中可能存在的潛在問題。透過討論權衡並強調一切可能降低辯論質量的因素，鼓勵經過深思熟慮的軟體辯論。下面，讓我們首先看看可能降低軟體工程辯論質量的因素。

 

 

 

利益相關

為什麼只能宣洩情緒、卻無法帶來實效的工程辯論那麼多？首要原因就是各方都在議題中都有 “利益相關性”，這就意味著最終結論必須落在贏家和輸家身上。以諮詢企業為例，他們只瞭解單一語言/框架，而且與其他組織相比，他們當然會盡力宣揚自己所選擇的解決方案。另一種情況則是工程師間的討論，他們之所以會拿出不同的結論，是因為不同的技術選擇會直接給他們造成對應影響甚至左右晉升前景。拿我之前瞭解的Uber內部對於Node與 Python 的爭議來看，這種對抗只會令企業錯失技術優勢（例如最簡單的 X更快、Y擴充套件性更強、Z維護需求更少等等）。

“利益相關”有時候相關的並不只是工作內容或者收入前景。一類常見的例子是，我們不想花時間學習新東西，或者說只希望學自己想學的東西，這對團隊來說當然是個負面因素。很多人可能在與熟悉技術的團隊合作時，仍然強烈主張自己所熟知的工具，因為這對自己來講更容易。或者，大家可能在考慮自己的職業前景，因此著力倡導一種能夠幫助自己的技術，即使這可能與團隊的利益相悖。這些技術選擇可能廣泛存在於我們的日常當中，其顯然只會增加複雜性，而不會帶來多大好處。

 

炒作與營銷

炒作與營銷內容對於那些 “利益相關”者來說可算是極為強大的盟友，甚至可以說二者是互相成就了對方。新的作業系統、社交網路、開源前端框架或者語言需要吸引使用者及開發人員，才能變得更具競爭力與價值。而其支持者也會努力進一步擴大使用者/貢獻者的規模，從而讓自己的意義得到體現。在這樣的思路之下，網路效應開始變得至關重要，並有可能引發與實際工程情況毫無關係的激烈爭論。

這一點在工程層面顯得尤為突出，因為工程討論應當以專業知識為先決條件 ——即只允許具有基本理解的人參與討論 （沒有真正理解，但卻自信能夠發表意見的作法其實相當危險） 。如果 “利益相關”一方達到較高的佔比水平，那麼正確一方的工程師們恐怕也別無選擇，只能跑去學習前者“強烈推薦”的技術方案。

此外，極端的陳述與流行語更受媒體的青睞，也更能吸引支持者。但在進行辯論時，這種細微的差別幾乎沒有任何價值。我們並不是要徹底否定專案宣傳，但開源專案或語言天然傾向於讓貢獻者反對其他開源專案，併為其描繪一幅光明的前景。這些企業 /開源專案的內容營銷（包括會談、博文、媒體報導以及由利益相關者主理的大學課程）都將悄悄潛入工程辯論，並直接衝擊冷靜工程師們提出的全面且準確的觀點。

炒作確實有可能獲得成功，因為有些人願意把自己的思想分享給那些特定的人群：沒有技術專長、缺少時間或者實踐經驗的群體。他們通常也無法意識到很多佈道者都有自己的利益主張。結果就是，他們會受到媒體缺乏論據的片面報導或者言辭激烈的帖子的直接影響。這就是所謂 “無腦相信”，這種以佈道內容為上，而不願認真考慮各方實際利益的作法，可能給團隊帶來巨大的損失。

 

好壞之分

工程辯論中的另一個常見問題，就是爭論的人們會考量不同的案例，並最終以這些案例作為判斷相關技術到底是 “好”還是“壞”的基礎。我們不妨以Vim與Emacs這兩款編輯器之間的永恆對抗為例：

你希望自己的文字編輯器能夠開箱即用嗎？如果你是一位不斷開拓新環境的 DevOps工程師，那麼與只面對單一開發環境的全棧工程師相比，你對於最佳選項自然擁有不同的想法與理解。對DevOps工程師而言，能夠開箱即用的方案也許更為理想；對只需要面對單一計算機的開發人員，IDE的功能齊備水平（自動補全、外掛、自定義按鍵）才是最重要的。這裡的問題在於，很多人將辯論集中在“好”與“壞”之間，而非哪款工具最適合某個特定用例。（在這方面，「利益相關」其實仍可分為兩個層面：那些已經投入數年對編輯器進行微調的使用者不願改變使用習慣；而Vim或者Emacs的貢獻者則希望搞垮對手以增加自身貢獻者及/或使用者規模，從而令競爭對手更難以與之抗衡。）

當團隊在技術方案選擇當中受到炒作觀點的引導時，這種 “好壞之分”的思維可能會帶來麻煩。例如，最近圍繞微服務的熱情（其在一定程度上重新定義了以往的使用實踐）促使不少人重構自己的程式碼庫。但即使是在初創企業當中，單體式架構仍然擁有著巨大的生產效益。在這樣的背景下，一部分團隊在起步階段就專注於微服務，而忽略了產品/市場適應性，並最終導致工程安排成為容器化炒作浪潮下的犧牲品。

這裡我單純討論好與壞的問題，但類似的過度簡化傾向還有其它表現形式，例如舊與新之類，大家可以自行腦補。

 

偏愛虛榮性的指標

效能、可擴充套件性與頁面載入大小都是工程辯論當中常見的所謂 “重要指標”，但它們真那麼重要嗎？卓越工程師的一大標誌，在於他們能夠根據手頭的實際問題做出權衡。因此，他們只會在必要時，犧牲開發速度、開發者生態系統規模或者可維護性等因素來換取語言的“高效能”或者頁面最小化。有時候，我認為我們對這類指標的關注，有點像汽車愛好者們討論中經常提到的百公里加速時間或者極速水平——這些指標確實非常有趣，但在不少重要決策當中卻毫無意義。畢竟如果一家卡車製造商僱用了一位特別喜歡談車輛效能的工程師，那麼結果只能是一敗塗地。

更進一步來講，我們的辯論也可以專注於技術最佳化，而不考慮其它權衡性因素 ——即確保最佳決策能夠實現全域性最大收益，而非技術最大收益。舉例來說，企業/專案對於程式語言的選擇不應僅基於技術細節（效能、可擴充套件性、記憶體佔用等等），還應考慮到庫生態系統、可招聘開發人員規模、開發團隊現有技能儲備、未來前景以及維護挑戰等眾多其它權衡因素。很明顯，目前大部分關於“正確語言”的爭論只集中在技術層面。在設計自己的系統或者工具時，許多工程師都非常瞭解全域性與本地最佳化問題，但在考慮其它問題時，卻往往忽略了這一點。事實上，這些問題都會受到全域性最大收益的影響。

引發這種狀況的部分原因，在於我們溝通時往往抱有某些偏見。我們顯然更瞭解自己的想法或技術，而不太瞭解對方的想法或技術。這時，我們往往會用最極端的觀點或案例諷刺對方，同時只關注自己最好的一面（當然，這也適用於人類之間的其他辯論議題，例如政治傾向等）。而對我們工具的攻擊，會被理解成對我們自身的攻擊，接下來就是一場亂戰。

 

如何進行更好的工程辯論

工程辯論非常重要。在初創企業當中，糟糕或者情緒化的技術辯論可能導致團隊的實際目標愈發模糊，讓人們無法弄清自己到底想打造怎樣的成果。而在任何公司之內，這樣的狀況都可能令本有機會成功的專案陷入失敗。

1.自我評估

第一步是進行自我評估。我們之所以經常與其他人就工具的好壞進行辯論，很大程度上在於我們自己預設了偏好。真正有價值的作法，在於思考哪些框架、庫或者語言有可能在你這裡引發爭吵性辯論，並反思如果再過幾年，其中還有多少仍然受歡迎甚至能否繼續存在。對於初級工程師來講，回顧過去三、五年來的技術新聞網站頭版，大家會發現很多此類辯論根本毫無意義。支援和倡導自己喜愛的工具可以理解，但我們也得真的花點時間瞭解另一方（正如經典的辯論格言：「讓對手的論點變得更好」）。因此，不妨反思我們喜愛的工具在哪些用例中並非理想選擇，同時結合對方提出的創新思路或見解。

另外，在宣揚自己的技術偏好時一定深思熟慮；因為你需要深入瞭解的不僅僅是自己的用例，還包括辯論物件的實際用例（這一原則不僅適用於辯論，也適用於你撰寫的博文與評論內容）。另外，無論你是佔據主動還是受到挑釁，都一定要保持謹慎的心態，千萬不要駁斥那些令人信服的論據。我們知道自己知道什麼，但更重要的是，我們得知道自己不知道什麼。

 

 

2. 評估外部資訊

接下來，要評估你在工程決策中使用的外部資訊。首先評估與你進行辯論的工程師。在與另一方進行技術辯論時，需要確定是否存在某些可能左右其觀點的個人或者狹隘的激勵性因素（例如個人易用性、財務 /職業動機、為產品建立開發者生態系統的意願以及自我形象塑造等）。評估他們用於做出決策的證據，看看這些證據的來源是否存在問題。如果另一方正在利用我們的需求宣傳他們的解決方案，請思考自己對具體用例是否瞭解、是否擁有深入的專業知識、是否充分考慮到權衡的意義。除非有充分的矛盾性證據說服對方，否則我們必須表現出必要的開放心態。

你還需要評估用於決策的工程內容。千萬不要使用營銷素材組織工程決策。想象一下，如果使用這些煽動性的資訊，我們能夠輕鬆讓一大群初級工程師相信那些根本站不住腳的結論 ——這看似讓我們在討論中勝出，實際上對後續工作絕不是好事。請記住，最理想的內容宣傳應當模糊作者的潛在意圖。

如果大家對某一工程議題一無所知，請花點時間檢視各類文章，並嘗試透過親自證明文章中的觀點來完成知識學習。另外，請始終關注解決方案當中做出的具體權衡，包括那些往往被忽略的非技術性權衡。這項工作可能很難，但對於關鍵性決策卻往往極為重要。或者，你也可以建立起一個值得尊重且思慮深遠的工程師社群，並透過初級研究（不僅僅是閱讀或者重複二手資料）進行論點測試。再有，請注意儘量避免使用新的術語描述舊有解決方案。雖然這種方法能夠有效拉攏隊友並激發人們的認同，但卻未必能幫助你的團隊找到正確選項。

在學習與個人成長方面，請支援那些願意表達明確價值取向的團隊，同時注意排除為了營銷目的而建立的內容。如果你決定利用媒體素材作出關於工程技術的決策，那麼必須確保自己能夠處理好炒作以及好 /壞二分觀點之間的平衡。在利用某一社群中的素材（例如開源軟體討論）解決其它問題（例如起始工程決策）時，你可能需要有針對性地做出內容調整。

 

3. 鼓勵全面的軟體辯論

最後，你需要調整自己的溝通方式，包括面對面交流與虛擬方式（社交網路、博文帖子等）。在進行激烈的技術討論時，請提出問題而非直接向某人叫板。這些問題能夠幫助我們瞭解對方做出的全部假設，並據此引導他們找到更好的答案，且不至於引發情緒上的牴觸。我們需要意識到，很多人除了字面上表達出的意思之外，在內心深處還有著另一股會引導其觀點的潛在認知。如果你的目標是說服那些有思想的人，請用心揣摩如何透過細微差別提升溝通效果，同時引導他們將好壞之爭轉化為權衡之辯。關注團隊或小組之間的共同目標，花點時間提升工程辯論本身的質量，而不僅僅是強調語言 /框架/工具等內容。