原創：微信公衆號 【阿Q說代碼】，歡迎分享，轉載請保留出處。
之前寫過一篇名爲《看了同事寫的代碼，我竟然開始默默的模仿了。。。》的文章，今天偶然間看了下後臺數據，大喫一驚。該文章的閱讀量在微信公衆號內竟然達到了驚人的5W+ 。對於沒見過市面的我來說已經相當滿足了。
當然，能達到這樣的數據離不開各位大佬的垂青，在此再次感謝各位大佬。
於是我又抱着好奇的態度去其他平臺看了下數據，感覺也不錯，大體算了一下全網竟然達到了10W+ ——此處應有掌聲，爲自己鼓個掌。
後面如果還有大佬想轉載這篇文章，可以第一時間聯繫我，謝謝。
閱讀感受
有趣的是大家對“閱讀同事代碼”這件事展開了熱烈討論，來兩張圖體會下。
對於我來說，也有些體會和感悟，分享給大家。
初出茅廬
“在座的各位都是垃圾，小丑竟是我自己” ——這是我剛剛參加工作時閱讀同事代碼的感受。
作爲初級程序員的我，剛參加工作不久，只會簡單的編程知識，對於設計原則、設計模式、代碼規範等一竅不通，卻“盲目自信”，認爲編程也就那麼回事。
閱讀同事寫的代碼時，由於本身眼界有限，認爲過於繁瑣、晦澀難懂，有裝X的嫌疑，總想着能不能給他優化一下子。你別說還真有"膽大"的同事給老員工優化代碼的案例，還好在測試階段把Bug測出來了，要不然上線之後追悔莫及。
在此建議別輕易修改別人的代碼，代碼的“混亂”不是一蹴而就的，是經過多個版本迭代或者需求的變更遺留下來的，是經得住推敲的。如果非得重構代碼，建議讓編碼者親自操刀。
當廢了九牛二虎之力把同事的代碼看懂之後，突然覺得同事真的太牛了。他當時是怎麼想到用這麼巧妙地方法來實現該功能的？崇拜之情溢於言表。要是跟他拜師學幾年，豈不是大業可成。
從容不迫
“進可攻退可守”——是我對閱讀同事代碼第二階段的感受。
工作幾年之後，對代碼的編寫和工作的流程有了進一步的理解，對閱讀別人代碼這件事也就有了更多的感受。俗話說“喫虧是福”，在工作中也一樣，不親自來踩一下項目中的坑，你永遠也不知道“社會的險惡”。
經歷過閱讀別人的代碼甚至修改別人的代碼之後，年輕的衝動和對垃圾代碼的憤怒也被緊急的項目以及莫名的Bug給磨平了，少了些青蔥的激昂，多了些老練的從容。
爲什麼總結爲“進可攻退可守”呢？是因爲有了工作的沉澱之後，對之前的設計原則、設計模式等有了基本的瞭解，再遇到垃圾代碼時總想大展身手，爲項目做點“貢獻”，將垃圾代碼重構一翻，故而稱之爲“進”。
當我們想大刀闊斧的爲項目改進時，卻發現項目的弊病根深蒂固，改造起來並不容易，然而隨着工期的逼近，我們不得不向時間妥協。利用版本控制工具默默的回滾代碼，繼續往垃圾代碼中添加“垃圾”，我把它稱之爲“退”。
當項目上線無Bug之後，意味深長的來一句：垃圾代碼還是有垃圾代碼的好處呀。當下次開項目重構需求討論會時，心裏默默的來一句：要不你還是把我殺了吧！
久經沙場
“寬猛並濟，不過度設計”——這是我現在閱讀同事代碼的感受。
並不是說我的技術有多牛或者說我的境界有多高，主要是我紮根於“搬磚”一線，工作時間長了，看的代碼也比較多而已。
從我身邊的同事或朋友來看，他們的個人技術能力都比較過硬，對業務對架構的熟練程度也比較到位。他們對各種設計規則、代碼規範瞭然於胸，但卻不執着於此。能簡單解決的問題一筆帶過，該注意的設計規範也能駕輕就熟。
在與朋友的交談中提及到閱讀代碼的問題，他們也是毫不避諱的說：每個項目中都會存在垃圾代碼，當然也不缺乏好的設計。對於垃圾的代碼，在不影響全局的情況下可以適度重構，當然對於重要的環節完全重構成本太高，試錯成本有點大。而對於精緻的代碼，平時遇到了也會研究一番，從設計思路到代碼編寫都會虛心學習，畢竟人無完人，代碼更是這樣。
要做到寬猛並濟也就是要做到：對自己要嚴格要求，儘量減少垃圾代碼的輸出與添加，儘量做到設計的規範與合理；對別人要以寬容幷包的心態來看待，每個人的風格不同，對同一業務的理解不同，實現方式自然不同。
當然如果想更上一層樓，那就需要把公司的成本與軟件的開發結合起來，適度設計、適度重構，畢竟盈利纔是公司的終極目標。
如何閱讀
至於該如何閱讀別人的代碼，我也來談談我的想法，在此拋轉引玉，大家評論區見。
優秀的評論可以獲取文末技術書籍一本。
在閱讀代碼之前可以查看一下項目原型、規劃流程、《設計文檔》等，如果公司開發需求比較急或者沒有對文檔編寫的習慣，找開發同事瞭解下開發邏輯流程或者找產品同事瞭解下項目的需求也是不錯的選擇。
一定要先了解需求與項目流程，這是代碼的靈魂。
我們還可以跟同事“嘮嘮嗑”，瞭解下他的實現方案、實現方式、關鍵技術等，待到看源碼時，便可以瞭然於胸，有的放矢。
如果一頭深深扎於代碼之中，對於有經驗的“老者”能瞭解代碼的層次結構，但是對於經驗欠缺尤其是對框架或者結構不明確的“年輕人”就會一頭霧水，哪怕最後將代碼搞懂了，可能也事倍功半。
讀代碼時可以先根據流程圖捋順整體邏輯，然後再去深入研究每一個函數的功能及實現。在研究的過程中，可以像讀Spring或者Mybatis等編碼清晰的源碼那樣，養成隨手畫流程圖或者思維導圖的習慣，下次再看時就一目瞭然了，畢竟好記性不如爛筆頭嘛。
如果不善於畫圖，當然可以在本子上畫個草圖呀，不要拘泥於形式。
如果還不擅長，那就將代碼檢出本地分支，在本地分支上做註解、打標記、寫疑問，盡你所能“迫害”本地代碼，爲所欲爲，直到便於自己理解，千萬別客氣。
當然代碼的理解也可以在Debug模式下進行，實踐出真知。看十遍不如跑一邊，讓程序動起來，你的思緒也就飛起來了，變得活絡了，也就便於理解了。
以上是我淺顯的觀點，評論區留下你的觀點吧！
小結
無論是從讀別人的代碼那種煎熬的程度，還是從如何閱讀才能提高效率，無一不體現出代碼的可讀性對開發效率的影響，因此我們在平時開發過程中一定要寫註釋、寫註釋、寫註釋！
好的註釋不光可以把流程顯示清楚，更可以將解決問題時存在的“坑”寫出來，讓後者少走彎路。畢竟前人挖坑，後人也不會管埋的！
阿Q將持續更新java實戰方面的文章，感興趣的可以關注下，也可以來技術羣討論問題呦！