不要做一個只會面向搜索編程的程序員！

在當今前端開發人員的世界裡，JavaScript 疲勞已非常普遍。似乎每天都會出現新的框架、架構、命令行工具或 SaaS 服務。新事物的持續涌動讓開發人員倍感疲倦。

為了避免這種情況，樹立一種可靠的本能很重要——即甄別那些值得花時間去研究的技術和產品的能力，有些技術和產品在歷經曇花一現後就銷聲匿跡，關於它們的文章在科技博客上也被歸檔，最後連正反兩面的評論也都被遺忘了。

大約在 30 年前我擁有了第一台自己的計算機，從此便開始了編程生涯。那是一台二手的 Commodore 64 的電腦，進入「Basic V2」時閃爍的游標像是在歡迎我。

從那以後，開發的世界裡唯一不變的就是變化，以及不斷學習和發現的需要。關於如何在不斷湧現的新事物中立於不敗之地，我有下面一些看法。

了解歷史

在這樣一篇討論如何在變革中處於領先地位的文章中，談及歷史可能有點出乎意料，但是為了了解和評估當代科技，你必須先了解該領域的歷史。

該領域中變化繁多且頻頻發生，很容易讓人覺得那些新東西真的是新的。但令人驚訝的是科技發展的是周期性非常明顯；表面看似是新東西，其實往往有深刻的歷史淵源。

2004 年，Ruby on Rails 問世，並迅速崛起，對整個行業產生了巨大影響。與此同時，它的基本思想還是基於模型視圖控制器（Model View Controller，MVC）模式，以及 Ruby 面向對象模式的基礎，這些技術可以追溯到 70 年代末的 Small Talk 編程環境。

作為當時熟悉主流網路平台（PHP、Java、ASP）的開發人員來說，Ruby on Rails 不僅推出了具有全新語法的新語言，還提出了新的概念和主要的元編程的新範例。然而，對於那些一直關注 SmallTalk 的興衰以及受其啟發而創建的語言和平台的開發人員來說，Ruby on Rails 是一個很熟悉的概念（新型的語法，並採用一些 SmallTalk 應用程序的方式來實現 Web 應用）。他們僅需掌握 Ruby 和 SmallTalk 之間的差異（很重要但是差異並不大），以及 MVC 在 Web 和 Small Talk 應用程序之間的差異。

與之類似，React 的出現把整整一代 JavaScript 框架都掃進了垃圾堆。其中大部分框架都受到了 Rails 的啟發，試圖將 MVC 模型轉移到瀏覽器中。對於很多開發人員來說，它似乎與依賴雙向數據綁定模板的單頁面的應用程序框架有很大的不同，與 JQuery 等簡化的代碼庫也不一樣。但是 React 的核心其實是受到了函數式編程語言（尤其是 OCAML）的啟發，這可以一直追溯到計算機的早期階段。

React 的創始人 Jordan Walke 最近在敘述自己的經歷時，回顧了創建 React 的歷史背景：

在很長一段時間裡，我以為「天啊，我覺得我只是個奇怪的程序員。」後來，我參加了一門關於編程語言基礎的課程（課程的大部分使用了 ML（SML）），而我終於掌握了一些如何描述我想建立的應用程序的一些基本術語。我還學習了編程風格，吸引我的既不是古怪，也不是新穎的思想，實際上是一些最古老的編程語言的思想（那些從未成為主流的思想），這些思想在軟體業界經歷了 20 多年的風吹雨打（在我看來都在朝著壞的方向發展）。

https://www.reactiflux.com/transcripts/jordan-walke/

對於很多前端開發人員來說，React 中完全成熟的狀態管理融合了 Redux 的形式（也許是結合了 Immutable.js）讓人一時有點難以理解。但是對於了解其後的歷史背景並關注函數式編程（其概念可以追溯到 1958 年出現的 LISP）再現的開發人員來說，React 反映了熟悉的概念和想法。

即使在積極嘗試學習新技術時，歷史也可以起到很大的幫助。當 Rails 首次發布時，除了一些在線文檔、教程和源代碼本身（稍後將詳細介紹源代碼）之外，很難找到相關的資料。然而，有很多關於 MVC 演變到 Small Talk，再到 Objective-C 的文章，以及很多基於 Small Talk 的消息傳遞機制的元編程和 OOP 的經驗教訓。

這可以成為學習新技術的一個好工具，提高學習速度；我們無需再閱讀最新的教程和新出現的文檔，而是要弄清楚它們的靈感來源，以及它們引用的之前的知識和創立的基礎。很多關於舊技術、想法和方法論的資料更加成熟，你會發現很多經驗教訓也完全可以使用該領域的新成果。

紮實的歷史知識可以為你提供一個非常好的工具包，在面臨新技術時可以想想：這次有什麼不同？該問題的答案通常會決定一個新技術的成敗。

人、文化和社區都很重要

人們往往以為工具和科技可以自行發展。例如，面向對象編程演變成了函數式編程，文本編輯器發展成了完全成熟的集成開發環境（IDE），還有動態語言轉變成了靜態類型語言。然而，新技術和框架不僅僅沿著自身的道路發展。它們是由人、組織和社區發明、構建並傳播的。

當一種新型的工具或技術湧現時，其背後的技術基礎（它有什麼不同？構建的基礎模式是什麼？）和動機（為什麼有人選擇現在創建這個？哪些人會對此感興趣？這項技術可以為公司解決哪些問題？）非常重要。

我最喜歡的一篇關於為什麼有些工具可以獲勝而有些被淘汰的文章是 Richard P. Gabriel 於 1989 年寫的《The Rise of Worse is Better》[1]。文章描述了為什麼 Unix 和 C 戰勝了基於 LISP 的技術（其原因與兩種解決方案內在的品質無關）。

在文章中，Gabriel 描述了「糟糕的設計卻有更好的發展」，他比較了新澤西學校和麻省理工與斯坦福大學的設計，表明實現的簡單性比終端界面的簡單性或正確性更重要。正是這一點使得 C 和 Unix 在市場上擊敗了 LISP。C 編譯器比 LISP 編譯器更加容易實現、移植和優化，這使得 Unix 的實現人員可以更快地向用戶交付軟體。這導致這項技術被迅速採納，並最終意味著更多人（和公司）向 C 和 Unix 生態系統的發展和完善投資。

在學習新技術時，不僅要理解它們的目標，以及在技術上的實現方法，還要了解它們的傳播方式，以及社區的發展。通常變成重要的主流編程社區的技術正是那些能投為後續問題提供最佳解決方法的技術，即使有時它們看似是在舊技術的基礎上發展起來的。

但真正的秘密是：

有時候領先於技術的工具註定無法得到廣泛的採用（我敢打賭很快我們就不會用 Idris 語言編寫 Web 應用了）。LISP 從未成為主流，但是當今很多主流框架、語言、代碼庫和技術都源自 LISP 的發明和探索的創意，即使在今天學習 LISP 也可以讓我們更好地了解未來的技術。

如果你發現有的工具正處在這樣的交叉路口，那麼掌握這些情況可能會讓你成為下一個超級開發。

知其然，更要知其所以然

在我做開發的時候，與 StackOverflow 非常接近的是帶有源代碼的計算機雜誌，你可以手動將這些代碼輸入到你的機器上並運行程序。

我是一個粗心大意的打字員，我從來做不到輸入完整的程序而不會有任何錯誤。與複製和粘貼 Stack Overflow 的代碼段相比，這實際上是印在紙上的計算機程序的一個好處（無可否認的僅有的幾個！），因為為了跑通代碼，你需要真正理解代碼。

作為開發人員，我們常常面臨最後期限迫在眉睫的情況，我們需要背負壓力儘快將新功能和改好的 Bug 交付到客戶手中。我見過那些急於求成的開發人員，他們只是將代碼庫和代碼片段放在一起，根本沒有時間去理解其中的工作原理。或者，他們發現有什麼不對的地方，然後只是嘗試不同的解決方案，而不是首先花時間了解為什麼系統出了問題。

不要學他們。記住，永遠不要無腦地借用 Stack Overflow 或其他地方的解決方案，你需要花時間掌握解決方案可行的原因。更進一步挑戰自己，弄清楚為了找到你自己的解決方案，你需要花費多少時間，需要哪些資源等。

有時你會發現一個小的改動（也許只是使用了另一個庫，調用了不同的函數等）就能改好一個 Bug，但是你並不明白其中的原因。不能就此打住，你需要深入研究，搞清楚為什麼原來那個解決方案失敗了，而現在這個可行。這種深入研究常常可以讓你找到一些蛛絲馬跡，並發現潛伏在系統其他地方的 bug。

學習新技術時的狀況也一樣。不要專註於表面的學習。學習不同框架的語法或語言對你沒有太多好處，但是了解這些技術下面的決策過程可以從根本上讓你成長為更好的開發人員。

當一項工作或學習結束以後，最重要的不是你學到了什麼（哪個框架、哪個工具、哪種語言），而是通過學習的過程你學到的了什麼。

付諸實踐

即便是對資深程序員來說，選擇合適的工具也並不簡單。選擇依賴眾所周知的、值得信賴的和可靠的工具，還是採用新技術（用新的更好的方法來解決問題），我們需要在這兩者之間權衡利弊。但是，作為開發工作的一部分，一些事前工作可以幫助你成功地選擇新工具並利用新工具實現功能。這實際上是一項不斷發展的實踐。下面是本文建議的幾種做法。

一、了解歷史

歷史知識可以讓你擁有紮實的基礎，幫助你思考：「這次有什麼不同？」該問題的答案常常會決定這項新技術的成敗。新鮮事物很酷，新鮮事物很有趣。但是如果過快的發展速度和 JavaScript 帶來的間歇性的爆發，讓你感覺難以接受時，你可以放慢腳步，記住這是一個漫長的過程，並且順應大趨勢比不斷急於用最新的框架重寫應用更為重要。

Peter Norvig 就這個問題發表了一篇很好的文章《十年內自學編程》（Teach Yourself Programming in Ten Years）

鏈接：http://norvig.com/21-days.html。

二、人、文化和社區很重要

感謝 GitHub、Stack Overflow 和 NPM 的迅速崛起，我們可以更加輕鬆地了解社區的發展，以及開發人員的雄心壯志。雖然貢獻度和給星表明很多項目已經取得成功，但在初期從這兩點並不能看出項目的成功與否。然而，你會用下列方法選擇技術來創建自己的軟體或選擇自己想去的公司，你也可以用相同的邏輯來確定一個項目是否會被社區接受：

是否有明確定義的願景？

是否有明確的用戶需求？

是否有合適的人員、資源和文檔可以擴展？

是否具有可擴展性？例如，是否可以擴展或採用新興技術或用戶類型？

背後的支持者是誰？

三、知其所以然

不要專註於表面，我們需要關注底下的暗潮湧動。學習不同框架的語法或語言可以讓你做好工作，但是了解這些技術的決策過程可以從根本上讓你成為更好的開發人員。

Michael Feathers 列出了「每個開發人員應該閱讀的 10 篇論文」[2]。所有這些文章都是關於語言、架構和文化的基本思想，並可以讓你初步了解諸多趨勢背後的基本思路，而這些直到今時今日仍然活躍在編程業內。

大膽地擁抱新事物！但是要有條不紊。讓自己建立正確而堅持的基礎。最終可以讓你更快地採用新技術，更深入地了解它們，並更徹底地評估它們的持久力。

參考資源：

[1] http://dreamsongs.com/RiseOfWorseIsBetter.html

[2] https://michaelfeathers.silvrback.com/10-papers-every-developer-should-read-at-least-twice

英文：Leveling up: why developers need to be able to identify technologies with staying power (and how to do it)

鏈接：https://medium.com/netlify/leveling-up-why-developers-need-to-be-able-to-identify-technologies-with-staying-power-and-how-to-9aa74878fc08

作者：Mathias Biilmann，Netlify 的創立人和 CEO。

譯者：彎月，責編：唐小引

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