一个资深程序员的敏捷开发心得

我收集各式各样的至理名言。最近我一直在研究敏捷软件开发；有收获吗？

奉上可以指导敏捷软件开发团队的24条核心原则。

1.用例一彻底可以运行后再开发用例二

厨房里有一种说法正好能够印证这个问题：“作好一盘菜后你再作下一盘”．对于软件开发来讲一个最大的问题就是人们喜欢并行开发多个任务。由于不可避免的，咱们设计的功能中总会有一部分会被放弃砍掉，若是提早开发，极可能作无用功。一次只开发一个用例（或不多几个用例，这根据你的开发团队的大小而定）；让这个用例功能完整；让相应的测试用例都能经过；相应的文稳都补齐；只有在当前的用例彻底开发完成后，才作为一个总体提交到版本库，才进行下一个用例。

2.避免提交一个半成品

避免提交一个半成品。这一点你们彷佛都知道，但这条原则必须列入任何一个开发指导里。可以听取这些忠告进行开发测试而后提交代码的程序员必定不会发生代码提交到版本库使整个项目没法编译码经过状况。若是系统编译失败，那必定是有人抄近道到了。

3.必定不要在没有使用例的状况下往类里添加成员方法

必定不要在没有使用例的状况下往类里添加成员方法。这跟上面一条极其类似，除了这里针对的是数据成员。开发人员很容易想到：一个‘客户记录’里应该有‘送货地址’的信息，但必定不要在没有任何用例要求这个属性的时候实现这个属性。

4.不要惧怕作决定；不要惧怕改变之前的决定

不要惧怕作决定；不要惧怕改变之前的决定。敏捷开发的目的是应对客户需求的不肯定。开发前期你不可能获到所有的信息。你应该尽量的拖延作决定的时间，但一旦到了你该作决定的时候，你应该当机立断，让项目向前推动。你不能说一直等到有了足够的信息才作决定。相反，你要依赖现有的信息做出最正确们决定。以后，当有新的信息出现后，不要惧怕对之前的决定做出更改。(老辈人有的称之为触发器，但我称之为随环境而变)

5.不断地了解如何改进系统

不断的了解如何改进系统。这项工做没有尽头，你应该作好思想准备，持续不断的寻找能够改进的地方，收集各类关于如何找到质量问题、解决质量问题的案例。

6.不要在尚未任何使用案例的状况下设计通用模块

只有在你知道有具体用例的状况下，你才能够实现一个具体的类，并且你在该类中只应该实现当前该用例须要的方法。你也许会想到未来这个类会有其它的用途，你能够用注释的方式记录一下，但不要去实现它，只有在有了具体用例后你才能够实现它。

7.审查，审查，审查

审查，审查，审查。敏捷开发能够帮助咱们应对需求在未来的不肯定，但过去的事情也存在不肯定性。测试工做永远不能停下来。程序每次运行的表现都要被评审和记录。

8.软件的设计要以人为本，而不是系统

软件的设计要以人为本，而不是系统。不少开发人员退而求其次、以技术为中心，让设计为技术服务。永远不要忘记软件的终极目标是什么，是帮助人们完成工做。

9.测试是产品的一部分

测试是产品的一部分。许多开发人员和经理都认为产品就是你打包给客户的东西，其他的都不重要。其实测试也应该看做是产品的实际一部分，应该在设计时给予至关的重视，甚至，在不少时候，测试功能也应该同产品一块儿提交给客户。（后面说的这部分不少人都不承认，一个内置的能自我测试软件包并不会占用多少额外的资源，但当你须要用到它时，你会发现它的巨大价值。)

10.先写测试用例，后写代码

先写测试用例，后写代码。测试用例能够用来精确的说明咱们的设计需求。不少时候咱们都是经过运行测试用例后发现咱们的设计中存在问题。想一想吧，先写测试用例后编码能节省多少时间。可是：写完测试用例1，而后编写用例1，完后才开始用例2。

11.清理垃圾代码

清理垃圾代码。很显然，又是一个尽人皆知的道理，但它也必须写入任何的开发原则里，由于它是如此的重要。查找垃圾代码的工做永远没有尽头，找到它，消灭它。要去除掉全部的不能给实际用户带来价值的代码。若是你不能指出某段代码对用户有什么用处，那它极可能就是没用的。

12.培养对集成失败问题当即作出反应的习惯

培养对集成失败问题当即作出反应的习惯。你要明白，当集成构建失败时，它会影响项目中的每个人，因此没有比让核心程序能正确的集成和测试经过更重要的事情了。我曾经见到过有的团队的集成构建中断几个月都不去管它，由于他们有其余的工做要作。每一个人都在忍受这种状况，但没人采起措施。咱们应该明白，应该普遍的认识到，只要作出一点点工做，整个的团队会所以获得很是大的回报。

13.团队的每一个成员都要知道客户的需求

团队的每一个成员都要知道客户的需求。大型复杂的项目必需要分割到几个独立的团队去开发，而后派发到每一个开发人员的手中，但这绝对不能变成程序员能够不明白最终产品的使用用户的需求和目标是什么。

14.把意义相关的东西放在一块儿

把意义相关的东西放在一块儿。组织好代码，让高度相关的东西都放在一块儿，也就是放在一个类里。这是标准的面向对象设计原则里的封装的概念。理想状况下，类以外的程序并不须要知道类里面的工做细节。有些开发人员喜欢把代码放到好几个文件里，这样是为了按另外一种方式组织它们：例如把相同的数据类型的放到一块儿，或按字母顺序分类。举个例子，有人会把全部的常量放在单独一个包下的一个类里，他们这样作毫无必要，增长了程序的复杂性。按照指导原则，它们应该按照相关性进行分组，从而减小复杂性。

15.先测试后提交代码

先测试后提交代码。这个准则能让你确保“永远不要让集成构建失败”的准则。

过早优化是灾难之源这句话是引用DonKnuth的，今天听起来一点不错。在内核里的代码应该尽力的写好来避免不要的浪费，但针对高于单个方法的级别的优化应该在整个项目测试经过、针对最终实际用户的压力测试用例经过以后才能进行。仅仅根据静态的代码来判断哪些是影响整个性能最主要的问题的论断每每是错误的。相反，评审整个系统的运行表现，找出真正影响性能的1%的代码，只针对这些代码作优化。

16.最小化未完成的编码任务的工做包（backlog）

最小化未完成的编码任务的工做包（backlog）。当开发人员开发一个设计用例时，有的功能会牵涉到全部修改着的但未彻底开发完成、充分测试的代码。把未修改完成的代码保存到本地数天或数星期，这样增长了工做浪费的风险，会出现返工。想象有三个任务，每一个估计都要一天。若是三个一块儿开发，并行起来每一个都须要3天，这样一累计会有9个’单位’的风险。若是顺序的开发，一个开发完成后再开发另外一个，只会有3个‘单位’的风险。这个并不符合咱们的直觉。咱们的直觉告诉咱们，当咱们在这种状况下时，咱们但愿三个一块儿完成。可是软件不像盖房子。小的、迅速的、完整的任务不只仅会下降咱们的认知负荷，也减小了进行中的开发对其余人正在进行的开发的相互影响。

不要过分功能范化。也就是咱们所说的“YAGNI–You Aren’t Going to Need It”。程序员在编写一个类时喜欢料想：这个类可能在其它地方其它类中会有其它用途用．若是这些用途是被当前的用例用到，那这样思考是没错的，但经常开发人员想到的这些用途都是目前不存在的用途，实际上多是永远不会用到的用途。 IIS7站长

17.若是两行代码能完成就不要写成三行

若是两行代码能完成就不要写成三行。简洁的代码永远都会给须要阅读这段代码的人带来好处。但千万不要把代码压缩的难以理解了。精简的、书写规范的代码易于维护和查找错误，冗长的、太多修饰的代码则相反。尽量的简化但不要过分。

18.永远不要按行数多少来评价代码头

永远不要按行数多少来评价代码头。编写某个任务所产生的代码行数会因程序员而异，因编码风格而异。代码的行数不会提供任何关于程序完成状况和代码质量的信息。代码质量能够相差200倍之多，这是计算代码行数的方法不能胜任的。应该计算功能性的用例数。

19.咱们应不断地再设计、再分析

咱们应不断的再设计、再分析。应用这一条时你要很是的当心，由于有些代码很脆弱、难以维护。但不要惧怕修改这些代码、让它符合真正的需求。一个数据成员之前是整数型的，但如今有个用例须要它是浮点型，不要惧怕去改变它，只要你按步骤：测试，写文档，布署。

20.删除死代码

删除死代码。当发现有一大段不能理解的代码时咱们习惯的作法是“让死狗躺在哪”。好比说，咱们须要往类里添加一个新方法来替换之前的旧方法，通用人们会保留老方法‘以防不测’。其实，咱们应该花一些功夫去检查看看这个老方法是否还有用，若是没有证据显示它还有用，就该删掉它。更糟糕的错误作法是把这些代码注释掉，留下一堆注释码。注释掉的代码一旦发现就该被删掉，不能留到测试时还有、甚至提交到代码库。添加代码老是容易的，删除代码老是困难的。所以，一旦发现有可能没用的代码，你应该花点时去确认它、删除它，这样会让代码更加可维护。

21.不要自创新语言

不要自创新语言。程序员喜欢使用文本文件来实现功能性的趋动，这样可使程序变的可配置。经过配置文件来改变软件行为所产生的后果是不过控的。XML的诞生促使了一系列的特别的自定义的‘脚本语言‘的出现，人们试图经过文件的配置以让最终用户‘编程’来控制软件的功能、避免从新编译。这种设计上的缺陷是：软件里的各类操做的准肯定义在脱离了具体上下文的特定实现的状况下不可能被准确的定义。这些各式各样的脚本型语言只是对那些对软件代码的内部工做机理有着相关的知识背景的人才会价值。因此，真正的最终用户是不可能知道软件的内部工做机理的，不可能推理出这些复杂的指令组合会产生什么样的预期结果。脚本有它的用途，也不该该被抵制，但设计人员必须以很是很是安全的方式使用它们，尽量使用现有的语言，必免使用新发明的语言。

22.只有当准备好了实现和测试才去肯定设计

只有当准备好了实现和测试才去肯定设计。我应该有一个整体的认识咱们要作什么，应该有个整体架构目标，而不是详细设计、详细的具体方法的实现，只有当开发迭代到必定程度后、足以让咱们定下设计细节后才去把它表现成文档。详细设计只应该包括当前需求用例中须要覆盖的部分。软件开发中最大的浪费就是你花时间设计出来东西后被告知不须要了，或者是你的设计一开始就创建在错误的假设上。

23.软件是可塑的

软件是可塑的。软件不像盖房子，咱们能够轻易的改的面目全非。无数事实代表软件比它的规格说明书善变的多。并且，软件产品和设计之间的互动明显比规格说明书有效率。因此，你应该直接实现你的设计，这样客户就能很容易明白你的设计细节。当发现有问题、要改变设计时，修改软件要比修改文档容易的多。更重要的是，当客户看到了能运行的程序后，你也就更能搞清客户的需求是什么了。

24.对被检测到的和被报告的异常状况请多花一点时间对其进行详细描述

对被检测到的和被报告的异常状况请多花一点时间对其进行详细描述。程序员通常都很是的懒，抛出异常时只描述错误的表面现象。设想若是只是做者本身会遇到这种错误，他会记得这种一直使用的错误描述信息是什么意思。但站在客服技术支持的处境，他们由于这种不许确的、不完整的错误描述浪费了大量时间。这些信息应该达到让一个刚走进屋里没有任何经验的人能看明白的程度。客户和客服基本都是对编程不懂的人。