大家好，欢迎来到停止重构的频道。
本期，我们讨论一个比较开放的问题，代码越少真的代表开发效率越高吗？
也欢迎大家把自己的观点写在评论区。
我们的观点是：如果单从完成功能而言，确实所写的代码越少一般就是开发效率越高，很多工程师也在追求用更少的代码行数完成编程任务。
但是从一整个项目角度而言：在不胡乱写代码的前提下，代码越少可能会加大运维或升级成本。
这是为什么呢？我们按这样的顺序阐明我们的观点：
减少代码的一些例子
这些例子会造成什么样的结果
编好程和做好项目是两回事
减少代码的一些例子抛开框架和工具，减少代码一般就是提升自身代码的复用度，如抽离通用函数、合并逻辑等。
以前端为例，如果使用vue-cli等的话，可以实现组件无限极嵌套，也就是说，理论上每一个页面元素的代码都只需要写一次。
又比如以后端为例，抽离多层工具类。则能大大减少接口代码重复率，或者把几个接口合并为一个接口。
有一些工程师甚至喜欢把增删改合并为一个接口。
这些例子会造成什么样的结果代码复用度高的话确实有一种开发效率高的感觉，而且还略带一点极简美。
但是这都是对于写代码的人而言的，对于接手的人来说，这简直就是噩梦。
在发生需求变更或修改bug时，由于代码结构复杂，排查修改点位置的时间会非常长（特别对于接手人来说）。即使是开发者自己，过两个月也会忘得一干二净。
即使确定了修改点，由于代码高度复用，根本不清楚影响范围，往往就是改好一个bug出现10个新bug。
一些时候，也可以新建一个代码副本进行修改，但长此以往，会多出很多代码副本，以至于越维护升级越难。
更不要说有些工程师为了炫技，会使用一些生僻的语法和设计一些奇怪的代码机制了。
所以代码越少，一般意味着项目的运维升级成本就越高，项目越大参与人数越多越明显。
一些朋友可能会说，等平台、项目赚钱重构不就好了吗？软件只有不断重构才会越来越好，
这是无法完全否认的事实，但这并不是做不好的借口。而且应该没有哪个平台或团队愿意不断花钱做相同的事情。
编好程和做好项目是两回事从某方面讲：代码越少，可能说明工程师的经验、能力越强，但是对于项目而言往往是弊大于利的。
毕竟，会编程和会做项目是两回事，项目是一群人合作的，不仅项目人员技术水平参差不齐，而且项目人员更替是常有的事情。
如果一个新来的开发人员需要很长时间交接或理解，才能接手别人代码的话，那么往往整体软件质量都不会太好的。大家都干得很累，但最后结果却一般很糟糕。
总结所以不要一味追求更少代码或多层级封装，对于以上代码混乱的规整化问题，在往期我们已经提出了具体的解决方案。
包括前端、后端、数据库设计，有兴趣的朋友可以翻看。
后续我们也会在我们的