这个话题来源于下午和同事们的讨论，背景是这样的：他们在一个小项目上工作，周期是4周。第一周是第0个迭代，主要的工作为写Story，做Spike等。而此后便开始开发，前几天开发的速度比较慢。因为他们经常在写了一些代码后又觉得，恩，结构设计的不够漂亮，中间应该加一层之类的。所以大部分时间都在推翻设计，修改以及添加测试，重构代码，分解依赖，运行Build脚本，提交代码。
问题就出现了，敏捷开发强调的是简单设计，Pair拿到一个Story的时候，分析业务需求，简单的讨论设计（大概15-20分钟），然后进行开发。在开发过程中发现有重复代码，进行重构，一切重复代码都得重构，包括测试。最终的结果就是，完成Story的时候，没有重复代码，这就是优良的设计。但是优秀的设计又要求容易扩展，需求变化的时候尽量少的修改。当代码能够很好完成它的功能，它就是有价值的，客户并不关心你的代码是否是低耦合，高内聚，也不关心它是否是多层架构的。花了很多时间做了高扩展的架构，到项目结束也没有要扩展的需求，这是否值得呢？
适当的设计是必要的，过多的设计是浪费，关键是要把握设计的度。怎样才是必要的呢？当你知道某地方以后会变化，该地方就得对扩展开放。举个例子，如果要你实现解析文件，然后把信息存入数据库这样一个功能，当前只要求解析Xml，你可能会毫不犹豫的用XmlDocument。但是，后面的需求是必须支持更多的文件类型，比如Excel，Csv等，你就得考虑需要引入Strategy模式。我觉得这就是适当的设计，为以后的扩展提供支持。如果你不考虑也可以，只是后面的开发过程中会大量的重构，修改测试，花更多时间，别人会说你设计不好。那什么是过多的设计呢？很明显客户只需要支持Sql Server，那我在DAO中就使用SqlConnection等，而不必要引入Provider或者Sql Dialect以支持多数据库的变化。这样的设计就是浪费。
良好设计的不二法则，面向接口编程。接口减少了类和类之间的依赖，提高了可测试性，很方便的引入DI框架。但是如果你看到我们项目的代码会发现，类之间全都是与接口交互，几乎所有类都会抽出接口，尽管它只可能有一种实现。这样做的目的是为了更好的使用Mock工具进行单元测试，当前还做不到Mock具体类而只能Mock接口。大量的接口伴随着唯一的实现，为了测试而设计，也是不小的浪费。我想肯定有更好的办法，比如将某些耦合紧密的类看作一个组合，对它进行单元测试。针对这些问题，我还需要更多的学习。
希望大家都来讨论，你们在开发过程中是如何设计的，如何把握设计的度呢？
posted on
