《修改软件的艺术》读书笔记

本文为《修改软件的艺术》读书笔记，纯粹记录作者观点，不做个人理解~
第一部分：遗留代码危机
大多数软件开发和维护方式“有些不对劲”，在传统的瀑布式开发环境下，我们要等到最后一步才能看到一切正常运转，当bug出现的时候，它难以修复，非常耗时，以至于追踪修复的成本很高。
从而引出为何需要敏捷开发：第二部分 延续软件生命和价值的9种实践方法。
敏捷理论摒弃了用增加流程来保证质量的方式，建议流程更加精简，好让开发者有更多时间实施更切实际的工程实践。
实践1：在问如何做之前先问做什么，为什么做，给谁做
作为软件开发者，我们希望了解产品负责人和客户需要什么以及为什么需要，我们想知道这些东西是为谁而做的———我们并不希望他们告诉我们如何去做，因为那是我们的工作。
要有一个产品负责人：一个对整个项目全权负责的人，和客户接触最频繁，对产品理解深刻的人。产品负责人还要准备好承担压力。
软件开发者之所以会过度开发，是因为我们害怕某个功能会以我们没有预料的方式使用。如果我知道了软件如何被使用，就可以针对这一需求开发，然后进行其它工作。
把定义功能的方式从描述实现细节转变为描述做什么，为什么做，给谁做，消除需求分档的编写，在产品负责人和开发团队之间建立创造性的合作关系，构建功能将更高效，可以节省三分之一的开发时间
实践2：小批次构建
时间盒子是一个用固定的时间周期执行任务的实践方法。范围盒子则不管时间而倾向于一个可以被简单描述的完整的工作：一个用户故事或功能。在时间盒子和范围盒子之间进行选择，取决于工作的类型。如果任务大小都是统一的而且比较小，范围盒子比较适用。管理范围比管理时间更需要技术，所以通常先选择时间盒子，直到你已经可以熟练地把功能分解为较小的任务。
将大任务拆分为小任务需要一定的技巧，即在分割的同时保持代码的模块化。
消除某项功能风险的唯一方式就是当它开发完成时就把它完整地集成进系统。
“迭代”的真正目的是让团队消除以发布为单位的构建习惯。一旦消除这种习惯，你就再也不需要“时间盒子”了，用一个称为看板的敏捷方法可以做到这点。
迅速找到缺陷不仅可以降低修复成本，而且帮助开发者从一开始就避免缺陷的产生。
用户故事越短越好。短故事容易预估、理解和实现。短故事有助于构建高内聚低耦合的代码。短故事更容易测试。
如何拆分
①把复合的故事拆分为组件
②把复杂的故事分割为已知的和未知的
③对未知持续迭代直至完全理解
④根据验收标准分割故事
⑤最小化依赖
⑥保持目的单一
⑦保持故事可测试性
小批次构建让每个任务都可以在短时间内完成，保证任务都满足验收标准，或者至少产生可观察的结果。
实践3：持续集成
“持续集成”是一种在构建使其而非发布前进行集成的实践。持续集之所以如此重要，是因为它不仅帮助开发者尽早消除bug，也帮助开发者学习如何编写更好的代码，使其更容易集成。
构建敏捷设施的7个策略
①用版本库管理一切
②一次点击全部构建
③持续集成
④为任务定义验收标准
⑤编写可测试的代码
⑥保证必要的测试覆盖率
⑦及时修复失败的构建
实践4：协作
在处理复杂问题时，近距离的合作会帮助你验证自己的想法，有助于对问题进行更全面的思考。结对编程可以帮助彼此提高速度，有助于资深开发者指导那些经验尚欠的开发者。结对编程有助于形成统一的代码风格和代码集体所有权。
穿刺是指两个或两个以上开发者一起执行同一个任务，通常用预先规定好的一段时间对某些未知问题进行研究。
结对编程的7个策略
①尝试一下，你会喜欢的
②驾驶员和领航员都要参与其中
③频繁交换角色
④充实工作一天
⑤尝试各种配置
⑥让团队决定细节
⑦跟踪进度
实践5：编写整洁的代码
Cohesive 内聚：类和方法应该具有单一的职责：一个类应该只有一个目的。
Looseiy Coupled 松散耦合：松散耦合的代码不直接依赖它使用的代码
Encapsulated 封装：根据客户端的需要设计服务。根据所做的事情命名服务，隐藏它是如何工作的。
Assertive 自主：对象之间不应该互相干预。他们应该具有权威。
Nonredundant 没有冗余：非刻意的冗余会产生维护性问题。
实践6：测试先行
从bug产生到它修复的时间越长，成本越大。
多数系统都含有并非通过测试驱动开发的代码，这样测试起来就会与难度。这些代码包括：和用户界面交互的代码，和数据库交互的代码，多线程代码，以及很多其它代码。
在编写先行测试的时候，我所做的是我对于需求理解的假设。我对如何调用一个服务以及我希望什么样的结果进行假设。我对完成结果进行假设。
单元是指一个行为的单元：一个队里的可验证的行为。它必须对系统产生可观察的影响，而不和系统的其他行为耦合。
TDD可以提供迅速的反馈
TDD可以为重构提供支持
实践7：用测试描述行为
如果所有测试都通过了，就会得到一个绿条，如果有些测试失败了，就会有个红条。这样和你的代码进行对话非常美妙。一点一点，周而复始，红条、绿条、重构，周期循环。用这个方式构建整个系统。
测试先行是一种设计方法，一定要编写可测试的代码，将需求具体化，这能帮助开发者构建高质量的代码。
实践8：最后实现设计
删除死代码、保持名称更新、集中决策、抽象、对类进行组织
实践9：重构遗留代码
图钉测试是非常粗粒度的测试，它测试的可能是成百长千行代码的单一行为。虽然最终期望的是许多更细粒度的测试，但是，通过图钉测试来覆盖整体行为会让我们有一个落脚点。，每次修改后，都可以回到图钉测试来验证最终点对点的行为是否依然正确。
以支持修改为目的重构
以开闭原则为目的重构
开闭原则：对扩展开放而对修改关闭
以提高可修改性为目的重构

来源：叶磊????