為什麼要進行Code Review？
- 自我提升工程師個人技術水準。
- 增強代碼品質，統一代碼的風格，提高可讀性，發現潛在bug，降低後期團隊維護成本。
- Code Review必然要面對重構，這是很好的鍛煉編碼技巧的機會。
- 為團隊合作提供交流分享的機會，代碼貫穿于團隊，不再是一個人掌握一塊代碼。
- 總結錯誤，提高今後設計開發的預見性。階段性總結對團隊是有益的，可以逐漸培養形成團隊的程式設計規範習慣。
Code Review的層次
- 基本的層次就是編碼規範，包名，類名，變量名，方法名等。
- 高層次的就是代碼品質，在保證代碼的美觀後，要保證代碼的合理性，健壯性，可讀性，可維護性等等。
基本的代碼規範就不說了，之前的文章介紹過了，下面列舉一些個人總結的關于Code reivew經驗：
1. 異常處理：使用try-catch-finally進行異常捕獲處理。
凡是會抛出異常的地方都進行捕獲，你可以在catch中處理異常，如果不想處理則throw這個異常，由調用者去try-catch處理:
涉及到資源關閉的記得在finally中關閉資源：
另外不要在循環體中捕獲異常，放在最外層，以提升性能。
2. 空指針，千萬不要理所當然的以為一個對象不會為空，在使用一個變量之前一定要進行判空處理，做好充分的容錯處理。
3. 數組越界，使用數組、List之前檢查索引和長度。
4. 魔鬼數字：直接寫在代碼裡的數字，一定要用常量符号代替。
5. 對于可以複用的部分，提取成共用的方法或工具類，減少代碼量。
6. 删除無用的變量和無用的引入。
7. 代碼中的中文字元串最好統一在strings.xml中定義。
8. 所有Activity可繼承自一個BaseActivity，便于統一行為管理，建構對話框統一建構器的建立，萬一需要整體變動，一處修改到處有效。
9. 資料庫表段字段常量和SQL邏輯分離，更清晰。
10. 全局變量放全局類中，子產品私有放自己的管理類中，讓常量清晰且集中。
11. 不要相信龐大的管理類的東西會帶來什麼好處，可能是一場災難，而要時刻注意單一職責原則，一個類專心做好一件事情。
12. 多線程操作資料庫時，db關閉了會報錯，可能出現互鎖的問題，使用事務。
13. 開始之前考慮哪些可以公用，資源，layout，類，做一個結構/架構分析以加快開發，提升代碼複用度。
14. 關于形參實參：參數為基本類型傳的是傳值；參數為對象傳遞的是引用，即傳址，這種改變會作用于原來對象。
15. 控制Activity的代碼量，保持主要邏輯清晰。其他類遵守SRP（單一職能），ISP（接口隔離）原則。
16. Log請打上Tag，調試列印一定要做标記，能定位列印位置，否則會尴尬不知道是哪裡在列印。
17.與Activity通訊使用Handler更友善； 如果你的架構回調鍊變長，考慮監聽者模式簡化回調。
18. 構造函數裡面不推薦啟動異步線程，會埋下記憶體隐患。
19. UI顯示注意内容過長的情形要提前使用ScrollView否則在小手機上尴尬你懂得。
20. String的比較用equals，不要一時犯傻用了==。
21. Long a; 判斷a有沒有指派，if(a == 0)在a沒有指派情況下會報錯。應該if(a == null)，Integer、Floag等也一樣。
22. 編碼遇到讀寫、出入等邏輯要雙向考慮，檔案導入導出，字元位元組互相轉換都要兩邊轉碼。
23. 從資源檔案或者檔案加載一張圖檔時注意其寬高，避免OOM, bitmap的記憶體占用是寬x高x機關像素占用位元組（RGB565是2個位元組，ARGB8888是4個位元組）。
24. 對于并不那麼注重通路性能的較小集合而言，List 則是合理的選擇。for循環對下标沒有要求的優先使用foreach循環。
25. 選擇正确的集合類型使你能夠在集合性能與記憶體占用之間達到合理的平衡。例如某些情況下用SparseArray代替HashMap。
26. 充分利用封裝（提供接口類來控制通路資料）和委托（helper對象來實施任務）兩種理念。
27. 當邏輯沒有明顯問題時考慮對象屬性、函數參數、網絡傳輸參數是否全部了解，是否設定正确。
28. 拼接字元串避免String進行頻繁+操作，應該使用StringBuilder提升性能，多線程使用StringBuffer操作string提高程式效率。
29. 基本資料類型定義的變量稱自動變量，存的是‘字面值’，存在于棧中，可共享（存在即不建立）。
30. 隻要是用new()來建立對象的，都會在堆中建立，而且其資料是單獨存值的，即使與棧中的資料（值）相同，也不會與棧中的資料共享。
31. 能複用同一個對象處理的盡量複用，不要使勁的在那裡new對象，記憶體吃不消，尤其是for循環等。
32. 改變邏輯的時候考慮全部用到這項功能的地方，分散的地方多了可能會忘記，不要為了填坑而挖了一個坑。
33. 不要在布局檔案xml中使用onClick屬性，如果你忘了在代碼中聲明onClick方法就會悲劇。
34. 注意參數的++或者--操作的差別。
35. 服務端可以實作的，就不要放在用戶端。
36. 引用第三方庫要慎重，避免應用大容量的第三方庫，導緻用戶端包非常大。
37. 重複類似的功能在統一個類中去實作，而不是重複的去new一個相同類的執行個體，如activity中在一個View.OnClickListener中處理所有的邏輯，接口回調在同一個callback中處理。
38. 多用組合，少用繼承。
39. 合理布局，有效運用<include> ，<merge>、<ViewStub>等标簽。
40. 盡量采用懶加載的政策，即在需要的時候才建立。
41. 盡量使用HashMap、ArrayList、StringBuilder，除非線程安全需要，否則不推薦使用Hashtable、Vector、StringBuffer。
42. 可以使用局部變量代替的，盡量不去建立全局變量。
43. 一個接口可以解決的事，盡量不去導入一個架構。
44. 控制一個應用中的單列使用場景，防止濫用，單例主要用于控制資源的并發使用、 控制執行個體的産生， 控制資料的共享。
45. 基本資料類型轉為字元串，推薦方式為：基本資料類型.toString()、String.valueOf(資料)次之、資料 + ""（避免）。
47. 使用的UI切圖圖檔資源等如果太大盡量壓縮以減少apk體積。
48. 避免常見的記憶體洩漏：
- 單例模式持有的context是Activity的context，改為能使用Application的Context就不要使用Activity的Content，Application的生命周期伴随着整個程序的周期。
- 非靜态内部類以及匿名内部類的靜态執行個體造成記憶體洩漏
- Handler和Thread使用不當造成的記憶體洩漏
- 資源未關閉造成的記憶體洩漏
- 使用了靜态的Activity和View造成記憶體洩漏
- 注冊了系統的服務，但onDestory未登出
- 不需要用的監聽未移除會發生記憶體洩露
- 集合中對象沒清理造成的記憶體洩漏
- 大尺寸的圖檔Bitmap使用造成的記憶體洩漏
記憶體洩漏相關文章：避免記憶體洩漏1，避免記憶體洩漏2，避免記憶體洩漏3。
49. 使用工具來分析代碼：
- 使用AS自帶的Lint來優化代碼結構（什麼，你不會？右鍵module、目錄或者檔案，選擇Analyze → Inspect Code），非常有用的一點是它能告訴你API版本相容的需求。
- 使用FindBug插件來查找bug，AS自行安裝。
- 使用AS自帶記憶體調試工具來查找記憶體洩漏。不會使用的可以看：使用1， 使用2。
養成良好的代碼規範和程式設計習慣不是一朝一夕的事，需要持之以恒，要知道妖精在修煉成精以前都是要堅持修煉的，我們程式猿也是如此，建議每天固定時間或隔幾天或固定每周幾進行一次Code Review，哪怕隻有十分鐘半小時，堅持下來也會受益頗多的。
CodeReview作為業界公認的最佳實踐，如果每個團隊都能運用起來，固然是最好的，但是這項活動否能有效運作往往跟團隊狀态、技術信仰和上司者訴求等都有莫大關系。技術驅動型團隊、公共服務型團隊、新人密集型團隊等比較容易有效進行Code Review，而業務驅動型團隊、創新型團隊等很難Code Review進行，此外還跟團隊上司者觀念以及公司文化有關（做這件事又不能提高我的績效為什麼要做它？bug都改不完功能還沒做完為什麼要做這個？）。
--------------------------------------------------------------------------------------------------------------------------------------------
“什麼狗屁代碼，老子看了幾個小時也沒明白！”
“這麼爛的代碼，到底是誰寫的！”
“This Is Just Like a Shit！”
Bob大叔說：“衡量代碼品質的唯一标準是閱讀該代碼時說髒話的次數”。
嗯，從哲學角度來看，不得不說這句話是很有道理的。。可見對于程式員而言可讀性是多麼重要的原則。
更多CodeReview方面的介紹請參考:
大家的公司的 Code Review 都是怎麼做的？遇到過哪些問題？