新手程序员在做规划时，因为缺乏经验，很简略写出欠规划的代码，但有一些经验的程序员，尤其是在刚学习过规划形式之后，很简略写出过度规划的代码，而这种代码比新手程序员的代码更可怕，过度规划的代码不仅写出来时的本钱很高，后续保护的本钱也高。因为相对于毫无规划的代码，过度规划的代码有比较高的了解本钱。说这么多，到底什么是过度规划？
什么是过度规划？
为了解说清楚，我这儿用个类比，假如你想拧一颗螺丝，正常的解决计划是找一把螺丝刀，这很合理对吧。 可是有些人就想：“我就要一个不止能拧螺丝的东西，我想要一个能够干各种事的东西！”，于是就花大价钱搞了把瑞士军刀。在你解决“拧螺丝”问题的时分，重心早已从解决问题转变为搞一个东西，这便是过度规划。
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。 但光从代码量来看，杂乱度也明显增加。回到我们原始的需求上来看，假如我们仅仅需求完成两个整数的加减乘除，这明显过度规划了。
过度规划的坏处
个人总结过度规划有两大坏处，首先便是前期的规划和开发的本钱问题。过度规划的计划，首先规划的进程就需求投入额定的时间本钱，其次越杂乱的计划完本钱钱也就越高、耗时越长，假如是在快速迭代的事务中，这些或许都会决议到事务的生死。其次即便是代码正常上线后，其杂乱度也会导致后期的保护本钱高，比方当你想将这些代码交接给他人时，他人也需求支付额定的学习本钱。
假如本钱问题你都能够承受，接下来这个问题或许影响更大，那便是过度规划或许会影响到代码的灵敏性，这点听起来和做规划的意图有些对立，做规划不便是为了提高代码的灵敏性和扩展性吗！实际上许多过度规划的计划搞错了扩展点，导致该灵敏的地方不灵敏，不该灵敏的地方瞎灵敏。在机器学习领域，有个术语叫做“过拟合”，指的是算法模型在测试数据上体现完美，但在更广泛的数据上体现十分差，形式短少通用性。 过度规划也会呈现相似的现象，便是短少通用性，在面临稍有差异的需求上时或许就需求伤筋动骨等级的改造了。
怎么避免过度规划
既然过度规划有着本钱高和欠灵敏的问题，那怎么避免过度规划呢！我这儿总结了几个办法，希望能够帮到我们。
充沛了解问题自身
在规划的进程中，要保证充沛了解了真正的问题是什么，明确真正的需求是什么，这样才能够避免做出过错的规划。
坚持简略
过度规划毫无例外都是杂乱的规划，许多时分未来有诸多的不确定性，假如过早的针对某个不确定的问题做出计划，很或许就白做了，等遇到真正问题的时分再去解决问题就行。
小步快跑
不要一开始就想着做出完美的计划，许多时分优秀的计划不是规划出来的，而是逐渐演变出来的，一点点优化已有的规划计划比一开始就规划出一个完美的计划简略得多。
寻求其他人的定见
假如你不确定自己的计划是不是过度规划了，能够咨询下其他人的，尤其是比较资深的人，交叉验证能够快速让你确认问题。
总结
其实在事务的快速迭代之下，很难判定当时的规划是欠规划仍是过度规划，你当时规划了一个简略的计划，未来或许无法习惯更杂乱的事务需求，但假如你当时规划了一个杂乱的计划，有或许会浪费时间……。 在面临相似这种不确定性的时分，我个人仍是比较推崇大道至简的哲学，当时用最简略的计划，等需求杂乱性扩展的时分再去重构代码。
