我的碼農原則
這篇文章只是體現我以前寫代碼和做代碼審查時候的一些原則。供大家借鑒：1、正確性，不能解決問題的代碼都是耍流氓；2、可讀性， 統一的代碼規范；diff 發出去之前，code-review 之中，check-in 之前分別應該做什么？
</blockquote>@王淮
這篇文章只是體現我以前寫代碼和做代碼審查時候的一些原則。供大家借鑒。歡迎大家補充。
正確性 (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）讓后續的或者別人的改動對自己代碼不經意的破壞被最快的展現出來。
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.
- 統一的代碼規范
比如文件名，變量或函數名的命名規范，分行的前置空 2 個 spaces 或 4 個；每行的字數（不應超過 80char）；如何使用 public/private/protected；用左右括號的原則；空行的使用；文件和代碼 comments 的位置 （比如，代碼 comment 只能單獨成行）；對“// TODO:”的使用規范；macro，constant 的使用；
等等等等。
這里沒有特別的哪一種 style 一定更對，但是需要有一個大家統一的 guideline，一起遵守，讓整體的代碼有統一的風格和標準。
最大的好處就是有利于 readability.
- object-oriented v.s function-oriented
Java 本身就是面向對象，所以這個問題不大。但千萬不要出現披著面向對象的外皮，在 class 里面寫超長的面向函數的處理。這種情況下，盡可能的分流成 helper function.
- crispy & sufficient 的注釋
注釋應當簡潔但充分。有些人覺得代碼應該 speak for itself。我不大同意，代碼是實現細節，適當的在意圖上給予說明，可以大幅度的減少讀代碼的人的煩惱。
diff 發出去之前
- 與 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)
來自: www.tmtpost.com本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！