标签：简便 16px 版本 直接 很多 时间 没有 font int
代码复审：看代码是否在“代码规范”的框架内正确的解决了问题
代码复审三种形式：自我复审、用同伴复审的标准来要求自己。不一定最有效，因为开发者对自己总是过于自信。如果能持之以恒， 则对个人有很大好处。
同伴复审、简便易行
团队复审、有比较严格的规定和流程，适用于关键的代码，以及复审后不再更新的代码覆盖率高——有很多双眼 睛盯着程序，但效率可能不高（全体人员都要到会）
代码复审目的： 找出代码的错误：编码错误，不符合团队规范的地方
发现逻辑错误，程序可以编译通过，但是逻辑是错的
发现算法错误，如使用的算法不够优化，边界条件没有处理好
发现潜在的错误和回归性错误——当前代码修改导致以前修复的缺陷又重新出现
发现可能需要改进的地方
教育（互相教育）开发人员，传授经验，让更多的成员熟悉项目各部分的代码，同时熟悉和应用领域相关的实际知 识
代码复审的步骤：
复审前
严格编译通过，测试过代码，提供新代码与文件差异分析工具
复审中
面对面、独立或其他方式
复审者可以在任何时候打断
开发者有义务给出详尽回答
结果需达成一致
复审后
开发者整理记录并解决问题
伙伴复审的问题：
复审人员缺乏对程序的深入了解，减弱了复审的效果
不能持久、定时进行复审
对需求和设计的不了解导致无法实现全面有效的复审
团队复审的缺点：
聚齐人不容易
人太多，对程序理解程度不同，复审速度无法平衡
人太多，有面子问题
由于成本问题，无法对所有的设计和代码进行深入的复审
敏捷流程的步骤：
第一步：
找出完成产品需要做的事情 — Product Backlog。
产品负责人领导大家 对于这个 Backlog中的条目进行分析，细化，理清相互关系，估计工作量，等工作。每一项工作的时间估计单位为“天”。
第二步：
决定当前的冲刺（Sprint）需要解决的事情 — Sprint Backlog。 整个产品的实现被划分为几个互相联系的冲刺（Sprint）。产品订单上的任务被进 一步细化了，被分解为以小时为单位（参见 WBS 工作划分的办法）。如果一个任务的估计 时间太长（如超过 16 个小时），那么它就应该被进一步分解。
第三步
团队按照backlog 任务执行
在冲刺阶段，外部人士不能直接打扰团队成员。一切交流只能通过 Scrum 大师（Scrum Master）来完成。
第四步：
得到软件的一个增量版本，发布给用户。
然后在此基础上又进一步计划 增量的新功能和改进。
标签：简便 16px 版本 直接 很多 时间 没有 font int
原文地址：http://www.cnblogs.com/a1s2/p/7616158.html
