75 | 在实际的项目开发中，如何避免过度设计？又如何避免设计不足？

滥用设计模式真的是不如不用

在日常工作中, 设计不足是经常出现的事情. 毕竟不是每个人都学过设计模式, 理解设计模式, 能正确的应用设计模式. 不知道你们怎么样, 我相处过的同事, 大多不懂或对设计模式一知半解. 包括我自己, 没系统学习本专栏前对设计模式的理解是非常浅薄的. 我认为理解设计思想, 学习设计模式任重道远. 试想, 你的团队协作成员全部具有设计意识, 不仅写出的代码健壮性强, 可读性, 可维护性好, 日常沟通效率也大大提升(加班还是要加班的, 效率高了加班摸鱼或者看书总比写业务强吧). 至于过度设计的问题, 新手难免会犯. 就像学习穿衣搭配一样, 不花个万八千买衣服扔衣服, 就永远学不会. 个人对于过度设计的看法就是多写多总结并持续重构. 过度设计并不是一件不可饶恕的事情, 只要有设计意识, 总有一天新手也会成长为高手, 过度设计的问题也就自然解决了.

往往只有过度设计之后才能学会适度设计

1.回答这两个问题。在该有的知识都具备的情况下。其实是在问，你的初心是什么。 2.如果你的初心是“保证项目持续迭代的效率”，或者说保证项目架构的持续优异。那么快速的先落地需求+持续重构会是主色调。这种模式下，落地需求不会有太多的过度设计，设计不足也能在持续重构中被摆正。但是，这非个人的事情，需要团队甚至整个公司的共同支持与认可。 3.如果你的初心是“写出高质量代码”。那么过度设计在所难免。可是，这问题很大吗？实际工作中，不会有人有时间一直去揣摩你的代码。而真要阅读你的代码，一般也是能看懂的。所以对团队的影响其实还是比较有限的，但对自己的认知和成长是有好处的。这么玩并不为过，重要的是保持谦逊，因为这个时候写的代码更多是实践知识点，缺少平衡架构合理和需求场景时的抉择，硬拿经典用例或伪需求来强调自己牛逼就有点令人生厌了。

在实际开发中,我认为 设计合适>过度设计>不进行设计,往往不进行设计的工程师,要么是没有了解过对应的知识,要么是对知识的不熟悉掌握,我个人也经常犯过度设计的毛病,但是我个人的观点是,如果学完了东西,尽可能的去尝试使用它,因为不使用它,那么可能一直就没有机会去使用,或者真正合适用的场景,也想不起来,不要畏惧自己的过度设计,因为没有过度设计的错误的铺垫,可能就永远没法设计出恰到好处的代码,没有人能一蹴而就,学习这条道路上都是踩着坑过来的

打卡 持续重构真的很重要 我现在看自己去年的代码都看不下去 相信明年的我看今年重构后的代码也看不下去

其实，当前遇到的大多是设计不足，而不是过度设计，毕竟过度设计是在追求高质量代码的路上，而大部分设计不足是对代码没有高追求。

争哥的课真的是满满干货，精髓就在于这对于设计思想的讲解，非常接地气。

对于这个问题，我发现有些开发人员是一个矛盾体，他们学习了新技术，为了练手，就往代码中硬套，不管是否适合。还有的把使用新技术当做成就（炫技）。这样的系统，不统一，不规范。谁维护谁头疼。 另外，当需要在系统中添加新功能的时候，当系统出现不易维护的时候，他们又偷懒，只是在系统上打补丁应付过去。此时正是需要好好分析，设计，重构的时机，他们白白的浪费机会。他们节省的时间又去学习新技术，然后又在系统中练手。他们学习的主要目的是为了应试，或者为了炫技。不关心代码质量和系统的健壮。 有些人学习JVM，但是当系统中CPU，内存异常，吞吐量降低，RT变高的时候，他们躲在一边生怕你让他去解决。 有些人学习Mysql，但是当出现慢查询，DB报警的时候，他们躲在一边生怕你让他去解决。

工作中有些同学真的是很喜欢过度设计。命名很简单的业务逻辑，非得去写好几层继承；结果看代码得不断跳，不断找，修改起来也是非常的累。。不懂的人，还会夸说写出这种代码厉害，，我也真是醉了。。