引言
我們來看一下幾類在程序員成長、發展的常見問題，如果你或多或少存在一些，那麼恭喜你，這篇文章值得你仔細往下看了：
你自認爲付出了跟別人同樣的努力，但是你的成長確實更慢一些，比如學得比別人慢，排查問題比別人慢，出方案老是有漏洞等等；
你覺得你只是在疲於應付需求，自己做的事情完全沒有技術含量（很多人覺得自己做的業務開發就是沒有技術含量，但我認爲每個領域都有自己的技術含量，只是你有沒有get到）；
你發現總是在犯同樣的錯誤，或者做的事情不斷地在同一個水平循環；
每次要晉升的時候，你發現根本講不出來（很多人會認爲是表達能力問題，但是我認爲不是）；
當你換到一個新的領域，你發現自己的經驗好像用不上；
你一直很難搞懂老鳥說的“認知升級”到底是什麼概念？不同級別的技術思維能力到底有什麼差別？爲什麼晉升的是他，而不是我？
在這篇文章裏，我會告訴大家一些技術成長的誤區，我先點出來：
只要把事情搞定了，成長是自然而然的事情——可能過段時間，你發現之前犯過的錯誤，後來一個都沒有避免；
我只要努力，996甚至007，我就能夠成長得比別人快——可能你發現你幹得最多，但是並沒有拿到最好的結果；
我盡力了，還是比別人慢，應該是我智商確實差一些——恭喜你，其實大家的智商並不會有太大差別；
別人表現好，或者晉升了，只不過是比我表達能力更強而已——我可以負責任地告訴你，這並不是僅僅是表達能力的問題。
先拋一個非常重要的結論：“思考力”是程序員需要具備的一種至關重要的素質。掌握了思考力，你就掌握了在互聯網領域，這種高度“智力密集型”行業成長的鑰匙。上面這幾個成長的問題和誤區，跟沒有掌握思考力有着非常重要的關係，而且我發現所有發展比較順暢的同學，他們的思考和學習能力是非常強悍的。
圖片描述(最多50字)
我個人在工作中，一直有意或者無意地鍛鍊自己和團隊同學的思考力，包括哪些是對我們最重要的思考力，如何去訓練思考力，有一些心得，希望能夠分享給大家。
關於思考力
思考力是一門很深的學問，包括認知科學，心理學、教育學、邏輯學，如果要系統化學習，是需要看很多書的，我推薦以下幾本：
1.《金字塔原理：思考、表達和解決問題的邏輯》-[美] 芭芭拉·明託，這本書系統闡述了思考、表達和解決問題的邏輯，也是麥肯錫的思維能力基礎，算是一本比較標準的思考力教材；
2.《麥肯錫教我的思考武器》- [日] 安宅和人，作者根據自己在麥肯錫公司工作時積累的豐富經驗以及腦神經學的專業背景，設計出一套極具邏輯性的問題解決思維模式；
3.《思維的本質》-[美]約翰·杜威 ，這本書是美國著名教育家約翰·杜威的代表作，闡述了思維訓練的基礎理論和實踐；
本文並不是探討思考力的深層理論，而是分享我們從日常的技術學習和項目過程中沉澱下來的思考力，以及如何培養這些思考力，這些思考力幾乎我們每天都可以用到，只要你有一定體感，你一定會感同身受。
有哪些對程序員最重要的思考力
原理性思維：找出知識背後的原理
有的人會說，爲什麼要思考原理，而不是直接掌握知識就可以了？我只需要會用就行了啊。
我們先來舉一些技術方案設計的案例：
爲什麼訂單創單要先create，然後enable？
這其實是一種採用二階段提交解決分佈式事務的思路，只是從一般的事務框架延展到交易領域；
業務系統中爲什麼要使用消息？
因爲消息使用的是觀察者模式，觀察者模式的好處是可以實現多個消費事務與觸發事務的解耦；
爲什麼業務系統中會使用DTS來做補償？
這本質上是一種最終一致性BASE理論解決分佈式事務的一種思路；
爲什麼更新數據的時候一定要在sql中加上版本比對或者狀態比對？
這本質上是一種藉助DB實現的樂觀鎖機制。
進一步，你會發現再大到系統架構和頂層設計的案例：
比如阿里系的技術框架NBF、TMF、早期的webx，各類框架設計理念，逃不脫設計模式，比如開閉原則，模板方法、責任鏈、工廠模式、開閉原則；
不管是底層中間件，錯綜複雜的業務系統，在設計的時候永遠無法離開核心的業務建模，比如實體與實體關係的構建；在分析這類系統的設計思想時，你會發現最好的工具就是UML！
實際上除了軟件領域的原理，還有商業設計的原理，比如案例：
所有的售中退款前必須要先取消履約，所有的履約過程中發生缺貨都需要退款，爲什麼？因爲交易的基本原則是：“錢貨平衡”，錢和貨的變更必須是最終同步的（允許短期的不平衡），你掌握了錢貨平衡的基本原理，交易中的很多複雜的流程設計就很好理解了；
在設計財務系統、庫存系統時候，業務流程、業務邏輯可能非常複雜，導致你暈頭轉向，這時候“有借必有貸，借貸必相等”的財務平衡性原理就發揮作用了，你只要知道這個原理，很快就能看懂各類財務流程、庫存流轉流程，以及各類數據對賬邏輯；
在我的領域“高可用線下收銀系統”進行線下系統容災的時候，有各種容災方案的設計，會員容災、商品容災、交易容災、支付容災……不同的容災手段看起來讓你眼花繚亂，但是他們有沒有共同遵循的原則呢？有，這就是“讓消費者最快速度完成交易，但保持最後追溯的能力”。你只要get到這個基本原理，設計各類容災策略就會得心應手了。
圖片描述(最多50字)
此外，我們的工作流程、管理手段，同樣也蘊含着深層的原理，非常有意思，大家可以抽空仔細推敲一下，比如：
爲什麼團隊機制要透明？溝通要透明？
爲什麼要有owner意識，都是在工作，owner意識會有什麼不同呢？
爲什麼管理者不能管得太細，也不能放羊？到底哪些該管，哪些不該管？
所以，掌握了知識背後的原理，帶來的好處是：
軟件系統的複雜度越來越高，我們所面對的場景越來越多，掌握原理實際上可以大幅度降低我們對於知識的記憶量，知識量是爆炸的，但是原理絕對是可控的！
原理性的東西比直接的知識有更強的複用度！記住最核心的原理，當你面對新的場景時，你會驚喜地發現，你的理解速度大大加快！這個點大家應該有體會，比如可能之前我們都學習過dubbo等底層的RPC通信框架的基本原理，但是你如果僅瞭解了他的基本用法，你會發現對你現在做業務系統沒有什麼幫助！但是，當你瞭解的是dubbo如何尋址，如何做容災，如何做擴展，你再去做業務系統，發現設計原理是一樣的，並沒有本質區別！這樣你之前研究中間件的設計思想就可以快速用到業務系統上面。
另外探求原理的過程，本身很有樂趣！這是一個非常有價值的思維訓練過程，不斷對系統設計思想、業務設計思想、做事情的工作方式，追尋背後的原理，並找到他們之間的共性，在我看來非常有樂趣，一段時間訓練以後，你會發現你看透本質的能力越來越強！
好，那麼我們程序員的工作中，究竟有哪些與原理性知識是需要我們掌握的呢？按我們團隊的實戰經驗來看：
java，linux，數據結構和算法，數據庫，網絡通信與分佈式計算的原理，這幾類是比較重要的基礎知識，我們在做方案設計、編碼、問題排查中會運用得很多；
設計模式，UML這個是對系統架構設計必要要掌握的知識，當你經歷了很多大規模的軟件系統設計，回到根本上，你會發現逃不出這一塊的理論和工具；
領域性的基本原則，比如我們上面提到的“錢貨平衡”，“財務平衡公式”，“線下收銀讓消費者最快速度走人”，這種邏輯需要大家get到這些領域性的設計原理，甚至自己去總結出這種原理；
關於管理學，人際溝通，心理學的一些基本原理，大家可以按照自己的實際需求去看一下。
如何在工作中學習和運用這些原理，我覺得有一個最佳實踐：
首先，對你可能用到的領域知識，建立一個基本的概念。看書，看文章，找行業資深的人去聊，都可以得到。注意，這裏需要有一個基本的概念就可以，這樣你在有可能touch到這些原理的時候，你會有意識，也不至於花很多時間；
在實踐中，有個意識是“多問一下爲什麼”，並一直“刨根問底”，最終肯定能夠追查到背後的最終原理；這裏面還要注意思考一下，爲什麼在這個地方會運用這個原理，也就是找到“場景”和“原理”的關聯關係，這樣你的理解會更加深刻；
瞭解了原理以後，在實踐中運用一下，這樣你對這個原理的理解就會非常深刻，並且你知道如何去運用這原理；
如果這是一個非常重要的原理，建議大家如有餘力去結合經典的書籍系統化學習。
圖片描述(最多50字)
結構化思維：構建自己的知識樹
知識樹要解決的問題，我們看一些場景：
爲什麼我知道很多東西，但是當場景來的時候老是會記不起來使用；
完成一個方案你只能想到一些點狀的手段，還有其他方案被漏掉了；
講一件事情的時候邏輯非常混亂，前後沒有邏輯性關聯。
但是很有可能你的知識都是知道的，爲什麼會出現這種悲劇？
這個就跟大腦中的知識結構有關，這是知識學習中“索引”沒有建立，也就是說，你的知識只有點，沒有線！大家想一想，把東西亂七八糟地丟在房間中，到用的時候沒有查找的線索和路徑，怎麼找得到呢？
來看一下我們工作場景的結構化的典型案例，大家體會一下：
項目中測試MM提了一個bug，我總結出來的比較標準的問題定位步驟：
確認剛纔是否有過代碼變更和部署，因爲有比較高的概率是剛纔變更的代碼又搞壞了……
追蹤鏈路日誌看鏈路是否有異常；
通過RPC的控制檯調用看接口輸入輸出是否符合預期；
追蹤關鍵方法的入參和出參，看是否有問題；
定位到方法細節後，推理邏輯是否有問題；
如果無法通過推理，那就最後一招，回放異常流量debug，這樣肯定能夠找到原因。
某個鏈路耗時比較長，需要進行性能優化，我的分析步驟是：
通過實際流量製造一個耗時較高的trace；
進行trace分析，看清楚耗時最多的原因，然後按優先級進行排序；
針對對原因找解決方案，可能的方案有：
減少數據訪問次數或者計算量，常見手段是增加cache：線程內的invokeCache；分佈式緩存tair；頁面緩存……
增強處理速度，比如多線程加速；
減少循環調用次數，比如請求合併後再分發；
減少數據處理範圍，比如減少查詢內容，異步加載分頁；
邏輯簡化，比如邏輯進行優化，或者非核心邏輯異步化等；
……
4.改掉以後，回放同樣的case，看性能消耗是否滿足預期，不滿足預期繼續優化；
如何熟悉一個新系統，我的步驟是：
要一個測試賬號，把相關功能走一遍，這樣能非常快地瞭解一個系統的功能；
看關鍵的核心表結構，這樣可以快速瞭解系統的領域模型；
根據功能步驟找到系統對外的接口列表，瞭解系統的L0業務流程；
下載系統工程，熟悉整個工程結構和模塊職責；
以一個最重要的流程爲入手點，閱讀代碼，看清楚核心的執行邏輯，可以變看邊畫時序圖；
製造一個debug場景，以debug方式走一遍流程，這樣可以實際加深一下對系統的理解；
做一個小需求，掌握相關的流程和權限；
圖片描述(最多50字)
下單這裏來了一個新的需求，出一個技術方案的步驟：
看清楚之前的需求，把這個需求所在的場景和鏈路大致閱讀一遍，搞懂；
找到需求的變化點；
分析變更的方案，涉及的內容可能會有：
數據結構會不會變，如何變；
交互協議會不會變，如何變，交互協議分爲：端和組件要不要變；和下游接口要不要變；
執行邏輯會不會變，如何變，執行邏輯變更的細化考慮點：是否變更域服務；是否變更流程編排；是否變更主幹邏輯；是否變更擴展點是否變更擴展點的內部邏輯，變更內部邏輯的時候，又可以進一步拆解：
a.重構原有的方法，覆蓋之前的邏輯，那就需要進行迴歸；
b.通過邏輯路由到新的方法，這裏需要增加路由邏輯；
- 穩定性方案；
- 發佈方案；
可以看到，面對任何一個場景，不管多大多小，我們所需要掌握的知識或者技能都可以構建成一個樹結構，同類之間是順序關係，上下之間是父子關係（或者粗細顆粒度）。
當這個樹在大腦中構建起來以後，你會發現你做什麼事情都是有一個明確的分析和執行邏輯，不太可能產生遺漏和混亂！
那麼如何訓練出自己的知識樹呢？我給一些比較有效的實踐方案：
習慣性總結，做完任何一個事情，都習慣性地回顧一下，往自己的樹上面掛新東西，這個是構建知識樹的必備手段，這個總結不需要花很多時間，比如做完事情後花個幾分鐘回顧一下就可以，但是需要堅持；
推薦一個很常見的工具：xmind，把自己的樹記錄下來；
訓練自己的思維習慣和做事方式變得結構化，當你做事情的時候，習慣性用樹的方式推進，強迫自己按照這個方式來。
更多的技術分享，盡在我的公衆號：Java小朔哥
還有我把近一年經歷過的面試，和一些刷過的面試題都做成了PDF，PDF都是可以免費分享給大家的，只要關注我的wx公衆號：java小朔哥，就可以獲取免費領取方式！