自学之路
1)Learning
這個是第一階段,看書、google、看視頻、看別人的博客都可以,但要注意一點是“系統化”,特別是一些基礎性的東西,例如 JVM 原理、Java 編程、網絡編程,HTTP 協議。。。。。。等等,這些基礎技術不能只通過 google 或者博客學習,我的做法一般是先完整的看完一本書全面的了解,然后再通過 google、視頻、博客去有針對性的查找一些有疑問的地方,或者一些技巧。
2)Trying
這個步驟就是解答前面提到的很多同學的疑惑的關鍵點,形象來說就是“自己動手豐衣足食”,也就是自己去嘗試搭建一些模擬環境,自己寫一些測試程序。例如:
- Jvm 垃圾回收:可以自己寫一個簡單的測試程序,分配內存不釋放,然后調整各種 jvm 啟動參數,再運行的過程中使用 jstack、jstat 等命令查看 jvm 的堆內存分布和垃圾回收情況。這樣的程序寫起來很簡單,簡單一點的就幾行,復雜一點的也就幾十行。
- Reactor 原理:自己真正去嘗試寫一個 Reactor 模式的 Demo,不要以為這個很難,最簡單的 Reactor 模式代碼量(包括注釋)不超過 200 行(可以參考 Doug Lee 的 PPT)。自己寫完后,再去看看 netty 怎么做,一對比理解就更加深刻了。
- MySQL:既然有線上的配置可以參考,那可以直接讓 DBA 將線上配置發給我們(注意去掉敏感信息),直接學習;然后自己搭建一個 MySQL 環境,用線上的配置啟動;要知道很多同學用了很多年 MySQL,但是連個簡單的 MySQL 環境都搭不起來。
- 框架封裝了 DAL 層:可以自己用 JDBC 嘗試去寫一個分庫分表的簡單實現,然后與框架的實現進行對比,看看差異在哪里。
- 用瀏覽器的工具查看 HTTP 緩存實現,看看不同種類的網站,不同類型的資源,具體是如何控制緩存的;也可以自己用 Python 寫一個簡單的 HTTP 服務器,模擬返回各種HTTP Headers 來觀察瀏覽器的反應。
還有很多方法,這里就不一一列舉,簡單來說,就是要將學到的東西真正試試,才能理解更加深刻,印第安人有一句諺語:I hear and I forget. I see and I remember. I do and I understand,而且“試試”其實可以比較簡單,很多時候我們都可以自己動手做。
當然,如果能夠在實際工作中使用,效果會更好,畢竟實際的線上環境和業務復雜度不是我們寫個模擬程序就能夠模擬的,但這樣的機會可遇不可求,大部分情況我們還真的只能靠自己模擬,然后等到真正業務要用的時候,能夠信手拈來。
3)Teaching
一般來說,經過 Learning 和 Trying,能掌握 70% 左右,但要真正掌握,我覺得一定要做到能夠跟別人講清楚。因為在講的時候,我們既需要將一個知識點系統化,也需要考慮各種細節,這會促使我們進一步思考和學習。同時,講出來后看或者聽的人可以有不同的理解,或者有新的補充,這相當于繼續完善了整個知識技能體系。
這樣的例子很多,包括我自己寫博客的時候經常遇到,本來我覺得自己已經掌握很全面了,但一寫就發現很多點沒考慮到;組內培訓的時候也經常看到,有的同學寫了 PPT,但是講的時候,大家一問,或者一討論,就會發現很多點還沒有講清楚,或者有的點其實是理解錯了。寫 PPT、講 PPT、討論 PPT,這個流程全部走一遍,基本上對一個知識點掌握就比較全面了。
碎片化時間管理
1 萬小時理論聽起來好像很簡單,每天持續 3 小時,也不難,但實際上真正做起來是很難的,就像我們互聯網的人加班加成狗,感覺身體天天被掏空,時間從哪來,這是一個現實問題,不要說每天抽 3 個小時提升自己,每天抽 1 個小時陪女朋友或者找女朋友的時間都不夠。具體怎么做?
首先是找到 3 個 30 分鐘:
第二點是利用或節省路途時間
我們每天上下班都是一兩個小時,比如像我這種,怎么去利用時間呢?
首先是可以利用上下班路上的時間去看書、聽書,也是可以做的。如果你覺得上班路上是不能看書的,或者是不可能學習的,比如你坐廣州的 3 號線,這是舉世聞名的擠得要命的,不要說看書了,把手伸出去都不知道去哪了,那就建議大家搬到離公司近一點位置,雖然每個月多幾百塊錢的房租,但是你要相信這個投資節省下來的時間用于提升自己,它最終的收益是 10 倍回報都不止的。
第三點是周末 4 小時
周末還是不用怎么加班的,周末用于放松、睡覺、看電影、娛樂,你也可以在周末里面規定自己擠出 4 個小時,也就是每天 2 個小時,這樣算下來,一天大概就兩個多小時,再加上你在工作中的積累,每天 3 小時也不是很難。
接下來講一下我是怎么做的,我現在有 2 個小孩,而且我住的比較遠,應該在座的比我忙的也不會很多,看一下我是怎么做的,我是坐廣州的四號線,坐四號線每天來回可以看一個小時的書,每天早晚 30 分鐘,周末 4 小時,有的同學可能會有疑問,周末肯定要帶小孩玩,自己也要休息,哪里有 4 個小時,其實只要你去找,時間都會有的,我找的方法就是當我小孩睡覺的時候,因為小孩子睡覺一般要睡三四個小時,大人一般睡一個小時、半個小時就差不多了,所以通過這種方式,大家可以看到 2015 年我一共看了 84 本書,有專業的,也有非專業的,人文社科、歷史這些都有。
不過特別提醒一下對于男程序員來說有一個時間千萬不能少,就是陪女朋友的時間,因為對程序員來說找女朋友不容易,別看了這篇文章回去之后女朋友也不要了,就天天回去提升,這也不是我們想要的生活。
10000 小時理論如何輕松落地?
雖然理論上很簡單,但真正要落地實行也并不那么容易,實行 10000 小時理論的關鍵在于堅持,我認為堅持的關鍵在于自己對于所從事的事業是否有“激情和興趣”。這點當然是核心,但如果只靠激情支撐,持續 10 年也確實有挑戰,正如一個朋友在分享會后問我的“要持續 10 年才能成為大牛啊,時間好長啊”!
如果說做一件事要 10 年后才能修成正果,估計很多朋友就會放棄了,畢竟像唐僧那么堅定的信仰者總是少數,大部分凡夫俗子都還是需要持續不斷的激勵才能有動力去做一件事,因為我們的大腦在進化的過程中已經形成了需要持續不斷的獎勵才能保持興奮的機制,也就是說相對于在第 10 年給一個大獎勵,還不如每年給一個小獎勵。
那如何才能在 10 年漫長的路上讓我們持續的堅持下去呢?答案其實就是首富的話:“先定一個能達到的小目標”!我們來看如何將“10 年成為大牛”這個目標分解為一個個能達到的小目標。我將這個方法歸納為“三段分解法”,即:將一個宏大或者長遠的目標經過 3 次分解,得到一個個短期內能達到的小目標。具體的分解方法如下。
一段分解:分解“等級”
10 年成為大牛的目標雖然比較長遠比較宏大,但并不意味著在沒有成為大牛前,我們一直都是菜鳥。從菜鳥到大牛的過程中,中間其實有幾個關鍵的里程碑,這些里程碑就是我們的一段目標。
以技術人員為例,技術人員典型的發展路徑基本上都是下面的這個模式:
1) 0 ~ 1 年:菜鳥,需要別人手把手來教
2)1 ~ 3 年:初級,需要別人帶你做
3)3 ~ 5 年:高級,能獨當一面,可以帶初級技術人員了
4)5 ~ 8 年:資深,能獨擋多面
5)8 ~ 10 年:大牛,統籌規劃,高屋建瓴
通過上面的分解我們可以看到,雖然說 10 年才能成為大牛,但是 3 年就可以達到初級水平,5 年就可以達到高級水平,8 年就可以達到資深水平,在這個過程中我們一直在成長和提升,而不是說沒有成為大牛就是菜鳥;并且對于很多朋友來說,如果目標不是像首富那樣要賺就賺 1 億,能達到高級或者資深水平,其實已經可以過得比較滋潤了。
通過這種分解方法,再核對一下自己目前所處的位置,然后先瞄準下一個目標,全力以赴其實也就 2 ~ 3 年時間,這樣來看一段目標其實是比較容易達成的。這種目標分解的方法除了適合技術人員外,其它很多領域也都適應,比如說產品人員、運營人員、甚至公務員!
二段分解:分解“技能”
經過一段分解后,明確自己目前所處的位置和下一個目標,接下來就要看這個一段目標如何實現了。雖然說每個一段目標持續時間在 2~3 年,但 3 年時間說長不長,說短也不短,如果沒有好好利用,可能到了 2 年多的時候回頭一看,好像什么都沒達成,還是原地踏步。因此,為了更好的利用這 3 年時間,我們需要進一步分解,這就是“二段分解”。
一段分解的維度是等級,二段分解的維度則不一樣,不能再分等級了,否則等級太細就沒法區別了。二段分解的維度變成了“技能”,即:為了達到一段目標,我需要具備什么樣的技能。
還是以技術人員為例,假設經過自我評估,認為自己目前處于初級階段,而且初級階段的事情已經做得比較順手和熟練了,那么下一個一段目標自然就是達到“高級”水平。“高級”與“初級”相比,有哪些不同的技能要求呢?
這就需要我們根據各自不同的行業和方向詳細列出來了,如果自己想不出來,網上有很多資料都可以搜索到,最方便的就是到一個招聘網站,多看看幾個招聘需求的描述,然后歸納總結一下。
我們隨便到網上搜索一個,例如拉勾網上滴滴的“高級 Java 開發工程師”招聘:
多看幾個類似的職位招聘,基本上我們就能明白“高級 Java 開發工程師”的一些基本要求。當然實際上的技能要求比招聘需求的描述還要更加細致,我個人的習慣是將這些要求整理為一個思維導圖,詳細列出每個技術點。例如:
注意:以上這個圖只是示例,并不是說所有 Java 高級工程師都一定是這個要求,例如互聯網行業和電信行業的要求不一樣)
有了這樣一個思維導圖后,我們就可以開始真正進行二段分解了,分解的方法很簡單:哪里不懂補哪里!例如:我感覺目前我的數據庫水平一般,僅僅會寫 CRUD 語句,其它的東西都不懂,那我就開始專攻數據庫這一部分,經過一段時間的專攻來提升自己的水平。
二段目標持續時間一般建議是 6 個月,既不能太短也不能太長。太短容易讓人陷入為了目標而做的誤區,沒有真正得到有效提升;時間太長的話,3 年時間又不夠完成其它目標了,例如要是我定一個目標說 2 年提升數據庫,那操作系統怎么辦?網絡怎么辦?……等等。以 6 個月為一個周期,基本上剛剛好。
經過分解,最終的二段目標可以分解為如下的幾個更小的目標:
1)2016.06 ~ 2017.01:提升數據庫水平
2)2017.01 ~ 2017.06:提升 Linux 水平
3)2017.06 ~ 2017.12:提升網絡和網絡編程水平
當然,二段分解目標并不是一成不變的,很多時候需要根據我們工作的內容進行調整。例如老大正好安排我來負責優化系統性能,降低機器負載,那么我完全可以將“提升 Linux 水平”安排到“提升數據庫水平”之前。
三段分解:分解“行動”
二段分解得到技能的小目標后,接下來的關鍵就是要實現這個目標,這就是三段分解的主要目的,即:將技能目標分解為具體要做的事情,然后按照計劃執行。
比如說我的二段目標是“提升 Linux 水平”,那怎么樣才能提升呢?可以上網搜索(知乎是個好地方),也可以去問有經驗的朋友。明確要做的事情后,三段分解需要將二段分解的 6 個月目標更加細化,分為 1 個月或者兩個月一個目標。
以我當時加入 UC 的情況為例,我在華為的時候是在 Windows 平臺上用 VC6 進行開發,而到了 UC 的時候是在 Linux 平臺上用 C++ 開發,我當時定了“提升 Linux 水平”的目標,然后通過上網查,找別人問等方法,最終將這個目標分解為幾個步驟:
1)1 個月:通讀《UNIX 環境高級編程》
2)1 個月:通讀《Linux 系統編程》
3)2 個月:通讀《UNIX 網絡編程卷1》
4)1 個月:Linux 常用命令實戰:tcpdump、ps、top 等
通過這種方法,將 6 個月的目標又進一步分解為 1 個月的目標,實施起來就簡單多了,每 1 ~ 2 個月專注一個具體目標,每次完成后都很有成就感,既感覺自己的水平有了提升,又佩服自己能夠堅持按計劃按目標完成任務,雙重獎賞讓自己更有動力進行下一個目標。
我大約花了 2 年的時間將 Linux、網絡、MySQL 三個重點技能從一無所知提升到高級的水平,很多同事都問我之前在華為是不是就是做這方面的,因為他們覺得短時間能達到這個水平是不太可能的。
綜合前面的分析,我們將三段分解提煉一下:一段分解“等級”,二段分解“技能”,三段分解“行動”。通過前面我們的案例就可以看出,原本一個宏大的“10 年成為技術大牛”的目標,經過三段分解,最終得到的是 1 ~ 2 個月可執行的具體行動,通過這種一步一個腳印的行動,最終就可以達成“10 年成為技術大牛”的目標。
天天寫業務代碼,如何成為技術大牛?
幾個典型的誤區
拜大牛為師
知乎上有人認為想成為技術大牛最簡單直接、快速有效的方式是“拜團隊技術大牛為師”,讓他們平時給你開小灶,給你分配一些有難度的任務。我個人是反對這種方法的,主要的原因有幾個:
- 大牛很忙,不太可能單獨給你開小灶,更不可能每天都給你開 1 個小時的小灶;而且一個團隊里面,如果大牛平時經常給你開小灶,難免會引起其他團隊成員的疑惑,我個人認為如果團隊里的大牛如果真正有心的話,多給團隊培訓是最好的。然而做過培訓的都知道,準備一場培訓是很耗費時間的,課件和材料至少 2 個小時(還不能是碎片時間),講解 1 個小時,大牛們一個月做一次培訓已經是很高頻了。
- 因為第一個原因,所以一般要找大牛,都是帶著問題去請教或者探討。因為回答或者探討問題無需太多的時間,更多的是靠經驗和積累,這種情況下大牛們都是很樂意的,畢竟影響力是大牛的一個重要指標嘛。然而也要特別注意:如果經常問那些書本或者 google 能夠很容易查到的知識,大牛們也會很不耐煩的,畢竟時間寶貴。經常有網友問我諸如“jvm 的-Xmn 參數如何配置”這類問題,我都是直接回答“請直接去 google”,因為這樣的問題實在是太多了,如果自己不去系統學習,每個都要問是非常浪費自己和別人的時間的。
- 大牛不多,不太可能每個團隊都有技術大牛,只能說團隊里面會有比你水平高的人,即使他每天給你開小灶,最終你也只能提升到他的水平;而如果是跨團隊的技術大牛,由于工作安排和分配的原因,直接請教和輔導的機會是比較少的,單憑參加幾次大牛的培訓,是不太可能就成為技術大牛的。
綜合上述的幾個原因,我認為對于大部分人來說,要想成為技術大牛,首先還是要明白“主要靠自己”這個道理,不要期望有個像武功師傅一樣的大牛手把手一步一步的教你。適當的時候可以通過請教大牛或者和大牛探討來提升自己,但大部分時間還是自己系統性、有針對性的提升。
業務代碼一樣很牛逼
知乎上有的回答認為寫業務代碼一樣可以很牛逼,理由是業務代碼一樣可以有各種技巧,例如可以使用封裝和抽象使得業務代碼更具可擴展性,可以通過和產品多交流以便更好的理解和實現業務,日志記錄好了問題定位效率可以提升 10 倍……等等。
業務代碼一樣有技術含量,這點是肯定的,業務代碼中的技術是每個程序員的基礎,但只是掌握了這些技巧,并不能成為技術大牛,就像游戲中升級打怪一樣,開始打小怪,經驗值很高,越到后面經驗值越少,打小怪已經不能提升經驗值了,這個時候就需要打一些更高級的怪,刷一些有挑戰的副本了,沒看到哪個游戲只要一直打小怪就能升到頂級的。
成為技術大牛的路也是類似的,你要不斷的提升自己的水平,然后面臨更大的挑戰,通過應對這些挑戰從而使自己水平更上一級,然后如此往復,最終達到技術大牛甚至業界大牛的境界,寫業務代碼只是這個打怪升級路上的一個挑戰而已,而且我認為是比較初級的一個挑戰。
所以我認為:業務代碼都寫不好的程序員肯定無法成為技術大牛,但只把業務代碼寫好的程序員也還不能成為技術大牛。
上班太忙沒時間自己學習
很多人認為自己沒有成為技術大牛并不是自己不聰明,也不是自己不努力,而是中國的這個環境下,技術人員加班都太多了,導致自己沒有額外的時間進行學習。
這個理由有一定的客觀性,畢竟和歐美相比,我們的加班確實要多一些,但這個因素只是一個需要克服的問題,并不是不可逾越的鴻溝,畢竟我們身邊還是有那么多的大牛也是在中國這個環境成長起來的。
我認為有幾個誤區導致了這種看法的形成:
1)上班做的都是重復工作,要想提升必須自己額外去學習
形成這個誤區的主要原因還是在于認為“寫業務代碼是沒有技術含量的”,而我現在上班就是寫業務代碼,所以我在工作中不能提升。
2)學習需要大段的連續時間
很多人以為要學習就要像學校上課一樣,給你一整天時間來上課才算學習,而我們平時加班又比較多,周末累的只想睡懶覺,或者只想去看看電影打打游戲來放松,所以就沒有時間學習了。
正確的做法正好相反:
首先我們應該在工作中學習和提升,因為學以致用或者有實例參考,學習的效果是最好的;其次工作后學習不需要大段時間,而是要擠出時間,利用時間碎片來學習。(參照前文 10000 小時理論)
正確的做法
總結
- 上一篇: RAM的一个实例,向下取整
- 下一篇: printf多行输入格式