老外的代碼走查
有一篇關(guān)于代碼走查的漫畫，一屋子程序員在一起做代碼走查，在屋子外面的人數(shù)一數(shù) WTF 出現(xiàn)的頻率，大概就知道走查代碼的質(zhì)量水平了。WTF 可能有點夸張了，但是這至少說明一件事情——這一屋子程序員至少是真的在審查代碼并對代碼的水平給出了自己的意見。
我們的代碼走查
很難想象我們的代碼走查會充斥著 WTF ，因為我們的代碼走查都很 和諧 。
我經(jīng)歷過的大多數(shù)代碼走查都是這么過來的：開發(fā)人員把代碼寫完并已經(jīng)調(diào)試通過了，然后不管是為了滿足團隊的驗收準則，還是因為項目有強制要求，反正找?guī)讉€同事一起看看，大致流程就是接上投影儀，然后從第一行開始往下念，這里是在干什么，那里是在干什么，正常情況下參加走查的同事大概能堅持個十來分鐘不走神，然后眼神就開始迷茫了，等所有代碼念完，象征性的提幾個大小寫或者格式對齊的問題，然后記錄到excel里面，大功告成。
代碼走查為什么沒有效果
為什么我們的代碼走查這么和諧呢？看起來并沒有起到應(yīng)有的效果？真是讓人百思不得其解的問題。
而在后來和其他的 team leader 溝通時才發(fā)現(xiàn)原來所有人都有同樣的疑問
為什么代碼走查的效果一點都不好？
帶著這個問題參加了一場又一場的代碼走查會議之后，我找到了下面兩個可以說服我自己的答案：
- 避免沖突：長期中庸文化熏陶讓我們下意識的避免沖突，在會議中指出他人的代碼問題會讓所有人都不舒服，多一事不如少一事
- 代碼可讀性不高：即使我們能夠說服所有人相信走查代碼并不是針對個人，并消除掉所有的顧忌，但仍會因為代碼本身的問題導(dǎo)致走查的效果不理想
代碼可讀性的問題相對于中庸之道更加隱蔽。代碼走查本質(zhì)上就是在讀代碼，如果代碼的邏輯層次不清晰，命名混亂，依賴復(fù)雜，就會讓人難以理解，更談不上去發(fā)現(xiàn)隱藏在其中的bug了。不妨將待走查的代碼設(shè)想為一個小 baby 的玩具房間，第一個房間剛剛經(jīng)歷了熊孩子的大鬧天宮，第二個房間剛剛被勤勞的媽媽整理收拾干凈，如果我們的目的是從兩個房間里找到一件特定物品，我想大多數(shù)人都會認為第二個房間更加容易。
而且兩個問題產(chǎn)生的影響還會疊加——首先，演示代碼的同事看起來并不希望有人質(zhì)疑他的設(shè)計，其次，這些狗屁不通的代碼我完全不知道是在干啥，所以，我還是抽空刷一刷朋友圈吧……
應(yīng)對之道
一，讓我們不要那么中庸
中庸——這種傳統(tǒng)的東方智慧可以幫助我們在處理很多事情時得心應(yīng)手，不像西方人那么死板，但是軟件開發(fā)行為以及衍生出來的技術(shù)和管理實踐都是根植于西方哲學(xué)（如信息論、控制論），這種價值觀的沖突讓東方的程序員在實施代碼走查之類的實踐時出現(xiàn)各種不適應(yīng)。
這種不適應(yīng)是無法在短時間內(nèi)扭轉(zhuǎn)過來的。我們從出生起就一直在東方哲學(xué)的指導(dǎo)下生活，雖然很少有人意識到它的存在，但是幾十年的耳濡目染早已深入骨髓。認識的一位管理教練曾經(jīng)說過一句話讓我印象深刻，“改變一個人是很危險的，但是我們可以改變他所處的環(huán)境”，我想為了讓東方程序員適應(yīng)這些實踐，大概也只能通過下面這些改變環(huán)境的辦法慢慢來了：
- 營造安全的技術(shù)環(huán)境
明確地聲明代碼集體所有權(quán)會是一個好的開始。確保任何人可以修改任何一段代碼，并且鼓勵將代碼重構(gòu)的更好的行為，鼓勵面對面的方案討論，避免每個人負責小一塊代碼，避免局部范圍的技術(shù)壟斷。當尷尬或者負面情緒出現(xiàn)時及時發(fā)現(xiàn)和化解（比如可以重申代碼集體所有權(quán)的原則）。 - 種子選手的示范作用
在代碼走查會議中，經(jīng)驗豐富且具備強烈責任性的開發(fā)人員是優(yōu)秀的種子選手，邀請或鼓勵他們對代碼提出自己的看法，發(fā)起討論，其他人會自然參與進來。 - 讓所有人看到這真的管用
當討論發(fā)生后，要確保討論形成可以落地的結(jié)論，如果有更優(yōu)的設(shè)計就堅決拋棄掉現(xiàn)有的代碼并按新設(shè)計進行重構(gòu)，即使僅僅是提出更準確的變量命名也應(yīng)該在代碼走查會議上當場重命名。
二，讓代碼具備走查的基礎(chǔ)
心儀的女神到家里做客，邀請女神參觀房間之前我們肯定會先收拾一下，同樣的道理，在代碼拿到會議上進行走查之前，我們也要先確保代碼進行了初步的收拾，比如沒有違反團隊的編碼規(guī)范，檢查了內(nèi)存申請和釋放是否匹配，異常也正確的進行了捕獲，這些動作可以通過約定 Check list 來進行自檢，避免走查會議的時間都浪費在這些細枝末節(jié)的爭論之中。
代碼走查應(yīng)該聚焦于功能實現(xiàn)的完整性和代碼架構(gòu)的合理性，關(guān)于第一點本文暫不涉及，代碼架構(gòu)的合理性又由很多因素決定，比如語言、架構(gòu)、設(shè)計模式等等，在《重構(gòu)》一書中 Martin Fowler 整理了很全面的技巧，在本文中我想重點介紹的是如何控制代碼的邏輯層次來提升代碼的可讀性。
TBD...
三，工具和其他
- 一個順手而強大的 IDE 可以大大降低重構(gòu)的成本（如 Eclipse），讓開發(fā)人員重構(gòu)代碼時行云流水，滿滿的成就感油然而生
- 經(jīng)驗豐富的會議主持人，保證代碼走查會議是在互相尊重的氛圍下進行，確保合理的會議時間安排（時間不宜太長，根據(jù)走查的代碼靈活安排走查的重點）
我們搞敏捷實踐，不管是 scrum xp KANBAN 精益 ，每一種方法都有一套具體的實踐，這些單個的實踐之間其實是有關(guān)聯(lián)關(guān)系的，很少能獨立存在，拿代碼走查來說，如果團隊缺少集體認同的代碼規(guī)范，或者對CleanCode的理解或價值存在不一樣的認知，沒有集體代碼所有權(quán)的意識，沒有擁抱變化、互相尊重的心態(tài)，缺少實現(xiàn)高擴展性代碼的能力、重構(gòu)的能力，那么做集體代碼走查就很難做好。而一旦做不好，團隊反過來就會質(zhì)疑做這個事情的意義，一旦我們對敏捷實踐開始質(zhì)疑，那我們在實施的時候就會更加隨意，按《第五項修煉》里的心智模型，這就是一個典型的正反饋系統(tǒng)，這個正反饋系統(tǒng)一旦形成，我們的敏捷轉(zhuǎn)型失敗就只是時間問題……
