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

在當今前端開發人員的世界裏，JavaScript 疲勞已很是廣泛。彷佛天天都會出現新的框架、架構、命令行工具或 SaaS 服務。新事物的持續涌動讓開發人員倍感疲倦。

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

 

大約在 30 年前我擁有了第一臺本身的計算機，今後便開始了編程生涯。那是一臺二手的 Commodore 64 的電腦，進入「Basic V2」時閃爍的光標像是在歡迎我。

從那之後，開發的世界裏惟一不變的就是變化，以及不斷學習和發現的須要。關於如何在不斷涌現的新事物中立於不敗之地，我有下面一些見解。

1、 瞭解歷史

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

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

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

該領域中變化繁多且頻頻發生，很容易讓人以爲那些新東西真的是新的。但使人驚訝的是科技發展的是週期性很是明顯；表面看似是新東西，其實每每有深入的歷史淵源。

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 的經驗教訓。

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

紮實的歷史知識能夠爲你提供一個很是好的工具包，在面臨新技術時能夠想一想：此次有什麼不一樣？該問題的答案一般會決定一個新技術的成敗。

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

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

是否有明肯定義的願景？

是否有明確的用戶需求？

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

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

背後的支持者是誰？

人們每每覺得工具和科技能夠自行發展。例如，面向對象編程演變成了函數式編程，文本編輯器發展成了徹底成熟的集成開發環境（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 也可讓咱們更好地瞭解將來的技術。

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

三：知其然，更要知其因此然

不要專一於表面，咱們須要關注底下的暗潮涌動。學習不一樣框架的語法或語言可讓你作好工做，可是瞭解這些技術的決策過程能夠從根本上讓你成爲更好的開發人員。

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

大膽地擁抱新事物！可是要有條不紊。讓本身創建正確而堅持的基礎。最終可讓你更快地採用新技術，更深刻地瞭解它們，並更完全地評估它們的持久力。

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

我是一個粗枝大葉的打字員，我歷來作不到輸入完整的程序而不會有任何錯誤。與複製和粘貼 Stack Overflow 的代碼段相比，這其實是印在紙上的計算機程序的一個好處（無能否認的僅有的幾個！），由於爲了跑通代碼，你須要真正理解代碼。

做爲開發人員，咱們經常面臨最後期限迫在眉睫的狀況，咱們須要揹負壓力盡快將新功能和改好的 Bug 交付到客戶手中。我見過那些急於求成的開發人員，他們只是將代碼庫和代碼片斷放在一塊兒，根本沒有時間去理解其中的工做原理。或者，他們發現有什麼不對的地方，而後只是嘗試不一樣的解決方案，而不是首先花時間瞭解爲何系統出了問題。

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

有時你會發現一個小的改動（也許只是使用了另外一個庫，調用了不一樣的函數等）就能改好一個 Bug，可是你並不明白其中的緣由。不能就此打住，你須要深刻研究，搞清楚爲何原來那個解決方案失敗了，而如今這個可行。這種深刻研究經常可讓你找到一些蛛絲馬跡，並發現潛伏在系統其餘地方的 bug。

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

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

4、付諸實踐

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

寫在最後：歡迎留言討論，加關注，持續更新！！！