|
|
這篇文章只是體現我以前寫代碼和做代碼審查時候的一些原則。供大家借鑒。歡迎大家補充。
正確性 (Correctness)
正確性是第一要求。不能解決問題的代碼是耍流氓。
- 結構 (Code Structure）
結構體現邏輯。第一步，第二步；需要什么數據，需要做什么處理，處理完了結果到那里去，都應該在結構中被很好的體現出來。
結構體現設計。 設計一定要清晰。我的經驗來看，一般來說，在design chart上面的每個component都對應著自己的class，然后之間或class內部的通信通過member function來完成。
一個可借鑒的做法 – 在一個大的feature implementation過程中，給出第一個diff的時候，可以只把結構當做一個diff，里面的函數可以是空的(place holder)。
把數據的生成和界面的展示分開來。典型的可以按照MVC的模式來，但也可以只把數據和UI分開來的比較輕量級的做法。結構應當是diff review時候最最關注的地方。最需要問的問題就是“這個diff號稱要解決的問題被正確解決了嗎？”
- test的重要性
不論你再正確，還是有錯誤的時候。通過（相對）公證的test來 1）減少自己被繞到代碼里的幾率；2）讓后續(xù)的或者別人的改動對自己代碼不經意的破壞被最快的展現出來。
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ī)范
比如文件名，變量或函數名的命名規(guī)范，分行的前置空2個spaces或4個；每行的字數（不應超過80char）；如何使用public/private/protected；用左右括號的原則；空行的使用；文件和代碼comments的位置 （比如，代碼comment只能單獨成行）；對“// TODO:”的使用規(guī)范；macro，constant的使用；
等等等等。
這里沒有特別的哪一種style一定更對，但是需要有一個大家統(tǒng)一的guideline，一起遵守，讓整體的代碼有統(tǒng)一的風格和標準。
最大的好處就是有利于readability.
- object-oriented v.s function-oriented
Java本身就是面向對象，所以這個問題不大。但千萬不要出現披著面向對象的外皮，在class里面寫超長的面向函數的處理。這種情況下，盡可能的分流成helper function.
- crispy & sufficient的注釋
注釋應當簡潔但充分。有些人覺得代碼應該speak for itself。我不大同意，代碼是實現細節(jié)，適當的在意圖上給予說明，可以大幅度的減少讀代碼的人的煩惱。
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)，以讓作者明白問題所在。
- 盡可能把對修改的所有意見一次性給出，減少來來回回的次數。比較復雜的建議reviewer主動找author來進行線下溝通，達成一致。
- 一般的diff，來回次數不宜超過3次；如果超過3次，想想看，是不是diff 太大，太復雜了。
check-in之前應該做的
- 與master做一次merge update，確保沒有問題
- run一次code change涉及到的所有test cases（包括新增的和涉及到的test cases)
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
