好記憶不如爛筆頭，能記下點東西，就記下點，有時間拿出來看看，也會發覺不一樣的感受。

不談具體技術，從更高層面看，技術選型應該怎麼做？
寫在前面
技術選型是一個很熱門的話題，最近我看到自己的微信朋友圈有好幾篇關於技術選型的文章，讀者對這類主題的熱情很高。在技術組織內部，技術人員經常會面臨技術選型問題，有時候，技術選型還常常牽扯好幾波干係人，相互之間還會產生爭議，有的甚至還可能發展到派系鬥爭的地步。即便像我自己，已經有十幾年研發和架構經驗的老司機，不管是工作還是業餘，有很大部分時間的思考都是深陷在 A 技術和 B 技術的利弊權衡之中，不能自拔。無論如何，技術選型說小了關乎專案和團隊成敗，說大了關乎企業業務的發展，不可小覷。


本文所表達的技術選型理念應該是與具體技術無關的，但是由於我個人的背景更偏向網際網路後端的研發和架構，所以本文的視角更偏向後端技術的選型。


軟體的本質複雜性
近年，雲端計算、微服務、容器和 DevOps 等新技術和理念層出不窮，技術人員對各種新技術的追捧熱情也空前高漲，各種新技術微信討論群也如雨後春筍般冒了出來。這是一個好現象，說明我們的開發人員多了，技術環境也日趨成熟，有點百花齊放的感覺。同時也讓我有一點擔憂，我擔憂的是純技術和工具論的擡頭，也就是太過專注技術，認為技術可以搞定一切，反而忽略了軟體研發的本質複雜性。回想當年，自己也曾是這樣的技術狂熱分子，EJB 剛出來的時候，我為 EJB 搖旗吶喊，Spring 出來的時候，我也曾一度是該技術的死忠，簡單認為這些技術是銀彈可以幫助解決所有的複雜性問題。


1986 年，人月神話的作者 Brooks 就提出，軟體的本質複雜性（Essential Complexity）存在於複雜的業務領域中（用技術的話講是業務領域建模複雜性），技術僅是輔助工具，它解決的問題是幫助將業務領域問題對映轉換成軟體實現，只解決次要複雜性（Accidental Complexity）。


作者同時指出，由於軟體本質的複雜性，真正的銀彈並不存在；也斷言在十年內，沒有任何一項技術或者方法可使軟體工程的生產力提高一個數量級。30 年前作者提出的論斷，今天依然閃爍智慧的光芒。人月神話已經出了 40 週年紀念版了，堪稱軟體工程的聖經，建議所有從事軟工行業的朋友學習。除了業務和技術，我還想強調軟體的本質複雜性同時隱含在企業的人、組織、流程和管理中，不容忽視。


架構師只有深刻理解軟體的本質複雜性，才能站在解決實際業務問題的角度，更好的做出技術選型，否則易陷入唯技術工具論的陷阱。


使用成熟的技術
大部分公司都是商業組織，不是科研機構或者純軟體研發機構。商業組織使用技術是為了解決當下的業務問題，他們更應該使用成熟穩定的技術。


如下圖，技術的使用有明顯的生命週期，早期有創新者和早期使用者採用，我把這個階段稱為試水趟坑期，也就是說這個階段技術不是很成熟穩定的，雖然嘗新者可能佔據一定的技術領先優勢，但是他們常常需要以踩坑填坑作為代價；如果這項技術經過早期驗證則會跨越鴻溝進入早期大眾階段，這個階段技術會逐漸走向成熟，處於上升期，坑逐漸被填平，技術被大眾所採納；之後技術緩慢經過末期大眾階段，最終走向滯後期，一直到生命週期的結束退出歷史舞臺。


技術選型的一大智慧是不要盲目追求新技術，老老實實採用成熟穩定的技術，讓那些喜歡追新的人去踩坑