這篇文章只是體現(xiàn)我以前寫代碼和做代碼審查時(shí)候的一些原則。供大家借鑒。歡迎大家補(bǔ)充。

　　正確性 (Correctness)

　　正確性是第一要求。不能解決問(wèn)題的代碼是耍流氓。

• 結(jié)構(gòu) (Code Structure）

　　結(jié)構(gòu)體現(xiàn)邏輯。第一步，第二步；需要什么數(shù)據(jù)，需要做什么處理，處理完了結(jié)果到那里去，都應(yīng)該在結(jié)構(gòu)中被很好的體現(xiàn)出來(lái)。

　　結(jié)構(gòu)體現(xiàn)設(shè)計(jì)。 設(shè)計(jì)一定要清晰。我的經(jīng)驗(yàn)來(lái)看，一般來(lái)說(shuō)，在design chart上面的每個(gè)component都對(duì)應(yīng)著自己的class，然后之間或class內(nèi)部的通信通過(guò)member function來(lái)完成。

　　一個(gè)可借鑒的做法 – 在一個(gè)大的feature implementation過(guò)程中，給出第一個(gè)diff的時(shí)候，可以只把結(jié)構(gòu)當(dāng)做一個(gè)diff，里面的函數(shù)可以是空的(place holder)。

　　把數(shù)據(jù)的生成和界面的展示分開(kāi)來(lái)。典型的可以按照MVC的模式來(lái)，但也可以只把數(shù)據(jù)和UI分開(kāi)來(lái)的比較輕量級(jí)的做法。結(jié)構(gòu)應(yīng)當(dāng)是diff review時(shí)候最最關(guān)注的地方。最需要問(wèn)的問(wèn)題就是“這個(gè)diff號(hào)稱要解決的問(wèn)題被正確解決了嗎？”

• test的重要性

　　不論你再正確，還是有錯(cuò)誤的時(shí)候。通過(guò)（相對(duì)）公證的test來(lái) 1）減少自己被繞到代碼里的幾率；2）讓后續(xù)的或者別人的改動(dòng)對(duì)自己代碼不經(jīng)意的破壞被最快的展現(xiàn)出來(lái)。

　　test應(yīng)該把class主要的function都測(cè)一遍

　　test也應(yīng)該把class和其他class最重要的integration也測(cè)一遍。

　　可讀性 (Readability)

　　Readability leads to maintanence cost.

• diff的大小

　　bug修改，無(wú)所謂，該多大多大。一般bug fix不會(huì)超過(guò)100行。超過(guò)的要特別重視，想想究竟是什么原因造成。會(huì)不會(huì)是當(dāng)初設(shè)計(jì)的問(wèn)題。

　　一個(gè)diff，原則上不應(yīng)該超過(guò)200-300行修改。但多了怎么辦，把一個(gè)diff變成多個(gè) – split to multiple changes.

• 每個(gè)diff應(yīng)該只做一件事情

　　每個(gè)diff盡可少的做一個(gè)改動(dòng)。這樣可以盡可能的方便自己的管理(學(xué)會(huì)用git branch)，和方便reviewer的代碼審查。如果diff越集中做一件事，審查代碼的人需要越短的時(shí)間來(lái)審查做出高質(zhì)量的，整體效率越高。

• 一個(gè)function超過(guò)1屏 => split it, idiot.　　
• 統(tǒng)一的代碼規(guī)范

　　比如文件名，變量或函數(shù)名的命名規(guī)范，分行的前置空2個(gè)spaces或4個(gè)；每行的字?jǐn)?shù)（不應(yīng)超過(guò)80char）；如何使用public/private/protected；用左右括號(hào)的原則；空行的使用；文件和代碼comments的位置 （比如，代碼comment只能單獨(dú)成行）；對(duì)“// TODO:”的使用規(guī)范；macro，constant的使用；

　　等等等等。

　　這里沒(méi)有特別的哪一種style一定更對(duì)，但是需要有一個(gè)大家統(tǒng)一的guideline，一起遵守，讓整體的代碼有統(tǒng)一的風(fēng)格和標(biāo)準(zhǔn)。

　　最大的好處就是有利于readability.

• object-oriented v.s function-oriented

　　Java本身就是面向?qū)ο螅赃@個(gè)問(wèn)題不大。但千萬(wàn)不要出現(xiàn)披著面向?qū)ο蟮耐馄ぃ赾lass里面寫超長(zhǎng)的面向函數(shù)的處理。這種情況下，盡可能的分流成helper function.

• crispy & sufficient的注釋

　　注釋應(yīng)當(dāng)簡(jiǎn)潔但充分。有些人覺(jué)得代碼應(yīng)該speak for itself。我不大同意，代碼是實(shí)現(xiàn)細(xì)節(jié)，適當(dāng)?shù)脑谝鈭D上給予說(shuō)明，可以大幅度的減少讀代碼的人的煩惱。

　　diff發(fā)出去之前

• 與master做一次merge update，確保resolve all conflicts
• run一次所有涉及的test cases （需要工具）
• 考慮最可能做reviewer的人，可以是團(tuán)隊(duì)伙伴，也可以是修改涉及到的源代碼的owner。但必須是關(guān)心該改動(dòng)或和改動(dòng)相關(guān)的人。
• 所有的manager應(yīng)當(dāng)自動(dòng)subscribe自己的團(tuán)隊(duì)里所有人的diff requests (做好filtering，但你不一定要看）

　　code-review之中應(yīng)該做的

• 作為reviewer，一定要讀懂diff；所有被accept的diff必須是在讀懂的前提下。做reviewer的人要有“將來(lái)如果這些代碼線上出問(wèn)題，我要幫助support”的心理準(zhǔn)備。
• code review 應(yīng)該被每個(gè)engineer當(dāng)做工作的重要一部分。做Performance Review的時(shí)候應(yīng)該把幫助做過(guò)的code review考慮，for both employee & manager.
• 應(yīng)當(dāng)在24小時(shí)內(nèi)給回復(fù)，這應(yīng)當(dāng)變成共識(shí)。
• 感覺(jué)有問(wèn)題的代碼，一定要在相應(yīng)的行上做出評(píng)論 （inline comments)，以讓作者明白問(wèn)題所在。
• 盡可能把對(duì)修改的所有意見(jiàn)一次性給出，減少來(lái)來(lái)回回的次數(shù)。比較復(fù)雜的建議reviewer主動(dòng)找author來(lái)進(jìn)行線下溝通，達(dá)成一致。
• 一般的diff，來(lái)回次數(shù)不宜超過(guò)3次；如果超過(guò)3次，想想看，是不是diff 太大，太復(fù)雜了。

　　check-in之前應(yīng)該做的

• 與master做一次merge update，確保沒(méi)有問(wèn)題
• run一次code change涉及到的所有test cases（包括新增的和涉及到的test cases)

it知識(shí)庫(kù)：我的碼農(nóng)原則，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。