你不可能僅通過看書成為程式設計高手，也不可能僅通過沒完沒了地做項目成為行業專家
多做項目
我是半路出家的，頭發沒剃光的那種（實際上我現在頭發還茂盛得很）。我在教育訓練機構呆了半年就出去找工作。
第一份工作失敗了——底子太薄，工作撸不動，很快主動辭職了（怕被請辭就太沒面子了）。
然後我花了點時間惡補了下——用今天的眼光看，那時的底子仍然薄得可憐，不過能應付初級工作。
第二份工作，我獨立做了很多項目——對于菜鳥來說，能有獨立項目做很重要，它能讓你較早地思考設計問題，而不僅僅是 CRUD。初入程式設計行業，最怕的就是幹了幾年，除了 CRUD 啥都不會，這對後面的發展非常不利。
然而現實的悖論是，菜鳥一般很難接到獨立項目（特别是對性能、穩定性有些要求的）。換你做 Leader，你會把重要的工作分給哪隻鳥？
是以菜鳥一定要有主動工作的意識。要有想法，且樂意表達自己的想法。開會的時候多發言，多說說自己的想法（但要謙虛，不要争吵，千萬不能讓人覺得自己自負、不合群）。要想讓 Leader 能配置設定重要任務給你，首先要獲得他的信任，要讓他覺得你是個潛力股，值得培養。
有一個很重要但被很多人忽略（或不屑）的點：要自己找事做。你得學會沒事找事。在我的職業生涯中，對我提升很大的項目中有一半都是我自己找的。我說的項目不是項目管理那個意義上的項目，它可以是需求，也可以是系統優化，可以大到需要多個團隊協作，也可以小到僅僅是個通用元件開發。
當然不是瞎找。要找公司的産品和系統有什麼痛點，這些痛點你能不能解決，解決了對你和公司能帶來什麼好處——雙赢才是唯一的出路。
我發現公司的登入流程混亂不堪，經常要接入分支流程，于是提出重構登入子產品；我發現公司各系統的下載下傳功能都是各自開發，而且資料量一大就崩潰，于是提出開發統一的下載下傳中心；我發現公司各種管理背景系統日益增加，系統間沒有一個統一登入方案，便利用加班時間開發了個 sso 系統。我還自己寫架構，然後在公司内推廣讓别人用......
我像一隻地鼠到處鑽，還自己造輪子——世界上有那麼多輪子，一個重要的原因是造輪子本身是團隊和個人技術沉澱的有效手段。我通過開發架構了解了大部分的設計模式。
是以，如果初出茅廬，看多少經典書籍不是主要的，主要的是要多做項目，特别是有挑戰的項目。不要怕失敗，我有很多項目是失敗的（有些功能優化被證明比優化前更糟；有些項目壓根沒上線），那又怎樣——至少我思考過，實踐過。
多看書
一味地做項目并不能大幅提升自己。程式設計能力跟做項目的數量沒有必然關系——雖然在接觸不同的釘子，但你手上拿的還是原來那把錘子。
有些人以自己“動手能力強”為借口鄙視看書。他們信奉“實踐出真知”，看書無用（特别是理論性較強的）。
熟不知書籍本身就是前人的經驗總結，還是牛人的經驗，是以必須看，看多少都不為過。
之是以是先多做項目後海量看書，是因為在沒有一定的實戰經驗之前，很多書你是看不明白的。
其實這個順序并不精确，往往是同步進行，但不同時期側重點不同。
起初一般看工具型的，如各種“深入了解”系列（深入了解 MySQL、深入了解 Redis），加深工作中密切相關的工具（你具體使用的程式設計語言、資料庫、緩存都是工具，這裡不是說程式設計語言 IDE、MySQL 用戶端這種開發工具），稍微深入到其底層細節——但除非你對某個東西特别感興趣，否則此階段沒必要過于深入，沒必要每個工具都要研究到源碼級别，燒腦是一回事，人的時間是有限的。
研究完這些工具，你會發現過去項目中一些代碼實作、資料庫設計是有問題的，存在優化空間的——這說明書沒白看，能力提升了。能力提升的标志是能意識到之前的實作方式的不足和改進點。
接着需要多看看跟具體工具無關的書，像計算機原理、作業系統、設計模式、系統架構、算法，甚至軟體工程。如果說前一個階段的閱讀重心是搞清楚如何用 Redis 做緩存系統，這個階段則是學習系統架構中的緩存實踐模式。
這種類型的書籍重點是講思想和實踐經驗，是以多少有點抽象，很多書看一遍後雲裡霧裡，覺得好像學到了什麼，但又什麼也沒學到。這很正常，因為你的項目實戰經驗還不足以支撐自己去深入了解這些東西。
我在看《領域驅動設計》時，雖然處處都能感受到驚喜，但很多概念是囫囵吞棗，覺得自己了解了，又好像沒了解。像聚合、聚合根、限界上下文、領域服務、應用服務，低頭看書時覺得上面的東西都能看得懂，一旦擡頭思考就卡住了。這一方面反映出我經驗不足，另外也說明我正觸碰到自己的認知邊界，正在接受一種全新的知識或說認知模式——一旦得到突破，便會有質的提升。
看完《領域驅動設計》後的一個重要效果是，以後在設計系統時，我會有意識地去用 DDD 裡面的東西思考設計。這時候多半會卡殼——經常卡的那種。于是我會回頭再去看書，因為這時候是帶着問題看的，直接找到相關主題看一遍，多半會有“原來如此”的感歎。
比如一些控制器裡面代碼邏輯較多，而且很可能多個控制器存在相同或相似的邏輯，但這些邏輯又明顯不屬于領域層，怎麼辦呢？我忽然想到應用服務的概念，這些邏輯應該抽離成服務，但屬于應用層的服務。這樣一實踐，大緻就了解了原本抽象的概念。任何概念都是用來解決問題的，如果你不知道一個概念是用來解決什麼問題的，你就沒有了解這個概念。
是以做項目和看書是不斷疊代的過程，不斷學習，不斷實踐，不斷思考，你才能不斷突破自己。
學習是辛苦的，突破是痛苦的。人的大腦本能地喜歡呆在舒适區。我們今天學了這門語言，明天再去學那門語言就會覺得很輕松，因為兩門語言的學習模式是一樣的，大腦是呆在舒适區的。但今天學習這門語言，明天去學習這門語言的實作就會很痛苦，因為這是兩種不同的認知模式，大腦需要走出舒适區，一旦走出舒适區就會進入混沌态——大腦不喜歡混沌态。
要想獲得大的突破，必須學會接納處于混沌态的自己。
讀些曆史書。這不是必須的，但“讀史使人明智”是真的。感興趣的話讀一讀人類曆史（不是教科書那種），以及科技史。至少要讀讀計算機史。曆史能告訴我們一些東西為啥是這樣而不是那樣的。計算機為啥叫 Computer？一個位元組為啥是 8 比特？鍵盤為啥是 QWERTY 布局？計算機一開始就用的二進制嗎？為啥說馮·諾依曼是現代計算機之父？學史跟程式設計沒有必然關系，但能開拓你的視野，讓你知道那個時候人們面臨怎樣的問題，是怎麼解決的。有些你認為的新東西其實很早就被發明或構思出來了（比如 10 年前開始流行的雲服務概念其實在上個世紀 60 年代就以“計算機公用設施”的概念盛極一時）。
人們不喜歡看書的一大理由是一種人人都有的感覺：很多書看完後很多東西都不記得了。這種感覺很不好。
有句話叫“好讀書，不求甚解”。我對“甚解”的了解是企圖把書中每個知識點甚至每句話都搞清楚并記住。
沒那個必要。除非記憶力超群（據說馮·諾依曼就有這個能力），大部分人在讀完一本書後都會忘掉大部分内容（甚至讀得越慢忘得越多）。但今後你再去讀任何一個章節，你都會覺得很熟悉，有時候在項目實踐中大腦會突然蹦出個原本已經“忘記”的知識點。這是大腦的正常生理機制，沒必要跟它較勁。
我有時候讀完一本書後，大腦裡隻剩下一個概念，其他的一概忘記了。比如我讀完《設計原本》後，腦袋裡隻剩下“概念完整性”這個詞。也許當時我真的沒讀懂這本書，但光這個詞就讓我獲益匪淺。在日後的系統設計、團隊管理，特别是跨團隊協作開發中大型系統時，這個詞不斷地出現在我腦海中。很多系統上線後 bug 不斷，就是概念完整性（以及概念一緻性）上出了問題，比如多個系統對同一個概念定義不同；金額四舍五入規則不同；一些重要概念在系統設計之初缺失（或誤用）導緻系統設計上的重大缺陷；對某些概念未做澄清而導緻實作和預期不一緻（如什麼是“使用者”，什麼是“會員”）。項目啟動之初需要花大量時間和精力來達成概念完整性和一緻性（各種會議、宣講，各種設計文檔），很多項目缺少了這些步驟導緻後期混亂不堪，團隊中每個人都隻見樹木不見森林。
是以，若能從一本書 get 到一個讓自己終身受用的東西，夫複何求？
放一張鄙人的讀書清單鎮樓（讀沒讀完不要緊，架勢要擺出來）：
多撸源碼
一個人能做的項目是有限的，而且很多項目都是同一種類型。更有甚，由于各種原因（如進的公司隻有 CRUD 型需求）壓根沒機會承接稍有挑戰性的項目鍛煉自己。咋辦？
既然自己沒項目撸，就去撸别人的吧。
有很多高品質的開源項目，撸起來津津有味。很多時候，撸完一個高品質（但不一定規模得有多大）的開源項目比自己開發一個項目收獲要大得多。
你看書時存在的疑惑很多都能在撸源碼的過程中找到答案。我相信你初學設計模式時一定跟我一樣自認為懂了，又覺得沒懂，反正感覺很抽象。撸些源碼，你會發現裡面用了很多設計模式，你會感歎“哦，原來這樣用”。
撸源碼之前最好看下對應項目的手冊，使用下，有個整體了解。也可以百度找下其他人撸出來的筆記，了解下大緻的技術結構。
先撸簡單的。走上來就撸 nginx，很容易留下心理陰影，從此戒撸。我學 golang 的時候就是從一個很簡單的緩存中間件（幾千行代碼）開始撸，越撸越有信心。
要寫筆記。我喜歡直接從 github fork 過來，邊撸邊寫注釋。
如果真的不想撸，或者撸不動（被裡面各種彎彎腸子的設計繞得雲裡霧裡），也可以看别人撸。可以花點錢在極客時間上看大神們撸。
有些項目撸着撸着就變成自己的項目了——我的意思是面試的時候可以寫入履歷裡面，和面試官聊的時候可以說說你對那個項目的了解，甚至能撒個謊說自己開發過類似的項目（别說我教的）。
去帶團隊
程式員經常問的一個問題是：做開發到後面必須要帶團隊嗎？
這個問題我也不知道答案（很多帶“必須”字眼的我都不知道答案——怎麼回答呢？說必須？肯定有人反駁；說不一定？感覺像個教科書），是以不打算回答。
我想說的是，如果你有帶團隊的機會，就去把握——特别是比較完整的團隊（不是整個公司就一個前端一個後端這種）。至少要去試試。
不是說帶團隊未來就一定是走管理崗，不敲代碼了。帶團隊對自己的實力提升有很多好處，我們不說提升什麼綜合能力，單說資源。
職位越高，可以擁有的資源就越多。當你隻是普通的開發人員時，多數時候你隻能被動接受别人的任務安排，哪怕這個任務對提升能力沒什麼幫助。但當你成為組長、經理、總監、CTO 時，你會發現自己能決定的事情越來越多（當然責任也越來越大），能夠影響的範圍越來越大，能夠獲得的資源越來越多。
這不是說你一定要走這條路，隻是說要有這個意識——畢竟國内大部分公司資源是通過“帶團隊”的形式獲得的。
如果我鐵定了走技術路線，資源有什麼用呢？可能沒用，比如你在某個真的靠技術論天下的大廠當資深程式員。但隻要你想往架構師方向發展（首架被普遍認為是技術路線的目标），你會發現你其實非常需要資源（當然成長為架構師并不是非要帶團隊不可）。
我們不提什麼架構師，就說普通程式員崗。所謂資源，是指為做某件事所需要的人力、财力以及時間。比如你想開發個系統，或者做個重構（從成長的角度來說對你以及團隊都有好處），如果你有一定的影響力（或者權利），你就有可能說服你的上司同意你做這件事（可能要兩個月時間，并涉及到幾個團隊的人事協作）；更有甚，你可以自己決定做不做這件事情。
起碼，你能成為一個團隊或一個項目的技術負責人，這并不難。站在團隊 Leader 的角度，也能讓你的視野更加寬闊。
當然，如果你對帶團隊很反感（請确認并非你的大腦不想走出舒适區），你完全可以不帶。這裡是說帶團隊可以獲得資源，但不是說資源隻能通過帶團隊的方式獲得。
多寫東西
大神都有一個共性：喜歡寫部落格。
上學的時候，學習好的大多喜歡記筆記，有些老師還強制要求學生記筆記。寫東西能強化記憶，還能加深對知識的了解。
寫作有益于建構一個人的知識體系。比如你對 DNS 有個初步了解，大緻知道它的作用是将域名解析成 IP 位址——僅此而已。但如果你打算寫一篇關于 DNS 的文章，肯定不能僅此而已。你會去查資料，了解 DNS 的曆史，研究現實中 DNS 解析的具體實作方式。這過程中，你了解到全球 DNS 層次結構，最上面有根 DNS 伺服器，下面有頂級域伺服器，再下面有權威 DNS 伺服器；你了解到 IANA 和 ICAAN 的曆史，順便還了解到 IP 位址在全球是怎麼統一管理的；你還了解到如何通過智能 DNS 解析實作 CDN 網絡；甚至你想自己搭建個權威 DNS 伺服器。如果不寫部落格，你很難有動力去了解這些，很難建構出 IP 和域名的完整知識體系。
對我而言，寫作還有個好處是刺激思考，整理思路。有時候我面對一個問題半天沒有頭緒，于是我嘗試把問題作為文章标題大大地寫下來。第一步，我嘗試寫出來關于該問題我能想到的任何東西（對問題本身概念性的厘清、初步的推理、引申出來的新問題等等，隻要能想得出來就寫下來）——然後我會發現自己的思路像是開了閘，自此暢通無阻。寫作能鍛煉人的思維能力。
從長遠看，寫作能建立個人品牌。公司需要品牌，個人也是如此。建立個人品牌（或叫打造個人 IP）主要有三種途徑：
- 混大廠。加入頭部公司（如 BAT）并在裡面混個不錯的名頭；
- 混開源。開發一款高 star 的開源軟體或作為某款知名軟體的重要貢獻者；
- 寫部落格。
有些大牛三方面都占了，但如果你我做不到這點，可以嘗試隻做一項，比如寫部落格。
很多人“不善于”寫作。這是借口。沒有人天生就善于寫作。那些所謂“善于”寫作的都是長時間訓練出來的。另外，寫技術部落格并不需要你的寫作功底多麼好——話能說明白就行。
還有些人覺得自己現在技術不咋地，怕班門弄斧，覺得還是等底子厚了再寫。沒必要，因為寫部落格本身就是提升技術底子的非常快速有效的手段，不要颠倒了。如果有人看你的部落格更好（有人看是大部分人能持續寫作的主要動力），沒人看的話，權當自我提升，順便練練手，寫得多了積累得多了品質自然上來了，自然會有人看了。
還有人覺得自己想寫的别人已經寫了很多了，沒必要再重複這些事情了。已經有那麼多小說了，仍然有人在寫；已經有那麼多音樂了，仍然有人在譜；已經有那麼多輪子了，仍然有人在造。從某方面看，《聖經》說得沒錯：太陽底下，并無新事。但另一種說法是一千個觀衆就有一千個哈姆雷特。每個人對同一個問題的看法，對同一個知識的了解都是不同的，雖然 HTTP 協定已經被講爛了，但你的了解，你的寫作風格，或許會有些新意。就算全無新意，一樣會有人看，因為資訊不是同步的，總有人會來到你的地盤而不是别人的。
是以，不要想得太多，寫就是了。
關于寫作平台，真是太多了：部落格園、CSDN、知乎、簡書、掘金以及自建部落格等等。還有人喜歡用 github（不過對搜尋引擎不太友好，是以個人不太建議）。
個人比較喜歡部落格園，我覺得部落格園技術氛圍最濃厚，也最簡潔，沒那麼多幺蛾子。當然，如果你打算将寫作事業長久經營下去，不妨嘗試去經營自己的公衆号，雖然更難，但一旦你堅持住了，從長遠看，它會給你帶來更大的收益（成長、品牌以及資金收益）。
去當講師
一般網際網路公司都有技術分享會，但我發現很多人不願意去抓這種機會。有些團隊的分享會進行不下去，不得不給成員配置設定分享任務，而大多數人也是将其作為一種額外負擔看待的，甚至有人抱怨 Leader 給自己加了額外的任務導緻自己不得不加班。
無論你處于什麼級别，能成為任何分享會的講師都是莫大的機會，值得去把握。大牛們都十分樂意參加各種分享會，公司内部分享會，行業峰會等等。
當講師至少有三方面的收益。
首先，快速提升專業能力。和寫作一樣，你必須選擇一個主題，該主題可能是你非常熟悉的，但更多時候可能隻是粗略了解過。是以你必須網羅材料并整理成體系。比如你想講 Unicode，因為你先前大緻了解過這塊，還自己寫過 UTF-8 的實作 demo，覺得對這塊很在行。但當你規劃講稿結構時發現，必須要先講講 Unicode 出現之前的字元編碼情況，據此才能引出 Unicode 的曆史必要性。于是你了解到 ASCII、ISO-8859、GB 2312、Big5 以及 IBM 和微軟的各種代碼頁；而後 Unicode 出現了，你必須搞清楚的一件事是，Unicode 如何相容這些早期的字元集編碼，于是你不得不深入 Unicode 的實作細節；當你了解到原來早期 Unicode 采用的是雙位元組定長編碼方案時，你必須去探明為何後面 UTF-8 超越 UTF-16 成為應用最廣泛的 Unicode 實作方案？如此，當你準備完講稿時，你已經建構了自己的字元集編碼知識體系（而不僅僅是了解些 Unicode 和 UTF-8 的零星的知識）。
其次，鍛煉自己站台講話的能力。随着經驗的積累，職位的提升，你多少需要上台講點話。你無需做到口若懸河，但最好也不要語無倫次。程式員平時很少有這種上台講話的機會（機會出現了大部分人也不願意去抓）。當講師一方面氛圍比較輕松，除非是大公司幾百甚至幾千人的分享或者行業峰會，否則聽衆基本都是平時打交道的熟人，你不會有多大心理壓力（特别是做過幾次分享後）；另外你要講的内容是充分打好草稿（PPT）的，心裡有數。是以這種場合的演講大部分人都能駕馭得了。但分享也是演講，要講究演講技巧，要将聽衆帶入你的世界并很容易了解你所講的東西（很多人做技術分享就是在那裡讀 PPT，完全不考慮聽衆感受，搞到後面很多人都在那玩手機了）。這是讓你體驗演講并鍛煉演講技巧的大好機會，大部分人第一次都講不好，但多講幾次，就會不自覺地去思考并提高演講技巧。
最後，讓更多人認識你。你是不是認為大家都在一個屋檐下共事，還有誰不認識你的？除非你在公司技術圈有很大影響力（大家公認的大牛），否則不認識你的人多了去了。所謂認識，不是說人家知道你名字就完事了。所謂認識，是要人家知道你在做什麼，你擅長做什麼，你哪方面比較牛；進而，認識會轉化為“認可”：讓别人認可你，更讓你的 Leader 認可你。今後有機會參加行業峰會了，也是讓更多的業内人士認識并認可你——如此也就打造出你自己的 IP 了。
很多人不願意當講師，除了沒有上台演講的經驗外，一大顧慮是認為自己并沒有什麼特别擅長的東西。記住一點，多數時候，不是因為你真的擅長某方面才去分享，而是你先決定分享某個你熟悉但不精通的東西，然後去鑽研，在分享的同時也真正精通了這個主題。
如果一開始沒有信心，就從小範圍做起。從小組内部分享開始，内容也不用那麼專業那麼深入，随意點。然後擴充到部門或者公司層面。
做分享跟寫部落格一樣，于人于己都百利而無一害，不要等，盡早去做。
不是因為自己行才去做，而是先做了才行的。
本文來自部落格園，作者：林子er，轉載請注明原文連結：https://www.cnblogs.com/linvanda/p/16104883.html