网站建设公司创业计划书,服务器代理,中国人去菲律宾做网站赌钱会抓吗,游戏代理0加盟费文章目录什么是过度设计#xff1f;过度设计的坏处如何避免过度设计充分理解问题本身保持简单小步快跑征求其他人的意见总结新手程序员在做设计时#xff0c;因为缺乏经验#xff0c;很容易写出欠设计的代码#xff0c;但有一些经验的程序员#xff0c;尤其是在刚学习过设…
文章目录什么是过度设计过度设计的坏处如何避免过度设计充分理解问题本身保持简单小步快跑征求其他人的意见总结新手程序员在做设计时因为缺乏经验很容易写出欠设计的代码但有一些经验的程序员尤其是在刚学习过设计模式之后很容易写出过度设计的代码而这种代码比新手程序员的代码更可怕过度设计的代码不仅写出来时的成本很高后续维护的成本也高。因为相对于毫无设计的代码过度设计的代码有比较高的理解成本。说这么多到底什么是过度设计什么是过度设计 为了解释清楚我这里用个类比假如你想拧一颗螺丝正常的解决方案是找一把螺丝刀这很合理对吧。 但是有些人就想“我就要一个不止能拧螺丝的工具我想要一个可以干各种事的工具”于是就花大价钱搞了把瑞士军刀。在你解决“拧螺丝”问题的时候重心早已从解决问题转变为搞一个工具这就是过度设计。 再举个更技术的例子假设你出去面试面试官让你写一个程序可以实现两个数的加减乘除方法出入参都给你提供好了 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。 但光从代码量来看复杂度也明显增加。回到我们原始的需求上来看如果我们只是需要实现两个整数的加减乘除这明显过度设计了。
过度设计的坏处 个人总结过度设计有两大坏处首先就是前期的设计和开发的成本问题。过度设计的方案首先设计的过程就需要投入额外的时间成本其次越复杂的方案实现成本也就越高、耗时越长如果是在快速迭代的业务中这些可能都会决定到业务的生死。其次即便是代码正常上线后其复杂度也会导致后期的维护成本高比如当你想将这些代码交接给别人时别人也需要付出额外的学习成本。 如果成本问题你都可以接受接下来这个问题可能影响更大那就是过度设计可能会影响到代码的灵活性这点听起来和做设计的目的有些矛盾做设计不就是为了提升代码的灵活性和扩展性吗实际上很多过度设计的方案搞错了扩展点导致该灵活的地方不灵活不该灵活的地方瞎灵活。在机器学习领域有个术语叫做“过拟合”指的是算法模型在测试数据上表现完美但在更广泛的数据上表现非常差模式缺少通用性。 过度设计也会出现类似的现象就是缺少通用性在面对稍有差异的需求上时可能就需要伤筋动骨级别的改造了。
如何避免过度设计 既然过度设计有着成本高和欠灵活的问题那如何避免过度设计呢我这里总结了几个方法希望可以帮到大家。
充分理解问题本身 在设计的过程中要确保充分理解了真正的问题是什么明确真正的需求是什么这样才可以避免做出错误的设计。
保持简单 过度设计毫无例外都是复杂的设计很多时候未来有诸多的不确定性如果过早的针对某个不确定的问题做出方案很可能就白做了等遇到真正问题的时候再去解决问题就行。
小步快跑 不要一开始就想着做出完美的方案很多时候优秀的方案不是设计出来的而是逐渐演变出来的一点点优化已有的设计方案比一开始就设计出一个完美的方案容易得多。
征求其他人的意见 如果你不确定自己的方案是不是过度设计了可以咨询下其他人的尤其是比较资深的人交叉验证可以快速让你确认问题。
总结 其实在业务的快速迭代之下很难判定当前的设计是欠设计还是过度设计你当前设计了一个简单的方案未来可能无法适应更复杂的业务需求但如果你当前设计了一个复杂的方案有可能会浪费时间……。 在面对类似这种不确定性的时候我个人还是比较推崇大道至简的哲学当前用最简单的方案等需要复杂性扩展的时候再去重构代码。
