《敏捷开发之道》读书笔记

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

72、你会觉得，不管什么时候，你的老板、董事长、质量保障人员、客户或者你的配偶来公司参观项目的时候，你都能很自信并毫不犹豫的给他们演示最新构建的软件。你的项目一直处于可以运行的状态。

73、如果你不得不让系统不可以发布，那就做一个分支版本，你可以继续进行自己的实验，如果不行，你还可以撤销，从头再来。千万 不能让系统即不可以发布，有不可以撤销。

74、敏捷开发的主要特点是持续开发，特别是在几个人一起开发同一个功能的时候，更应该频繁地集成代码。

75、在产品开发过程中，集成是一个主要的风险区域。让你的子系统不断的增长，不去做系统集成，就等于一步一步把自己置于越来越大的风险中，世界没有你仍可以运行，潜在的分支会继续增加。相反，尽可能早点集成也更好的发现风险，这样风险及相关的代价就会相当的低。而等的时间越长，你也就会越痛苦。

76、提早集成，频繁集成。代码集成是主要的风险来源。要想避免这个风险，只有提早集成，持续而有规律的集成。

77、从第一天起就开始交付：一开始就进行全面部署，而不是等到项目的后期，这会有很多的好处，事实上，有些项目在正式开始之前就设置好了安装环境。在我们的公司，要求大家为预期客户实现一个简单的功能演示---验证一个概念的可行性。即使项目还没有正式开始，我们就有了单元测试，持续集成和基于窗口的安装程序。这样，我们就可以更容易更简单的给用户交付这个演示系统：用户所要做的工作，就是从我们的网站上点击一个连接，然后就可以自己在各种不同的机器上安装演示这个系统了。在签约之前，就能提供出一个如此强大的演示，这无疑证明了我们非常的专业，具有强大的开发能力。

78、没有人的思想和观点可以被冻结，特别是项目的客户。就算他们已经告诉你了他想要的东西了，他们的期望和想法还是在不停的进化着。特别是他们在使用新系统的部分功能时才意识到它的影响和可能发生的问题。这就是人的本性。

79、如果你能于客户频繁的协商，根据他们的反馈开发，每一个人都能从中获获益。客户会了解你的工作进度，你会得到客户真正的需求。

80、项目启动以后你要进入一个舒适的状态，团段和客户建立一种健康的富有创造性的关系。

81、有些客户，也许不能应对每天、每周的会议。毕竟他们还有自己很多事情。我们要尊重客户的时间。如果客户接受一个月我们就定一个月。

82、演示是为了从客户那里得到反馈，有助于驾驭项目的方向。

83、询问客户，哪些是产品不可或缺的核心功能。不要为那些华丽的功能分心，不要沉迷于你的想象，去做那些华而不实的用户界面。

84、发布带有小却有可用功能的产品。每个增量开发中，使用1~4周迭代周期。如果发布的功能背离了用户的需求，那多半是因为迭代的周期太长了。

85、在敏捷项目中，我们小步前进，不停地收集反馈，时刻矫正自己。

86、《单元测试之道》

87、单元测试能及时提供反馈；单元测试让你的代码更健壮；单元测试是更有用的设计工具；单元测试是你更自信的后台；

单元测试是解决问题时的探测器；单元测试是可信的文档；单元测试是学习工具；

88、关键业务逻辑必须单独进行独立严格的测试，并且最后需要通过用户的审批。

89、编写优雅的代码：意味着代码包含良好的注释，见名知意。

90、引入有警告的代码，等于引入没有测试的代码或者引入错误的代码。

91、单元测试代码良好效应。

92、将问题各个击破这样做有很多好处。

93、将问题问题单元隔离出来，隔离问题。

94、用二分法查找定位问题，快速定位问题是解决问题的前提。

95、项目的成功与否在于团队的共同努力和团结协作。

96、高效协作是敏捷开发的基石。

97、面对面交流还是沟通的最好方式，希望每一个人投入到编码的过程中来。也就是说架构师必学写代码。希望实现代码所有制。

98、立会短小精悍，保证会议不跑题。有助于团结团队和发现问题提出问题，并让大家投入到一天的工作当中（立会要开始在工作的开始，不要占用非工作时间）。

99、计时器会议，提高会议效率。

100、真正的架构师如果被拒绝参与编码的话，他们会提出强烈的抗议的。

101、鼓励程序员参与设计，也就说主力程序员要担任架构师的角色。程序员放弃了设计就等于放弃了思考。优秀的设计从程序员那里开始。

102、在极限编程中是不存在一个人编程的，编程总是结对进行的，两双眼睛盯着看，就像在进行着持续的代码复查工作。

103、及时发布项目的进展情况，新的想法和所关注的问题，不要等到别人来询问。

104、书的内容结束了，下面该怎么做就看你自己的了。