敏捷开发的26条至理名言

敏捷开发愈来愈热，那么在实际应用时，应该如何去运用以及须要注意哪些东西呢？不妨来看看本文提供的26条至理名言吧！

一、完整地干完一件过后在开始另外一件事：用厨房比喻来讲就是：“先上这道菜，再开始作下一道”。软件开发的最大问题就是同时开始几件事情，这将不可避免的形成某些工做被废弃，从而形成浪费。专一于一件事；完整地实现其功能；运行测试；编写文档；签入全部，把这当作一项工做完成，而后再开始下一件事。

二、不要破坏构建：很是明显，但必须被包含在任何软件开发建议清单中。程序员在签入以前采起全部合适的预防措施进行测试，则永远不会破坏构建。若是构建被破坏，一般是由于有人偷懒了。

三、在用例须要以前，不要实现程序：当你实现一个特定的类，你应该在脑海中有一个特定的用例，同时应该只实现用例须要的方法。你能够考虑该类潜在的功能，写入注释之中，但直到用例真正须要时，才应去实现它。

四、在用例须要以前，不要添加数据成员：同上一条，不过这是从类的数据成员角度考虑的。彷佛显而易见地，“客户”记录须要“送货地址”，但直到有用例明确须要送货地址，才应该实现它。

五、不要惧怕作决定，不要惧怕改变先前的决定：敏捷开发是关于相应变化和快速相应的。开发初期，你没有完整的信息。你应该尽量的推迟决策，直到你必须作出决策的时候。没有信息，没法支持你的决定，相反，在有效信息的基础上作出最佳决定。有了新的信息，不要惧怕改变先前的决定。（某些“恐龙”称之为摇摆不定，但我称之为响应变化的环境）

六、持续学习如何改善质量：这项工做永不会结束，所以你应常常留意能够改善的事情，并收集质量问题被确认和处理的案例。

七、度量、度量、度量：敏捷开发帮助处理将来不肯定性问题，但对于过去应没有不肯定性。测试应持续运行，每次运行的性能表现应被度量和记录。

八、为人而设计，而不是系统：开发者经常因技术而使设计误入歧途。毫不要忘记设计的最终目标，那就是帮助人们完成工做。

九、测试是产品的一部分：不少开发者和经理认为产品就是交付给客户的东西，而其它全部东西都不那么重要。测试应被认为是产品实实在在的一个部分，值得在设计时仔细考虑，甚至，在不少状况下，和产品一块儿交付给客户。（后半部分有争议，可是内建测试做为软件交付的一部分仅仅占用可有可无的空间，却在必要时提供显而易见的好处，这种方式应该被考虑。）

十、在代码以前编写测试：测试自己能够用来阐释真正须要的设计。设计的缺陷经常是经过测试用例被发现的。想一想看，编码以前，经过这些用例，能够节约多少时间。可是，为用例1编写测试，而后编码，而后再开始用例2。

十一、消除浪费：坦率的说，这是另外一个必须包含在任何开发原则清单中的陈词滥调，由于它过重要了。发现浪费并消除它，这项工做没有尽头。消除任何不能增长客户价值的东西。若是你不能确认客户价值，那极可能你并不须要它。

十二、创建对构建破坏当即响应的文化：要明白当构建被破坏，会影响项目中的每个人，所以，最重要的是确认核心代码被构建并合理测试。我曾见过有些团队听任失败测试持续数月，由于那是其它人的工做。每一个人都痛苦，但没人采起行动。想反，必须造成共识，那就是小工做能为团队得到大的回报。

1三、全部团队成员应理解客户须要：大型的复杂项目定然被分解为独立的团队，进而被分派给开发人员。可是，不该在此范围内作的是，失去关注最终项目真正用户的指望和目标。

1四、把相关定义放在一块儿：组织代码以使高度相关的事情在一块儿，或在一个类中。这是标准面向对象设计封装原则。理想状况下，全部的类外的代码不须要知道内部工做细节。一些开发者乐于将细节扩散到多个文件中以便按不一样方式组织，如全部相同的数据类型放在一块儿，或者按字母顺序组织。例如，在他们要用的不一样包中，将全部常量放在一个类里，这增长了没必要要的程序复杂性。指导原则应该是按相关性分组从而隐藏复杂性。

1五、始终在签入以前运行测试：这条准则帮助你知足“不要破坏构建”准则。

1六、过早的优化是万恶之源：引用高德纳被证明的话：代码应编写良好以免微观层面的浪费，但独立方法层次之外的优化应等待整个程序基于真实的最终用户使用情景的压力测试的进行。仅仅基于对代码的静态理解，直觉地判断对总体性能什么是重要的，结论几乎老是错误的。相反，度量整个系统的行为，辨别1%真正影响性能的代码，并专一于此。

1七、减小积压未完成的编码任务：当开发人员开始一个用例，会发生成本，跟已修改却未完成和测试的代码相关联。留着未完成的变化几天或几个星期会累积成巨大的重作风险。考虑每一个估算须要一天的三个任务，同时开始这三个任务，并在3天内同时进行，意味着9个单位的累计成本。可是顺序进行每一个任务，完成一个再开始下一个，意味着只有3个单位的成本。这个不是直觉，直觉告诉咱们，在工做完成以前，咱们不妨同时作三件事情。但软件不像物理构造。短小，快速和完整的工做不只减小认知的负担，并且减小未完成工做与他人未完成工做之间冲突的可能。

1八、不要过分强调代码的通用性：这就是著名的“YAGNI-你不会须要它”。当编写一个特定类的时候，程序员总喜欢认为该类可能用于其它用途。若是如今的用例须要这些用途，这很好，可是，程序员常常考虑未被说起的用途，或者那些实际上永远不须要的。（这经常让我联想到经典的周六现场滑稽短剧，关于某产品既是地板蜡，也是糕点上的甜食。）

1九、两行代码能行，就不要用三行：有人阅读时，简洁的代码总能得到回报。但不要将代码压缩到难以阅读。更小的，编写良好的代码比之冗长的，编写华丽的代码更容易维护，也更容易发现错误。始终尽量简化，但别过度。

20、不要用行数来度量代码：完成特定任务所需的代码行数，不一样的程序员之间和编码风格之间差别很大。代码行数不能告诉你代码完成和质量的些许东西。代码质量能够相差200倍，这足以抵消代码行数的做用。应该统计功能用例的数目。

2一、持续地从新设计和重构：谨慎地使用这条准则，由于有些代码脆弱而难以改变，但一般你不该惧怕更改代码以符合实际使用状况。一个数据成员过去多是整数，可是当一个用例要求它是一个浮点数时不要惧怕去改变它。

2二、删除死代码：涉及到大量不能很好理解的代码是，有个倾向是不自找麻烦。一个例子就是往类中增长新的方法去替换另外一个，开发人员经常会留下旧的方法以防万一。必须努力检查方法是否必须，若是没有证据代表它是必须的，那就删除它。最糟糕的就是注释掉大量的代码，并把它留在那儿。注释掉的代码应在测试经过后尽快删除，固然应在签入以前。所以，某个时候你发现一些东西可能并不须要，付出小小的努力去验证并消除此代码能让代码基线更易维护。

2三、不要发明新语言：程序员喜好使用文本文件配置在运行时驱动功能。没有配置文件可以不编译而改变程序的行为。XML的出现推进了无休止的专门定制“脚本语言”的浪潮，以使功能能被最终用户定制而不须要编译。这种推理的缺陷在于，离开某个特定实施的环境，操做行为几乎历来没能很好地精肯定义，同时，那些脚本语言只对那些对问题领域代码的内部运行有深刻了解的人有用。所以，不具有详尽内部知识的真实最终用户永远不可能知道预料复杂的命令组合的效果须要什么。脚本语言有用，也不能被消除，可是设计者必须采起很是很是保守的态度，尽量使用现有的语言，避免新的发明。

2四、在你准备实现并测试前，别作设计：你应该有行进的整体思路和对系统架构的概览，可是，直到开发迭代容许设计被实现和测试前，不要作详细设计，不要编写功能实现的详细说明。详细设计应当只涉及处处理目前的用例。软件开发中最大的浪费源于将时间花在设计那些不须要，或者由于某些错误的设计假定而须要从新设计的事情之上。

2五、设计是可塑的：不像物理制造，软件能够很容易地得到显著改变。事实上，有大量证据证实软件自己比描述软件的设计说明书更容易改变。此外，软件比说明书更有效地传达设计。所以，你应该把时间用于直接实现设计，让客户能看见设计的细节。若是你犯错并改变设计，改变软件比改变规格更容易。但最重要的是，客户看到代码运行后，你关于客户想要什么的信息大为完善。

2六、花时间编写发现和报告异常状况的代码中的问题的完整描述：程序员每每很懒惰，抛出粗浅描述错误的异常。认为他们永远是惟一会看到这个问题的人，而且他们从含糊的描述会记得这个问题的意思。但实际上，在客户支持环境，不许确或者不完整的错误报告比其它缘由浪费更多的时间。编写每一个错误消息，就好像你正向某个正好走进房间而且没有此代码经验的人解释情况。客户和客户支持团队毕竟没有此代码的经验。

这些介绍没有特定的顺序，欢迎讨论我忽略的原则，或者（若是是这种状况）你不认同的敏捷开发原则。