为什么有的程序员能把很简单的业务逻辑抽象成超级复杂的系统

楼上那些调侃 Java 的我也是醉了，人不行关语言鸟事，我就不信这帮鸟人写 PHP 、go 什么的就不会写出花来。

PS：我认为觉得 Java 不行的人，也就半瓶子醋了。不接受反驳，要杠就是你对。

大部分是喜欢那种考虑周全给未来留余量的程序员。如果拍板人斩钉截铁地说，就这么一把梭了，别想太多，有问题我负责，那是最好了。大家都可以松一口气。但也不排除也某些程序员真的爱表现他的经验

过度设计嘛，你问就是万一这里要改，要加 xxxx 怎么办，实际上大部分并不通用，而且 80%一辈子也不用改

我不自觉的就会过渡设计，就怕以后要用上，现实是往往都用不上，因为业务上不来，但是如果你设计简单了就像脚本，虽然快，一旦需求改了，你是重构还是继续➕屎呢？重构就是要时间，别问问就是急明天就要。➕屎就是 if else ，虽然能用但是几个版本后自己也看不懂了，如果重构就要从产品出发重新整理在开始新的一轮。后来就想先让产品先出个 0.1 0.2 0.3 版本，看看能不能带来效益，如果能就打算认真搞了，别一上来就是大的，全面的，除非这是有充足的时间预算能给到位的

说个暴论吧，臭写代码的谁愿意加系统复杂性？

还不是提需求指点江山那帮老板、产品，需求朝令夕改，每隔一段时间都有新想法，工期也是想一出是出。

接着负责代码的小组 leader 又是个没能力抗压的，就把需求囫囵推给大头兵。

然后呢？然后程序员也学精了啊，天天这么改系统谁受得了，那就把系统写得再抽象一点，啥啥都搞个抽象，配置化，为的就是防他一手日后再改。

您猜怎么着？老板和产品一看，哦哟，完成度还行，看来需求还能再提提！小李啊，咱们再加个 AI 知识库……

小李：看来系统还不够抽象，没法应对更灵活的需求！

最后系统设计的抽象程度，左脚踩右脚，螺旋上天……

@LevineChen 道理没毛病，承载就是要尽可能的预判。但是预判依据来自哪里呢，产品规划还是个人经验？

面向简历编程? 哈哈哈哈哈

除了#1 没人发出针对 java 的暴论，谢谢大家，看来大家都是正常开发者

一个月给你 3W 、5W ，不整点活哪能行

楼下勿跟，骗金币的，具体案例也不说，纯情绪收割机

mvc? 你太 low 了。
https://mahmoudz.github.io/Porto

让接口变得:
1. 加速开发
2. 企业级可扩展性
3. 有组织的架构
4. 恶心人,找 bug 打开一堆文件(这才是我说)

你先说说具体情况吧？啥业务，你负责那一块，上来就开地图炮，你就是找认同来了是吧

一个 User Login 举例，一般语言也就 3-5 层封装
User Entity
User Dao
User Service
User Controller
上微服务的再加个接口类型定义


来自上古 XX 时代的传承，起手式就是
User Entity
User Repository
User Dao
User BO
UserLoginBO
User VO
User DTO
User Business
User ServiceInterface
User ServiceImpl
User Controller
PasswordEncoderProvider
PasswordEncoder
别问为什么，培训班都是这么教的，天量的存量代码也是这么写的，你要简化，就是挑战整个江湖。

@sagaxu

你们会把 Entity 返回吗。正常给前端的应该是 VO 没毛病

javaer：谁在叫我

这个功能要做成可配置化，方便将来用户提新需求
结果用户用都不去用

@sagaxu 这还好，我这个是把后端能处理的问题全放在前端供人欣赏

@karmaisbitch 业务自己都看不懂为啥要有这个功能，反正每步代码都给个前端接口就是了，也没什么技术含量

简单的业务抽象成复杂但易于维护和易于扩展的叫能力
单纯复杂叫渣渣

@pureGirl #10 搞了半天是说产品。。你能不能表述清楚