6-构造与设计的管理

6.1 协同构建

6.1.1 内容

• 结对编程
• 正式检查
• 非正式技术复查
• 文档阅读
• 让开发人员共同承担创建代码及其他工作产品责任的技术

6.1.2 数据:评审的益处

6.1.3 写作构造是一种文化

6.1.4 代码集体所有

6.1.5 结对编程原则

• 用编码规范来支持结对编程
• 不要让结对编程变成旁观
• 不要强迫在简单的问题上使用结对编程
• 有规律的对结对人员进行轮换
• 鼓励双方跟上对方的步伐
• 确认两个人能够看到显示器

6.1.6 结对编程的益处

• 使人们在压力之下保持好的状态
• 改善代码质量
• 缩短进度表
• 培养集体归属感

6.1.7 评审–正式检查

是一种特殊的复查

6.1.8 评审的流程

• 概述
• 准备
• 详查会议
• 返工

• 跟进

• Checklists focus the reviewers’ attention on areas thathave been problems in the past.

• The inspection focuses on defect detection, notcorrection.
• Reviewers prepare for the inspection meeting beforehandand arrive with a list of the problems they’ve discovered
• Distinct roles are assigned to all participants.
• The moderator of the inspection isn’t the author of thework product under inspection.
• The moderator has received specific training inmoderating inspections.
• The inspection meeting is held only if all participantshave adequately prepared.
• Data is collected at each inspection and is fed intofuture inspections to improve them.
• General management doesn’t attend the inspection meeting unless you’re inspecting a project plan or other management materials. Technical leaders might attend

6.2 开发者测试

6.2.1 开发者测试所占时间

6.3 重构与调优

再庞大复杂的代码都可以通过重构加以改善

6.3.1 重构的理由

• 代码重复
• 冗长的子程序
• 循环过长或嵌套过深
• 内聚性太差的类
• 类的接口未能提供层次一致的抽象
• 游泳太多参数的参数列表
• 类的内部修改往往被局限于某个部分
• 变化导致对多个类相同的修改
• 对集成体系的同样修改
• 同时使用相关数据并未以类的方式进行组织
• 成员函数使用其他类的特征比使用自身类的特征还多
• 过多使用基本数据类型
• 某个类无所事事
• 一系列传递流浪数据的子程序
• 中间人对象无事可做
• 某个类同其他类关系过于亲密
• 子程序命名不恰当
• 数据成员被设置为公用
• 某个派生类金金使用了基类的很少一部分成员函数
• 注释被用来解释难懂的代码
• 使用了全局变量
• 在子程序调用前后有一系列必须操作
  
  

6.3.2 重构的策略

• 保存初始的代码
• 重构的步伐请小些
• 同一时间只做一项重构
• 把要做的事情一条条列出来
• 设置一个停车场
• 多使用检查点:多个历史版本
• 利用编译器警告信息
• 重新测试
• 增加测试用例

• 检查对代码的修改

• 在增加子方法的时候重构

• 在添加类的时候重构
• 在修补缺陷的时候重构
• 关注易于出错的模块
• 关注高度复杂的模块
• 在维护环境下改善你手中正在处理的代码
• 定义清楚干净代码和拙劣代码的边界,然后尝试把代码移过这条边界

6.3.3 重构检查表

6.3.4 重构&调优

Code tuning is the practice of modifying correct code in ways that make itrun more efficiently, and it’s the subject of the rest of this chapter.”Tuning” refers to small-scale changes that affect a single class, a singleroutine, or, more commonly, a few lines of code.

6.3.5 调优的层次

6.4 构建管理

6.4.1 鼓励良好的编程实践

• 给项目的每一个部分分派两个人
• 逐行复查代码
• 要求代码签名
• 安排一些好的代码示例供人参考
• 强调代码是共有财产

6.4.2 配置管理

配置管理是”系统化地定义项目工件和处理变化,以使项目一直保持其完整性”的实践活动–变更控制

6.4.3 评估构建工作表

评估构建工作量

评估构建进度表

• 建立目标
• 为评估留出时间并做出计划
• 清楚说明软件需求
• 在底层细节层面进行评估
• 使用不同的评估方法，比较结果
• 定期重新评估
  

度量

• For any project attribute, it’s possible to measure thatattribute in a way that’s superior to not measuring it at all
• If data is to be used in a scientific experiment, it must bequantified
• Be aware of measurement side effects
• To argue against measurement is to argue that it’sbetter not to know what’s really happening on yourproject

6.5 把程序员当人看

HR的一些问题

• 个人绩效差异
• 因团队不同
• 信仰问题
• 环境问题
• 管理你的管理者

小结

6.3 重构与调优

再庞大复杂的代码都可以通过重构加以改善

6.3.1 重构的理由

• 代码重复
• 冗长的子程序
• 循环过长或嵌套过深
• 内聚性太差的类
• 类的接口未能提供层次一致的抽象
• 游泳太多参数的参数列表
• 类的内部修改往往被局限于某个部分
• 变化导致对多个类相同的修改
• 对集成体系的同样修改
• 同时使用相关数据并未以类的方式进行组织
• 成员函数使用其他类的特征比使用自身类的特征还多
• 过多使用基本数据类型
• 某个类无所事事
• 一系列传递流浪数据的子程序
• 中间人对象无事可做
• 某个类同其他类关系过于亲密
• 子程序命名不恰当
• 数据成员被设置为公用
• 某个派生类金金使用了基类的很少一部分成员函数
• 注释被用来解释难懂的代码
• 使用了全局变量
• 在子程序调用前后有一系列必须操作
  
  

6.3.2 重构的策略

• 保存初始的代码
• 重构的步伐请小些
• 同一时间只做一项重构
• 把要做的事情一条条列出来
• 设置一个停车场
• 多使用检查点:多个历史版本
• 利用编译器警告信息
• 重新测试
• 增加测试用例

• 检查对代码的修改

• 在增加子方法的时候重构

• 在添加类的时候重构
• 在修补缺陷的时候重构
• 关注易于出错的模块
• 关注高度复杂的模块
• 在维护环境下改善你手中正在处理的代码
• 定义清楚干净代码和拙劣代码的边界,然后尝试把代码移过这条边界

6.3.3 重构检查表

6.3.4 重构&调优

Code tuning is the practice of modifying correct code in ways that make itrun more efficiently, and it’s the subject of the rest of this chapter.”Tuning” refers to small-scale changes that affect a single class, a singleroutine, or, more commonly, a few lines of code.