敏捷开发学习心得

过年放假这几天读了一些敏捷开发方面的书籍，基于自己对敏捷开发的理解总结出以下几点。本文内容还会进一步整理，暂时先贴出来，权当作是一份备忘吧。也希望对阅读过本文章的挨踢人有些许启发，如果能留言进行进一步的讨论交流就再好不过了。

我认为敏捷开发应该围绕如下几点进行：

1、出了现了一个问题或发现了一个bug，第一重要的事情不应该是想办法确定这个问题是谁造成的，而是应该试图去想办法解决这个问题。因为去争论这个问题是谁造成的没有任何意义，有意义的是如何去解决，让系统能正常的工作起来。

2、发现一个bug，并且时间紧迫，如果不去了解真正的原因就进行快速修复确实能解决它（在最后添加一行代码或者是对结果进行简单的偏移运算）。但是要知道，千里之堤毁于蚁穴，这样的修复日积月累下来就会使项目代码变得凌乱且晦涩难懂。如果在这样的项目之上添加新功能或者进行其他的改动，将会很难下手。所以，未雨绸缪。建议不要孤立的进行编码，要经常阅读团队中别人写的代码（包括单元测试）。自己要对每个功能写好单元测试，写单元测试能帮助代码进行分层，方便别人阅读与理解。这样，不管是你在修改别人的bug还是别人修改你的bug，会相应的顺手一下。这样坚持下去，即可最大限度的保持项目的保持整洁与清晰。

3、在设计或者代码中遇到了奇怪的问题，应该花时间去理解代码为什么会是这样的。如果找到了解决方法，但是代码仍然不好理解，那么就鼓起勇气去重构它，使它变得容易理解。如果没有马上理解那段代码，就不要轻易的否定和重写它。那不是勇气，那是鲁莽。

4、养成立会的习惯。顾名思义，立会即站立着开会，参与者不允许在会议中就坐，这样能保证会议的快速进行。因为一个人坐下之后，会由于感到舒适而使会议持续更长的时间。立会可以在每天十点准时举行，每人发言时间控制在三分钟内，会议内容围绕昨天有哪些收获、今天准备做什么、当前面临着怎样的障碍这三个方面来进行叙述。各项问题不进行深入讨论，防止延长会议时间。如果有深入的必要，可以在会后进行。这样的立会可以让团队成员达成共识，并能保证会议短小精悍不跑题。

5、要寻找深藏不露的程序bug，进行正式的代码复查其效果是任何已知形式测试的两倍，而且是移除80%缺陷的唯一已知的方法。代码复查由项目团队中的成员来完成，可采用交换复查的方式。代码复查在团队中某一个成员即将提交代码时进行。代码复查内容包括代码能否被读懂和理解、是否有明显的错误、代码的改动是否会对项目其他部分造成影响、是否存在重复的代码、是否存在可以改进和重构的部分。

6、和客户讨论问题的时候，准备几种可以让客户选择的方案。从业务角度而不是技术角度向客户介绍每种方案的利弊，以及潜在的成本和利益，以及和他们讨论每个选择需要的时间和预算。如果事后他们又想要其他的东西，可以公正的就时间和成本重新进行讨论。

7、搭建一个演示服务器，每添加一个新的功能或者是对系统进行优化之后，告知客户访问最新的系统。这样系统每一次迭代都能获取客户的反馈意见，这样也基本保证了项目始终是沿着客户的需求进行开发的。保持项目随时可发布很重要。

8、很多项目都是因为程序代码失控而陷入困境。修复一个bug导致更多的bug，从而又导致了更多的bug修复。这时我们需要一个频繁的反馈，虽然可能不会使代码更好。但是也不会使代码变坏，至少还是像昨天那样可以运行。此处，使用单元测试就是一个非常不错的选择。单元测试应该在增删改某个功能的时候来运行，至少应该在提交代码的时候运行。单元测试中用来测试的数据应该包含边缘数据（比如11:59:59,0:00:00都是比较好的边缘测试数据），并不能放过任何一个失败的测试。

9、建议采用先测试再实现的方式进行开发，也就是“测试驱动开发”。总是在有一个失败的单元的测试后才开始编码，测试总是先于代码编写。通常这种测试失败的原因是测试的方法不存在或者是方法的逻辑还不足以让测试通过。先写测试，就会站在用户的角度来思考，而不仅仅是一个单纯的实现者。这样做和先编写后测试有很大的区别，你会发现因为自己要使用它们所以才设计了他们。这种方式能让接口的设计更有效。除此之外，还有助于消除过于复杂的设计，可以专注于真正需要完成的工作。

10、并不意味着单元测试在自己的机器上能运行，就一定能在其他的机器上能运行。不同的环境可能会有不同的结果。这个和操作系统环境有关，甚至可能和硬件环境有关。

11、在系统开发中辛苦的编写单元测试用来获取代码的反馈，却往往容易忽视了最终用户的反馈。不仅需要和真实的用户进行交谈，还需要耐心的倾听。即使他们说的内容是一些让你觉得非常直观，非常简单的问题。因为每一个用户的抱怨背后都隐藏了一个事实，我们要做的是找出真相，修复真正的问题，而不是对用户发出嘲笑。

12、用户在使用系统的过程中如果出现什么错误，不要只是简单的弹出一个错误对话框。应该告知用户发生了什么错误，方便用户进行有效的反馈。如果出于保护代码底层的原因不想让用户知道具体的错误信息，也可以在系统后台给技术支持人员发送一份问题的详尽错误报告。

13、编写能够清晰表达意图的代码，这样的代码清晰易懂，仅凭小聪明写的那些晦涩难懂的程序很难维护。注释虽然能帮助理解，但是有可能会对理解造成干扰。其实，这里也不是说注释不用写，只是不能让别人完全通过注释才能理解所写的代码。最好是采用规范的命名、清晰的流程、简单的编码等方式来达到代码既是注释的效果。

14、在代码编写或项目开发的时候应使用增量式的开发方法，即每完成一个功能或者方法的时候确保其对应的单元测试能正确通过。这样，在编码的过程中也能实时不断地获取来自代码的反馈。提交代码之前需要保证所有的单元测试能完全通过。

15、应具有一个自动化测试环境，每天固定的时间开始从svn检出最新版本的源代码进行单元测试。测试完成之后会生成一份测试报表。这样，每天早上就能获取一份关于最新代码的测试报告。时刻了解项目目前的状况。

16、编写具有内聚的代码，做到一个方法只做一件事情，一个类只包含他自己所应该包含的方法，一个包只包含应有的模块。这样有利于维护。但是内聚的颗粒不能太粗也不能太细，要拿捏的恰到好处。这样有助于对代码的理解，也降低了项目维护的难度。举个例子：当需去储物室寻找一台电脑的时候，打开们一看，里面乱七八糟的什么都有，后来费了很大的气力才把电脑找出来，这就属于颗粒太粗，没有分好类；当需要去储物室寻找一台电脑，打开门一看，里面大大小小的箱子盒子收拾的井井有条，一眼就看见了一个盒子上面写的电脑二字，打开盒子一看，里面是内存、CPU、硬盘、主板……这属于颗粒太细，虽然得到了自己想要的东西，但是不能马上用，还需要自己组装之后才可正常使用。