普通碼農和CTO之間的差距

虛心
學習的第一步是——「我不懂」。一個空是水杯才能裝水，若是是滿的就沒有辦法裝水了。「自我確定」是一種很是難克服的習慣，常常會有朋友看到某個技術或者實現以後不假思索的是——「好爛」；若是問他爛在哪裏幾乎說不出個因此然來。

最近微軟發佈了。NetCore，若是你有機會看到這個標題的文章不妨看一下評論。各類「噴子」從「性能」、「道德」、「微軟很壞」、「PHP是最好的」等各類無厘頭開噴。這彷佛是程序員們的通病，對於一個本身沒有好感的東西（好比：國產或者微軟，這兩個最容易拉仇恨）會各類毫無理性的嘲諷。這種狹隘的胸襟每每會影響本身成長。

不要待在溫馨區

心理溫馨區，是指人們習慣的一些心理模式，是你感到熟悉、得心應手時的心理狀態。人在這個「區域」是很是「溫馨」的一切得心應手，工做輕輕鬆鬆；一旦走出這個「區域」就會感到不安全、焦慮，甚至恐懼。

一些人擁有「5年工做經驗」甚至「8年工做經驗」，仔細聊下來你會發現他們多是「一年工做經驗用八年」。他們用的工具是一萬年的Eclipse（甚至不肯意接受新版本的Eclipse）；他們的編碼風格很是具備濃郁的「歷史感」；他們習慣用一些「本身」（或者公司的）一些「框架」來作開發。這就是很長時間待在「溫馨區」的結果。失去對新技術的追求和探索，一味的否認或者找各類不靠譜的藉口開脫會讓本身的只是愈來愈陳舊，目光愈來愈狹隘直到有一天忽然發現——溫馨區已經沒了，才真正的陷入恐慌。

勇敢的走出「溫馨區」去探索新的技術，新的方法；把「非溫馨區」轉換成溫馨區會拓展咱們的知識面。這種不斷探索的精神最後可能發展到——不只僅停留在探索「IT技術」上，開始各類折騰，好比折騰電子製做、折騰寫小說、折騰研究曲藝、折騰評書（好吧，後面兩項是個人愛好）。

常常思考

「寫程序的康德」，這個公衆號的寓意就是思考，個人出發點是發一些東西可讓你們多思考（但願我達到這個目的了）。

解決完一個問題後咱們要常常「回頭看看」，咱們要學習的不是「解決具體問題的辦法」而不是「解決問題的方法」。不少朋友經過網絡或者同事幫助解決完一個問題以後就沒有而後了，不會去主動分析問題的緣由，解決辦法、原理。這樣的「經驗」不能算經驗，最多算「經歷」，沒有究根問底的對一個問題進行分析，思考，不能算「解決問題」。

多讀代碼

最好的學習方式是「山寨」。程序員和程序員之間交流最直接的方式不是UML，不是XXX文檔，而是——代碼，不管是架構、設計、技巧、規範都蘊含在代碼中。

OpenSource運動給世界的開發人員提供了一個巨大的倉庫，裏面有各類各樣的項目，質量良莠不齊。經過閱讀優秀的代碼能夠提升你的見識、分析能力。這裏推薦幾份靠譜的代碼：

Java併發包，混併發界你要是沒聽過DougLea那你算白混了，老爺子說得上是學術、工程兩屆通吃。文有提筆能寫論文，武能鍵盤碼程序的全才。java.util.concurrent依舊經典，不管是API仍是性能都叱吒風雲多年屹立不倒。（只要你用線程、鎖這種併發模型，java的併發庫分分鐘秒殺全部）

Guava，比起apachecommons包它很是現代化。google的招牌這個就沒必要多說了。

apacheroller，若是你須要一個JavaEE的正確姿式，那麼我推薦這個，除了有些顯老以外沒有別的缺點。Apache的招牌也是很是硬的。

作業餘項目

作一個業餘項目能夠給咱們更大的自由，在這個項目中咱們能夠嘗試新技術，新方法，徹底有本身決定全部的技術。若是一不當心，你的項目對不少人帶來幫助那會給你帶來更多的機會。

作一個業餘項目是很是鍛鍊我的能力的事情，當咱們在吐槽xxx技術不行的時候不妨本身在業餘項目中嘗試一下，或許你會理解做者的難處；當咱們以爲xxx技術簡直是很是酷的時候不妨本身在業餘項目中嘗試一下，或許你會發現它除了能寫一個helloworld以外真的沒有辦法幹別的事情了。

和別人交流

本身學會一個技術是一回事，幫助別人學會是另外一回事。在工做中幫助同事解決問題每每能夠給咱們帶來更大的收穫（也會收穫更大的成就感）。

和別人交流技術能夠幫助咱們提升兩方面的能力：

提升技術理解的深度，若是咱們想把一個技術講個別人聽首先要本身把它的每一個知識點搞清楚。好比咱們可能對HTTP協議並不陌生，可是真的要講給別人聽怎麼講？HTTP協議和TCP協議什麼關係？HTTP協議有那些支持的方法？什麼是無狀態？爲何設計成無狀態？Session和Cookie是什麼關係、什麼樣的工做原理？看似很簡單的問題，其實蘊含着不少知識點，經過「交流」咱們會對曾經認爲——「我會了」的技術有更加深入的理解。

提升表達能力，表達能力不是一朝一夕練出來的，也沒有固定的技巧可循，它徹底是一項「實踐性」技能。經過交流咱們能夠不斷的磨練本身的溝通技巧，若是咱們能把一個技術講清楚那麼咱們的溝通能力應該足夠咱們搞定「萌妹子」的。^_^

學習技術而不是工具

在新框架，新方法，新工具橫行的今天咱們很難判斷出哪些是「技術」，哪些是「工具」。我我的認爲程序員不存在——Java程序員、Python程序員、Android程序員、iOS程序員，這些前綴都是「工具」，後面的「程序員」三個字纔是技術。讓一我的號稱作Web的去作Android爲此離職的人真的不在少說，他們的理由一般是：我是作JavaWeb的，不是作Android的。可是若是有一天Web沒了怎麼辦？甚至有一天Java沒了怎麼辦？（不是危言聳聽，Java最近的負面新聞太多。以Oracle的無恥性格放棄它也是幹得出的，不要覺得名氣大就不會被幹掉，被幹掉OpenSolaris、OpenOffice、Mysql個個歷史悠久，名氣大。）

那麼究竟什麼是「技術」？答案：數據結構、操做系統、計算機體系結構、數據庫原理、編譯器工做原理、軟件工程方法論等。咱們的全部的工做都是這些理論的實踐，經過這些實踐咱們發現問題經過刨根問底的方式回到「理論」，這樣一套追蹤下來保證你們醍醐灌頂，豁然開朗，欲仙欲死，爽到爆。

舉個例子，Spring都不陌生。可是它是什麼？會有人用AOP、IoC來回答，那麼繼續追問AOP和IoC是什麼？會有人舉出一些例子來講明AOP和IoC。可是這些都不是答案，Spring是容器，不信能夠去看官方文檔開頭寫的

TheSpringFrameworkisaJavaplatformthatprovidescomprehensiveinfrastructuresupportfordevelopingJavaapplications.

Spring是一套Java平臺的基礎架構，繼續翻跳過AOP和IoC以後迎來第一個模塊「2.2.1」叫CoreContainer（包括spring-core、spring-beans、spring-context、spring-context-support模塊）；第三部分的第一個章節（7章）叫TheIoCcontainer。全部IoCContainer是任何一個spring模塊都必須依賴的基礎技術，它是整個Spring的創新點和關鍵所在。若是你繼續探索（可能須要很長一段時間），你會發現什麼是組件，什麼是容器，什麼是生命週期管理，在這個過程當中會不斷的加深你對Spring的理解，也會升華你對組件開發的理解，對軟件設計的理解。（在這個xxxinAction，xxx技術內幕，xxx深刻淺出的時代，我要推薦一本老書《ExpertOne-on-OneJ2EEDevelopmentwithoutEJB》，做者RodJohnson，沒錯Spring的締造者。有選擇的看一些章節，經過「考古」你可能會發現Spring設計的動機到底是什麼。該書已經絕版，請自行搜索電子版）

個人一個經歷

我剛入職的時候公司全部的Service都返回一個這樣的類：

err表示是否出錯，代碼裏面還定義了一堆的錯誤代碼；data表示實際執行的結果。因此每次調用都要執行一個if判斷，若是錯誤代碼不存在還須要本身新增一個。雖然個人項目經理告訴我這個方法就是「標準」，可是我以爲這個寫法太low了。因此等到我能本身決定怎麼寫的時候，我寫下了下面的代碼：

個人實踐告訴我，沒有正常人喜歡用「錯誤代碼」，世界上不可能還有比這更噁心；也沒有一個正常人喜歡強制類型轉換。因此新的Result裏面用isSuccess表示是否執行成功，若是失敗則錯誤消息經過errorMessage返回；用泛型解決了Object強制轉換的問題，。

固然，後來我用了異常。由於我以爲沒有正常人喜歡用if來不停的判斷，看起來就像C語言同樣「二」。函數的執行結果並非很明顯，每次都要get一下才能拿到結果。因此我用異常來處理錯誤，若是出錯則拋出「RuntimeException」；函數的執行結果經過函數的返回值返回。

這些變化不是一天、兩天內產生的，也不是一兩年內產生的。隨着本身知識的積累，技術的演進咱們老是會發現「新方法」，須要咱們不斷的「否認」->「嘗試」->「否認」->「嘗試」。