聊一聊过度设计!

  新手程序员在做设计时，因为缺乏经验，很容易写出欠设计的代码，但有一些经验的程序员，尤其是在刚学习过设计模式之后，很容易写出过度设计的代码，而这种代码比新手程序员的代码更可怕，过度设计的代码不仅写出来时的成本很高，后续维护的成本也高。因为相对于毫无设计的代码，过度设计的代码有比较高的理解成本。说这么多，到底什么是过度设计？

什么是过度设计？

  为了解释清楚，我这里用个类比，假如你想拧一颗螺丝，正常的解决方案是找一把螺丝刀，这很合理对吧。 但是有些人就想：“我就要一个不止能拧螺丝的工具，我想要一个可以干各种事的工具！”，于是就花大价钱搞了把瑞士军刀。在你解决“拧螺丝”问题的时候，重心早已从解决问题转变为搞一个工具，这就是过度设计。

  再举个更技术的例子，假设你出去面试，面试官让你写一个程序，可以实现两个数的加减乘除，方法出入参都给你提供好了 int calc(int x, int y, char op)，普通程序员可能会写出以下实现。

    public int calc(int x, int y, int op) {if (op == '+') {return x + y;} else if (op == '-') {return x - y;} else if (op == '*') {return x * y;} else {return x / y;}}

  而高级程序员会运用设计模式，写出这样的代码：

public interface Strategy {int calc(int x, int y);
}public class AddStrategy implements Strategy{@Overridepublic int calc(int x, int y) {return x + y;}
}public class MinusStrategy implements Strategy{@Overridepublic int calc(int x, int y) {return x - y;}
}
/*** 其他实现  */
public class Main {public int calc(int x, int y, int op) {Strategy add = new AddStrategy();Strategy minux = new MinusStrategy();Strategy multi = new MultiStrategy();Strategy div = new  DivStrategy();if (op == '+') {return add.calc(x, y);} else if (op == '-') {return minux.calc(x, y);} else if (op == '*') {return multi.calc(x, y);} else {return div.calc(x, y);}}
}

  策略模式好处在于将计算(calc)和具体的实现(strategy)拆分，后续如果修改具体实现，也不需要改动计算的逻辑，而且之后也可以加各种新的计算，比如求模、次幂……，扩展性明显增强，很是牛x。 但光从代码量来看，复杂度也明显增加。回到我们原始的需求上来看，如果我们只是需要实现两个整数的加减乘除，这明显过度设计了。

过度设计的坏处

  个人总结过度设计有两大坏处，首先就是前期的设计和开发的成本问题。过度设计的方案，首先设计的过程就需要投入额外的时间成本，其次越复杂的方案实现成本也就越高、耗时越长，如果是在快速迭代的业务中，这些可能都会决定到业务的生死。其次即便是代码正常上线后，其复杂度也会导致后期的维护成本高，比如当你想将这些代码交接给别人时，别人也需要付出额外的学习成本。

  如果成本问题你都可以接受，接下来这个问题可能影响更大，那就是过度设计可能会影响到代码的灵活性，这点听起来和做设计的目的有些矛盾，做设计不就是为了提升代码的灵活性和扩展性吗！实际上很多过度设计的方案搞错了扩展点，导致该灵活的地方不灵活，不该灵活的地方瞎灵活。在机器学习领域，有个术语叫做“过拟合”，指的是算法模型在测试数据上表现完美，但在更广泛的数据上表现非常差，模式缺少通用性。 过度设计也会出现类似的现象，就是缺少通用性，在面对稍有差异的需求上时可能就需要伤筋动骨级别的改造了。

如何避免过度设计

  既然过度设计有着成本高和欠灵活的问题，那如何避免过度设计呢！我这里总结了几个方法，希望可以帮到大家。

充分理解问题本身

  在设计的过程中，要确保充分理解了真正的问题是什么，明确真正的需求是什么，这样才可以避免做出错误的设计。

保持简单

  过度设计毫无例外都是复杂的设计，很多时候未来有诸多的不确定性，如果过早的针对某个不确定的问题做出方案，很可能就白做了，等遇到真正问题的时候再去解决问题就行。

小步快跑

  不要一开始就想着做出完美的方案，很多时候优秀的方案不是设计出来的，而是逐渐演变出来的，一点点优化已有的设计方案比一开始就设计出一个完美的方案容易得多。

征求其他人的意见

  如果你不确定自己的方案是不是过度设计了，可以咨询下其他人的，尤其是比较资深的人，交叉验证可以快速让你确认问题。

总结

  其实在业务的快速迭代之下，很难判定当前的设计是欠设计还是过度设计，你当前设计了一个简单的方案，未来可能无法适应更复杂的业务需求，但如果你当前设计了一个复杂的方案，有可能会浪费时间……。 在面对类似这种不确定性的时候，我个人还是比较推崇大道至简的哲学，当前用最简单的方案，等需要复杂性扩展的时候再去重构代码。