哪個技術火就選哪個？熱鬧驅動開發的技術選型使不得！

接收程序員的技術早餐

作者｜Marek Kirejczyk

翻譯｜余晟

本文的主題是技術選型，作者總結了他見過的各種不靠譜的技術選型方式，比如有的團隊會根據社交媒體上的討論來決定選擇哪種架構，也有的團隊會跟風走，哪個熱門就選哪個。但總體來看，這樣簡單粗暴的方式一定會為未來埋下隱患。那為什麼這樣說？我們應該如何做正確的選擇？且聽作者細細道來。另本文譯者余晟，曾經是主力程序員、技術文章的寫作和翻譯愛好者，現在在滬江負責研發和軟體架構。歡迎關注他的個人公眾號「余晟以為」，了解一位非典型 IT 人員對世界的看法。

軟體開發團隊所做的軟體架構或技術棧的決策，很多並沒有經過踏實的研究和對目標成果的認真思考，而是不準確的意見、社交媒體的信息，或者就些是「熱鬧」的玩意。我稱這種作派為「熱鬧驅動開發（Hype Driven Development，HDD）」，眼見它的危害，我贊成更專業的做法，就是「腳踏實地的軟體工程」。下面我們一起看看HDD的來龍去脈，想想能如何改進。

新技術帶來新希望

開發團隊把最新最熱的技術應用到項目里，這樣的情景你見過嗎？有人是因為讀到了相關的博客，有人是看到了Twitter上的潮流，還有人是剛剛在技術大會上聽到了關於某門技術的精彩演講。不久，開發團隊就開始採用這種時髦的新技術（或者軟體架構設計範式），結果他們卻沒法更快（就像之前說的那樣）開發出更優秀的產品，反而身陷囹圄。開發的速度降下來了，信心受挫了，後續版本的交付也出問題了。有些團隊甚至乾脆專心修bug，停止開發新功能。他們「只需要多花幾天」就能把事情搞定。

熱鬧驅動開發

熱鬧驅動開發有很多流派，也有很多渠道介入大家的項目：

Reddit驅動開發。在選擇技術、架構、設計方案時，團隊和個人的決策依據是知名博主的文章，或者Reddit、Hacker News、博客、Twitter、 Facebook、GitHub以及其它社交媒體上的熱門信息。

技術會議驅動開發。仔細觀察觀察，參會回來的傢伙們有什麼表現。他們聽了演講興緻高漲。然而這是雙刃劍。他們沒有做足夠的研究，就開始使用最新最熱的類庫、框架、架構範式，於是可能踏上通往地獄的高速公路。

嗓門驅動開發。有人整天談論新框架/類庫/技術，他自己其實沒有實際經驗，但是反覆念經終於讓團隊決定採納他的意見。

Gem/類庫/插件驅動開發。在RoR社區里特別流行這種情況，有時候我會發現一個gemfile太長，唯一比它更長的只有程序啟動時的裝載時間。這種流派源自下面的觀念：Rails里的每個問題都應當有個gem來解決。有時候分明只要自己動手寫幾行代碼就能解決，但是我們還是一個勁地添加類庫/插件/gem/框架。

我還希望提到熱鬧驅動開發的一個常見流派，StackOverflow 驅動開發。開發人員從StackOverflow（總之就是互聯網上）拷貝代碼，而沒有真正弄懂這些代碼。

HDD 就是開發團隊自掘墳墓

湊熱鬧的問題是：它很容易導致錯誤決策。無論是糟糕的架構決策，還是糟糕的技術棧決策，對團隊的影響都常常持續數月甚至數年。最壞的結果是造成極其嚴重的軟體工程問題，只能推倒重來。但推倒重來而成功的案例幾乎沒有。

一切罪惡的根源似乎都是社交媒體——新觀點傳播得太快，都還沒來得及經過檢驗。大家還來不及細想有哪些利弊，這些觀點就已經傳播開了。

湊熱鬧的起承轉合

大多數湊熱鬧的過程是相同的，像下面這樣：

第一階段：真實問題和解決方案

熱鬧的來源是，某些公司真的遇到了問題。這些公司里的開發團隊認為，現成的技術棧、流程、架構並不能解決這個問題，必須自己動手。所以他們研發了新的框架、類庫、範式，問題迅速解決了。

第二階段：宣示、推廣、包裝關鍵詞

團隊熱衷於向他人展示自己的成果。很快他們就發布了博客文章，也去技術會議上演講。這些問題通常是有難度的，所以解決方案是有分量的，結果也是很可觀的，開發團隊對此很自豪。其它人也開始對這項新技術有了興緻。唯一的問題是，並非所有興緻勃勃的人都能徹底理解問題本身和解決方案的細節。畢竟，問題有難度，解決方案也有分量，所以不是一條推文、一次碎碎念、甚至是一篇博客就能講清楚的。利用博客文章、技術大會的主題演講之類的社交工具，原始信息就很容易走樣。

第三階段：狂熱現身

HDD陰影下的開發人員都會閱讀博客、參加技術會議。然後，世界各地的開發團隊都開始使用新技術了。因為信息已經走樣了，所以有些人會在框架問題上做草率的決定。哪怕新框架沒有解決任何具體問題，開發團隊仍然期望新的框架會帶來幫助。

第四階段：心灰意冷

新鮮勁頭過去了，新技術並沒有給團隊帶來期望的改進，反而增加了很多額外的工作。大家得重寫很多代碼，花不少時間專門學習。工作的速度慢下來，管理者也沒耐心了。大家都感覺被騙了。

第五階段：反省領悟

最終團隊做了復盤，認清了追逐這項新技術的代價，也認清了新技術適合解決的問題。大家都變聰明了，直到再次湊熱鬧為止。

HDD 舉例

來看看幾個熱鬧驅動開發的例子，看看它是怎麼發生的。

舉例 1：React.js

Facebook遇到了一個問題，Facebook自己的複雜單頁面應用里會出現各種狀態改變的事件，必須追蹤到發生了什麼，並且保持狀態的連貫一致。

Facebook用幾個時髦的詞包裝新範式：函數式、虛擬DOM、組件。

追逐熱鬧的人說：Facebook創造了未來的前端框架。我們現在就把一切用react重寫吧。

等等！要做的工作很多，但這項投資看不到什麼短期回報。

React非常適用於包含很多實時通知的複雜單頁面應用程序，但是對簡單應用來說，它不見得合適。

舉例 2：TDD被DHH殺死了

David Heinemeier Hansson（DHH，Ruby on Rails框架的創造者）意識到，Rails的框架里沒有對OOP支持很好的架構，所以很難做測試驅動開發。於是他做了個現實的選擇：不要提前寫測試代碼。

DHH的博客和會議演講引發了熱潮。關鍵詞是：TDD is DEAD。

忘了測試吧！我們的領袖說過。一個測試也不要寫。我們可不是在假裝，而是在虔誠地執行。

等等！以前一些能正常運行的代碼現在都出問題了。我們新寫的代碼錯誤百出。

TDD無所謂生死。TDD是需要權衡的，權衡因素包括API變化的風險、既有設計、參與者的水平——Kent Beck。

舉例3：微服務

龐大的單體系統很難擴展。在某個時候我們可以把它拆成多個服務。如果各個都用QPS之類的指標來衡量，擴展就容易很多，也更容易拆分給多個團隊。

熱鬧關鍵詞：可伸縮性、松耦合、單體系統。

讓我們重寫所有的服務！我們的單體系統已經是一鍋粥了。得把所有東西都拆成微服務。

見鬼！現在系統開發的速度變慢了，部署的難度提高了，我們還花了不少時間在多個系統之間追蹤bug。

微服務需要團隊有充分的DevOps能力，還需要權衡增加系統和團隊擴展性，保證投入划算。在你遇到嚴重的規模問題之前，這樣的投資是超前的。微服務是提煉出來的，不是重寫出來的。按照Martin Folwer的說法，微服務的門檻可不低。

舉例 4：NoSQL

在應對高壓力和處理非結構化數據時，關係型資料庫有不少問題。全世界的團隊都在研究新一代資料庫。

熱鬧關鍵詞：可伸縮性、大數據、高性能

我們的資料庫太慢，而且容量不夠。我們需要NoSQL。

我們還需要聯表查詢？這可不行。簡單的SQL操作現在都越來越有挑戰了。開發速度越來越慢，我們的核心問題還沒解決。

NoSQL是用來解決特定問題的（要麼是海量的非結構化數據，要麼是非常高的負載）。如果專業水平足夠高，關係資料庫也是應對高負載和處理海量數據的好工具。非得使用NoSQL的情況，在2016年仍然不多見。

舉例 5：Elixir和Phoenix (或者是你喜歡的語言/框架組合)

RoR之類的Web框架不能很好地應付高性能應用、分散式應用、Websockets。

熱鬧關鍵詞：可伸縮性、高性能、分散式、容錯性。

噢，我們的系統太慢，我們的聊天系統不是可伸縮的。

才發現，學習函數式編程和分散式解決方案沒那麼容易，我們進展真慢。

Elixir和Phoenix是很優秀的框架，但學習成本太高。如果你確實需要高性能的系統，它的益處要很長時間才會顯現。

推而廣之

在軟體開發的小小天地里，已經有太多領域是熱鬧非凡的了。在JavaScript里，幾乎每天都有新框架誕生。Node.js(關鍵詞：事件編程），React編程，Meteor.js（關鍵詞：共享狀態），前端MVC，React.js…… 你可以隨便舉例。軟體工程領域裡新概念也層出不窮：領域驅動開發，六邊形架構理論，DCI架構（數據-場景-交互）。你最喜歡哪一種呢？

正面的例子

如果我們不能相信網上的言論或是其他人的說法，那如何做出聰明的選擇？下面是一些好的建議：

先測試、研究，再決定

快速搭建原型，不要從博客學習，而要從經驗學習。針對新技術提供的功能，在決定採用之前花一兩天搭個原型，然後組織大家分析利弊。你可能會遇到若干能彼此替代的技術，可以讓團隊里不同人用不同的技術來搭原型。

黑客馬拉松，這也是不錯的辦法，它讓大家真正感受到不同技術的代價。對所有兼具風險和誘惑力的技術，都讓整個團隊花一兩天來把玩。這會讓大家自主做出聰明的選擇，根據自己的經驗來決策。

何時開始？

原則上說，應當選擇投資回報巨大的時間點開始。大多數技術是用來解決特定問題的。你遇到了那個問題嗎？那個問題重要不重要？會不會節省很多時間？新技術帶來的好處能不能抵消學習成本和重新的成本？如果我們的開發速度從一開始就降低到正常水平1/2甚至1/4？想想新技術還值得嗎？

優秀的團隊有更多自主權——一些團隊確實比其他團隊更快出成果，他們也更容易厭煩自己手頭的工作。這些團隊可以更多更快地引入新技術。但這不是省略快速搭建原型或者黑客馬拉松的理由。相反，如果這樣的團隊在交付上遇到了麻煩，一定要加倍小心。

找到對的人

有良好技術背景的人——那些人了解不同的範式，理解編程的理論（演算法和並發），受過良好工程文化熏陶，這樣的人很少去湊熱鬧。

有經驗的人——年輕的開發人員更喜歡湊熱鬧。如果有多年的開發經驗，見過許多技術，踩過許多坑，在技術決策時就更容易做出客觀的判斷。

今日薦文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！