一，心得體會

第一是 “興趣”。這也是我認為最重要的一點，一件事情做10年甚至做一輩子，如果沒有興趣的話，我覺得是很痛苦的。興趣是本能的驅動力，有了興趣，遇到問題會一直想著怎樣去解決，而不是覺得“很難做”；有了興趣，碰到一個新的東東會覺得很興奮，而不會覺得是一種負擔；有了興趣，接觸到一個東西后就像更加深入的去了解，而不是用過了就不管了。所以我認為如果想在一個行業（不限於軟體行業）長期發展並有所提升的話，一定要問問自己是否有足夠的興趣。

我當時之所以換工作，也是因為我對當時的工作內容不感興趣，因為我更喜歡親手做出一個產品，而不是找一群人開會討論然後寫個文件就完事了。

第二是“堅持”。《異類》一書中提到一個10000小時理論，我覺得非常有道理，意思就是說如果你想成為頂尖人才的話，一定要積累10000小時以上的訓練和經驗。特別是在軟體開發這個領域，技術又多，技術更新又快，如果沒有堅持去積累和提升的話，是很難達到一定高度的。作業系統、資料庫、網路、程式語言、設計方法等都要掌握，每個技術點又有很多更細的分類。以程式語言來說，C、C++、Java、PHP、Python等主流的都有10來種，每個語言繼續深入的話又有很多內容，例如Java可以列出來的有JVM、IO、NIO、網路程式設計、反射。。。。。。等等。所以這麼多的東東，短時間內快速入門還可以，但如果說21天就精通XXX，那是不可能的，必須經過長時間的積累。其實我現在都不敢說我精通什麼，只能說相對周圍其他人會精通一些。

第三就是“方法”。掌握正確的方法，能夠讓我們事半功倍，更快的提升，一些常見的方法我就不囉嗦了，這裡特別分享獨家祕方：

一個祕方是“寫部落格”，注意這裡不是“看部落格”，也不是“轉載部落格”而是“親自寫部落格”。哪樣東西你覺得你比較懂了，那麼你就寫成部落格。當你真正去寫的時候，你會發現，其實還有很多不懂或者不清楚的地方，這樣就會促使你又去學習研究；當你的部落格發表後，其他人除了能夠從你的部落格中學到東西外，也能夠幫你發現一些問題或者錯誤，這樣你就更進一步的掌握了；

另外一個祕方就是“鏈式學習”。形象點說，就是你抓住了一個鏈條的一個鏈，然後慢慢慢慢把所有的鏈都拉出來。舉一個很簡單的例子：socket sever程式設計。很多人在程式設計的時候，都是去搜索引擎搜尋一下“socket server樣例”，然後對照樣例很快就寫完功能了。然後呢。。。。。。很多人沒有然後了，完成任務就不管了。其實這樣做就錯過了一次提升自己的好機會。

“鏈式學習”則不一樣，它是這樣做的：我通過搜尋引擎搜尋到樣例完成工作後，我會問自己很多問題：樣例中的api每個引數都是什麼含義，有哪些注意事項，還有其它API麼？為了解決這些問題，我就可能去找本書看，某個程式語言的socket程式設計；看完以後我知道socket程式設計的全貌和一些注意事項，而這些是通過搜尋引擎搜尋的樣例中沒有的；知道socket程式設計的全貌後，我又會問自己：作業系統是怎麼做的呢？ 那我又會去看《UNIX網路程式設計》，看完後我就對作業系統層面的又掌握更多了；看完《UNIX網路程式設計》後，我又知道socket是和tcp/ip相關的，那我又會去看《TCP/IP協議詳解》。。。。。。

這樣去做就是一條學習鏈： socket server程式設計 -> socket 程式設計 -> UNIX網路程式設計 -> TCP/IP協議，後面還可以繼續不斷拓展下去。如此不斷的拓展和深入，一個很小的契機就能初始你學到很多東西，而這些東西在以後的工作中某些時刻就派上用場了。

我之前在華為是在Windosw平臺上用MFC開發，後來到了UC轉為Linux平臺開發，用這種方法，大約用了2年就熟練掌握了Linux平臺相關的開發技術，包括Linux、MySQL、C++、Java、PHP等

第三個祕方就是“閉環學習”。“鏈式學習”適合於一組相關聯的知識或者技能的學習，而“閉環學習”更適合業務、相互配合的知識和技能的學習。由於軟體開發是需要多個團隊分工合作的，所以絕大部分人都只負責整個系統或者全流程中的一環，這樣導致很多人以為只需要將自己負責部分精通就可以了。其實這樣不利於個人的發展，一個原因是自己負責的一般都比較窄，可學習和提升的空間可能不多，另外一個原因是很難設計整體上優秀的方案。

而“閉環學習”則不一樣，它是這樣做的：瞭解整個功能或者業務的全流程實現，涉及了哪些模組和系統，每個模組和系統主要負責什麼功能，涉及到什麼技術，效能怎樣，有什麼注意點。舉一個我做個的HTTP的業務樣例：從使用者點選一個url開始，經過了 瀏覽器 -> 網路 -> CDN -> Nginx -> PHP -> MySQL -> PHP -> Nginx -> 網路 -> 瀏覽器，最後呈現在使用者面前。我開發的時候只是用PHP開發，但並不只侷限於PHP本身，閉環學習就要求全流程中的每個環節都要去了解和熟悉，這樣你就可以學到了“瀏覽器、Nginx、CDN、MySQL”等很多知識。

有的朋友可能會問：這樣做有什麼用呢？其實用處非常大，一個是當出現問題的時候，有了閉環學習掌握的知識和技能，你就知道哪些地方可能有問題，應該如何處理；另外一個用處是，當你考慮設計方案的時候，就不侷限於PHP本身了，也許某個功能Nginx或者CDN或者前端能做的更好，用PHP實現反而很蹩腳。

《羊皮卷》：目前市面上的《羊皮卷》大部分都是心靈雞湯式的文章的組合，但有一本其中有一篇《選擇的力量》，我看了後醍醐灌頂，真的是就像佛家禪宗說的突然“悟道”一樣，看了後深受啟發，從此後很多為人處世方式都因此而改變了；

《異類》：一本從不同視角講述成功人士到底是如何成功的，會告訴你很多不為人知的故事，能夠讓你免受心靈雞湯之害，也能夠明白成功既要靠自己努力，也要靠機遇；

《隨機漫步的傻瓜》：這本書看起來是講投資的，但其實講述了一個關於“運氣和命運”的問題，讓你能夠以不同的視角來評價和判斷所謂的“成功”

首先是“快速學習能力”。這裡不是說一定要去快速去學習各種各樣的新技術，而是說當有需要時，能夠快速的學習。很多人開始學新的技術和技能時，一開始就一頭扎進去寫樣例、寫Demo、看原始碼，我認為這不是好的方法，而且比較耗費時間，收效也不明顯。

我給大家分享我的4W2H快速學習方法。我在學習新的技術的時候，都是按照這樣的步驟去了解的：1）這個技術能解決什麼問題（why） 2）比較適合在哪些場景應用（where + when) 3）這個技術跟我已經掌握的哪個知識或技能類似，有什麼差別、有什麼特點、 有什麼優點和缺點（what），4）瞭解前面的問題後，我才會開始去嘗試寫寫Demo，或者更進一步去應用（How to use） 5）覺得有興趣或者其實現很牛逼的情況下，我就去研究一下原理機制，看看原始碼等 （How it implements）

其次是“良好的理解能力”。程式設計師需要將產品人員或者使用者用自然語言表述的需求翻譯成程式語言。自然語言有一個特點就是通俗但不嚴謹，而程式語言必須是非常嚴謹的。如果對產品人員或者使用者提出的需求沒有很好的理解，即使程式語言寫的再漂亮，技巧再高，最後做出來也是一個不符合要求的產品。

記得有一個關於“美女”的笑話：人聽到“美女”後的反應是想到“天使面孔魔鬼身材童顏巨乳”，而豬聽到“美女”後的反應是“烏克蘭大白豬”，貓聽到“美女”後的反應是“有著金色光滑皮毛的波斯貓”。如果程式設計師給了貓一個“天使面孔魔鬼身材童顏巨乳”的美女，貓一定會覺得很難看。

第四是“樂於分享”。如果單純從個人完成工作的能力來看，可能確實也有很多程式設計師不愛分享但確實很厲害。但我認為真正優秀的程式設計師一定是除了自己優秀外，還能讓其他人也變得優秀，或者能夠貢獻優秀的開源專案以降低別人的重複工作。分享的途徑有很多種，可以給公司人員做培訓，可以寫部落格，可以貢獻開源專案等。

四，面向物件和程式語言

1，對於初學者，你覺得他們怎樣才能知道有沒有掌握面向物件程式設計的思想？ 

掌握面向物件程式設計的技能是很容易的，會用Java寫個類，寫個繼承，寫個介面，基本上就可以說自己掌握了面向物件程式設計的技能，如果再加上設計模式和設計原則，基本上就可以說熟練掌握了面向物件程式設計。

但如果說真正掌握了面向物件程式設計的思想，我覺得一定是要看是否用面向物件的方式去分析和理解問題。舉個很簡單的例子：很多人都是用面向過程的方法去分析和理解問題，然後在實現的時候覺得這裡可以封裝為一個類，那裡可以用一個介面，有的地方可以用繼承，有的地方可以用抽象類等，這樣其實就是用面向物件實現了面向過程。

2，面向物件程式設計的重要性和適用範圍在哪？以及面向物件程式設計的弊端是什麼？

面向物件思想作為應對軟體複雜性日益攀升的解決之道提出來的，其重要性在於通過封裝的方式將複雜性隔離開來。但面向物件不是“銀彈”，不是所有場景都適合應用的，我覺得面向物件特別適合於“容易發生變化”的業務系統開發，例如網際網路相關業務、遊戲開發、ERP等行業，不太適合底層系統如作業系統、驅動、資料庫等開發。

面向物件程式設計本身我覺得並不存在固有的弊端。比如說有的人認為面向物件增加了類關係設計開銷，但這個開銷和隔離複雜度帶來的收益相比基本可以忽略不計，加上設計模式和設計原則的成熟，設計良好的面向物件方案並不會帶來多大的開銷；有的人說面向物件帶來了更多的複雜性，但這個複雜性主要是語言本身的複雜性，一旦熟練掌握後就不會成為障礙，而且我覺得面向物件更加符合人類的思維特點，是一種“人的思維”，一旦轉換後，人其實更加適應面向物件的思維。

1. 需求模型

通過和客戶溝通，結合行業經驗和知識，明確要求客戶的需求。

在這個階段中， 面向物件和麵向過程的開發方式沒有差異，如果有人認為分析方法不一樣，那是因為沒有明白需求分析具體的目標是什麼，

需求分析的目標就是要準確把握客戶需求，和具體的實現技術、開發流程都沒有關係。

2. 領域模型

基於需求模型，提煉出領域相關的概念，為後面的面向物件設計打下基礎。 面向過程的開發流程中對應的階段是“功能提取”。

在這個階段，面向物件和麵向過程的開發過程差異就很明顯了，面向物件的流程主要任務是從需求模型中提煉“領域類”，而面向過程的開發要求的是從需求模型中提煉“功能的處理過程”。

3. 設計模型

以領域模型為基礎，綜合面向物件的各種設計技巧，完成類的設計。 面向過程的開發流程對應的階段是“功能分解”

在這個階段，面向物件的開發過程要求完成從“領域類”演進到“軟體類”，並逐步細化求精，完成最終的軟體類設計，而面向過程的開發此時需要做的是將全流程的功能分解為子功能，並細化子功能的具體步驟。

4. 實現模型

以設計模型為基礎，將設計模型翻譯為具體的語言實現，完成編碼。

在這個階段，面向物件開發和麵向過程開發都是使用具體的程式語言來實現各自的設計，流程上沒有什麼差別，但使用不同的語言來開發的話，效率上是有一定的差別的，

總體來說，面向物件程式語言在語言層面上效率要比面向過程的開發語言效率要高一些。但程式設計的效率是受很多因素影響的，單純的語言因素對總體的效率影響並不明顯。

總結一下，面向物件的開發流程其實是以“類”來串聯整個開發流程，而面向過程的開發流程是以“功能”來串聯整個開發流程

毫無疑問，設計模式就是GoF提出的23個設計模式，其它模式基本都是這些模式的變體或者組合；設計原則就是SOLID原則。 設計模式和設計原則在我的部落格專欄《面向物件葵花寶典》都有深入和別出心裁的闡述，大家可以參考。（編者注：李老師在專欄中針對設計模式和原則進行了全面深入的闡述，由於內容較多，這裡不再引用，還請移步專欄閱讀。）

首先要了解面向物件出現的歷史背景，然後要了解面向物件和麵向過程的對比，面向物件的優點缺點等，最後才是面向物件的這些概念、原則、方法。如果談到面向物件就只知道“抽象、類……”等這些概念，是知其然不知其所以然，在實際中也很難更好的應用面向物件。

這部分內容可以參考我的部落格專欄《面向物件葵花寶典》。