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.更优质的代码.

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

结对需要一男一女

太好了我也是这么想的,哈哈,正好自己带队,徇私一下.:)

好吧.
我曾经结对编程..跟某位女同事..的确比现在有趣多了.起码不像现在这样累,这样枯燥

结对需要格外注意个人卫生、口气、健康……

结对的做法对新人很有用.成熟的技术人员结对简直是浪费时间浪费生命。

这是为什么呢？
成熟的技术人员不需要交流、讨论？

感觉对于新人来说用结对反而不好, 因为没有起到结对的意义, 结对编程主要是体现了敏捷中交流与反馈的作用.

让更多的人理解同一业务和代码.

其次就是避免一个人产生惰性和大意出现的问题

敏捷对开发人员的素质要求比较高，起码重构能力要强，对各种模式也要很熟悉。
设计人员要宏观把握需求的，设计不能太僵硬。
很难组织这样的团队 ， 很多coder都还停留在面向过程的思想，虽然是用的面向对象的语言，这是障碍。思想不对，沟通很难。

这个问题已经讨论了老多遍了。得出的结论就是为新人结对还不如不结对。
结对就是要高手与高手。否则写的来的代码质量谁来保证？就和下棋一样，老是把人家下的大败，真的能提高自己水平？新手真的能短时间快速成长？
每次都看见这种白痴言论，还真的发现有些人真的不适合做IT行业