Head First 软件开发(Software Development) 10-12
Section 10 Next Iteration
拥有可构建的软件片段, 完成Iteration, 通过所有测试(单元 系统 Black White) 按客户需求完成设计的代码
下一轮的计划
>关键 新加的US, 客户会增加US, 改变优先级 >时间效率值的更新 >工作量完成状况, 准备新白板 >下一个US >Defect
>把上衣个白板上的内容归档 拍照orDoc 了解计划的和完成的工作量 >
>在下一轮开发时, 重新计算修正US Estimation 和 时间效率
1)计算新的时间效率值(四舍五入) NextDays/(LastDays*Person) = newVel 2)预估时间 LastDays * Person * newVel = NextDays 3)新的工作填充白板 4)安排候选的US和上一轮留下的工作
>Defect 可以用US代表 作出保守的估算 包括research错误原因和修正错误的时间 可以参照类似出现过的Defect来估算时间
>决不能让团队执行超过最大工作量限制的任务, Solution -延长开发循环 但这样做会增加开发循环的风险 -拆分大的任务
时间效率值 计算Velocity是对团队在进行开发的真实情况下的考虑, 增加对估算值的信心, 确保工作量合适, 能按照承诺交付软件
变化是不可避免的 需要客户认可全部计划 如果客户作出重大改变, 白板需要重新规划, 你已经知道 -计算团队的时间效率值 -估计US和task的时间 -计算开发循环的规模(人天)
别人的软件代码集成 >US 第三方代码集成作为一个使用情节 >估计 build integration.. >优先级 客户确认
>Tasks 文档说明 序列图 类图 设计更新 集成代码 如果3rdParty不能正常运行, 了解第三方软件的授权范围, 联系第三方开发, 或者获得源代码
重用代码时, 要测试和确认第三方代码是可以正常运行的, 项目对第三方代码产生了依赖
>无论谁的代码在你的软件系统中, 它就变成了你的责任, 需要你来想办法解决(Source code Fix Or 联系相关人员修正Defect)
>对别人的代码持怀疑态度, 除非完整地经过测试
Summary
>本章要点 和客户检查下一轮开发的工作计划, 确认客户需求; 重新估算时间效率值; 让客户基于开发循环允许的工作量重新设定US的优先级; 不论写新代码还是重用他人代码, 遵循软件的开发流程;
用US表示代码功能, 包括新的和第三方的; 不要对重用的代码做假设, 用测试确认; API不能保证代码能正常运行, 需要测试确认; 需要多人Review Codes, 可阅读性, 可靠性, 易理解性
>处理不能正常运行的代码是软件开发工作的一部分
Responsibility, Project Board, Prioritize, Process 测试驱动, 版本控制, 持续集成
---Section10 End---
Section 11 Professionally Fix
把重构Refactoring和预构Prefactoring应用于Defect Fixing, 避免未来可能出现的Defect
第三方程序有问题, 不能在系统上正确运行
>和客户沟通 >错误跟踪, 放置Issue >将Source整合到存储目录, 构筑合理的目录结构 src test doc res..., 进行版本控制, 保证Build成功 >编写Building script
>考虑Build和Package, 整合到系统 >测试代码, 模拟运行
TODO >代码关联性, 对系统的影响 >考虑Package的版本 >标注History/Description >UML图 >测试覆盖率报告 >做好足够准备和预估, 能为之后的工作节省大量时间
功能性是重心 >只需修改对所需的功能有影响的Defect, 修改US所依赖的codes
>本章要点 一切围绕面向用户的功能性; 代码满足US的要求; 仅仅修改那些损坏的代码, 测试帮助定位; 测试是安全网, 帮助确认Defect;
如果某功能没有被测试, 相当于此功能是坏的; 符合功能性的代码比漂亮的代码重要, 修改代码是为了符合用户需求
Spike Test 峰值测试, 在一段时间内解决一部分问题, 利用这些结果来估计完成其他事情需要多长时间
>计划几天时间做SpikeTest >随机挑选Defect来修复 >最后计算错误修正率 Fixed Number / Days = Daily Fix Rate, 用来估算修复所有Defect的时间
>峰值测试提供定量的数据 Quantitative data, 作为可估计的基础, 随机样本
>没有提供定性的数据, Qualitative data, 有潜在的不确定因素影响估计
团队成员的真实感 >考虑信心值 (>95%) 可以计算成员的平均信心值 >增加信心 (Defects Number / Fix Rate ) / Average_Confidence = Days
代码质量 >通过测试(Hand test + Unit test) >可读性 命名 流程 注释 >按时交付通过测试的, 具有可读性的代码比完美代码更重要
保证所有被用于完成US的代码通过了测试, 可正常运行, 保证功能性
Summary
>开发技巧 修改代码前确认可控性和可构建性; 使用峰值测试来估计难以估计的Defects修复时间; 修正估计工作量, 加入信心值; 利用测试验证Defect Fixing
>开发原则 Be Honest to Customer; 第一要紧是软件能正常运行; 可读性, 易读性是第二步; 未经测试的代码被看作是不能正常运行的; 修正功能; 系统中所有的代码(包括第三方)都属于团队责任
>本章要点 修改代码之前先把它加入到构建流程和源码管理中; 对软件中所有的代码负责; 不要假设代码能运行, 需要测试验证; 正常运行的代码第一, 出色的代码第二;
自豪感测试, 你乐意让别人阅读和依赖你的软件, 表明代码良好
Fix Rate, Prefactor, Prioritize, Readable, Functionality, Responsibbility, RandomSample, SpikeTest
---Section11 End---
Section 12 Handle the Real Process
软件开发流程定义 强加在软件产品开发上的一种程序结构, 开发高品质软件的框架
没有万能的流程 伟大的软件开发流程就是使开发团队成功的流程
>反复式开发 包括开发循环 >不断评估和核定 在变化中调整 >整合最佳实践 对项目有帮助的方式 流程怀疑论 Process Skepticism
谨慎改变流程
>尽量不要在开发循环的中期改变 等到当前开发循环结束 >建立衡量标准来确定变化是否有帮助 1理由2改变3检查, 避免太主观和情感化 >重视团队成员
White Board >提供了项目进度的跟踪 每个成员的Tasks情况 WIP, Done, ToDo >减少了功能遗漏, 帮助任务计划, 掌握开发循环的成果
User Story >分解软件需求, 记录需求, 确认客户想要的系统功能是否正确捕捉 >减少了对系统功能的错误理解, 有助于加快开发进度
Version Control >代码的修改能分发到每个成员, 减轻文件丢失损坏的风险代价, 标记分支产生多个 软件版本 >帮助代码合并, 对软件中一部分的修改不影响其他部分
Continuous Build >存储目录中的软件可构建, 运行编译和测试, 软件能运行 >帮助编译测试程序, 减少Defect
TDD >保证代码在开发之初就可以测试, 测试友好 Test-friendly模式 >良好的测试覆盖率, 减少Defect, 较好的设计, 较少的无用代码
Test Coverage >衡量多少代码测试通过, 发现Defect的一种方式, 没有被测试和覆盖的代码通常存有Defect >软件错误集中产生在边界情形, 主要部分经过良好测试
>正式的文档 Design, 项目计划, US, HLSD... >正进行的大多数工作都可以被捕捉并生成正式份额报告
>选择适合团队和项目的流程, 调整并且使其符合客户需求
Summary
>开发技巧 采用真实评测数据, 批判性地评估对流程作出的评估; 必要的话, 做正式化的交付; 尽量在吧流程变更放在不同开发循环之间
>开发原则 伟大开发人员交付软件; 好的开发人员能克服不好的流程; 好的流程帮助团队成功
>本章要点 在做流程变更时要考虑团队中其他成员的意见; 流程变更需要1)讨论决定2)评估有效性; 避免在多个地方保存文档, 维护文档代价太大; 对流程持怀疑态度, 保持应变, 找到适合的
Standups, Ship, Average, iteratively, ProcessSkepticeism, Idealdays, Priority, ,
---Section12 End---
附录I:
1 UML Unified Modeling Language, 表达代码和应用结构的重要细节 类图 表述静态结构 >关联关系 一个类是由另外一个类的对象组成 >继承关系
2 序列图 表述事件发生顺序,显示对象在运行时的相对顺序 lifeline 表示生命周期 方向箭头表示调用Function和顺序
3 使用情节/用户案例 相类似的方式来描述软件要做的一件事
4 系统测试/单元测试 -代码能正常工作 -满足客户设定的需求
>Unit Test 验证代码工作, 每一个类应该有一个相应的测试单元, Test Drive时, 测试代码最先写
>System Test 验证代码符合需求, 模拟客户, 模拟场景
>Acceptance Test 验收测试由客户主导
5 代码重构 Refactoring 修改代码结构但不改变行为
增强清晰性, 灵活性和可扩展性, 对代码的检查是一个持续不断的过程
附录II:
技术和原则 (=Summary)
End
