作为一个写了8-9年的CRUD工程师，写了不知道多少的业务代码，有一些心得和困惑。
在我们实际的牛马搬砖过程中，大部分是在非常成熟，生态非常庞大的框架下写业务代码，比如springboot 等等。
设计模式，这个影响深远的编程思想，而实际的等等确实用的少，有时候如果刻意用，还会影响代码的可阅读性和可维护性。
一直说面相对象编程，但是实际生产中，却编程了面向过程编程，因为框架已经大部分给你做好了，如果强行加对象，有可能还会带来冗余对象的产生，进而影响内存。面向过程编程，那么就只能修炼 如何更好的封装方法，如果更好的写好注释！
不知道大家有没有同感~~！
我感觉是看你怎么写代码 如果代码能跑业务能实现 后面的事情后面说 那你说的是对的 面向对象和设计模式都是累赘 但你的要求入股是代码别人能看懂 后续会扩展或者重构 那面向对象和设计模式是非常有用的 人月神话这本书说的就是些问题。 个人浅显理解。。。
到不是觉得设计模式累赘，而是觉得在框架加持的业务代码，着实不好套用。反而自己在开发新工具，或者写一些自定义的小轮子的时候确实好用
得看业务的迭代频率了。
如果不需要更新那确实面向过程比较方便，但是面对需要一直迭代或者扩展的业务，选择合适的设计模式/面向对象还是挺有必要的。
我对这些理解比较简单,首先大家都是按照最简单的方式去实现. 然后逐渐发现了问题. 在没有发现问题的前提下怎么去设计和避免问题都比较空.
设计模式是为了解决软件设计中反复出现的问题，提供经过验证的通用解决方案。 在每次做的时候进行考虑和调整.
现在一面要求“快”,另一面要求“好” 这本质上也会让技术还没沉淀就开始“飘”了.
整体看需要一个团队对这些东西的理解和自己手上项目的考虑衡量.
这让我想到 道与术 有道无术，术尚可求也。有术无道，止于术。
没有完美的方案和方法去“抄”,结合自己的团队进行理解去发展会比较落地.
确实，互联网公司都要求敏捷，好多时候改成设计模式就变成了迭代二期的事情，一期根本没时间考虑这个
是的,我也是一直在工作中感受到不友好的就是快的代价没人去处理了. 我们可以先快,后面还债的时间在哪里.