1、结对，找到一个伙伴进行结对；伙伴的博客连接：http://www.cnblogs.com/frx15100213/设计模式
2、各自对本身的伙伴上周进行的“单元测试”练习所完成的代码进行复审，造成“代码复审检查表”。数据结构
| 概要部分函数 |
代码符合需求和规格说明么？post |
大体符合单元测试 |
| 代码设计是否考虑周全？学习 |
不太周全测试 |
|
| 代码可读性如何？优化 |
简单明了ui |
|
| 有冗余的或重复的代码吗?编码 |
没有 |
|
| 代码的每一行都执行并检查过了吗？ |
是 |
|
| 设计规范部分 |
设计是否听从已知的设计模式或项目中经常使用的模式？ |
否 |
| 有没有硬编码或字符串/数字等存在？ |
有 |
|
| 代码有没有依赖于某一平台? |
没有 |
|
| 有没有无用的代码能够清除？ |
没有 |
|
| 代码规范部分
|
修改的部分符合代码标准么? |
符合 |
| 修改的部分的设计是否规范？ |
大体符合规范 |
|
| 具体代码部分 |
数据结构中有没有用不到的元素？ |
没有 |
| 对于调用的外部函数，是否检查了返回值？ |
是 |
|
| 效能 |
代码的效能（Performance）如何？ |
良好 |
| 代码中，特别是循环中是否有明显可优化的部分 |
没有 |
|
| 可读性
|
有没有足够的注释？ |
没有注释 |
| 逻辑是否容易理解？ |
是 |
|
| 段落间和符号旁有没有空白？ |
没有 |
|
| 可测试性 |
是否须要更新或建立新的单元测试？ |
是 |
代码复审感想：
提升代码质量在项目的早期发现缺陷，将损失降至最低评审的过程也是从新梳理思路的过程，双方都加深了对系统的理解促进团队沟通、促进知识共享、共同提升。代码审查自己提升开发者的能力，让其从自身犯过的错误中学习，从他人的思路中学习。在代码审查中若是发现问题，对于问题的发现者来讲这是好事，应该予以鼓励。但对于被发现者，咱们不主张使用这个方式予以惩罚。软件开发中bug在所不免，过分苛求自己有悖常理。更糟的是，若是形成参与者怕承担责任，不肯意在审查中指出问题，代码审查就没有任何的价值和意义。