第1章 敏捷——高效软件开发之道

定义

一般误认为敏捷就是快，越快就是越敏捷——字典上的名词解释是其依据。岂不知它本来要以“lightweight processes”（轻量级过程）命名，只不过有些参会者不喜欢被看做是在拳台上跳来跳去的轻量级拳手，所以才用了“敏捷”这个词。还有其他一些误解是，敏捷就是只写代码不写文档；敏捷需要重构而无需设计；敏捷迭代就是尽量做到最小，以至于一个小时就好几次。

敏捷开发宣言

一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法”。“敏捷方法可以快速地响应变化，它强调团队合作，人们专注于具体可行的目标（实现真正可以工作的软件），这就是敏捷的精神。”

本质

我们进行的是持续开发、持续反馈。越早发现问题，就越容易修复问题，所以应该就在此时此刻把问题修复。

原因

为什么要进行持续开发呢？因为软件开发是一项非常复杂的智力活动，你遗留下来的任何问题，要么侥幸不会发生意外，要么情况会变得更糟糕，慢慢恶化直到变得不可控制。当问题累积到一定程度的时候，事情就更难解决，最后无法扭转。面对这样的问题，唯一有效的解决办法就是持续地推进系统前进和完善。

工作方式

敏捷团队往往是一个小型团队，或者是大团队分成的若干小团队（10人左右）。团队的所有成员在一起工作，如果可能，最好有独立的工作空间，一起共享代码和必要的开发任务，而且大部分时间都能在一起工作。同时和客户或者软件的用户紧密工作在一起，并且尽可能早且频繁地给他们演示最新的系统。使用自动化工具不断地构建（持续集成）、测试系统并且重构代码。

第2章 态度决定一切

作为团队一员应有的处理事情的态度，要积极的，所做的是为了项目更好的发展

1、做事

遇到问题是要先解决问题，同事之间要帮助解决，不是寻找问题的根源

“勇于承认自己不知道答案，这会让人感觉放心。一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起工作，应互相帮助，而不是互相指责。”

2、欲速则不达

有些代码是可以很快被修复，但是并不去深究底层原因，就会埋下隐患，最终爆发的时候就会花费更多的时间

“只要我们继续进行快速修复，代码的清晰度就不断降低。一旦问题累积到一定程度，清晰的代码就不复存在，只剩一片混浊。”

“千里之堤，溃于蚁穴，大灾难是逐步演化来的。一次又一次的快速修复，每一次都不探究问题的根源，久而久之就形成了一个危险的沼泽地，最终会吞噬整个项目的生命。”

3、对事不对人

当有问题分歧时只是表达自己的观点，礼貌待人。团队讨论不能达成一致时，可以设定最终期限、设立仲裁人、支持已经做出的决定等继续执行

“没有最好的答案，只有更合适的方案。设定期限能够帮你在为难的时候果断做出决策，让工作可以继续进行。”

4、排除万难、奋勇前进

发现问题，有勇气向其他成员、老板提出

“做正确的事。要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。”

第3张 学无止境

软件开发行业是一个不停发展和永远变化的领域，这就要求个人和团队不断学习

5、跟踪变化

就是不断学习新的知识，因为软件技术在不断更新

“你能嗅到将要流行的新技术，知道它们已经发布或投入使用。如果必须要把工作切换到一种新的技术领域，你能做到。”

6、对团队投资

要有良好的团队学习、沟通氛围，聚餐、读书会等

“在一个团队中，如果只是你个人技术很好还远远不够。如果其他团队成员的知识不够，团队也无法发挥其应有的作用：一个学习型的团队才是较好的团队。”

7、懂得舍弃

舍弃旧的技术，包括技术的思维习惯的舍弃

“打破旧习惯很难，更难的是自己还没有意识到这个问题。”

8、打破砂锅问到底

多问问为什么，才能发现一些潜在的问题，才能了解更加深入

“在理解一个问题的时候，需要渐次地问5个以上的“为什么”。”

9、把握开发节奏

工作的安排有计划，有规律性，不要变更需求，迭代版本时间尽可能有周期性

“项目开发需要有一致和稳定的节奏。编辑，运行测试，代码复审，一致的迭代，然后发布。如果知道什么时候开始下一个节拍，跳舞就会更加容易。”

第4章 交付用户想要的软件

敏捷开发中以用户的需求为主导，频繁、有规律的更新、给用户展示，不断修正前进的方向

10、让客户做决定

不要试图自己去决定，由于想法的差异性，最后很大概率会重做，当客户也没有想好时，要给出自己的建议

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

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

画UML图，思考不同选择的缺点和益处，然后开始编码。注意，设计也只是当前的，在编码过程中也可能改变

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

12、合理地使用技术

先找问题，再根据问题找合适的技术，不要为了用这项技术而用，需要考虑技术的可行性、可变更性、维护成本

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

13、保持可以发布

保持主版本随时可以发布，新大量变更的需求可以新建分支。工作流程：在本地运行测试、检出最新的代码、提交代码

“最好的办法是，你有一个持续集成系统，可以自动集成并报告集成结果。”

14、提早集成、频繁集成

每天集成几次代码，而不是统一集成，会减少集成可能会带来的问题。

“如果你真正做对了，集成就不再会是一个繁重的任务。它只是编写代码周期中的一部分。集成时产生的问题，都会是小问题并且容易解决。”

15、提早实现自动化部署

系统应该在开发前几天就有部署环境，而不是等到上线之前，可以规避很多问题。重复的部署会浪费很多时间，这时候就应该考虑用到自动化部署工具。

“这些工作都应该是无形的。系统的安装或者部署应该简单、可靠及可重复。一切都很自然。”

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

1-2周向客户演示项目，让客户提出反馈意见，有助于帮助项目以后的方向。

“软件开发的成功就在于最后你离客户的期望有多近。你计算的每个精确位置，就是一个给客户演示目前已经完成功能的机会，也正是得到用户反馈的时候。在你动身进入下一段旅程的时候，这些反馈可以用来纠正你的方向。”

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

缩短发布周期，如果是大的系统，把它拆分成很多有用的小系统。短迭代让人感觉专注切有效率。

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

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

软件开发中随时有着需求的变更，还有一些小问题的出现，这些都是难以估计，所以更要把项目功能拆分。

“你的评估数据会在整个项目中发生变化——它们不是固定的。但是，你会觉得自信心在不断增加，你会越来越清楚每个迭代可以完成的工作。随着时间的推移，你的评估能力会不断地提高。”

第5章 敏捷反馈

测试的重要性

19、守护天使

单元测试很重要，最好做到自动化，建议书籍《单元测试之道》

“把单元测试的结果看作是和编译器一样——如果测试没有通过（或者没有测试），那就像编译没有通过一样糟糕。”

20、先用它再实现它

让自己站在用户的角度，先自己去使用产品（接口），才能更好的设计

“TDD（Test Driven Development，测试驱动开发）有机会让你编写代码之前（或者至少在深入到实现之前），可以深思熟虑将如何用它。这会迫使你去思考它的可用性和便利性，并让你的设计更加注重实效”。

21、不同环境，就有不同问题

要测试不同版本不同系统，自动化测试。很多公司会在硬件方面节省，可是这将会花费软件开发人员大量时间，实际成本更高。

“构建机器的硬件成本相当于开发人员的几个小时而已。”

22、自动验收测试

自动测试能验证各种异常和正常数据，保证健壮性，节省时间

“FIT，即集成测试框架，它很实用，可以更容易地使用HTML表格定义测试用例，并比较测试结果数据。”

23、度量真实进度

当在一个任务中，不要用工作完成了百分比，而是用工作剩余多少工时完成，当意识到工时变长时，要即时真实反馈，下次预估时间应该乘以上次用时的系数。

“你的评估会波动一段时间，有时候过低估计，有时候过高估计。但随着时间的推移，你的评估会与事实接近，你也会对任务所花费的时间有更清楚的认识。”

“一周工作40个小时，不是说你就有40个小时的编码时间。你需要减去会议、电话、电子邮件以及其他相关活动的时间。”

24、倾听用户的声音

产品应该简单、易用，用户使用错误时应给与合理、友好的提示

“没有愚蠢的用户，只有愚蠢、自大的开发人员。”

“不管它是否是产品的bug，还是文档的bug，或者是对用户社区理解的bug，它都是团队的问题，而不是用户的问题。”

“开发人员在完成任务时，可能会难以抵挡诱惑为节省时间而走“捷径”。然而，这些“捷径”往往只会推迟问题的爆发时“间，而不是把它彻底解决掉。当项目时间上的压力增加时，问题最终还是会在项目团队面前出现，让大家心烦意乱。”

第6章 敏捷编码

敏捷开发中编码的一些要点、习惯

25、代码要清晰地表达意图

• 1 代码要注重可读性，清晰度的优先级排在执行效率之前
• 2 多用枚举，少用位移运算符
• 3 代码规范让代码易于理解，减少不必要的注释和文档

“应该让自己或团队的其他任何人，可以读懂自己一年前写的代码，而且只读一遍就知道它的运行机制。”

26、用代码沟通

• 1 方法命名很重要
• 2 避免使用神秘的变量名
• 3 必费尽心机去用繁复冗长的名字替换大家已习惯的名称
• 4 注释要简洁，说明目的和功能

“源代码可以被读懂，不是因为其中的注释，而应该是由于它本身优雅而清晰——变量名运用正确、空格使用得当、逻辑分离清晰，以及表达式非常简洁。”

27、动态评估取舍

不要过分追求一项到极致，例如性能和UI，可以花费一些时间在其他薄弱可以快速提升的方面

“即使不能面面俱到，你也应该觉得已经得到了最重要的东西——客户认为有价值的特性。”

28、增量式编程

增量式注意拆分功能和测试，注重循序渐进，提高了可维护性

“采取增量式编程和测试，会倾向于创建更小的方法和更具内聚性的类。你不是在埋头盲目地一次性编写一大堆代码。相反，你会经常评估代码质量，并不时地进行许多小调整，而不是一次修改许多东西。”

29、保持简单

不要刻意用设计模式，按需使用

“评价设计质量的最佳方式之一，就是听从直觉。直觉不是魔术，它是经验和技能的厚积薄发之产物。”

30、编写内聚的代码

要编写高内聚的代码，一个类中只做单一的功能，但是也不能拆分过细

“让类的功能尽量集中，让组件尽量小。要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。”

31、告知、不要询问

命令与查询模式分离，当查询时，不要去获取类内部的状态等

“作为某段代码的调用者，开发人员绝对不应该基于被调用对象的状态来做出任何决策，更不能去改变该对象的状态。这样的逻辑应该是被调用对象的责任，而不是你的。在该对象之外替它做决策，就违反了它的封装原则，而且为bug提供了滋生的土壤。”

32、根据契约进行替换

继承与委托区别：新类可以替换已有的类，is-a关系，用继承，新类只是使用已有的类，has-a、use-a关系，用委托

“Liskov替换原则告诉我们：任何继承后得到的派生类对象，必须可以替换任何被使用的基类对象，而且使用者不必知道任何差异。换句话说，某段代码如果使用了基类中的方法，就必须能够使用派生类的对象，并且自己不必进行任何修改。”

第7章 敏捷调试

开发过程中调试的一些注意点，异常的处理

33、记录问题解决日志

要记录问题的发生和解决方案，可以迅速解决新发生的重复问题

“要共享日志给其他人，而不仅仅是靠一个人维护。把它放到共享的网络驱动器中，这样其他人也可以使用。或者创建一个Wiki，并鼓励其他开发人员使用和更新其内容。”

34、警告就是错误

提交代码时不能有警告错误，警告会带来未知的风险，也会增加测试的工作量

“要找到一种方式让编译器将警告作为错误提示出来。如果编译器允许调整警告的报告级别，那就把级别调到最高，让任何警告不能被忽略。”

35、对问题逐个击破

书写代码是逻辑要清晰，使各个模块容易被抽离，当有问题时，就要逐步的对模块进行测试，比整体测试更容易找到问题的点

“识别复杂问题的第一步，是将它们分离出来。”

36、报告所有的异常

异常不能被忽略，忽略有可能当前页没有问题，但这容易导致其他的关联问题

“当出现问题时，心里知道能够得到抛出的异常。而且没有空的异常处理方法。”

37、提供有用的错误信息

开发人员要假定自己是新用户进行使用，报错信息尽可能详细，方便用户也方便自己排查问题

“错误信息有助于问题的解决。当问题发生时，可以详细研究问题的细节描述和发生上下文。”

第8章 敏捷协作

敏捷开发其他的一些事项，包括团队的会议、交流、指导，代码的复查，问题的抛出

38、定期安排会面时间

公司的立会，站立会使会议时间缩短，要保证议题不会发散，立会每人只回答以下3个问题：

• 1 昨天有什么收获
• 2 今天计划要做哪些工作
• 3 面临着哪些障碍

“使用立会。立会可以让团队达成共识。保证会议短小精焊不跑题。”

39、架构师必须写代码

架构师应该参与代码的部分实现，项目的主力开发人员也应该参与项目的设计

“作为设计人员，如果不能理解系统的具体细节，就不可能做出有效的设计。只通过一些高度概括的、粗略的设计图无法很好地理解系统。” “优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况，是无法展开设计的。”

40、实行代码集体所有制

对于多人开发，应该使所有人了解整个项目的代码，这样就能减少风险，代码被频繁的检查、重构和维护。同时写代码的人和改代码的人也会更注意、小心，降低错误几率。

“在团队中实行任务轮换制，让每个成员都可以接触到不同部分的代码，可以提升团队整体的知识和专业技能。”

41、成为指导者

要与团队成员分享知识，既能提升自己，也能提升团队

“教学相长:好的想法不会因为被许多人了解而削弱。当我听到你的主意时，我得到了知识，你的主意也还是很棒。同样的道理，如果你用你的蜡烛点燃了我的，我在得到光明的同时，也没有让你的周围变暗。好主意就像火，可以引领这个世界，同时不削弱自己。”

42、允许大家自己想办法

给同事帮助时先提供一些指引，帮助别人提高解决问题的能力

“授人以鱼，三餐之需；授人以渔，终生之用。”

43、准备好后再共享代码

开发中的代码提交的话要保证提交代码是可以正常运行、兼容，并不会影响其他开发者

“要保证在提交代码之前，所有的单元测试都是可以通过的。使用持续集成是保证源代码控制系统中代码没有问题的一种良好方式。”

44、做代码复查

写完代码让其他人员进行复查，能提高代码质量

“代码复查随着开发活动持续进行，而且每次针对的代码量相对较少。感觉复查活动就像是项目正在进行的一部分，而不是一种令人畏惧的事情”

45、及时通报进展与问题

当项目进行进展不顺，会拖延进度的时候，积极通知其他各方，来寻找解决问题的方案，也不会让别人感到突然

“及时通报进展与问题。发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。”

第9章 尾声：走向敏捷

好的习惯很重要

“只要一个新的习惯，就让团队发生了巨大的变化。”

个人总结

读完全书，对敏捷开发有了一个全新的认识，这本书并不是干货书籍，没有讲到具体的知识点，只是分类别的讲了敏捷开发的注意点，全书也是通俗易懂，也会举很多现实中的例子说明，并没有什么专业性，所以对于各个级别的开发人员都是适合去阅读的。特别是对于一些刚开始工作的软件开发人员，本书是着重讲了工作中的惯问题，并不仅仅是代码风格、编码习惯，而是工作中处理各种工作事物的习惯，或者说是工作流的习惯，这对于刚工作的软件开发人员帮助很大。有了好的习惯，编码效率、技术才能更快的提升。当然对于其他未养成良好习惯的开发人员，阅读也是很有必要的。

虽然本书说是敏捷开发修炼之道，但是其中很多的章节应该都是各类程序员，甚至是工作人员通用的，比如说前面的工作态度、学无止境、遇到问题的反馈等等。前面把每一个章节、小结都用我自己认为简练的一句话概括，方便自己以后回顾，每小节也引用了书中个人任务比较好的一段工作习惯的问题，每过一段时间回过头扫一眼，不用花费很多时间，也是对于工作有帮助的。

书中的敏捷开发的定义，并不是我个人以前所认知的敏捷，可能有很多人和我以前一样，只是从字面去理解含义，其实这个敏捷是追求中大型项目、长期稳定的团队的最终开发效率的敏捷，这些对于一些小项目，或者是只做一期尝试的项目用处不大，但是也有一些可以借鉴的地方，比如说反馈交流、短迭代、问题的抛出等等。敏捷开发是为了避免一些大项目出现大的偏差而浪费了大量的人力、财力而出现的，把项目分功能、模块化、短迭代、自动化进行布局，可以时时更改、修正，向着正确的需求前进，而不是等全部功能做完了才发现是南辕北辙。

这其中指出的很多习惯，对于我们日常的工作确实也是很有帮助的，可以提升自己的工作效率、更好的提升技术。里面提到的很多点，现在所在的公司也有很多执行的地方，觉得效果还不错，大家也可以尝试着去执行，当然，这并不是要所有的都去执行，毕竟每个人和公司所处的情况不一样，这个还是要按照自己的需求，习惯是适合自己的才是最好的，当然别人的优秀习惯也要去借鉴。