关于设计:聊一聊过度设计

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

为了解释分明，我这里用个类比，如果你想拧一颗螺丝，失常的解决方案是找一把螺丝刀，这很正当对吧。然而有些人就想：“我就要一个不止能拧螺丝的工具，我想要一个能够干各种事的工具！”，于是就花大价格搞了把瑞士军刀。在你解决“拧螺丝”问题的时候，重心早已从解决问题转变为搞一个工具，这就是适度设计。

再举个更技术的例子，假如你进来面试，面试官让你写一个程序，能够实现两个数的加减乘除，办法出入参都给你提供好了 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{
    @Override
    public int calc(int x, int y) {return x + y;}
}

public class MinusStrategy implements Strategy{
    @Override
    public 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。但光从代码量来看，复杂度也明显增加。回到咱们原始的需要上来看，如果咱们只是须要实现两个整数的加减乘除，这显著适度设计了。

集体总结适度设计有两大害处，首先就是后期的设计和开发的老本问题。适度设计的计划，首先设计的过程就须要投入额定的工夫老本，其次越简单的计划实现老本也就越高、耗时越长，如果是在疾速迭代的业务中，这些可能都会决定到业务的生死。其次即使是代码失常上线后，其复杂度也会导致前期的保护老本高，比方当你想将这些代码交接给他人时，他人也须要付出额定的学习老本。

如果老本问题你都能够承受，接下来这个问题可能影响更大，那就是 适度设计可能会影响到代码的灵活性 ，这点听起来和做设计的目标有些矛盾，做设计不就是为了晋升代码的灵活性和扩展性吗！ 实际上很多适度设计的计划搞错了扩大点，导致该灵便的中央不灵便，不该灵便的中央瞎灵便。在机器学习畛域，有个术语叫做“过拟合”，指的是算法模型在测试数据上体现完满，但在更宽泛的数据上体现十分差，模式短少通用性。适度设计也会呈现相似的景象，就是 短少通用性，在面对稍有差别的需要上时可能就须要伤筋动骨级别的革新了。

既然适度设计有着老本高和欠灵便的问题，那如何防止适度设计呢！我这里总结了几个办法，心愿能够帮到大家。

在设计的过程中，要确保充沛了解了真正的问题是什么，明确真正的需要是什么，这样才能够防止做出谬误的设计。

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

不要一开始就想着做出完满的计划，很多时候优良的计划不是设计进去的，而是逐步演变进去的，一点点优化已有的设计方案比一开始就设计出一个完满的计划容易得多。

如果你不确定本人的计划是不是适度设计了，能够征询下其他人的，尤其是比拟资深的人，穿插验证能够疾速让你确认问题。

其实在业务的疾速迭代之下，很难断定以后的设计是欠设计还是适度设计，你以后设计了一个简略的计划，将来可能无奈适应更简单的业务需要，但如果你以后设计了一个简单的计划，有可能会浪费时间……。在面对相似这种不确定性的时候，我集体还是比拟推崇大道至简的哲学，以后用最简略的计划，等须要复杂性扩大的时候再去重构代码。

关于设计:聊一聊过度设计

什么是适度设计？

适度设计的害处

如何防止适度设计

充沛了解问题自身

放弃简略

小步快跑

征求其他人的意见

总结