前几天一个朋友说他写的程序有点问题，让我给看看。我大致看了一下，指出他在结构设计上存在着一个比较大的缺陷，因为要修正这个问题，改动比较大，所以他下不了决心去修改。

没有TDD的下场就是这样。

重要的是把TDD用起来。我去年就曾经向那位朋友推销过TDD了，可是他一直都没有用起来。其实我自己也是在知道TDD后很长时间才慢慢开始用的。 有人说：写不出测试用例，是因为对需求还不够了解。但是现在我发现问题不仅于此，还有一方面是：程序员的思维一向是碰到问题就开始考虑实现，一时很难适应 用“测试用例”这种语言来表达他们所理解的需求。

从某种程度上说，软件工程是对建筑设计工程的一种模仿，其重点是在早期消灭隐患，所以有一个共同点：设计先行。但是建筑毕竟不同于软件，建筑一旦到了施工阶段，任何修改都必然带来成本，而且这种成本可能非常的高。而且对于建筑来说，需求的变化相对来说小得多，而且工期通常以年为单位。这些都是软件与它的根本不同。

很 多软件工程的书都喜欢强调一个说法，那就是：在软件开发的后期发现问题所带来的修正代价将是巨大的。但那是在没有TDD的时代。现在有了TDD，配合方便 的SCM工具，我们可以随时用重构来改进最初不好的设计，即使到了后期的小改动，也不至于付出很大的代价。所以我喜欢测试先行的敏捷方法。

比 如对于需求的了解还比较有限的情况下，比如在需要分阶段实现的情况下，设计先行存在很多困难，很容易出现过度设计的问题，而且为了尽量将问题消除在项目早 期，可能导致设计成本过高等。而对于测试先行来说，则是在开发的过程中，设计慢慢变得完善起来。因为有TDD和SCM等的保证，变化是会向好的方向去，而 不是相反。

在OOD中，有一些原则，一如在OOP中的设计模式。在早几年，我是不知道这些原则的。不过最近翻看了一些自己的老代码，有相当 一部分中还是比较好地遵循了这些OOD的原则。就如同设计模式一样，写过一段时间程序的人回头去看老代码，一样可以看到自己曾经用过类似的模式。因为不论 是OOD原则还设计模式，都是来自于对实践的总结，学习它们可以使我们进步得更快一些，但是脱离了实践，它们就什么也不是了。坦白说，没有经过经过相当的 实践，实在很难让人理解那些OOD的原则。而在那些老代码中出现OOD原则或设计模式的，大多是一些修改过多次的代码，在那个没有TDD的时代，这真是一 件痛苦的事。

敏捷方法无疑是对这些技术的学习实践起到很好的帮助作用。

gigix介绍了在ThoughtWorks里，敏捷方法被运用到了怎样一种程度。强啊。

令狐回复说：其实正如Gigix说的那样，敏捷方法也是需要实施者真正有水平才行的，如果没有受过训练，的确有可能出现“写不出测试用例”或“重构越构越乱”之类的问题。就像没有一个编程新手很难写出一个良好运用设计模式的实例一样，虽然他可能对这些概念都了如指掌。其实对于一般人可行的办法就是，持续改进代码，到自己满意的程度。这样就可以了，随着理解的深入，持续的改进会越来越好。一开始要求做测试优先或者规范的重构之类，除非有人带着，不然真的很难的。

那是当然，没有银弹嘛。^O^ 对于软件开发来说，人，始终是最重要的因素。