對於很多前端開發人員來說，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。
“徵稿啦”
CSDN 公眾號秉持著「與千萬技術人共成長」理念，不僅以「極客頭條」、「暢言」欄目在第一時間以技術人的獨特視角描述技術人關心的行業焦點事件，更有「技術頭條」專欄，深度解讀行業內的熱門技術與場景應用，讓所有的開發者緊跟技術潮流，保持警醒的技術嗅覺，對行業趨勢、技術有更為全面的認知。
如果你有優質的文章，或是行業熱點事件、技術趨勢的真知灼見，或是深度的應用實踐、場景方案等的新見解，歡迎聯繫 CSDN 投稿，聯繫方式：微信（guorui_1118，請備註投稿+姓名+公司職位），郵箱（[email protected]）。
閱讀更多 CSDN 的文章
