20170930-构建之法：现代软件工程-阅读笔记

Posted 2020-10-09 nothingisimpossible

代码复审：看代码是否在“代码规范”的框架内正确的解决了问题

代码复审三种形式：自我复审、用同伴复审的标准来要求自己。不一定最有效，因为开发者对自己总是过于自信。如果能持之以恒， 则对个人有很大好处。

 

　　　　　　　　　  同伴复审、简便易行

　　　　　　　　　 团队复审、有比较严格的规定和流程，适用于关键的代码，以及复审后不再更新的代码覆盖率高——有很多双眼 睛盯着程序，但效率可能不高（全体人员都要到会）

代码复审目的：  找出代码的错误：编码错误，不符合团队规范的地方
　　　　　　　　发现逻辑错误，程序可以编译通过，但是逻辑是错的     
　　　　　　　　发现算法错误，如使用的算法不够优化，边界条件没有处理好
　　　　　　　　发现潜在的错误和回归性错误——当前代码修改导致以前修复的缺陷又重新出现
　　　　　　　　发现可能需要改进的地方
　　　　　　　　教育（互相教育）开发人员，传授经验，让更多的成员熟悉项目各部分的代码，同时熟悉和应用领域相关的实际知 识

代码复审的步骤：
　　　　　　　　复审前
　　　　　　　　　　严格编译通过，测试过代码，提供新代码与文件差异分析工具

　　　　　　　　复审中
　　　　　　　　　　面对面、独立或其他方式
　　　　　　　　　　复审者可以在任何时候打断
　　　　　　　　　　开发者有义务给出详尽回答
　　　　　　　　　　结果需达成一致

　　　　　　　　复审后
　　　　　　　　　　开发者整理记录并解决问题

 

伙伴复审的问题：
　　　　　　复审人员缺乏对程序的深入了解，减弱了复审的效果

　　　　　　不能持久、定时进行复审

　　　　　　对需求和设计的不了解导致无法实现全面有效的复审

团队复审的缺点：
　　　　　　聚齐人不容易

　　　　　　人太多，对程序理解程度不同，复审速度无法平衡

　　　　　　人太多，有面子问题

　　　　　　由于成本问题，无法对所有的设计和代码进行深入的复审

敏捷流程的步骤：
　　第一步：
　　　　找出完成产品需要做的事情 — Product Backlog。
　　　　产品负责人领导大家 对于这个 Backlog中的条目进行分析，细化，理清相互关系，估计工作量，等工作。每一项工作的时间估计单位为“天”。
　　第二步：
　　　　决定当前的冲刺（Sprint）需要解决的事情 — Sprint Backlog。 整个产品的实现被划分为几个互相联系的冲刺（Sprint）。产品订单上的任务被进 一步细化了，被分解为以小时为单位（参见 WBS 工作划分的办法）。如果一个任务的估计　　　时间太长（如超过 16 个小时），那么它就应该被进一步分解。
　　第三步
　　　　团队按照backlog 任务执行
　　　　在冲刺阶段，外部人士不能直接打扰团队成员。一切交流只能通过 Scrum 大师（Scrum Master）来完成。
　　第四步：
　　　　得到软件的一个增量版本，发布给用户。
　　　　然后在此基础上又进一步计划 增量的新功能和改进。