技術的正宗與野路子

時間  2019-11-05
標籤 技術 正宗 路子 简体版
原文   原文鏈接

黃衫女子的武功彷佛與周芷若乃是一路，飄忽靈動，變幻無方，但舉手擡足之間倒是正而不邪，如說周芷若形似鬼魅，那黃衫女子即是態擬神仙。html

這段描寫出自《倚天屠龍記》第三十八回。java

「九陰神抓」本是《九陰真經》中的上乘武功，但當初梅超風夫婦因爲拿到的《九陰真經》不完整，學不到裏面的內功心法，硬是把這門上乘武功練到了邪路上，因而就成了「九陰白骨爪」。周芷若爲求速成，也練就了這門邪功。android

但黃衫女子乃出身武林名門（相傳是楊過和小龍女的後人），天然修煉的是正宗的《九陰真經》。雖然武功路數與周芷若本同屬一脈，但更加「醇真深厚」，天然也更勝一籌。這是金庸武俠中「正宗」武功賽過「野路子」的一個典型案例。ios

那麼，這是否可以說明，「正宗」必定強於「野路子」呢？git

且慢！程序員

喜歡金庸武俠的朋友，可還記得《越女劍》中的阿青？github

阿青本是一名牧羊女，卻在牧羊時巧遇一頭會使竹棒的白猿。在與白猿的玩耍嬉鬧中，她硬是悟得了高超的劍法，竟能以一人之力敵兩千越甲！redis

就是這樣一個從野路子練出來的柔弱女子，即便按廣大金庸迷的保守估計，她也能在整個金庸武俠圖譜中至少排名前五！編程

作技術，猶如修習一門武功。api

歷數我周圍的技術牛人（牛不到必定程度的先不算），他們中既有名牌大學計算機科班畢業的，也有半路出家轉行過來的。

但他們都有一個共同特色：他們在遇到問題後，思考片刻，老是能一會兒切中要害，在表達上也每每一語中的。這也包括那些日常不善言辭的程序員。反觀那些「更通常」的程序員（其中不乏科班畢業的），他們常常很難抓住問題的本質，表達起來也老是說不到點子上。

可見，「正宗」仍是「野路子」，並不在出身。

寫到這裏，我終於本身長出了一口氣。我出身一個極普通的農民家庭，既不是書香門第，也不是技匠世家。記得在大學一年級的上機編程課上，我才發現本身原來根本不會用鍵盤打字。相比那些初中高中就把計算機玩得很溜的同窗，我算野路子嗎？

好了，那「正宗」仍是「野路子」，不在出身在什麼呢？

在於學習和思考的方法。

據我觀察，技術牛人的學習方法和思考方式，大致相似。

思考方式，是個很難說清的東西。因此，本文咱們重點來討論討論學習的方法。

面對一項新技術的時候，咱們怎樣去學習才能按部就班，最終理解得深入？

讓咱們先把可供自學的資料列出來，分析一下：

  • Tutorial（入門教程）。由該項技術的官網提供。一般是英文的。這份資料是給初次接觸該項技術的人看的，通常是一步一步地教你完成某些例子。當咱們說某項技術對於新手不太友好的時候，通常也是由於這項技術的Tutorial部分作得不夠好。
  • Specification，簡稱Spec。這是集中體現該項技術的設計思想的東西，是高度抽象的描述。這個通常也是一份完備的、系統的描述，包含該項技術涉及到的方方面面。這部分資料在不一樣的地方叫法不一樣，在相對簡單的技術項目中，也可能沒有；在另外一些狀況下，這部分資料混雜在其它文檔資料之中；它還可能以論文（paper）的形式出現。
  • API Reference。大而全的API索引和文檔，針對不一樣的語言接口可能提供多份。當咱們使用這項技術進行編程的時候，API Reference天然是個離不開的、老是要不停去查詢的一份資料。
  • 別人寫的技術博客。質量參差不齊，到底有沒有價值，咱們要學會去分辨。
  • 技術書籍。跟技術博客相似，質量有好有壞。稍後咱們和技術博客放在一塊兒來分析。
  • Source Code。若是咱們要學習的技術是開源的，那麼很幸運，咱們能獲得源代碼。這是一份終極資料。

爲了讓這些概念表達無誤，我接下來多舉一些例子。

Java語言

歷來沒有接觸過Java語言的人，要想開始自學Java，從哪裏開始呢？能夠從Oracle官方提供的Tutorial入手：

這份資料《The Java™ Tutorials 》，集中體現了Tutorial類型的資料的特色。它從最開始的編譯和運行環境搭建提及，教你寫出第一個Hello World，再用介紹的方式將Java各類語言特性（變量、類、泛型、Lambda表達式、JavaBeans，等等）進行講解，同時還有對於JDK裏經常使用API（集合類、多線程、IO等等）的介紹。

對初學者而言，須要的就是這樣一份資料。即便你手頭沒有任何Java的入門書籍，讀完這樣的一份資料以後，一個新手基本就能夠開始使用Java來編程了。

再看Spec：

這份文檔，叫作《The Java® Language Specification》。是一份很典型的Spec，完備而規範。

任何講Java語法的資料，包括各類書籍和前面提到的Tutorial，都只能涉及部分。而這份Spec，若是你能讀通的話，那麼與Java語言特性有關的全部一切，你就不再用求人了。

JDK 8的API Reference:

用Java語言編程的時候，咱們須要不斷查閱的就是這份API Reference。咱們日常通常是經過IDE來快速查看某個接口的文檔說明。

Android開發

Android針對新手的Tutorial類型的資料，官網上稱爲Training：

這份資料是典型的Tutorial。它教你製做第一個Android App，並針對若干個主題進行一步一步的教學。

下面這份資料在Android官網上被稱爲：API Guides。

它其實是一份介於Tutorial和Spec之間的文檔。它有不少Spec的特色，好比它介紹Android中的抽象的四大組件的概念，介紹資源尺寸的抽象（dp），介紹View層原理，等等。可是，跟前面看到的Java Spec相比，它沒有那麼規範和正式，描述也更隨意一些，估計也算不上完備（但涉及到了Android技術的絕大部分）。

當咱們對Android中某項具體技術存疑，或是有爭論的時候，咱們就須要來翻翻這份文檔。所以，它基本能夠納入Spec類型。

而後是Android SDK的API Reference：

這份API Reference的質量並不高，描述上過於簡略，甚至模糊不清，其可讀性跟前面提到的JDK 8的API Reference徹底不在一個水平上。這也是一些開源項目的通病，不重視接口文檔。

iOS開發

蘋果在iOS開發方面給出的文檔是至關豐富的，這也是一個閉源系統作得好的地方。

iOS開發的文檔，很難區分出Tutorial和Spec這兩個層面。它由不少文檔組成，每一個文檔描述系統的某一方面。一般是在一個文檔中，既有教學的部分，又有完備描述的部分。

針對徹底的新手入門的話，下面這個文檔，算是真正的一個Tutorial：

其它各個文檔也是介於Tutorial和Spec之間，更偏向Spec。好比：

而後是iOS的API Reference：

如前所述，這份API Reference的可讀性很是高，比Android SDK的要強多了。不少先後相關的概念，在這份API Reference的描述中，都有體現。

固然，除了developer.apple.com以外，iOS的文檔也均可以經過XCode取到。

Redis

Redis的Tutorial是我見過的最好的Tutorial，它對初學者很是友好，不只能讀，還能執行。

Redis的Spec舉例:

Redis的Commands Reference:

TCP/HTTP

網絡協議與前面的都不一樣，它不是一個實現，而是一種標準。

網絡協議的Spec文檔很明顯，就是它們對應的RFC。若是你的工做常常涉及到使用某個網絡協議，恐怕就須要找來RFC通讀一遍了。

再來講一下技術博客和技術書籍。

如今網上的技術文章空前繁榮，想讀都讀不過來。胡峯同窗在他的微信公衆號「瞬息之間」上，發過一篇文章《技術乾貨的選擇性問題》，討論的就是技術人員在當前技術文章爆炸的狀況下如何取捨的問題。

在這裏，咱們從另外一個角度來討論一下這個問題。若是一篇技術文章，僅僅是對於所涉及技術的官方文檔（Tutorial或Spec）的複述，甚至只是個翻譯，那麼就價值不高。換句話說，若是咱們能經過閱讀官方文檔學到一樣的知識，那爲何要看你寫的技術文章呢？官方文檔天然更權威，直接閱讀它能確保不會遺漏重要的東西。

那什麼樣的技術文章纔有價值呢？大概能夠說（未必那麼準確），那些包涵了實踐經驗的，能將各個技術點綜合起來產生思考，從而給人以啓迪的。簡單來講，就是有深度的。

固然，技術書籍也大致如此。

咱們回過頭來再看一下，各個學習資料之間的層次結構。

每當咱們接觸一項新的技術的時候，咱們都要把手頭的資料按照相似的這樣一個金字塔結構進行分類。若是咱們閱讀了一些技術博客和技術書籍，那麼也要清楚地知道它們涉及到的是金字塔中的哪些部分。

最開始，通常讀完Tutorial以後，就基本能上手作一些開發工做了。而後一邊開發，一邊查閱API Reference。注意，從這時候起，你的老闆就開始向你付工資了，由於你的工做已經可以產出成果了。

可是，工做一段時間以後，咱們發現，彷佛身邊的技術牛人學東西都比較快，並且在很短的時間內就能對某項新技術達到很深的理解。這是爲何呢？

這並非由於技術牛人閱讀技術資料閱讀得快，而是他們知道閱讀正確的資料，從而很快能達到知識金字塔更高的一層。

我見過的不少技術牛人，他們若是不是把一項技術至少理解到Spec那個層次，他們是不敢隨便寫代碼的。相反另外一些人則從網上隨意拷貝代碼，並在本身不能徹底理解的狀況下用到項目中去。技術牛人們固然也參考網上的代碼，但他們一般會確保它的每一部分都能安放在知識金字塔的某一部分，他們不允許那種不屬於任何體系的知識孤島的出現。

咱們如今能夠這樣總結，技術的「野路子」，實際上是知識結構的不完整和不繫統形成的一種狀態。只有當你衝破知識金字塔層層的障礙，邁向更高層次的時候，老闆纔開始向你付高價。

咱們的大腦比如內存。

既然是內存，就裝不下全部的知識。但應該能裝下對於知識的索引，不然咱們便無法工做了。

那麼，這裏就有一個選擇性的問題：咱們選擇哪部分知識加載到「內存」裏呢？

顯然，應該優先選擇重要的，對咱們最有用的信息。

對於那些最核心的技術，咱們應該作到：

  • 通讀Spec。讀完就再也不困惑。
  • 重要部分的API Reference要通讀。裏面包含了不少跟實現有關的信息。
  • 若是工做須要，還可能須要讀到Source Code。特別是對於日常一直在使用的SDK，不必定從頭至尾把源碼讀通，這樣工做量太大且效率不高，但必定要把你的開發環境設置成一點擊某個調用的方法就能跳轉進源碼實現。只有這樣，你才能把日常開發的時間利用起來，隨時隨刻都點過去看源碼。

對於剩下的知識裏80%的部分，應該至少理解到Spec層次。只有這樣，咱們才能遊刃有餘地去使用它。

通讀重要的Spec，在不少狀況下，其實仍是頗有難度的。這須要毅力，和一點點英語基礎。

按本文前面提到的例子，作Java的人有誰讀過Java Spec？作Android的人有誰把developer.android.com上的API Guides都能通讀下來？而作iOS的人，developer.apple.com上的各個Programming Guide又完整地讀過幾個？對於常常調用的SDK，你會有計劃地去通讀其中重要部分的API Reference嗎？

可以把這一套作下來的，有可能不成爲技術牛人嗎？

到了文章最後了，總感受還有些意猶未盡，腦海中彷佛有些東西仍是沒有表達出來，也不肯定本文描述的學習方式是否是適用於每位讀者。仔細想一想也難怪，學習原本就是一個複雜的問題，每一個人並非徹底同樣的套路。

可是，無論本文介紹的方法是「正宗」的路子，仍是屬於「野路子」，我在這裏想要強調的一點是很明確的，那就是：要把知識梳理成系統的結構，要讓頭腦中的知識層次清楚，爲此，咱們須要閱讀恰當的東西，須要不斷地練習，須要克服種種困難。

成長沒有捷徑可走。須要的是一個一個堅實的突破。

（完）

其它精選文章：

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程