交付用户想要的软件---高效程序员的45个习惯读书笔记

该博客已经停止更新,新博客点击此处:DevWiki的博客

交付用户想要的软件

让用户做决定

在设计方面,做决定的时候必须有开发者参与.

在一个项目中,开发者不应该做所有的决定,特别是业务方面的决定.

决定什么不该决定.
让客户做决定.开发者,经理或者业务分析师不应该做业务方面的决定.

业务应用需要开发者和业务负责人互相配合来开发.

平衡的艺术

记录客户做出的决定.
不要用过于具体和没有价值的问题打扰繁忙的业务人员.
不要假设具体的问题不会影响业务人员的业务.
如果业务负责人回答”我不知道”,这也是一个称心如意的答案.

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

设计是软件开发过程不可缺少的步骤.

开发之前画关键工作图是必不可少的,在做设计时你需要花时间去考虑各种不同选择的缺陷和溢出,以及如何权衡.然后下一步才考虑开始编码.

严格的需求-设计-代码-测试开发流程源于理想化的瀑布式开发方法,它导致在前面进行了过度的设计.

设计可以分为两层:战略和战术.
1. 前期的设计属于战略,通常只有在么有深入理解需求的时候需要这样设计.
2. 战术设计重点是集中在单个的方法或数据类型上.这时更合适讨论如何设计类的职责.

CRC(类-职责-协作)卡片的设计方法就是用来做这个事情的.
* 类名
* 职责:它应该做什么?
* 协作者:要完成工作它需要与其他的什么对象一起工作?

什么是好的设计?

如果需求有了小变化,它仍能容易去实现,那么它就是好的设计.

好的设计应该是正确的而不是精确的.

平衡的艺术

• 不要在前期做大量的设计,并不是说不要设计.
• 计时初始的设计到后期不在管用,你仍需设计.
• 白板,草图,便利贴都是非常好的设计工具.

合理地使用技术

根据需要选择技术.

在考虑使用新技术之前,先要把你需要解决的问题找出来.找到了需要解决的问题,接下来就要考虑:
1. 这个技术框架真能解决这个问题吗?
2. 你将会被他拴住吗?
3. 维护成本是多少?

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

写的代码越少,需要维护的东西就越少!

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

平衡的艺术

1. 也许在项目中真正评估技术方案还为时太早.
2. 每一门技术都会有有点和缺点.

保持可以发布

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

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

在团队工作中,修改一些东西的时候必须很谨慎.

如何防止你提交的代码破坏系统的代码?
1. 在本地测试运行.
2. 检出最新的代码
3. 提交代码

保持你的项目时刻可以发布.保证你的系统随时可以编译,运行,测试并立即部署.

平衡的艺术
1. 有时候,做一些大的改动后,你无法花费太多的时间和精力去保证系统一直可以发布.但是这只是例外,不能养成习惯.
2. 如果你不得不让系统长期不可发布,那就做一个分支版本,你可以继续进行自己的试验.如果不行,还可以撤销,从头再来.
3. 千万不能让系统既不可以发布,有不可以插销.

提早集成,频繁集成

在产品的开发过程中,集成是一个主要的风险区域.

独立开发和早期集成之间是具有张力的.

当你独立开发时,会发现开发速度更快,生产效率更高,你可以有效地解决出现的问题.
但并不意味着你避免或者延迟集成.一般需要每天集成几次,最好不要2~3天集成一次.

绝不要做大爆发式的集成.

平衡的艺术
1. 成功的集成就意味着所有的单元测试不停地通过.
2. 每天要和团队其他成员一起集成好几次.
3. 如果你集成的不频繁,也许救会发现整天在解决代码集成带来的问题,而不是专心写代码.
4. 独立开发很好,但是不能独立开发太久,一旦你有了经验就要快速地开始集成.

提早实现自动化部署

如果现在你还是在手工帮助质量保证人员安装应用,花些时间,考虑如何将安装过程自动化.

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

在项目一开始就应该实现自动化部署.

平衡的艺术

1. 一般产品在安装的时候,都需要有相应的软硬件环境.这些环境的不同可能会导致很多问题,所以检查依赖关系,也是安装过程的一部分.
2. 在没有征得用户的统一之前,安装程序绝不能删除用户的数据.
3. 部署一个紧急修复的bug应该很简单,特别是在生产服务器的环境中.
4. 用户应该可以安全且完整地卸载安装程序.
5. 如果维护安装脚本变得很困难,那可能是一个早起警告.

使用演示获得频繁的反馈

需求就像流动的油墨.

你无法冻结需求,正如你无法冻结市场,竞争,知识,进化或者成长一样.

没有人的思想和观点可以及时冻结,特别是项目的客户.

不管是什么事情,我们都能做好,不过是以缓慢而逐步的方式.

软件开发的成功就在于最后你离客户的期望有多远.

应该定期的每隔一段时间,与客户进行演示反馈.

如果你能频繁地和用户协商,根据他们的反馈,每个人都可以从中收益.

不一致的术语是导致需求误解的一个主要原因.所以需要维护一个项目术语表.

项目开发应该是清晰可见的开发.

平衡的艺术

演示是用来让客户提出反馈,有助于驾驭项目的方向.

使用段迭代,增量发布

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

迭代开发是你在小且重复的周期里完成各种开发任务.

对付大项目,最理想的办法就是小步前进,这也是敏捷开发的核心.

大部分用户都是希望现在就有一个够用的软件,而不是在一年之后得到一个超级软件.

询问用户哪些是产品的可用且不可少的核心功能.
不要为所有可能需要华丽功能而分心,不要沉迷于你的想象,而去做那些华而不实的界面.
尽快发布你的应用,迟了也许它就没有作用了.
使用段迭代和增量开发,可以让开发者更加专注于自己的工作.

段迭代让人感觉非常专注且具效率

平衡的艺术

1. 如果每个迭代的时间都不够用,要么任务太大,要么因为迭代时间太短,把握好自己的开发节奏.
2. 如果发布的功能背离了用户的需求,多半是因为迭代的周期太长了.
3. 增量的发布必须是可用的,并且能为用户提供价值.

固定的价格就意味着背叛承诺

软件项目天生就是变化无常的,不可能重复.

开发项目时如何与客户交流?
1. 主动提议先构建系统最小,小的和有用的部分.
2. 第一个迭代结束时客户有两个选择:可以选择一系列新的功能,继承进入下一个迭代.或者可以取消合同.
3. 如果他们选择继续前进,那么这时候,应该就能很好地预测下一个迭代工作.

基于真实工作的评估.

平衡的艺术
1. 如果你对答案不满意,那么看看你是否可以改变问题.
2. 如果你在完成第一个迭代开发之前,拒绝做任何评估,也许你会失去这个合同.
3. 敏捷不是意味着开始编码,我们最终会知道合适可以完成.你需要根据当前的知识和猜想,做一个大致的评估.
4. 如果你别无选择,你不得不提供一个固定的价格,那么你需要学到真正好的评估.
5. 也许你会考虑在合同中确定每一个迭代的固定的价格,但迭代的数量是可以商量的,它可以根据当前的工作状况进行调整.