 |
1
zhujinliang 1 天前 via iPhone  43
你是说 Java 程序员吗
|
 |
2
shunia 1 天前 4
能抽象的人一般不会把它搞复杂，会把它搞复杂的人显然没做好抽象
|
 |
3
phreej2voo 1 天前
抽象化解耦侬晓得伐
|
 |
4
yh7gdiaYW 1 天前
简单的逻辑，你要真的简单写了那后面改起来就是屎山代码
但另一方面，不是所有的业务都需要考虑后面的维护 |
 |
5
X0V0X 1 天前 35
人和代码有一个抽象就行
|
 |
6
x86 1 天前 1
做销售的潜力
|
 |
7
pureGirl OP @zhujinliang 是的！
|
 |
8
fredweili 1 天前
现在很简单，将来呢？改需求就一句话，改代码就是大麻烦
|
 |
9
lyusantu 1 天前
设计模式的功劳
|
 |
11
shen13176101 1 天前
屎山代码怎么来的。
|
 |
12
iosyyy 1 天前 1
这不是产品的问题吗 楼里这些人一上来就搞抽象给人的感觉就是没干过活
|
|
13
shen13176101 1 天前
@pureGirl #10 你说的是项目经理提的需求，程序员只是按照 需求开发
|
 |
14
LevineChen 1 天前 4
用最小的复杂度承载最大的可能性, 称之为优雅. 很显然大部分人没这个能力
|
 |
15
woodfizky 1 天前 9
没有具体需求和场景就抛出来这么一句话，那我不好评价。
能力不够的产品/管理对接过，被坑过就知道了。 这帮人做需求分析和功能设计的能力对这个岗位来是都是严重低下的，他们的不作为和浅薄的理解最终会导致程序员的工作量大大增加，甚至反过来得帮产品整理分析需求。这其中还有很多是无效工作。 当然如果你也是程序员，你只是在吐槽平级程序员在做多余的事情，那当我没说。 |
 |
16
Rorysky 1 天前
抄的模板
或者 想的极端情况太多 |
 |
17
yunlongV 1 天前
之前做一个问卷调查，单/多选题后端要求把问题，用户选择的答案和该题的所有选项传给他，而不是传任何和 ID 有关的东西..我至今不明白为什么..
|
 |
18
fu82581983 1 天前
因为一部分人就是会把简单事情复杂化，或者照搬不加思考
|
 |
20
iorilu 1 天前
很多都是提前考虑的太多
所谓做的通用化, 配置化 实际上根本不需要 |
 |
21
pkoukk 1 天前
抄的模板不适合当前业务，他懒得改，或者项目没给够他时间改
（这事我也干过 |
 |
22
AlexHsu 1 天前 2
一些程序员 特别是某个大厂出来的程序员 特别会做假设性思考 写个破工具类也考虑扩展性 构建个百十来人的系统也考虑微服务化
|
 |
23
kidult 1 天前
想简单用下火山平台的 DS api ,活生生进去四五回才找到配置
|
 |
24
itskingname 1 天前
两种可能：
1. 这个人是 Java 程序员，嘴里经常有这样几个关键词『后期』、『后续』『以后』，所以什么东西都过度设计。 2. 这个人之前机缘巧合进了一个大厂，看到了大厂的复杂系统。后来出来以后，在新公司，根本不考虑实际情况，就只知道照搬大厂的架构。 |
|
25
AlexHsu 1 天前 2
之前有一句话叫 优秀的程序员单行道过马路也要左右看
现在是某一些程序员 单行道过马路看要先盖天桥保证绝对安全 盖天桥要保证以后不影响挖隧道和地铁站 |
 |
26
jrtzxh020 1 天前
是的，我司就是。有时一个简单功能，能开会讨论几天。现在只有几个人，OA 流程复杂得一比，有的人一个流程要过两三遍。所以从巅峰二三百人堕落到剩十多个人，估计还会裁员。。
|
 |
27
llsquaer 1 天前
看别人项目得来回几次。 当然也有很多划分很不错的直接就明白意图了。
哪些不清晰的，这一个定义，哪里一个定义，然后元类。 所谓的组织化。。。哎 |
 |
28
wangtian2020 1 天前
老东西思维固化，写半辈子 jquery 出来的人换其他框架也去不掉一不小心把简单的事写复杂
|
 |
29
zhangeric 1 天前
就是想偷懒,想搞复用,所以搞得很复杂.
|
 |
31
adoal 1 天前
看到 OP 在#10 里补充说的，我感觉他吐槽的可能不是大多数回复所理解的意思。
|
 |
33
mumbler 1 天前
培训班就这样教的
|
 |
34
levelworm 1 天前 via Android
一般要么是想得太多了，上来就搭框架，要不就是经验不足，没考虑一些多少会碰到的情况，碰到了就只好用浆糊糊上去，多几次就是这样了。
|
 |
35
CodersZzz 1 天前
这就是自研产品和外包的区别了。自研产品考虑的比较多，扩展性要强，虽然当下看上去导致代码复杂，但是当有后续扩展时逻辑才更清晰
|
 |
36
jasontsai 1 天前
你到底说的是架构还是产品，为什么有的人连简单的问题都表达不清呢
|
 |
37
somebody1 1 天前
|
 |
38
liqingyou2093 1 天前
这种人一般都是想到啥就说啥，其实本身并没有对整个业务进行了全流程的了解
|
 |
39
shintendo 1 天前
你说的前台到底是指什么
|
 |
40
MozzieW 1 天前
骗金币的，发了一堆没意义帖子，送你了
|
 |
41
xuanbg 1 天前 1
楼上那些调侃 Java 的我也是醉了，人不行关语言鸟事，我就不信这帮鸟人写 PHP 、go 什么的就不会写出花来。
PS：我认为觉得 Java 不行的人，也就半瓶子醋了。不接受反驳，要杠就是你对。 |
 |
42
me1onsoda 1 天前
大部分是喜欢那种考虑周全给未来留余量的程序员。如果拍板人斩钉截铁地说，就这么一把梭了，别想太多，有问题我负责，那是最好了。大家都可以松一口气。但也不排除也某些程序员真的爱表现他的经验
|
 |
43
1402851639 1 天前 via Android
过度设计嘛，你问就是万一这里要改，要加 xxxx 怎么办，实际上大部分并不通用，而且 80%一辈子也不用改
|
 |
44
zxkxhnqwe123 1 天前
我不自觉的就会过渡设计，就怕以后要用上，现实是往往都用不上，因为业务上不来，但是如果你设计简单了就像脚本，虽然快，一旦需求改了，你是重构还是继续➕屎呢？重构就是要时间，别问问就是急明天就要。➕屎就是 if else ，虽然能用但是几个版本后自己也看不懂了，如果重构就要从产品出发重新整理在开始新的一轮。后来就想先让产品先出个 0.1 0.2 0.3 版本，看看能不能带来效益，如果能就打算认真搞了，别一上来就是大的，全面的，除非这是有充足的时间预算能给到位的
 |
 |
45
lzgshsj 1 天前
说个暴论吧，臭写代码的谁愿意加系统复杂性？
还不是提需求指点江山那帮老板、产品，需求朝令夕改，每隔一段时间都有新想法，工期也是想一出是出。 接着负责代码的小组 leader 又是个没能力抗压的，就把需求囫囵推给大头兵。 然后呢？然后程序员也学精了啊，天天这么改系统谁受得了，那就把系统写得再抽象一点，啥啥都搞个抽象，配置化，为的就是防他一手日后再改。 您猜怎么着？老板和产品一看，哦哟，完成度还行，看来需求还能再提提！小李啊，咱们再加个 AI 知识库…… 小李：看来系统还不够抽象，没法应对更灵活的需求！ 最后系统设计的抽象程度，左脚踩右脚，螺旋上天…… |
 |
46
Ryanel 1 天前
@LevineChen 道理没毛病，承载就是要尽可能的预判。但是预判依据来自哪里呢，产品规划还是个人经验？
|
 |
47
kakki 1 天前
面向简历编程? 哈哈哈哈哈
|
 |
48
Meld 1 天前 1
除了#1 没人发出针对 java 的暴论，谢谢大家，看来大家都是正常开发者
|
 |
49
holdeer 1 天前
一个月给你 3W 、5W ，不整点活哪能行
|
 |
50
NewMoorj 1 天前 via Android 2
楼下勿跟，骗金币的，具体案例也不说，纯情绪收割机
|
 |
51
lyxxxh2 1 天前
mvc? 你太 low 了。
https://mahmoudz.github.io/Porto 让接口变得: 1. 加速开发 2. 企业级可扩展性 3. 有组织的架构 4. 恶心人,找 bug 打开一堆文件(这才是我说) |
 |
52
magicZ 1 天前
你先说说具体情况吧？啥业务，你负责那一块，上来就开地图炮，你就是找认同来了是吧
|
 |
53
sagaxu 1 天前 5
一个 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 别问为什么，培训班都是这么教的，天量的存量代码也是这么写的，你要简化，就是挑战整个江湖。 |
 |
55
kxg3030 1 天前
javaer：谁在叫我
|
 |
56
karmaisbitch 1 天前
这个功能要做成可配置化，方便将来用户提新需求
结果用户用都不去用 |
|
58
pureGirl OP @karmaisbitch 业务自己都看不懂为啥要有这个功能，反正每步代码都给个前端接口就是了，也没什么技术含量
|
 |
59
Yanlongli 1 天前
简单的业务抽象成复杂但易于维护和易于扩展的叫能力
单纯复杂叫渣渣 |
 |
61
bytecc 1 天前
要扩展啊，你以为就搞一下
|
 |
62
Lockroach 1 天前
除非很明确后期不会再增加需求，不然随着需求堆上来前期简单的功能都会变成庞然大物
|
 |
65
lawrencelee 1 天前
@pureGirl 你们没产品吗？
|
 |
66
FlorentinoAriza 1 天前
你也知道我做的积分系统被别人分散到各个莫名其妙的菜单了？
|
 |
67
kristofer 1 天前
咋说呢，你得举出例子啊，或者脱敏下，拿出个具体场景。现在你只是在输出情绪而已，然后一大堆人还在虚空打靶。
|
 |
68
felixcode 1 天前 via Android
请帮我做个简单的输入框，输入文本后能显示网上的热门网页链接的搜索结果就行，不需要太复杂
|
|
69
pureGirl OP @lawrencelee 这个项目没有产品
|
 |
70
wangsd 1 天前
提前想太多，后面项目会不会继续演进下去还是个未知数，平白增加维护难度那是真的。
|
 |
71
8355 1 天前 1
@zhujinliang 用 Spring 的魔法召唤出十二层抽象工厂，最后在二十个分包里种下九种设计模式
|
 |
72
yolee599 1 天前 via Android
过度设计，即使只有一个实现也要把弄成接口。
|
 |
74
NotLongNil 1 天前
是不是都是 DDD 的概念？中文程序员的圈子唯一的架构圣经-DDD 。要让自己的代码看上去高大上，不就得引进 DDD ，才能叫架构
|
|
75
NotLongNil 1 天前
把复杂的事情变简单是件难事。把简单的事变复杂，是非常容易的事。
|
 |
76
fengzl 1 天前
互联网不就是把简单的名词抽象不说人话显得高大上吗
|
 |
77
xiangbohua 1 天前
这个就是设计带来的问题吧，说复杂也有两种可能，一个是你菜确实看不懂别人优秀设计，二一种就是过度设计了。这个平衡不是很好把握，而且不同人看有不同的观点，你看觉得复杂换个人觉得设计的不错。
如果直接写有该有人说：把 ifelse 给我去掉！ |
 |
78
roundgis 1 天前 via Android
写业务框架需要一些抽象
|
 |
79
sn0wdr1am 1 天前
因为老板和产品的脑洞大开，程序员尽可能去维持扩展性，导致过度设计。
|
 |
80
ooee2016 1 天前
因为你看到的要处理的业务是今天的，但是这可能是从 4 年前就有的功能，一直在变更的。
|
 |
82
ooo4 23 小时 44 分钟前 1
|
 |
84
james122333 23 小时 43 分钟前 via Android
|
 |
85
nomagick 23 小时 37 分钟前
Level1: 不承认存在复杂的系统，一切都应该是简单的
Level2: 认识到系统的复杂性，一切都应该是复杂的，不存在简单 Level3: 封装复杂系统，暴露的 API 是简单而有体系的，把复杂留给自己，简单留给外包 |
 |
86
gzldc 23 小时 34 分钟前
工作这么多年 我觉得这是一种很不错的能力。
|
|
87
james122333 23 小时 29 分钟前 via Android
|
 |
88
kissice 23 小时 23 分钟前
三个字：被逼的。
因为没有话语权，就算你想也没法做简单，参考某支付软件里面塞小视频小游戏。 |
 |
89
dudubaba 23 小时 16 分钟前
这个就是过度设计，美其名曰“利于扩展”，但是绝大部分都是一次性代码，就算你写的再牛逼，下一位也是在上面堆屎山。
|
 |
90
jiangzm 23 小时 10 分钟前
没有具体案例光一句话 博主的这个吐槽是成立的。
那到底是多简单的业务呢 又设计成多复杂的系统呢？ 是博主理解能力问题吗， 还是后台故意把简单问题复杂化？ |
 |
91
mcluyu 22 小时 55 分钟前
有的人就是很擅长把简单的事情复杂化, 思考问题的方式就是越想越多, 怎么复杂怎么来, 而不是把问题简单化.
当然具体情况要具体分析, 但我说的就是那些看到女的胳膊就能一下想到跟她生了几个孩子的傻叉, 明明就是搭个帐篷, 他非要先挖几十米的地基,还美名其曰 架构、可扩展性。。。。 |
 |
92
leconio 22 小时 46 分钟前 via iPhone
不解偶容易改错东西，新手可能改一个符号，引起整片问题。解偶后同时员工也容易替代
|
 |
93
zhybb2010 22 小时 41 分钟前
OP 描述太过空洞。同等经验下，如果你有这种认知，那么大概你是正确的；但是如果对方经验远超于你，这部分的设计可能是超出你的认知了，OP 可能是正确的；反之，你是正确的。
|
 |
94
Essaim 22 小时 38 分钟前
说这话的时候有考虑过产品不不接受以后砍需求吗? 本来过度设计就是迎合国内极度业务驱动的产物.你永远不知道产品要改哪里.
|
 |
96
lesismal 21 小时 58 分钟前
特意赶来给一楼点赞
|
 |
98
sxms77777 21 小时 34 分钟前
初级程序员到高级的转变中会有个很尴尬的时期。就是学了很多设计思想，框架，工具，但是实际项目经验有限。这就会导致无法区分什么时候应该抽象到什么程度，导致过度设计。
当然，还有些程序员会永远停留在这个阶段。 |
 |
99
Rust2015 21 小时 27 分钟前
看源码要看设计
写代码要看需求 |
 |
100
jojofunc 21 小时 24 分钟前
简单是不是就是一句话需求? 然后多问几个细节就说别人复杂化了
|
Select Language