編者按：本文來(lái)自微信公眾號(hào)“CSDN”（ID：CSDNnews)，作者 Mathias Biilmann（Netlify 的創(chuàng)立人和 CEO），譯者 彎月，責(zé)編 唐小引。36氪經(jīng)授權(quán)轉(zhuǎn)載。

在當(dāng)今前端開(kāi)發(fā)人員的世界里，JavaScript 疲勞已非常普遍。似乎每天都會(huì)出現(xiàn)新的框架、架構(gòu)、命令行工具或 SaaS 服務(wù)。新事物的持續(xù)涌動(dòng)讓開(kāi)發(fā)人員倍感疲倦。

為了避免這種情況，樹(shù)立一種可靠的本能很重要——即甄別那些值得花時(shí)間去研究的技術(shù)和產(chǎn)品的能力，有些技術(shù)和產(chǎn)品在歷經(jīng)曇花一現(xiàn)后就銷聲匿跡，關(guān)于它們的文章在科技博客上也被歸檔，最后連正反兩面的評(píng)論也都被遺忘了。

大約在 30 年前我擁有了第一臺(tái)自己的計(jì)算機(jī)，從此便開(kāi)始了編程生涯。那是一臺(tái)二手的 Commodore 64 的電腦，進(jìn)入“Basic V2”時(shí)閃爍的光標(biāo)像是在歡迎我。

從那以后，開(kāi)發(fā)的世界里唯一不變的就是變化，以及不斷學(xué)習(xí)和發(fā)現(xiàn)的需要。關(guān)于如何在不斷涌現(xiàn)的新事物中立于不敗之地，我有下面一些看法。

01  了解歷史

在這樣一篇討論如何在變革中處于領(lǐng)先地位的文章中，談及歷史可能有點(diǎn)出乎意料，但是為了了解和評(píng)估當(dāng)代科技，你必須先了解該領(lǐng)域的歷史。

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

2004 年，Ruby on Rails 問(wèn)世，并迅速崛起，對(duì)整個(gè)行業(yè)產(chǎn)生了巨大影響。與此同時(shí)，它的基本思想還是基于模型視圖控制器（Model View Controller，MVC）模式，以及 Ruby 面向?qū)ο竽Ｊ降幕A(chǔ)，這些技術(shù)可以追溯到 70 年代末的 Small Talk 編程環(huán)境。

作為當(dāng)時(shí)熟悉主流網(wǎng)絡(luò)平臺(tái)（PHP、Java、ASP）的開(kāi)發(fā)人員來(lái)說(shuō)，Ruby on Rails 不僅推出了具有全新語(yǔ)法的新語(yǔ)言，還提出了新的概念和主要的元編程的新范例。然而，對(duì)于那些一直關(guān)注 SmallTalk 的興衰以及受其啟發(fā)而創(chuàng)建的語(yǔ)言和平臺(tái)的開(kāi)發(fā)人員來(lái)說(shuō)，Ruby on Rails 是一個(gè)很熟悉的概念（新型的語(yǔ)法，并采用一些 SmallTalk 應(yīng)用程序的方式來(lái)實(shí)現(xiàn) Web 應(yīng)用）。他們僅需掌握 Ruby 和 SmallTalk 之間的差異（很重要但是差異并不大），以及 MVC 在 Web 和 Small Talk 應(yīng)用程序之間的差異。

與之類似，React 的出現(xiàn)把整整一代 JavaScript 框架都掃進(jìn)了垃圾堆。其中大部分框架都受到了 Rails 的啟發(fā)，試圖將 MVC 模型轉(zhuǎn)移到瀏覽器中。對(duì)于很多開(kāi)發(fā)人員來(lái)說(shuō)，它似乎與依賴雙向數(shù)據(jù)綁定模板的單頁(yè)面的應(yīng)用程序框架有很大的不同，與 JQuery 等簡(jiǎn)化的代碼庫(kù)也不一樣。但是 React 的核心其實(shí)是受到了函數(shù)式編程語(yǔ)言（尤其是 OCAML）的啟發(fā)，這可以一直追溯到計(jì)算機(jī)的早期階段。

React 的創(chuàng)始人 Jordan Walke 最近在敘述自己的經(jīng)歷時(shí)，回顧了創(chuàng)建 React 的歷史背景：

在很長(zhǎng)一段時(shí)間里，我以為“天啊，我覺(jué)得我只是個(gè)奇怪的程序員。”后來(lái)，我參加了一門關(guān)于編程語(yǔ)言基礎(chǔ)的課程（課程的大部分使用了 ML（SML）），而我終于掌握了一些如何描述我想建立的應(yīng)用程序的一些基本術(shù)語(yǔ)。我還學(xué)習(xí)了編程風(fēng)格，吸引我的既不是古怪，也不是新穎的思想，實(shí)際上是一些最古老的編程語(yǔ)言的思想（那些從未成為主流的思想），這些思想在軟件業(yè)界經(jīng)歷了 20 多年的風(fēng)吹雨打（在我看來(lái)都在朝著壞的方向發(fā)展）。

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

對(duì)于很多前端開(kāi)發(fā)人員來(lái)說(shuō)，React 中完全成熟的狀態(tài)管理融合了 Redux 的形式（也許是結(jié)合了 Immutable.js）讓人一時(shí)有點(diǎn)難以理解。但是對(duì)于了解其后的歷史背景并關(guān)注函數(shù)式編程（其概念可以追溯到 1958 年出現(xiàn)的 LISP）再現(xiàn)的開(kāi)發(fā)人員來(lái)說(shuō)，React 反映了熟悉的概念和想法。

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

這可以成為學(xué)習(xí)新技術(shù)的一個(gè)好工具，提高學(xué)習(xí)速度；我們無(wú)需再閱讀最新的教程和新出現(xiàn)的文檔，而是要弄清楚它們的靈感來(lái)源，以及它們引用的之前的知識(shí)和創(chuàng)立的基礎(chǔ)。很多關(guān)于舊技術(shù)、想法和方法論的資料更加成熟，你會(huì)發(fā)現(xiàn)很多經(jīng)驗(yàn)教訓(xùn)也完全可以使用該領(lǐng)域的新成果。

扎實(shí)的歷史知識(shí)可以為你提供一個(gè)非常好的工具包，在面臨新技術(shù)時(shí)可以想想：這次有什么不同？該問(wèn)題的答案通常會(huì)決定一個(gè)新技術(shù)的成敗。

02  人、文化和社區(qū)都很重要

人們往往以為工具和科技可以自行發(fā)展。例如，面向?qū)ο缶幊萄葑兂闪撕瘮?shù)式編程，文本編輯器發(fā)展成了完全成熟的集成開(kāi)發(fā)環(huán)境（IDE），還有動(dòng)態(tài)語(yǔ)言轉(zhuǎn)變成了靜態(tài)類型語(yǔ)言。然而，新技術(shù)和框架不僅僅沿著自身的道路發(fā)展。它們是由人、組織和社區(qū)發(fā)明、構(gòu)建并傳播的。

當(dāng)一種新型的工具或技術(shù)涌現(xiàn)時(shí)，其背后的技術(shù)基礎(chǔ)（它有什么不同？構(gòu)建的基礎(chǔ)模式是什么？）和動(dòng)機(jī)（為什么有人選擇現(xiàn)在創(chuàng)建這個(gè)？哪些人會(huì)對(duì)此感興趣？這項(xiàng)技術(shù)可以為公司解決哪些問(wèn)題？）非常重要。

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

在文章中，Gabriel 描述了“糟糕的設(shè)計(jì)卻有更好的發(fā)展”，他比較了新澤西學(xué)校和麻省理工與斯坦福大學(xué)的設(shè)計(jì)，表明實(shí)現(xiàn)的簡(jiǎn)單性比終端界面的簡(jiǎn)單性或正確性更重要。正是這一點(diǎn)使得 C 和 Unix 在市場(chǎng)上擊敗了 LISP。C 編譯器比 LISP 編譯器更加容易實(shí)現(xiàn)、移植和優(yōu)化，這使得 Unix 的實(shí)現(xiàn)人員可以更快地向用戶交付軟件。這導(dǎo)致這項(xiàng)技術(shù)被迅速采納，并最終意味著更多人（和公司）向 C 和 Unix 生態(tài)系統(tǒng)的發(fā)展和完善投資。

在學(xué)習(xí)新技術(shù)時(shí)，不僅要理解它們的目標(biāo)，以及在技術(shù)上的實(shí)現(xiàn)方法，還要了解它們的傳播方式，以及社區(qū)的發(fā)展。通常變成重要的主流編程社區(qū)的技術(shù)正是那些能投為后續(xù)問(wèn)題提供最佳解決方法的技術(shù)，即使有時(shí)它們看似是在舊技術(shù)的基礎(chǔ)上發(fā)展起來(lái)的。

但真正的秘密是：

有時(shí)候領(lǐng)先于技術(shù)的工具注定無(wú)法得到廣泛的采用（我敢打賭很快我們就不會(huì)用 Idris 語(yǔ)言編寫 Web 應(yīng)用了）。LISP 從未成為主流，但是當(dāng)今很多主流框架、語(yǔ)言、代碼庫(kù)和技術(shù)都源自 LISP 的發(fā)明和探索的創(chuàng)意，即使在今天學(xué)習(xí) LISP 也可以讓我們更好地了解未來(lái)的技術(shù)。

如果你發(fā)現(xiàn)有的工具正處在這樣的交叉路口，那么掌握這些情況可能會(huì)讓你成為下一個(gè)超級(jí)開(kāi)發(fā)。

03  知其然，更要知其所以然

在我做開(kāi)發(fā)的時(shí)候，與 StackOverflow 非常接近的是帶有源代碼的計(jì)算機(jī)雜志，你可以手動(dòng)將這些代碼輸入到你的機(jī)器上并運(yùn)行程序。

我是一個(gè)粗心大意的打字員，我從來(lái)做不到輸入完整的程序而不會(huì)有任何錯(cuò)誤。與復(fù)制和粘貼 Stack Overflow 的代碼段相比，這實(shí)際上是印在紙上的計(jì)算機(jī)程序的一個(gè)好處（無(wú)可否認(rèn)的僅有的幾個(gè)！），因?yàn)闉榱伺芡ùa，你需要真正理解代碼。

作為開(kāi)發(fā)人員，我們常常面臨最后期限迫在眉睫的情況，我們需要背負(fù)壓力盡快將新功能和改好的 Bug 交付到客戶手中。我見(jiàn)過(guò)那些急于求成的開(kāi)發(fā)人員，他們只是將代碼庫(kù)和代碼片段放在一起，根本沒(méi)有時(shí)間去理解其中的工作原理?；蛘撸麄儼l(fā)現(xiàn)有什么不對(duì)的地方，然后只是嘗試不同的解決方案，而不是首先花時(shí)間了解為什么系統(tǒng)出了問(wèn)題。

不要學(xué)他們。記住，永遠(yuǎn)不要無(wú)腦地借用 Stack Overflow 或其他地方的解決方案，你需要花時(shí)間掌握解決方案可行的原因。更進(jìn)一步挑戰(zhàn)自己，弄清楚為了找到你自己的解決方案，你需要花費(fèi)多少時(shí)間，需要哪些資源等。

有時(shí)你會(huì)發(fā)現(xiàn)一個(gè)小的改動(dòng)（也許只是使用了另一個(gè)庫(kù)，調(diào)用了不同的函數(shù)等）就能改好一個(gè) Bug，但是你并不明白其中的原因。不能就此打住，你需要深入研究，搞清楚為什么原來(lái)那個(gè)解決方案失敗了，而現(xiàn)在這個(gè)可行。這種深入研究常?？梢宰屇阏业揭恍┲虢z馬跡，并發(fā)現(xiàn)潛伏在系統(tǒng)其他地方的 bug。

學(xué)習(xí)新技術(shù)時(shí)的狀況也一樣。不要專注于表面的學(xué)習(xí)。學(xué)習(xí)不同框架的語(yǔ)法或語(yǔ)言對(duì)你沒(méi)有太多好處，但是了解這些技術(shù)下面的決策過(guò)程可以從根本上讓你成長(zhǎng)為更好的開(kāi)發(fā)人員。

當(dāng)一項(xiàng)工作或?qū)W習(xí)結(jié)束以后，最重要的不是你學(xué)到了什么（哪個(gè)框架、哪個(gè)工具、哪種語(yǔ)言），而是通過(guò)學(xué)習(xí)的過(guò)程你學(xué)到的了什么。

04  付諸實(shí)踐

即便是對(duì)資深程序員來(lái)說(shuō)，選擇合適的工具也并不簡(jiǎn)單。選擇依賴眾所周知的、值得信賴的和可靠的工具，還是采用新技術(shù)（用新的更好的方法來(lái)解決問(wèn)題），我們需要在這兩者之間權(quán)衡利弊。但是，作為開(kāi)發(fā)工作的一部分，一些事前工作可以幫助你成功地選擇新工具并利用新工具實(shí)現(xiàn)功能。這實(shí)際上是一項(xiàng)不斷發(fā)展的實(shí)踐。下面是本文建議的幾種做法。

一、了解歷史

歷史知識(shí)可以讓你擁有扎實(shí)的基礎(chǔ)，幫助你思考：“這次有什么不同？”該問(wèn)題的答案常常會(huì)決定這項(xiàng)新技術(shù)的成敗。新鮮事物很酷，新鮮事物很有趣。但是如果過(guò)快的發(fā)展速度和 JavaScript 帶來(lái)的間歇性的爆發(fā)，讓你感覺(jué)難以接受時(shí)，你可以放慢腳步，記住這是一個(gè)漫長(zhǎng)的過(guò)程，并且順應(yīng)大趨勢(shì)比不斷急于用最新的框架重寫應(yīng)用更為重要。

Peter Norvig 就這個(gè)問(wèn)題發(fā)表了一篇很好的文章《十年內(nèi)自學(xué)編程》（Teach Yourself Programming in Ten Years）

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

二、人、文化和社區(qū)很重要

感謝 GitHub、Stack Overflow 和 NPM 的迅速崛起，我們可以更加輕松地了解社區(qū)的發(fā)展，以及開(kāi)發(fā)人員的雄心壯志。雖然貢獻(xiàn)度和給星表明很多項(xiàng)目已經(jīng)取得成功，但在初期從這兩點(diǎn)并不能看出項(xiàng)目的成功與否。然而，你會(huì)用下列方法選擇技術(shù)來(lái)創(chuàng)建自己的軟件或選擇自己想去的公司，你也可以用相同的邏輯來(lái)確定一個(gè)項(xiàng)目是否會(huì)被社區(qū)接受：

• 是否有明確定義的愿景？

• 是否有明確的用戶需求？

• 是否有合適的人員、資源和文檔可以擴(kuò)展？

• 是否具有可擴(kuò)展性？例如，是否可以擴(kuò)展或采用新興技術(shù)或用戶類型？

• 背后的支持者是誰(shuí)？

三、知其所以然

不要專注于表面，我們需要關(guān)注底下的暗潮涌動(dòng)。學(xué)習(xí)不同框架的語(yǔ)法或語(yǔ)言可以讓你做好工作，但是了解這些技術(shù)的決策過(guò)程可以從根本上讓你成為更好的開(kāi)發(fā)人員。

Michael Feathers 列出了“每個(gè)開(kāi)發(fā)人員應(yīng)該閱讀的 10 篇論文”[2]。所有這些文章都是關(guān)于語(yǔ)言、架構(gòu)和文化的基本思想，并可以讓你初步了解諸多趨勢(shì)背后的基本思路，而這些直到今時(shí)今日仍然活躍在編程業(yè)內(nèi)。

大膽地?fù)肀率挛?！但是要有條不紊。讓自己建立正確而堅(jiān)持的基礎(chǔ)。最終可以讓你更快地采用新技術(shù)，更深入地了解它們，并更徹底地評(píng)估它們的持久力。

參考資源：

[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