【敏捷】敏捷开发的至理名言

• 完整地干完一件事后在开始另一件事

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

• 不要破坏构建

• 非常明显，但必须被包含在任何软件开发建议清单中。
  
• 程序员在签入之前采取所有合适的预防措施进行测试，则永远不会破坏构建。
  
• 如果构建被破坏，通常是因为有人偷懒了。

• 在用例需要之前，不要实现程序

• 当你实现一个特定的类，你应该在脑海中有一个特定的用例，同时应该只实现用例需要的方法。
  
• 你可以考虑该类潜在的功能，写入注释之中，但直到用例真正需要时，才应去实现它。

• 在用例需要之前，不要添加数据成员

• 同上一条，不过这是从类的数据成员角度考虑的。
  
• 似乎显而易见地，“客户”记录需要“送货地址”，但直到有用例明确需要送货地址，才应该实现它。

• 不要害怕做决定，不要害怕改变先前的决定

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

• 持续学习如何改善质量

• 这项工作永不会结束，因此你应经常留意可以改善的事情，并收集质量问题被确认和处理的案例。

• 度量、度量、度量

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

• 为人而设计，而不是系统

• 开发者常常因技术而使设计误入歧途。
  
• 绝不要忘记设计的最终目标，那就是帮助人们完成工作。

• 测试是产品的一部分

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

• 在代码之前编写测试

• 测试本身可以用来阐释真正需要的设计。
  
• 设计的缺陷常常是通过测试用例被发现的。
  
• 想想看，编码之前，通过这些用例，可以节约多少时间。但是，为用例1编写测试，然后编码，然后再开始用例2。

• 消除浪费

• 坦率的说，这是另一个必须包含在任何开发原则清单中的陈词滥调，因为它太重要了。
  
• 发现浪费并消除它，这项工作没有尽头。
  
• 消除任何不能增加客户价值的东西。如果你不能确认客户价值，那很可能你并不需要它。

• 建立对构建破坏立即响应的文化

• 要明白当构建被破坏，会影响项目中的每一个人。
  
• 因此，最重要的是确认核心代码被构建并合理测试。
  
• 我曾见过有些团队放任失败测试持续数月，因为那是其它人的工作。
  
• 每个人都痛苦，但没人采取行动。相反，必须形成共识，那就是小工作能为团队获得大的回报。

• 所有团队成员应理解客户需要

• 大型的复杂项目定然被分解为独立的团队，进而被分派给开发人员。
  
• 但是，不应在此范围内做的是，失去关注最终项目真正用户的期望和目标。

• 把相关定义放在一起

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

• 始终在签入之前运行测试

• 这条准则帮助你满足“不要破坏构建”准则。

• 过早的优化是万恶之源

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

• 减少积压未完成的编码任务

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

• 不要过度强调代码的通用性

• 这就是著名的“YAGNI-你不会需要它”。
  
• 当编写一个特定类的时候，程序员总喜欢认为该类可能用于其它用途。
  
• 如果现在的用例需要这些用途，这很好，但是，程序员经常考虑未被提及的用途，或者那些实际上永远不需要的。
  
• （这常常让我联想到经典的周六现场滑稽短剧，关于某产品既是地板蜡，也是糕点上的甜食。）

• 两行代码能行，就不要用三行

• 有人阅读时，简洁的代码总能获得回报。
  
• 但不要将代码压缩到难以阅读。
  
• 更小的，编写良好的代码比之冗长的，编写华丽的代码更容易维护，也更容易发现错误。
  
• 始终尽可能简化，但别过分。

• 不要用行数来度量代码

• 完成特定任务所需的代码行数，不同的程序员之间和编码风格之间差异很大。
  
• 代码行数不能告诉你代码完成和质量的些许东西。
  
• 代码质量可以相差200倍，这足以抵消代码行数的作用。
  
• 应该统计功能用例的数目。

• 持续地重新设计和重构

• 谨慎地使用这条准则，因为有些代码脆弱而难以改变，但通常你不应害怕更改代码以符合实际使用情况。
  
• 一个数据成员过去可能是整数，但是当一个用例要求它是一个浮点数时不要害怕去改变它。

• 删除死代码

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

• 不要发明新语言

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

• 在你准备实现并测试前，别做设计

• 你应该有行进的总体思路和对系统架构的概览，
  
• 但是，直到开发迭代允许设计被实现和测试前，不要做详细设计，不要编写功能实现的详细说明。
  
• 详细设计应当只涉及到处理目前的用例。
  
• 软件开发中最大的浪费源于将时间花在设计那些不需要，或者因为某些错误的设计假定而需要重新设计的事情之上。

• 设计是可塑的

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

• 花时间编写发现和报告异常情况的代码中的问题的完整描述

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

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

• 已找不到原始出处，重新调整了格式，侵删。

​