1、結對，找到一個夥伴進行結對；夥伴的博客連接：http://www.cnblogs.com/frx15100213/設計模式
2、各自對本身的夥伴上週進行的「單元測試」練習所完成的代碼進行復審，造成「代碼複審檢查表」。數據結構
| 概要部分函數 |
代碼符合需求和規格說明麼？post |
大體符合單元測試 |
| 代碼設計是否考慮周全？學習 |
不太周全測試 |
|
| 代碼可讀性如何？優化 |
簡單明瞭ui |
|
| 有冗餘的或重複的代碼嗎?編碼 |
沒有 |
|
| 代碼的每一行都執行並檢查過了嗎？ |
是 |
|
| 設計規範部分 |
設計是否聽從已知的設計模式或項目中經常使用的模式？ |
否 |
| 有沒有硬編碼或字符串/數字等存在？ |
有 |
|
| 代碼有沒有依賴於某一平臺? |
沒有 |
|
| 有沒有無用的代碼能夠清除？ |
沒有 |
|
| 代碼規範部分
|
修改的部分符合代碼標準麼? |
符合 |
| 修改的部分的設計是否規範？ |
大體符合規範 |
|
| 具體代碼部分 |
數據結構中有沒有用不到的元素？ |
沒有 |
| 對於調用的外部函數，是否檢查了返回值？ |
是 |
|
| 效能 |
代碼的效能（Performance）如何？ |
良好 |
| 代碼中，特別是循環中是否有明顯可優化的部分 |
沒有 |
|
| 可讀性
|
有沒有足夠的註釋？ |
沒有註釋 |
| 邏輯是否容易理解？ |
是 |
|
| 段落間和符號旁有沒有空白？ |
沒有 |
|
| 可測試性 |
是否須要更新或建立新的單元測試？ |
是 |
代碼複審感想：
提升代碼質量在項目的早期發現缺陷，將損失降至最低評審的過程也是從新梳理思路的過程，雙方都加深了對系統的理解促進團隊溝通、促進知識共享、共同提升。代碼審查自己提升開發者的能力，讓其從自身犯過的錯誤中學習，從他人的思路中學習。在代碼審查中若是發現問題，對於問題的發現者來講這是好事，應該予以鼓勵。但對於被發現者，咱們不主張使用這個方式予以懲罰。軟件開發中bug在所不免，過分苛求自己有悖常理。更糟的是，若是形成參與者怕承擔責任，不肯意在審查中指出問題，代碼審查就沒有任何的價值和意義。