敏捷软件开发-第六章

敏捷软件开发第六章是关于一个保龄球程序的实践过程。

主要涉及了两个主题:测试驱动和重构--这两个概念都很好。
但我觉得这篇文章不好,感觉编写代码的过程没有很清晰的思路,过度依赖测试用例。我完全同意它结论部分的反方意见。
----
结论
 完成本章后,我把它发布在ObjectMentor的web站点上。许多人阅读后给出了自己的意见。有些人认为这篇文章不好,因为其中几乎没有涉及面向对象设计方面的任何内容。我认为这种回应向对象设计的情形。事实上,仅有Scorer类稍微有一点面向对象的味道,不过那也只是一个简单的分割,而不是真正的OOD。
 另外一些人认为确实应该有Frame类。有人竟然创建了一个包含Frame类的程序版本,该程序比上面所看到的要大得多,也复杂得多。
 一些人觉得我们对UML有失公正。毕竟,在开始前我们没有做一个完整的设计。餐巾纸背面的有趣的小UML图不是一个完整的设计。其中没有包括序列图。我认为这种看法更加奇快。就我而言,即使在图6.2 中加入序列图,也不会促使我们放弃Throw类和Frame类。事实上,那样做反而会使我们觉得这些类是必需的。
 图示是不重要的吗?当然不是。嗯,实际上,对于某些我所碰到的情形是不需要的。就本章中的程序而言,图示就没有任何帮助。他们甚至分散了我们的注意力。如果遵循这些图示,所得到的程序就会具有很多不必要的复杂性。你也许会说同样也会得到一个非常易于维护的程序,但是我不同意这种说法。我们刚刚浏览的程序是因为易于理解所以才易于维护的,其中没有会导致该程序僵化或者脆弱的不正当依赖关系。
 所以,是的,图示有时是不需要的。何时不需要呢?在创建了它们而没有验证他们的代码就打算去遵循它们时,图示就是无益的。画一幅图来探究一个想法是没有错的。然而,画一幅图后,不应该假定该图就是相关任务的最好设计。你会发现最好的设计是在你首先编写测试代码,一小步一小步前进时逐渐形成的。
---
我同意上面三个反方的观点:
1 没有进行面向对象的设计,而这个例子用面向对象设计应该很清晰
2 确实应该有Frame类,看完程序,我非常有冲动想以自己的面向对象的设计  来重新写一遍。
3 没有一个完整性的设计,过度依赖能够想到的测试用例。

没看过这本书。

从上面看出,这本书作者本身设计水平可能不全面,OO上有待提高,说实在,老外中就是出书的能完全站在OO上面,能有几个,中国更是几乎没有。