跳转至

1. 敏捷-高效软件开发之道

个体和交互胜过过程和工具 可工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循计划 虽然右项也有价值,但我们认为左项具有更大的价值。 敏捷宣言作者,2001年版权所有。

敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善。

2. 态度决定一切

  • 1.做事:指责不会修复 bug
  • 2.欲速则不达:拙劣的代码工人会这样不假思索地改完代码,然后快速转向下一个问题。不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。
  • 3.对事不对人:引导性地提出一个疑问,让他们自己意识到问题。你不需要很出色才能起步,但是你必须起步才能变得很出色。
    • 设定最后期限;设立仲裁人;支持已经做出的决定
  • 4.排除万难,奋勇前进:

3. 学无止境

  • 5.跟踪变化
  • 6.对团队投资:一个学习型的团队才是好的团队
  • 7.懂得丢弃:学习新东西,抛弃旧的东西
  • 8.打破沙锅问到底:多问为什么
  • 9.把握开发节奏:许多的敏捷技巧来源于时间盒——设定一个短时的期限,为任务设定不能延长的最终期限。

4.交付用户想要的软件

  • 10.让客户做决定:开发者(及项目经理)能做的一个最重要的决定就是:判断哪些是自己决定不了的,应该让企业主做决定
  • 11.让设计指导而不是操纵开发。设计满足需求即可。CRC(类—职责—协作)卡片:类名;职责(它应该做什么);协作者(要完成工作与其他什么对象一起工作)
  • 12:根据需要选择技术
  • 13.保持可以发布:已提交的代码应该随时可以行动
  • 14.提早集成,频繁集成
  • 15.提早实现自动化部署
  • 16.使用演示获得频繁反馈
  • 17.使用短迭代,增量发布
  • 18.固定的价格就意味着背叛承诺

5.敏捷反馈

  • 19.守护天使:编写能产生反馈的代码:测试是可重复的;测试边界条件;不要放过失败的测试用例
  • 20.先用它再实现它:TDD
  • 21.不同环境就有不同问题
  • 22.自动验收测试
  • 23.度量真实的进度:待办
  • 24.倾听用户声音

6.敏捷编码

  • 25.代码要清晰地表达意图。清晰度应该排在效率之前
  • 26.用代码沟通
  • 27.动态评估取舍
  • 28.增量式编程
  • 29.保持简单。开发可以工作的、最简单的解决方案
  • 30.编写内聚的代码:内聚性用来评估一个组件(包、模块或配件)中成员的功能相关性。内聚程度高,表明各个成员共同完成了一个功能特性或是一组功能特性。内聚程度低的话,表明各个成员提供的功能是互不相干的。
  • 31.告知,不要询问:面向过程的代码取得信息,然后做出决策。面向对象的代码让别的对象去做事情。命令与查询相分离模式
  • 32.根据契约进行替换: is-a has-a

7.敏捷调试

  • 33 记录问题解决日志
  • 34 警告就是错误
  • 35 对问题各个击破
  • 36 报告所有的异常:处理或是向上传播所有的异常
  • 37 提供有用的错误信息

8.敏捷写作

  • 38 定期安排会面时间:站立会议
  • 39 架构师必须写代码
  • 40 实行代码集体所有制
  • 41 成为指导者
  • 42 允许大家自己想办法
  • 43 准备好后再共享代码
  • 44 做代码复查
  • 45 及时通报进展与问题。发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。

9.尾声:走向敏捷

  • 9.1 只要一个新的习惯
  • 9.2 拯救濒临失败的项目
  • 9.3 引入敏捷:管理者指南:从立会开始(见第148页习惯38)。这可以让团队有机会进行彼此讨论,并对一些重大问题达成共识。把之前相对孤立的架构师带到团队中,并让他们参与到日常开发工作(见第152页习惯39)。开展非正式的代码复查(见第165页习惯44),并做出计划,让客户与用户也参与到项目中来(见第45页习惯10)。
  • 9.4 引入敏捷:程序员指南举例来说,从单元测试开始是一个不错的选择。可以先针对自己的代码开始使用。在短时间之内(几周甚至更少),就可以看到代码质量提升了——减少了错误的数目,提高了质量,健壮性也有所提升。你下午5点就可以下班回家,而且所有的任务都可以顺利完成——不必担心半夜被电话叫醒,去修复bug。旁边的开发人员想知道你是如何做到的,而且消息也渐渐传开了。整个团队现在都想尝试这些新奇的习惯,而不需要你努力去说服他们。