當(dāng)然，能達(dá)到這樣的數(shù)據(jù)離不開各位大佬的垂青，在此再次感謝各位大佬。

于是我又抱著好奇的態(tài)度去其他平臺看了下數(shù)據(jù)，感覺也不錯(cuò)，大體算了一下全網(wǎng)竟然達(dá)到了10W+ ——此處應(yīng)有掌聲，為自己鼓個(gè)掌。

后面如果還有大佬想轉(zhuǎn)載這篇文章，可以第一時(shí)間聯(lián)系我，謝謝。

閱讀感受

有趣的是大家對“閱讀同事代碼”這件事展開了熱烈討論，來兩張圖體會下。

5評論.jpg

6評論.jpg

對于我來說，也有些體會和感悟，分享給大家。

初出茅廬

“在座的各位都是垃圾，小丑竟是我自己” ——這是我剛剛參加工作時(shí)閱讀同事代碼的感受。

作為初級程序員的我，剛參加工作不久，只會簡單的編程知識，對于設(shè)計(jì)原則、設(shè)計(jì)模式、代碼規(guī)范等一竅不通，卻“盲目自信”，認(rèn)為編程也就那么回事。

閱讀同事寫的代碼時(shí)，由于本身眼界有限，認(rèn)為過于繁瑣、晦澀難懂，有裝X的嫌疑，總想著能不能給他優(yōu)化一下子。你別說還真有"膽大"的同事給老員工優(yōu)化代碼的案例，還好在測試階段把Bug測出來了，要不然上線之后追悔莫及。

在此建議別輕易修改別人的代碼，代碼的“混亂”不是一蹴而就的，是經(jīng)過多個(gè)版本迭代或者需求的變更遺留下來的，是經(jīng)得住推敲的。如果非得重構(gòu)代碼，建議讓編碼者親自操刀。

當(dāng)廢了九牛二虎之力把同事的代碼看懂之后，突然覺得同事真的太牛了。他當(dāng)時(shí)是怎么想到用這么巧妙地方法來實(shí)現(xiàn)該功能的？崇拜之情溢于言表。要是跟他拜師學(xué)幾年，豈不是大業(yè)可成。

從容不迫

“進(jìn)可攻退可守”——是我對閱讀同事代碼第二階段的感受。

工作幾年之后，對代碼的編寫和工作的流程有了進(jìn)一步的理解，對閱讀別人代碼這件事也就有了更多的感受。俗話說“吃虧是福”，在工作中也一樣，不親自來踩一下項(xiàng)目中的坑，你永遠(yuǎn)也不知道“社會的險(xiǎn)惡”。

經(jīng)歷過閱讀別人的代碼甚至修改別人的代碼之后，年輕的沖動(dòng)和對垃圾代碼的憤怒也被緊急的項(xiàng)目以及莫名的Bug給磨平了，少了些青蔥的激昂，多了些老練的從容。

為什么總結(jié)為“進(jìn)可攻退可守”呢？是因?yàn)橛辛斯ぷ鞯某恋碇?，對之前的設(shè)計(jì)原則、設(shè)計(jì)模式等有了基本的了解，再遇到垃圾代碼時(shí)總想大展身手，為項(xiàng)目做點(diǎn)“貢獻(xiàn)”，將垃圾代碼重構(gòu)一翻，故而稱之為“進(jìn)”。

當(dāng)我們想大刀闊斧的為項(xiàng)目改進(jìn)時(shí)，卻發(fā)現(xiàn)項(xiàng)目的弊病根深蒂固，改造起來并不容易，然而隨著工期的逼近，我們不得不向時(shí)間妥協(xié)。利用版本控制工具默默的回滾代碼，繼續(xù)往垃圾代碼中添加“垃圾”，我把它稱之為“退”。

當(dāng)項(xiàng)目上線無Bug之后，意味深長的來一句：垃圾代碼還是有垃圾代碼的好處呀。當(dāng)下次開項(xiàng)目重構(gòu)需求討論會時(shí)，心里默默的來一句：要不你還是把我殺了吧！

久經(jīng)沙場

“寬猛并濟(jì)，不過度設(shè)計(jì)”——這是我現(xiàn)在閱讀同事代碼的感受。

并不是說我的技術(shù)有多?；蛘哒f我的境界有多高，主要是我扎根于“搬磚”一線，工作時(shí)間長了，看的代碼也比較多而已。

從我身邊的同事或朋友來看，他們的個(gè)人技術(shù)能力都比較過硬，對業(yè)務(wù)對架構(gòu)的熟練程度也比較到位。他們對各種設(shè)計(jì)規(guī)則、代碼規(guī)范了然于胸，但卻不執(zhí)著于此。能簡單解決的問題一筆帶過，該注意的設(shè)計(jì)規(guī)范也能駕輕就熟。

在與朋友的交談中提及到閱讀代碼的問題，他們也是毫不避諱的說：每個(gè)項(xiàng)目中都會存在垃圾代碼，當(dāng)然也不缺乏好的設(shè)計(jì)。對于垃圾的代碼，在不影響全局的情況下可以適度重構(gòu)，當(dāng)然對于重要的環(huán)節(jié)完全重構(gòu)成本太高，試錯(cuò)成本有點(diǎn)大。而對于精致的代碼，平時(shí)遇到了也會研究一番，從設(shè)計(jì)思路到代碼編寫都會虛心學(xué)習(xí)，畢竟人無完人，代碼更是這樣。

要做到寬猛并濟(jì)也就是要做到：對自己要嚴(yán)格要求，盡量減少垃圾代碼的輸出與添加，盡量做到設(shè)計(jì)的規(guī)范與合理；對別人要以寬容并包的心態(tài)來看待，每個(gè)人的風(fēng)格不同，對同一業(yè)務(wù)的理解不同，實(shí)現(xiàn)方式自然不同。

當(dāng)然如果想更上一層樓，那就需要把公司的成本與軟件的開發(fā)結(jié)合起來，適度設(shè)計(jì)、適度重構(gòu)，畢竟盈利才是公司的終極目標(biāo)。

如何閱讀

至于該如何閱讀別人的代碼，我也來談?wù)勎业南敕?，在此拋轉(zhuǎn)引玉，大家評論區(qū)見。

優(yōu)秀的評論可以獲取文末技術(shù)書籍一本。

在閱讀代碼之前可以查看一下項(xiàng)目原型、規(guī)劃流程、《設(shè)計(jì)文檔》等，如果公司開發(fā)需求比較急或者沒有對文檔編寫的習(xí)慣，找開發(fā)同事了解下開發(fā)邏輯流程或者找產(chǎn)品同事了解下項(xiàng)目的需求也是不錯(cuò)的選擇。

一定要先了解需求與項(xiàng)目流程，這是代碼的靈魂。

我們還可以跟同事“嘮嘮嗑”，了解下他的實(shí)現(xiàn)方案、實(shí)現(xiàn)方式、關(guān)鍵技術(shù)等，待到看源碼時(shí)，便可以了然于胸，有的放矢。

如果一頭深深扎于代碼之中，對于有經(jīng)驗(yàn)的“老者”能了解代碼的層次結(jié)構(gòu)，但是對于經(jīng)驗(yàn)欠缺尤其是對框架或者結(jié)構(gòu)不明確的“年輕人”就會一頭霧水，哪怕最后將代碼搞懂了，可能也事倍功半。

讀代碼時(shí)可以先根據(jù)流程圖捋順整體邏輯，然后再去深入研究每一個(gè)函數(shù)的功能及實(shí)現(xiàn)。在研究的過程中，可以像讀Spring或者Mybatis等編碼清晰的源碼那樣，養(yǎng)成隨手畫流程圖或者思維導(dǎo)圖的習(xí)慣，下次再看時(shí)就一目了然了，畢竟好記性不如爛筆頭嘛。

如果不善于畫圖，當(dāng)然可以在本子上畫個(gè)草圖呀，不要拘泥于形式。

如果還不擅長，那就將代碼檢出本地分支，在本地分支上做注解、打標(biāo)記、寫疑問，盡你所能“迫害”本地代碼，為所欲為，直到便于自己理解，千萬別客氣。

當(dāng)然代碼的理解也可以在Debug模式下進(jìn)行，實(shí)踐出真知?？词椴蝗缗芤贿?，讓程序動(dòng)起來，你的思緒也就飛起來了，變得活絡(luò)了，也就便于理解了。

以上是我淺顯的觀點(diǎn)，評論區(qū)留下你的觀點(diǎn)吧！

小結(jié)

無論是從讀別人的代碼那種煎熬的程度，還是從如何閱讀才能提高效率，無一不體現(xiàn)出代碼的可讀性對開發(fā)效率的影響，因此我們在平時(shí)開發(fā)過程中一定要寫注釋、寫注釋、寫注釋！

好的注釋不光可以把流程顯示清楚，更可以將解決問題時(shí)存在的“坑”寫出來，讓后者少走彎路。畢竟前人挖坑，后人也不會管埋的！

阿Q將持續(xù)更新java實(shí)戰(zhàn)方面的文章，感興趣的可以關(guān)注下，也可以來技術(shù)群討論問題呦！