Agile Java 一些感想

最近看了一些关于敏捷的东西,

很认真的学习了Agile Java这本书.

虽然一直都很认真的写测试,但是基本上都是开发驱动测试,为了完成覆盖率而写.

用了两天时间将这本书的例子都跑了一遍之后发现,其实TDD还是真得不错,先构建测试有助于理解我们需要实现什么功能,以及功能实现时可能存在的边界问题.

Agile Java中驱动我是这么看得
1.写一个测试,运行得到失败的报告,Case只需要覆盖一个功能点
2.编写代码,代码只需要保证Case能够正常的通过.
3.运行测试,保证测试通过.
4,重构代码,确保代码没有什么臭味道.
5.修改测试代码,确保测试代码易懂.

重此往复.

坚持TDD的关键,就在于坚持在没有无法通过的测试的时候,就不要增加新的代码.
凡是增加新功能,或者修改功能的时候都必须要有新的无法通过测试用例.

可是无休止的增加测试用例,对于程序员来说是一项灾难性的工作,我们大多时候都难以坚持,我们会认为,我们的代码足够强装,新的测试用例所测试的范围我们以后的代码已经照顾到了.不需要增加这样的测试用例.

至于测试用例有多么的重要和必要,就不多说了,但是经过几年来不断的版本升级,足够强壮的自动测试是软件持续演进必不可少的一环.不管你的代码写的如何臭不可闻,但是至少软件的已有功能不会受到影响.

为了让TDD能够贯彻始终,敏捷团队中特意提出的结对编程这种方式.以这种方式客服一个人的惰性.

我是没有什么真正的结对编程的经验,只是有一些两人一同开发,一人负责测试用例,一人负责代码的经验.即使如此,代码的质量也大大高于一个人开发.

我们团队是以FDD模式在运作,但是在程序员级别上,我们有意推行Strum团队编程,很不幸或者恨幸运被选作Strum master,来带动整个团队的运行.

结对编程,据说在其他项目组中运用重来没有取得过成功,但是我还是想一开始就运用他,而不是仅仅只是用Scrum来管理进度.

我所看到的结对编程的优点:
1.最大的优点就是所有敏捷团队中首要的第一点交流,与更快的反馈.
2.能够更好的贯彻TDD开发.
3.能够更好的避免一个人编程中出现的不仔细的失误.
4.更好的互相成长和学习.
5.更优质的代码.

但是也许结对编程的很多存在问题由于没有实践而无法获得,但是不管如何,总的等一个周期运行结束之后再来总结一下得失,才知道是真好,还是假好.