最近碰到一个这样的问题，有两个Solution，它们之间在数据层上有一定的联系，简单说就是B项目为A项目提供录入数据的功能，功能上它们两个各有分工，代码暂时也没有耦合，但都出现了一个验证某数据的要求，这个算法是相同的。我的第一反应是肯定要独立出一个Project，单独有一个类，里面有这个验证方法。然后2个Solution分别引入此Project。但我讲出这个想法，团队最后予以否定，说是如果有更多相同的类似验证数据的代码可以重用时再这样做，现在不是最佳时机（可以理解为可重用的太少了，等再多一点再做，或者是如果现在做会拖慢进度之类的）。
这反应出我一个特点，就是对代码质量的要求很苛刻。在生活中也可以体现出来，头上有个灯坏了，一闪一闪的，有些人可以永远忍受，我就不行，即使它闪的不是很厉害，我也受不了，我很奇怪为什么别人都能受得了。
绝对不允许有重复代码是敏捷开发中重要的原则，团队中也有人学了敏捷开发，可为何不站出来支持我呢？在讨论中出现了另外一个问题，假如2个项目中重用此代码，应该用ClassLibrary还是用WebService，下面我一并列出我的观点：
1. 首先一定要重用可以重用的代码。因为重复代码是维护的大敌，当不重用时，如果算法有某些修改，那么我们不得不同时改2个地方，即使算法没有修改，但是实现这个算法的代码自身有缺陷，那么也要同时改2个地方。（事后也证明，实现此算法的代码确实有缺陷，它没有预防可以避免的异常。）
2. 把这个相同的代码摘出来，放到一个单独的Project里，绝不会拖慢进度。有点经验的都应该明白，这个工作只不过3分钟的事儿。
3. 任何一个需求（特别是数据验证的任务），即使现在确实是只有一个，但都不应该看成一成不变的，应该看成有可能不断增加的。当不单独提出来时，每增加一个就要同时在2个地方加代码，既然有很大的把握可以预知未来一定会增加需求，为何不现在就积极准备呢？何况这2个Solution是有内在联系的，它们共同引用一个库是非常非常合理的，并没有增加它们之间的耦合度。
4. 如果重用应该用ClassLibrary。理由是WebService是比较Big的方案。首先，我们知道WebService最佳的应用是跨平台、穿越防火墙，但现在这2个项目是运行在同一局域网中的，WebService的优势完全用不上。第二，WebService在布署上比ClassLibrary复杂，主要是因为它的配置复杂，首先要有个WebSite来承载这个服务，它的地址和端口号需要配置进用到它的应用中去（假设按照代码类的方式访问），一旦改变了，就要改配置（针对现在的情况，要改2个地方的配置）。第三，WebService的性能不好，用在这里没有用牺牲一点性能换到任何一点好处，哦，唯一的好处是算法变了，可以只改一个地方，可是你们也说了，算法99%是不会变的。再看如果算法增加了的情况，比如新增了一个验证需求的时候，我们可以看到，用ClassLibrary或WebService工作量是一样的，都要重新布署3个地方（一个WebService，和两个用它的项目），即WebService也没有比ClassLibrary有任何的优势。
5. 还是像原来一样，我觉得现在的团队对“变化”的态度太保守了，我不明白为何这样显而易见的问题也要开会讨论，最后还得出一个“维持现状”的结论。我对现在团队越来越失望了。
也许有些人觉得我小题大作了，可我觉得高楼大厦都是由一砖一瓦盖起来的，我们必须重视一砖一瓦，而不是成天炫耀，我们用了什么什么模式，什么什么框架，这些号称“柱子”的东西。你们说对吗？
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
看了评论，发现漏说了一点，即WebService与重复代码的关系。我的理解是这样的（假设都用代理类来访问）：
1. 当两个项目都访问同一WebService必然存在重复代码，即代理类本身，虽然它可以自动生成，不用我们管，但它确实是重复代码 :( 。
2. 另外访问WebService的2个项目都有重复的对WebService地址的配置信息，如果地址变了，就不得不改2个地方。
我之所以说WebService是个Big的方案，就包含有以上原因。
