高效程序的45个习惯---第四章 交互用户想要的软件

为了让软件符合用户的需求，要一直做下面的准备工作。为了降低集成新代码带来的破坏性变化，你要提早集成，频繁集成。当然，你不想破坏已有的代码，想让代码一直保持可以发布。

 

10 让客户做决定

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

 

平衡的艺术

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

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

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

 

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

 

 

 

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

 

一些项目领导和经理认为设计应该尽可能地详细，这样就可以简单地交付给“代码工人们”。他们认为代码工人不需要做任何决定，只要简单地把设计转化成代码就可以了。就作者本人而言，没有一个愿意在这样的团队中做纯粹的打字员。我们猜想你也不愿意。

 

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

 

平衡的艺术

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

 

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

 

12 合理地使用技术

 

平衡的艺术

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

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

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

 

13 保持可以发布

 

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

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

 

14 提早集成，频繁集成

 

 

独立开发和早期集成之间是具有张力的.当你独立开发时,会发现开发速度更快,生产率更高.你可以更有效地解决出现的问题.但那并不是意味着要你避免或延迟集成(见本页侧边栏).你一般需要每天集成几次,最好不要2~3天才集成一次.

平衡的艺术

□ 成功的集成就意味着所以的单元测试不停地集成.正如医学院界西波克拉底的誓言:首先,不要造成伤害.

 

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

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

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

 

15提早实施自动化部署

16 使用演示获得频繁反馈

 

平衡的艺术

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

2 一些客户，也许会觉得没有时间应付每天、每周甚至一个月一次会议，那么就定一个月。

 

3 一些客户的联络人的全职工作就是参加演示会议。他们巴不得每隔1个小时就有一次演示和反馈。你会发现这么频繁的会议很难应付，而且还要开发代码让他们看。缩减次数，只有在你做完一些东西可以给他们演示的时候，大家才碰面。定性的时候，不应该拿来演示，那只能让人生气。可以及早说明期望的功能：让客户知道，他们看到的是一个正在开发中的应用，而不是一个最终已经完成的产品。

 

 

17使用迭代开发，保持发布

 

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

 

使用短迭代和增量开发，可以让开发者更加注于自己的工作。如果别人告诉你有一年的时间来完成系统，你会觉得时间很长。如果目标很遥远，就很难让自己去专注于它。在这个快节奏的社会，我们都希望更快地得到结果，希望更快地见到有形的东西。这不一定是坏事，相反，她会是一件好事，只要把它转化成生产率和正面的反馈。

 

18 固定的价格着承诺的背叛