2014年的项目的总结(二) 谨防过度设计 别为显示技术而搞复杂 杀鸡焉用牛刀？

　14年最后一个项目无疑收获巨大，自己掌握的很多东西都得到了检验，而其中暴露出来的问题更让我得到教训，特别是开始走入的过度设计的误区，为了显示技术什么复杂用什么，现在想想真是后背发凉。这样的经历，像我这样的新手估计很容易犯吧。

---

上图

• 开始的架构

一开始做设计时，为了统一所谓的对外接口，解决耦合问题，防止action层与service层多对多的复杂关系，使用façade（外观模式）将对应模块的多个service做了下轻封装，想象中的层次关系是左边这样的，将左边换成右边，怎么看都是右边更顺眼，所以加了façade层。

 

• 可是 事实上，当前项目的关系是这样的

---

完全没那么复杂，为什么要加facade层，这是我突然想问自己的，它有这个必要吗，而且这个项目也无需再扩展，没必要考虑业务复杂后的扩展性，杀鸡焉用牛刀。

设计太多的分层，搞个Hello world，都要来五六个文件的话，这项目也就玩不下去了。

其实，敏捷开发的思路就是答案，简单，最简单的解决方案就是最好的解决方案，够用就行，在一次次的重构中提升架构的水准。

按照这个思路，我把底层的框架选型也改了，一开始用hibernate，嫌不够灵活，换了mybatis后，配置还多了不少，最后全不用，直接用上自己以前写的一个仿hibernate的持久层框架durable，采用约定优于配置，完全零配置，甚至注解都不需要，而且满足当前需求。

数据库也不用oracle，以前是因为oracle用得多，习惯搞什么都用oracle，其实也没这个必要，oracle太重量级了，mysql小多了，足以满足需求。

这个也让我想到包括我在内的同学们的简历上，项目里描述了那么多高大上的技术，本来就是简单的玩意，非得为了显示自己技术水平，什么复杂用什么，一问反而啥也不知，这就是装X啊，我开始也是抱有这种想法的，学到什么，一股脑用上去，反而误入了歧途。

做技术，还是实事求是的好。。

参考

过度设计