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

　　正確性 (Correctness)

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

• 結構 (Code Structure）

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

　　結構體現(xiàn)設計。 設計一定要清晰。我的經(jīng)驗來看，一般來說，在design chart上面的每個component都對應著自己的class，然后之間或class內部的通信通過member function來完成。

　　一個可借鑒的做法 – 在一個大的feature implementation過程中，給出第一個diff的時候，可以只把結構當做一個diff，里面的函數(shù)可以是空的(place holder)。

　　把數(shù)據(jù)的生成和界面的展示分開來。典型的可以按照MVC的模式來，但也可以只把數(shù)據(jù)和UI分開來的比較輕量級的做法。結構應當是diff review時候最最關注的地方。最需要問的問題就是“這個diff號稱要解決的問題被正確解決了嗎？”

• test的重要性

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

　　test應該把class主要的function都測一遍

　　test也應該把class和其他class最重要的integration也測一遍。

　　可讀性 (Readability)

　　Readability leads to maintanence cost.

• diff的大小

　　bug修改，無所謂，該多大多大。一般bug fix不會超過100行。超過的要特別重視，想想究竟是什么原因造成。會不會是當初設計的問題。

　　一個diff，原則上不應該超過200-300行修改。但多了怎么辦，把一個diff變成多個 – split to multiple changes.

• 每個diff應該只做一件事情

　　每個diff盡可少的做一個改動。這樣可以盡可能的方便自己的管理(學會用git branch)，和方便reviewer的代碼審查。如果diff越集中做一件事，審查代碼的人需要越短的時間來審查做出高質量的，整體效率越高。

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

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

　　等等等等。

　　這里沒有特別的哪一種style一定更對，但是需要有一個大家統(tǒng)一的guideline，一起遵守，讓整體的代碼有統(tǒng)一的風格和標準。

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

• object-oriented v.s function-oriented

　　Java本身就是面向對象，所以這個問題不大。但千萬不要出現(xiàn)披著面向對象的外皮，在class里面寫超長的面向函數(shù)的處理。這種情況下，盡可能的分流成helper function.

• crispy & sufficient的注釋

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

　　diff發(fā)出去之前

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

　　code-review之中應該做的

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

　　check-in之前應該做的

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

it知識庫：我的碼農(nóng)原則，轉載需保留來源！

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