17 软件构造.pptVIP

Issues: Workplace Layout Bad Better Best Issues: Partner Picking Principles Expert paired with an Expert Expert paired with a Novice Novices paired together * * 常见错误(1) 内存或资源泄漏； 逻辑错误； 编码错误（例如条件判断不够充分）； 内存溢出（超出本身限制）； 循环错误（死循环或数目不合适）； 条件错误； 指针错误（超出范围，未赋值）； 分配释放错误（分配两次、未分配即释放、释放两次、分配未释放）； * 常见错误(2) 多线程错误（同步）； 定时错误（没有考虑特殊情况）； 存储错误（考虑磁盘已满，文件不存在等特例）； 集成错误（相互之间的考虑不相容）； 转换错误（字符转换等出现问题）； 硬编码长度/尺寸； 版本缺陷（对以前的不兼容）； 不恰当重用带来的缺陷。 * 修复缺陷的注意点 一次只修复一个缺陷。 修改前保留旧版本的备份，如果项目使用了配置管理系统，这个工作会由配置管理工具完成，否则就需要由程序员手动完成。 使用测试和评审验证修复的有效性。 检查和修复类似的缺陷，这可以在代码搜索、程序切片等工具的帮助下进行。 * 代码评审 代码评审对代码的系统检查，通常是通过同行专家评审来完成的。通过评审会议可以发现并修正之前忽略的代码错误，从而同时提高软件的质量和开发者的技巧。 代码评审一般分为正式评审、轻量级评审和结对编程。 * 评审的经验 就算不能评审全部的代码，最少也要评审一部分（20–33%）代码，以促使程序员编写更好的代码。 一次评审少于 200–400 行的代码。 目标为每小时低于 300–500 LOC 的检查速率。 花足够的时间进行正确缓慢的评审，但是不要超过 60–90 分钟/每次。 确定代码开发者在评审开始之前就已经注释了源代码。 使用检查列表，因为它可以极大地改进代码开发者和评审者的工作。 确认发现的缺陷确实得到修复了。 培养良好的代码评审文化氛围，在这样的氛围中搜索缺陷被看做是积极的活动。 采用轻量级，能用工具支持的代码评审。 * 代码评审检查列表(1) * 代码评审检查列表(2) * 代码评审检查列表(3) * 集成与构建 在以分散的方式完成程序基本单位（例程、类）之后，软件构造还需要将这些分散单位集成和构建为构件、子系统和完整系统。 集成有大爆炸式集成和增量式集成两种方式。实践中增量式集成有着更好的效果。 构建将可读的源代码转换为标准的能在计算机上运行的可执行文件。构建过程需要配置管理工具的帮助。 * 集成与构建: Best Practices daily build smoke test, Microsoft Continuous integration 构造管理 构造计划 Select Construction Environments 度量 配置管理 * Individual Variation Is Significant Researchers have found variations ranging from 10x to 28x in: Coding speed Debugging speed Defect-finding speed Percentage of defects found Bad-fix injection rate Design quality Amount of code generated from a design Etc. Select Construction Environments Construction Environments Programming Language Construction Platforms OS, DBMS, Network, Middleware, Etc. Standards Code standards Technology standards Component model, etc. Tools Coding environments Debug and testing environments Sourcing managing environments Main Contents What’s Construction Construction Activities Some best practices of construction 实践方法 重构 测试驱动开发 结对编程 * 重构 重构 修改软件系统的严谨方法，它在不改变代码外部表现的情况下改进其内部结构 最初是软件维护的方法，后来被用于软件设计 重构的时机 增加新的功能时 重构发生在新