读书笔记-->第四章 交付用户想要的软件 -->《高效程序员的45个习惯》

第四章

交付用户想要的软件

没有任何计划在遇敌后还能继续执行

---Helmuth von Moltke（德国陆军元帅）

真正的敌人是变化

敏捷--成功的软件开发方法--取决于你识别和适应变化的能力。只有这样才有可能在预算之内及时完成开发，创建真正符合用户需求的系统。

在设计方面，做决定的时候必须有开发者参与。可是，在一个项目中，他们不应该做所有的决定，特别是业务方面的决定。

开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让企业主做决定。

决定什么不该决定

Decide what you shouldn't decide

让你的客户做决定：开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定

切身感受

业务应用需要开发者和业务负责人互相配合来开发。这种配合的感觉就应该像一种良好的、诚实的工作关系

平衡的艺术

记录客户做出的决定，并注明原因。好记性不如烂笔头。可以使用工程师的工作日记或日志、Wiki、邮件记录或者问题跟踪数据库。但是也要注意，你选择的记录方法不能太笨重或者太繁琐

不要用低级别和没有价值的问题打扰繁忙的业务人员。如果问题对他们的业务没有影响，就应该是没有价值的

不要随意假设低级别的问题不会影响他们的业务。如果能影响他们的业务，就是有价值的问题

如果业务负责人回答“我不知道”，这也是一个称心如意的答案。也许是他们还没有想到那么远，也许是他们只有看到运行的实物才能评估出结果。尽你所能为他们提供建议，实现代码的时候也要考虑可能出现的变化

11、让设计指导而不是操作开发

设计满足实现即可，不必过于详细

Design should be only as detailed as needed to implement

严格的需求-设计-代码-测试开发流程源于理想化的瀑布式开发方法【瀑布式开发方法意味着要遵循一系列有序的开发步骤，前面是定义详细的需求，然后是详细的设计，接着是实现，再接着是集成，最后是测试】，它导致在前面进行了过度的设计，这样在项目的生命周期中，更新和维护这些详细的设计文档变成了主要工作，需要时间和资源方面的巨大投资，却只有很少的回报。

设计分为两层：战略和战术。前期的设计属于战略，通常只有在没有深入理解需求的时候需要这样的设计。更确切的说，它应该只描述总体战略，不应该深入到具体的细节

做到精确

如果你自己都不清楚所谈论的东西，就根本不可能精确地描述它

---约翰、冯、诺依曼

前面刚说过，战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的细节。那应该留到战术设计阶段，它应该在项目开发的时候再具体展开，良好的战略设计应该扮演地图的角色，指引你向正确的方向前进。任何设计仅是一个起跑点：它就像你的代码一样，在项目的生命周期中，会不停地进一步发展和提炼

不要一开始就进行战术设计，它的重点是集中在单个的方法或者数据类型上，这时，更适合讨论如何设计类的职责。因为这仍然是一个高层次、面向目标的设计。事实上，CRC（类-职责-协作）卡片的设计方法就是用来做这个事情的。每个类按照下面的术语描述

类名

职责：它应该做什么？

协作者：要完成工作它要与其他什么对象一起工作？

好的设计是一张地图，它也会进化。设计指引你向正确的方向前进，它不是殖民地，它不应该标识具体的路线。你不要被设计（或者设计师）操纵

切身感受

好的设计应该是正确的，而不是精确的。也就是说，他描述的一切必须是正确的，不应该设计不确定或者可能会发生变化的细节。它是目标，不是具体的处方

平衡的艺术

“不要在前期做大量的设计”并不是说不要设计。只是说在没有经过真正的代码验证之前，不要陷入太多的设计任务。当对设计一无所知的时候，投入编码也是一件危险的事。如果摄入编码只是为了学习或创造原型，只要你随后能把这些代码扔掉，那也是一个不错的办法

即使初始的设计到后面不再管用，你扔需要设计：设计行为是无价的。正如美国总统艾森豪威尔所说：“计划是没有价值的，但计划的过程是必不可少的”。在设计过程中学习是有价值的，但设计本身也许没有太大的用处

白板、草图、便利贴都是非常好的工作。复杂的建模工具只会让你分散精力，而不是启发你的工作。

12 合理地使用技术

盲目地为项目选择技术框架，就好比是为了少交税而生孩子

Blindly picking a framework is like having kids to save texes

在考虑引入新技术或框架之前，先要把你需要解决的问题找出来

这个技术框架真能解决这个问题吗？

你将会被它拴住吗？

维护成本是多少？

如果你发现自己在做一些花哨的东西（比如从头创建自己的框架），那就醒醒吧，闻闻烟味有多大，马上该起火了。你的代码写得越少，需要维护的东西就越少

不要开发你能下载到的东西

Don't build what you can download

对象关系的映射就是计算机可续的越南战场。你可以把更多的时间和精力投入到应用的开发--领域或具体应用中

根据需要选择技术。首先决定什么是你需要的，接着为这些具体的问题评估使用技术。对任何要使用的技术，多问一些挑剔的问题，并真实地做出回答

切身感受

新技术就应该像是新的工具，可以帮助你更好地工作，它自己不应该成为你的工作

平衡的艺术

也许在项目中真正评估技术方案还为时太早。那就好。如果你在做系统原型并演示给客户看，也许一个简单的散列表就可以代替数据库了。如果你还没有足够的经验，不要急于决定用什么技术

每一门技术都会有优点和缺点，无论它是开源的还是商业产品、框架、工具或者语言，一定要清楚它的利弊

不要开发那些你容易下载到的东西。虽然有时需要从最基础开发所有你需要的东西，但那是相当危险和昂贵的。

13、保持可以发布

任何时候只要你没有准备好，那就是敌人进攻你的最佳时机

已提交的代码应该随时可以行动

checked-in code is always ready for action

下面是一个简单的工作流程，可以防止你提交破坏系统的代码

在本地运行测试

检出最新的代码

提交代码

读书笔记-->第四章 交付用户想要的软件 -->《高效程序员的45个习惯》

平衡的艺术

有的时候，做一些大的改动后，你无法花费太多的时间和精力去保证系统一直可以发布。如果总共需要一个月的时间才能保证它一周内可以发布，那就算了。但这只应该是列外，不能养成习惯

如果你不得不让系统长期不可以发布，那就做一个（代码和架构的）分支版本，你可以继续进行自己的实验，如果不行，还可以撤销，从头再来。千万不能让系统既不可以发布，又不可以撤销。

14、提早集成，频繁集成

敏捷的一个主要特点就是持续开发

尽可能早地集成也更容易发现风险，这样风险及相关的代价就会相当低

绝不要大爆炸式的集成

Never accept big-bang integration

提早集成，频繁集成

代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成

平衡的艺术

成功的集成就意味着所有的单元测试不停地通过，正如医学界希波克拉底的誓言：首先，不要造成伤害

通常，每天要和团队其他成员一起集成代码好几次，比如平均每天5~10次，甚至更多。但如果你每次修改一行代码就集成一次，那效用肯定会缩水。如果你发现自己的大部分时间都在集成，而不是写代码，那你一定是集成的过于频繁了

如果你集成的不够频繁（比如，你一天集成一次，一周一次，甚至更糟），也许就会发现整天在解决代码集成带来的问题，而不是专心写代码。如果你集成的问题很大，那一定是做的不够频繁

对那些原型和实验代码，也许你想要独立开发，而不要想在集成商浪费时间。但是不能独立开发太长时间。一旦你有了经验，就要快速地开始集成。

15、提早实现自动化部署

质量保证人员应该测试部署过程

QA should test development

从第一天起就开始交付

即使项目还没有正式开始，我们就有了单元测试、持续集成和基于窗口的安装程序

一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同机器上用不同的配置文件测试依赖的问题。质量保证人员要像测试应用一样测试部署。

平衡的艺术

一般产品在安装的时候，都需要有相同的软、硬件环境，所以检查这些依赖关系，也是安装过程的一部分。

在没有询问并征得用户的同意之前，安装程序绝对不能删除用户的数据。

部署一个紧急修复的bug应该很简单，特别是在生产服务器的环境中。你知道这会发生，而且你不想在压力之下，在凌晨3点半，你还在手工部署系统

用户应该可以安全并且完整地卸载安装程序，特别是在质量保证人员的机器环境中。

如果维护安装脚本便得很困难，那很可能是一个早期警告，预示着--很高的维护成本（或者不好的设计决策）。

如果你打算把持续部署系统和产品CD或者DVD刻录机连接到一起，你就可以自动地为每个构件制作出一个完整且有标签的光盘。任何人想要最新的构件，只要从架子上拿最上面的一张光盘安装即可。

16、使用演示获得频繁反馈

需求就像是流动着的油墨

Requirements are as fluid as ink

Edward V.Berard曾经指出：“如果需求能被冻结，那么开发软件就如再冻冰上走路一样简单”。

软件开发的成功就在于最后你离客户的期望有多近。你计算的每个精确位置，就是一个给客户演示目前已经完成功能的机会，也正是得到用户反馈的时候。

如果你能与客户频繁协商，根据他们的反馈开发，每个人都可以从中受益。

如果你的迭代周期是一个季节或者一年（那就太长了），就应把周期缩短到一周或者两周。

维护项目术语表

不一致的术语是导致需求误解的一个主要原因。企业喜欢用看似普遍浅显的词语来表达非常具体、深刻的意义。

在项目的开发过程中，从术语表中为程序结构---类、方法、模型、变量等选择合适的名字，并且要检查和确保这些定义一直符合用户的期望。

清晰可见的开发，在开发的时候，要保持应用可见（而且客户心中也要了解）。每隔一周或者两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。

切身感受

当你第一次视图用这种方法和客户一起工作的时候，也许他们被这么多的发布吓到了。所以，要让他们知道，这些都是内部的发布（演示），是为了他们自己的利益，不需要发布给全部的最终用户。

尊重客户的时间。如果客户只可以接受一个月一次会议，那么就定一个月

缩短次数，只有在你做完一些东西可以给他们演示的时候，大家才碰面

演示是用来让客户提出反馈的，有助于驾驭项目的方向。如果缺少功能或者稳定性的时候，不应该拿来演示，那只能让人生气。可以及早说明期望的功能：让客户知道，他们看到的是一个正在开发中的应用，而不是一个最终已经完成的产品。

17、使用短迭代，增量发布

统一过程和敏捷方法都使用迭代和增量开发

迭代开发时，在小且重复的周期里，你完成各种开发任务：分析、设计、实现、测试和获得反馈，所以叫做迭代。

迭代的结束就是一个里程碑。

Capers Jones格言：“..大型系统的开发就是一件非常危险的事情。” 大型系统更容易失败。它们通常不遵守迭代和增量开发的计划，或者迭代时间太长。

Larman指出，软件开发不是精细的制造业，而是创新活动，规划几年之后客户才能真正使用的项目注定是行不通的。

对付大项目，最理想的办法就是小步前进，这也是闽籍方法的核心。大步跳跃大大地增加了风险，小步前进才可以帮助你很好地把握平衡。

构建复杂的系统需要花费时间，你无法用增量的方式开发一个大型的系统。

使用短迭代和增量开发，可以让开发者更加专注于自己的工作。

根据项目的大小，理想的发布周期是几周到几个月。在每个增量开发周期里，应该使用短的迭代（不应该超过两周）

增量开发。发布带有最小却可用功能块的产品。每个增量开发中，使用1~4周左右迭代周期。

切身感受

短迭代让人感觉非常专注且具效率。你能看到一个实际并且确切的目标。严格的最终期限迫使你做出一些很难的决策，没有遗留下长期悬而未决的问题。

平衡的艺术

在每4周的迭代中间安排一周的维护任务。没有规定说迭代必须要紧挨着下一个迭代。

如果每个迭代的时间都不够用，要么是任务太大，要么是迭代的时间太短。把我好自己的节奏

如果发布的功能背离了用户的需求，那么多半是因为迭代的周期太长了。

增量的发布必须是可用的，并且能为用户提供价值。