別再學習框架了,你覺得呢?
作者 | Eduards Sizovs
譯者 | 謝麗
作為開發人員,我們需要跟上技術發展的步伐。每天,我們都在學習新的編程語言、框架和庫。但是,技術和時尚一樣,正在以光速變化。本文作者認為,這是一場沒有贏家的比賽,因為技術的發展沒有終點。因此,他建議大家停止學習框架,而是把最寶貴的時間花在可遷移的技能上。本文的英文原文在 Hacker News 上獲得了接近 500 個點贊。其實每過幾年都會有類似的文章出現,然而程序員卻依然疲於學習新的框架,希望本文能給你帶來一些啟發。
我們是開發人員。我們需要跟上技術發展的步伐。每天,我們都在學習新的編程語言、框架和庫。我們知道的現代化工具越多越好。
跟蹤 Angular、React、Vue、Riot、Ember、Knockout 的最新進展很有意思。
但是,我們在浪費自己的時間。
時間是我們擁有的最寶貴的資源。時間是有限的,不可再生的,你無法多買一點。
技術和時尚一樣,正在以光速變化。為了趕上其發展速度,我們就需要跑得很快。這場比賽沒有贏家,因為它沒有終點。
來自 Martin Scorsese 2013 年拍攝的《華爾街之狼》
我的導師曾給我上過這樣一課。
導師:「Ed,你在做什麼?」
我(驕傲的): 「我在讀一本有關使用 GWT 構建現代 Java 應用的書。」
導師: 「為什麼?」
我: 「作為一名 Java 開發人員,我需要緊跟潮流。GWT 是流行趨勢。」
導師:「在 GWT 之前,你讀過什麼技術書籍?」
我: 「一本關於 Apache Tapestry 的 500 頁的著作。 Tapestry 那時是流行趨勢。」
導師:「Tapestry 現在還流行嗎?」
我: 「不流行了。現在流行 GWT。」
導師:「你還可以重用 Tapestry 的技能來解決當前的問題嗎?」
我: 「不能,現在沒人用它了。」
導師:「Tapestry 的知識能幫助你更好地理解 GWT 嗎?」
我: 「不,不能。但我看到了一些重疊的模式。」
導師:「那是設計模式。它們能幫你解決當前的問題嗎?」
我: 「是的。可以解決其中許多問題。」
導師:「技術變化無定,但有很多共同點。確定好優先順序。將 80% 的學習時間投入到基礎知識上。剩下的 20% 用於框架、庫和工具。」
我: 「嗯…僅 20% 用於框架、庫和工具?」
導師:「是的。反正你在工作中解決問題的時候會學習它們。」
我: 「謝謝。」
導師:「你以後會感謝我的。」
這個建議改變了我的生活
。我從我的書架上拿走了所有介紹框架的書。這些書從 50 本降到了 0 本。我總算鬆了一口氣!我買了一套常青樹著作。這些書佔據了我 80% 的學習時間。
《程序員修鍊之道》
《代碼整潔之道》
《程序員的職業素養》
《領域驅動設計》
《測試驅動的面向對象軟體開發》
《持續交付》
我還買了一本關於當前技術的書。
Lindy 效應
表明,Spring 框架一定是項不錯的投資:技術未來的預期壽命與其當前的年齡成正比。它每多活一段時間,預期壽命就會延長。
一項技術在市場上存在的時間越長,投資就越安全。
不要急於學習新技術——它有很高的死亡幾率。
時間會證明哪項技術值得投資。時間是你最好的導師。學會等待。
10 年過去了。我為 50 個不同的軟體項目提供了幫助。由於這些建議,我學到的所有東西都可以跨公司、團隊和領域遷移。我的知識到今天仍然有用。我沒有浪費時間。
除非你能看透表象,否則所有的項目看上去都不同:
編程語言不同,但設計類似;
框架不同,但會體現出同樣的設計模式;
開發人員不同,但與人打交道的規則一致。
記住——框架、庫和工具變化無定。時間寶貴。
來自 Andrew Niccol 2011 年拍攝的《時間規劃局》
把最寶貴的時間花在可遷移的技能上——那些永不過時的技能。
不是微服務框架,而是演化架構;
不是新的編程語言,而是整潔的代碼、設計模式和 DDD;
不是 LeSS、SAFe,而是精益生產原則;
不是 Hystrix,而是容錯模式;
不是 Docker,而是持續交付;
不是 Angular,而是 Web、HTTP 和 REST。
吃瓜群眾咋看?
在 Hacker News 上,這篇帖子引起了熱烈討論,然而,並不是所有人都認可作者的觀點:
網友 1:
學習框架的一個好處是,你可以理解作者的內心,另一個好處是你可以看到作者最初的抽象模式和想法。
學習 Rails 教會了我元編程、可逆資料庫遷移、ACID 以及 ORM 的優缺點。學習使用 C#構建 XAML 應用程序讓我了解了雙向數據綁定、MVVM、DSL 和套接字通信。學習 React 和 Redux 讓我搞懂了協作線程、函數式編程、事務狀態管理和測試前端功能,而不使用 selenium 和 webdriver。
現在,我已經「知道」了大部分這些知識,但此前並沒有將它們應用到現實世界中。在精心設計的框架中實現這些經驗,教會了我很多理論以外的關於實際應用的知識。
網友 2
:框架有好有壞。原文里提到的 GWT 我用過,體驗非常糟糕。當我在 GWT 最初發布時試用過,它只適用於演示代碼 / 頁面。
解決任何更複雜的問題都要求我搞懂 Java、JavaScript 以及他們用來將 Java 代碼轉換為「生成 JS」代碼的代碼 / 系統 / 進程。對於我有限的大腦,這個問題的複雜性是 O(n ^ 3)。
也許這種狀況已被改變,2017 年我看到他們又發布了一個新版本。
Python 作為一種語言 / 框架在我看來非常好,它非常容易學習、調試、創建複雜的系統並根據需要深入挖掘。
網友 3:
作者說他買了這些書:《程序員修鍊之道》
《代碼整潔之道》
《程序員的職業素養》
《領域驅動設計》
《測試驅動的面向對象軟體開發》
《持續交付》
不是打擊大家的熱情,但這都是一些軟技能書籍。
我曾經在一次 10 小時的飛行中看《程序員修鍊之道》這本書,但是因為太無聊睡著了兩三次。初學者也許能從中學到一些東西,但都是剛入行幾個月需要學習的常識性知識。
每個人的書架上應該都有這類書,以及其他更經典的書,比如《計算機程序設計藝術》(Art of Computer Programming)。有趣的是,我發現幾乎沒人看這些書,並不是因為它們很無聊(軟技能),也不是因為很難學(AOCP),只是因為把它們擺在書架上的儀式感。好像書架上沒有幾本沒看過的編程書,你就不好意思稱自己是個程序員。
棄框架而專轉向軟技能書籍似乎並不是進步。如果你想學習價值更長久的東西,還是學習《計算機科學》更實用點。
我是說演算法和數學。
這還意味著你會接觸功能編程或邏輯編程等範例。我推薦 Haskell,不是因為你需要學習另一種語言,而是因為這個生態系統中的知識上限非常高,而且它是目前關於函數式編程的論文使用的通用語言。
有些技術比其他技術更持久。例如我們仍在使用 POSIX。CPU 體系結構不斷發展,但 CPU 處理指令和訪問內存的基礎知識沒有發生什麼變化。框架和庫十年河東十年河西,但並發性、並行性、非同步性的基本原理不會改變。
作者回復
:「軟技能」這個詞用得不準確。這些書並不是關於軟技能的,而是軟體編程:軟體質量、軟體設計、軟體測試、部署、軟體生命周期等。
《計算機科學》並不能教會你軟體編程。
作為工程師,你不需要學計算機科學,而是編程技巧。
網友 4:
大部分開發者所做的項目都是由其中的利益相關方來決定成敗的。由於沒有使用正確的演算法導致產品失敗的案例數量,和因為期望不合理或構建錯誤的軟體導致產品失敗的案例數量相比,二者之間至少存在一個數量級的差別。
溝通尤其重要,所以關於溝通和架構的書也很重要。
作者回復:
這難道不是選擇偏差的鍋嗎?管理不善的項目肯定不會成功。那些演算法不好的項目雖然能上,但是存在很多技術瑕疵。閱讀軟技能書籍就像在工作中接受強制性的反腐訓練。很明顯這很無聊,然而還是有些人需要它。
各位 InfoQer,您怎麼看?
英文原文
https://sizovs.net/2018/12/17/stop-learning-frameworks/
面對井噴式的業務需求,節奏加快的迭代進程,那些巨頭公司的工程師們都在關注什麼?他們的學習路線與方法是怎樣的?他們的團隊又在落地哪些新技術?
QCon 全球軟體開發大會落地廣州,5 月 25-28 日與你相約萬富希爾頓,分享一線大廠實戰經驗,共同探討技術邊界。目前,
大會 7 折限時優惠
,立減 2040 元,團購更多驚喜!掃描下方二維碼
或點擊閱讀原文
了解,有任何問題歡迎諮詢 Joy 同學,電話:13269078023(微信同號)。
點個好看少個 bug
??
※架構拆分原理解析
※GitHub 9K Star!Apollo作者手把手教你微服務配置中心之道
TAG:InfoQ |