虛心
學習的第一步是——“我不懂”。一個空是水杯才能裝水，如果是滿的就沒有辦法裝水了。“自我肯定”是一種非常難克服的習慣，經常會有朋友看到某個技術或者實現之後不假思索的是——“好爛”；如果問他爛在哪裏幾乎說不出個所以然來。
最近微軟發佈了。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”；函數的執行結果通過函數的返回值返回。
這些變化不是一天、兩天內產生的，也不是一兩年內產生的。隨着自己知識的積累，技術的演進我們總是會發現“新方法”，需要我們不斷的“否定”->“嘗試”->“否定”->“嘗試”。
---------------------
作者：一杯甜酒
原文：https://blog.csdn.net/u012562943/article/details/51888248