高效程序员的45个习惯笔记 第一章

第一章

不管路多远，错了就要重新返回。

• 个体和交互胜过过程和工具
• 可工作的软件胜过面面俱到的文档
• 客户协助胜过合同谈判
• 响应变化胜过遵循计划

敏捷开发的宣言：一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。

敏捷方法可以快速的响应变化，它强调团队合作，人们专注于具体可行的目标（实现真正可以工作的软件），这就是敏捷的精神。它打破那种基于计划的瀑布式软件开发方法，将软件开发的重点转移到一种更加自然的可持续开发的方式上。

它要求团队中的每个人都具备职业精神，并积极的期待项目能够成功。他并不是所有人都是有经验的专业人员，但必须具有专业的工作态度——每个人最大可能的做好自己的工作。

这意味着你不会再项目结束的时候才开始测试，不会再月底才进行一次系统集成，也不会在一开始编码的时候就停止收集需求和反馈。

开发要持续不断，切勿时续时断
Continuous development , not episodic

相反，这些活动会贯穿项目的整个生命周期。事实上，只要有人继续使用这个软件，开发就没有真正的结束。我们进行的是持续开发、持续反馈。你不需要等到几个月之后才发现问题：越早发现问题，就越容易修复问题，所以应该就在此时此刻把问题修复。

这就是敏捷的重点。

这种持续前进的开发思想根植于敏捷开发中。它不但对应用于软件开发的生命周期，还应用技术技能的学习、需求采集、产品部署、用户培训等方面。它包括了软件开发的各个方面的所有活动。

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

继续注入能量
Inject energy

防微杜渐，把问题解决在萌芽状态，你要探索未知领域，在大量成本他投入之前先确定其可行性。

敏捷的修炼之道

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

以下将扼要讲述它的具体含义，以及敏捷的团队应该采取什么样的工作和生活方式。

首先，他要整体团队一起努力。敏捷团队通常是一个小的团队，或是大团队分成诺干个小团队（10人左右）。团队的所有成员在一起工作，如果可能，最好有独立的工作空间（或者类似 bull pen),一起共享代码和必要的任务，而且大部分时间都能在一起工作。同时和客户或者软件的用户紧密工作在一起，并且尽可能早且频繁地给他们演示最新的系统。

你要不断从自己写的代码中得到反馈，并且使用自动化的工具不断的构建（持续集成）和测试系统。在前进过程中，你都会有意识的修改一些代码：在功能不变的情况下，重新设计部分代码，改善代码的质量。这就是所谓的重构，它是软件开发中不可或缺的一部分——编码永远没有真正意义上的“结束”。

要以迭代的方式进行工作：确定一小块时间（一周左右）的计划，然后按时完成它们。给客户演示每个迭代的工作成果，及时得到听他们的反馈（这样可以保证方向正确），并且根据实际情况尽可能频繁地发布系统版本让用户使用。

对上述内容有了了解后，我们会从下面几个方面更深入地走进敏捷开发的实践。

第2章：态度决定一切。软件开发是一项智力劳动。在此章，我们会讲解如何用敏捷的心态开始工作，以及一些有效的个人习惯。这会为你使用敏捷方法打下扎实的基础。

第3章：学无止境。敏捷项目不可能坐享其成。除了开发之外，我们还要在幕后进行其他的训练，虽然它不属于开发工作本身，但对团队的发展及其重要。我们将看到，如何通过培养习惯来帮助个人和团队成长并自我超越。

第4章：交付用户想要的软件。如果软件不符合用户的需求，无论代码写得多么的优美，她都是毫无用处的。这里将会介绍一些客户协作的习惯和技巧，让客户一直加入到团队的开发中，学习他们的业务经验，并且保证符合他们的真正需求。

第5章：敏捷反馈。敏姐团队之所以能够顺利开展工作，而不会陷入泥塘挣扎导致项目失败，就是因为一直使用反馈来纠正软件和开发过程。最好的反馈源自代码本身。本章将研究如何获得反馈，以及如何更好地控制团队进程和性能。

第6章：敏捷编程。为了满足将来的需求而保证代码的灵活和可变性，这是敏捷方法成功的关键。本章给出了一些习惯，介绍如何让代码更加的整洁，具有更好的扩展性，防止代码慢慢变坏，最后变得不可收拾。

第7章：敏捷调试。调试错误会占有很多项目开发的时间——时间是经不起浪费的。这里将学到一些调试效率的技巧，节省项目的开发时间。

第8章：敏捷协助。最后，一个敏捷开发者已经能够独当一面，除此之外，你需要一个敏捷的团队。这里有一些最有效的实践有助于粘合整个团队，以及其他一些实践有助于团队日常事务和成长。

敏捷工具箱

Wiki : Wiki是一个网站，用户通过浏览器，可以编辑网页内容并创建链接到到一个新的内容界面。Wiki是一个很好的支持协助的工具，因为团队中每一个人都可以根据需要动态的新增和重新组织网页中的内容，实现知识的共享。关于Wiki的更多详情，可查询《Wiki之道》

版本控制：项目开发中的产物——全部的源代码、文档、图标、构建脚本等，都需要放入版本控制系统中，由版本控制系统来统一管理。令人惊讶的是，很多团队仍然喜欢把这些文件放到一个网络上共享的设备上，但这是一种很不专业的做法。如果需要一个安装和使用版本控制系统的详细说明，可以查阅《版本控制之道——CVS》

单元测试：用代码来检查代码，这是开发者获取反馈的主要来源。在本书后面会更多的谈到它，但要真正知道框架可以处理大部分的繁琐工作，让你把精力放到业务代码中。想要了解单元测试，可以看《单元测试之道java版》

自动构建：不管是在自己的本地机器上实现构建，还是为了整个团队实现构建，都是全自动化并可重复的。因为这些构建一直运行，所以又称为持续集成。和单元测试一样，有大量的免费开源产品为你提供支持。《项目自动化之道》