我想很多人都饱受过糟糕软件设计的痛苦，因此心里总有一股气，自己一定要做一个非常优秀的设计。至少我是这样的人。
近日公司的一个项目进行TR1评审的时候，在技术方案的评估文档中，我发现其第一项列出的便是上一个版本存在的设计缺陷：
-
产品之间复用只是停留在代码级别
-
模块代码不够独立，后期不能复用
-
模块代码不易扩展现在的新功能
由于是公司产权产品，其具体的内容不便详说。幸好我们只需要关注一下其中的重点。对，就是复用！
当然了，这份技术方案中，剩下的就是自己如何解决所有问题，如何提取可供复用组件，如何架构一个好的系统。姑且不谈对本系统的设计如何，我们跳出来看看我们在做一件什么样的事。
否定 --> 肯定 --> 否定
第一个否定，是我们在“否定”上一个版本，“肯定”是我们在肯定自己的版本，最后一个“否定”，是别人来否定我们的版本。不管我们意愿如何，这几乎是很多公司中必然的境况。
再来看看我们所希望的：我们希望我的设计足够优秀，所以在这个产品的下一个版本的时候（或者维护阶段），他们不会抨击设计的缺陷，并且能发现，
- 其架构的扩展性非常好，
- 可重用的模块也非常多。
- 原有系统的稳定性值得肯定。
可是，事实总不如我们想象的那样。为什么呢？
古人有一句非常有道理的话：己所不欲，勿施于人。什么意思呢？你希望别人来称赞你的设计，将来来复用你的模块。那么你这么做了吗？你愿意这么做吗？你自己都不做，何以希望别人来做呢？
是的，作为设计师的你来说，设计的根本目的是解决问题。解决业务上的问题，解决原有系统的问题。那么你的设计才会被认为是有用的。至于设计是否是优秀的，事实上，谁也没把握。未来的事，谁知道呢？
如果只是来证明你有足够能力设计整个系统，我相信你一定早就拥有了。可是说到优秀，却又一个标准问题。这和编写代码不一样。我能编100000行代码，你一定会认为我很强。我把整个系统的大部分全都实现了，你一定会将我捧到非常高的地步。
可惜，你要考虑的是，你不再是在编码，你是在设计。那么到底设计的衡量标准是什么呢？设计的标准很多，可是我相信有一个非常重要：
用最少的代码完成最多的事！
这和程序员的宗旨看上去完全是反其道而行之的。为什么呢？
- 代码越少，复杂度越低，所隐含的BUG也会越少。
- 代码越少，编写成本也越少。生产率提高了，你的待遇也就提高了。
- 代码越少，才真正证明了设计的重要性。如果设计就是让系统复杂话的话，要设计做什么？
- 代码越少，维护越简单
代码的大量减少，其实是意味着稳定性的模块在持续增加。这些稳定性的模块，才是设计的真正精髓所在。那么，这些稳定性的模块如何来呢？
一种选择是你来完成这样的模块，让别人调用。
另外一个选择就是你直接用别人的模块。
当然了，这里有一个非常有意思的地方。你或许会说，原来那么差的设计，我怎么使用？只能等我来设计了。可是我要说，如果你眼里只有第一种选择，那么你对别人来说，也不会有第二种选择。或者几乎可以肯定的是，你的设计，没有人会愿意复用。他们总可以发现你的设计中有足够多的缺陷来让他们放弃！就像你现在一样。
这个不是简单的所谓态度决定一切的阐述。这之间几乎有着必然的联系：
- 你发现不了别人系统中可以复用的，那么你在复用方面的意识就没有提升到足够的高度
- 没有足够的高度的复用意思，编写不出足够可以复用的模块
- 如此循环。抛弃式的设计只是会证明一点，又有一个存在众多问题的产品出生了。
如果从企业角度来看，那么复用的重要性更是不可言语。不过，公司的高层一般在技术细节方面不会太多涉及，所以反而容易忽略这点最可以提升生产效率的过程。不过好的公司，会规划平台性质的产品模块，来降低系统设计的范围。也可以减少设计的错误。这和前面的想法从基本上是一致的。
总之一句话，如果在解决问题之外，我们还想设计成优秀的产品，那么先从复用别人开始！