对于刚刚学完的设计模式,往往对应的工程师会出现两种情况,一种是过度设计,在编写代码之前,会花费很长的时间去做代码设计,开发过程中应用各种设计模式,应对未来的需求,但是实际上,未来的需求根本不会有,只是单纯的提高了代码的复杂度,以后所有的开发都要按这个复杂的设计基础上完成,或者就是设计的不足,怎么简单怎么来,写出来的代码能跑就行,顶多是个Demo,看似是KISS原则(保持简单)和YAGNI原则(不要过度设计),实际上忽略了很多设计环节,毫无扩展性可言,一点改动就牵扯了全身
那么,如何避免过度设计,如何避免设计不足?
1.设计的初衷是提高了代码的质量
初心,为何是初心,就是为什么干这件事,不管走多远,多少次迭代,都是为了干这一件事,那么使用设计模式也是如此,使用前问下自己,为何要这么做,是否能够真正的提高代码质量
如果自己很难讲的清楚,或者给出的理由很牵强,那么就不要用
实际上,设计原则和思想是心法,设计模式只是招式,掌握心法,以不变应万变,无招胜有招,设计思想和原则比设计模式更加通用
2.设计的过程是先有问题,后有方案
如果将代码看做产品,那么做产品的时候,思考用户的真正需求在哪里,而不是去凑需求,代码的设计也是如此,我们会首先分析代码的痛点,然后可读性不好,可扩展不好等等,然后针对性的利用设计模式去改善,而不是看到某个场景后,觉得跟之前设计模式很像,就直接套用上去
很多的新手,在学完设计模式的时候,往往是喜欢直接套用,不管青后皂白,而且写完后,看着自己的复杂代码,沾沾自喜,这就是炫技,再回头看自己当年的代码,会感觉到对自己的脸红,
所以我们不需要一开始就知道最终的设计,而是可以培养分析问题,解决问题的能力,在看到某段代码的时候,可以分析出好和不好的地方,如何改善的地方
3.设计的应用场景是复杂代码
很多的书籍中,介绍设计模式,都会拿一些简单的例子,但是这些简单的例子只是用于讲解,并不能照葫芦画瓢的应用到自己的项目之中,导致了过度设计
设计模式最大的用处是解耦,将一大坨代码拆分成为更小的类,从而满足了高内聚低耦合的也行,创建型就是将创建和使用解耦,结构型就是将不同的功能代码解耦,设计型模式就是了解决复杂化的代码问题
因此,对于复杂代码,我们就是,我们才需要大量的设计,越是复杂的代码,花在设计上时间越多
,不仅如此,每次提交的代码,都要保证代码的质量,经过足够的实践
但是对于简单的项目,就没有必要引入一些过于复杂的设计模式,将简单的问题复杂化
4.持续的重构
应用设计模式会提高代码的可扩展性,但是也会带来可读性的降低,所以我们为了避免错误的需求导致的过度设计,所以一般进行持续重构的开发方法,持续重构不仅仅是为了保证代码质量的重要手段,而且是避免过度设计的有效方式,再有痛点的情况下,再去看考虑使用设计模式,而不是一开始就是用设计模式
对于要不要使用某种设计模式,我们可以考虑下,如果不用这种设计模式,随着代码的演进,会不会有一天会使用它,重构的代码是否很大,能不用就不用了,怎么简单怎么来
5.为何出现设计不足
首先可以能是知识储备的不足,比如需要掌握各种设计原则,思想,编码规范,设计模式,如果这些不足的话,那么可能发挥不好
其次,有一些的可以训练,现在来说,很少看完了设计模式后去练手写一个,这就是问题所在
最后,要有代码的质量意识,设计意识
写代码之前,需要想想那些是需要扩展的需求,那些会变,哪些不会变,这样就是增强代码的质量最好途径
6.不要脱离实际的场景去谈设计
设计是一门艺术,而艺术是没法去具体的判定的,脱离了具体的场景去谈设计都是空谈,所以我们需要针对不同的场景去设计代码,如果我们开发的是偏底层的,框架的通用的代码,那么一定要设计好,谨慎,因为一旦出现了改动,影响面很大,而我们开发的是业务系统或者不需要长期维护的项目,放低一些代码的质量,也是可以的
课后思考:
在实际开发中,我认为 设计合适>过度设计>不进行设计,往往不进行设计的工程师,要么是没有了解过对应的知识,要么是对知识的不熟悉掌握,我个人也经常犯过度设计的毛病,但是我个人的观点是,如果学完了东西,尽可能的去尝试使用它,因为不使用它,那么可能一直就没有机会去使用,或者真正合适用的场景,也想不起来,不要畏惧自己的过度设计,因为没有过度设计的错误的铺垫,可能就永远没法设计出恰到好处的代码,没有人能一蹴而就,学习这条道路上都是踩着坑过来的