作者chal ( )
看板Soft_Job
标题Re: [请益] 痾 遇到这种事情 是不是需要赶快离职了?
时间Wed Jul 24 20:27:43 2024
我个人感觉程式语言也是有语感的
跟学历关系不大
我自己碰过一种写法
if 变数 == a print 甲.jpg
if 变数 == b print 乙.jpg
if 变数 == c print 丙.jpg
看来逻辑没问题
但其实这段 if else 根本就不需要
你只要改成
print 变数.jpg
就可以了
这样写 还可以未来扩充都不用修改
另外还有很多类似的例子
但其实一堆可以在业界完成工作的工程师
都没办法发现那样写的问题
他们只想完成工作与逻辑
但也有可能是我没在更高阶的程式环境
其实很多设计模式与多形
在我看来都是为了消除if else
例如依赖反转与依赖注入 都可以减少if else
应该视 if else 为恶魔
时时想着要怎麽消除 if else
久了就会有进阶的处理方式
我记得很久以前
可能有二十年前了
有人曾经说他一小时内可以写几千行程式来显示自己很会写
那像我这样一直思考如何减少 if 程式码的人
不就反而是他眼中很不会写的人
台湾不是软体为主的经济体
当老板的人不见得是专业的工程师出身
以老板角度来说
不管怎麽写 逻辑对都没差
我还遇过一个老板直接叫我直接加一个if 以减少工时
後来几年後 那个项目就倒了
被同行说是烂到业界出名的产品
那个老板也懂一点程式 所以反而更糟糕
这现象可能无解
他们还是能完成工作
就只能加强沟通与教育
然後做好自己的工作
拿出成果让他们知道为什麽要这样改
去其他公司 这种人还是不少
另外这跟你待在甲方乙方也有关系
有公司会找乙方来写
代表这不是他们的核心业务
代表他们是为了求快才找乙方
所以你帮他写得比较好有意义吗
花时间写得比较好
但对他们来说快速比较重要
某 funcation 有 95% 一样
但你为了让程式变好 共用
决心想去搞懂那 5% 的不同
这其实有风险
你要很懂系统 也要有完整的测试案例
其实会花更多时间
搞不好还会弄坏别人的功能
在乙方速度就是一切
因为台湾人找乙方就是为了快
我甚至认为理想的程式宇宙
不应该有乙方这种产业存在
但我也知道 现实社会就是有乙方需求
或许乙方应该一家独大 极大化
大到可以要甲方乖乖听话 慢慢写
我知道这里高手很多
但也明显有一些新人上来问问题
所以也就讲一下很基本的经验
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.235.109.212 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1721824065.A.9E6.html
1F：推 shieldsky: 但我觉得为了要弄懂那5%而改成共用函式，对於工作者本 07/24 20:43
2F：→ shieldsky: 身的能力提升有帮助，当然也需要完整测试避免弄坏已经 07/24 20:43
3F：→ shieldsky: 写好的功能。 07/24 20:43
如果是未来还要维护 去搞懂就有意义
但乙方大部份写完 专案就结束了 有时只是去救急
搞懂对你来说只是奇怪的知识增加了
有时候你会觉得你多花时间帮忙写好一点是为他们好
但更多时候他们只会觉得你写得比较慢
我曾经写过一个功能 为了可以共用所以多花一点时间
那支共用可以节省专案一年的时间
但多花了几星期将不同处改成设定档用设定的
但甲方才不管这个 你帮他们省了一年时间
他们只觉得你一个案例多花了几星期去写
然後去沟通也没意义 你又不是甲方的人
让甲方觉得你有贡献也拿不到什麽实质的奖励
你也不会想待在那种甲方
所以写完就算了 被念就被念 也过了
乙方真的是一个很奇妙的经历
但是重来就算会被念 我还是会写共用 + 设定档
因为实在太蠢了 明明是同一种逻辑
受不了复制贴上
写好後 我根本是悠闲的完成类似需求
调调设定档就好
整个团队十几人都没人想去做共用
应该不是没人发现可以共用
而是某种文化正在形成
4F：→ abccbaandy: 研究垃圾有啥帮助... 07/24 20:51
5F：推 NDark: a/b/c也是你事後才知道. 规格出现的时候可能根本没规格 07/24 20:52
我反而觉得这是照规格写才写成这样
因为写规格的人不见得会写程式
不会理解程式中的有变数观念
所以他们写规格时很直观的想
如果是这样 就那样
如果是那样 就这样
但会写程式的人 因为有变数的观念
才会懂这根本不用加判断
6F：→ knives: 推楼上 07/24 21:05
7F：推 viper9709: a/b/c有可能临时要多一个d,而且不只是印东西 07/24 22:27
多一个d ，就上传一张 d.jpg 的图片 就解决了
完全不用动到程式
如果不只是印东西 那就要改需求了
原来的写法也是要改
8F：→ wuyiulin: 同意一楼，但是实务上通常很多需求都是追加，除非是有 07/24 23:27
9F：→ wuyiulin: 经验工程师/做同类型的产品做多了知道要哪里留接口，不 07/24 23:27
10F：→ wuyiulin: 然消除 if else 是一个假议题。 07/24 23:27
完全消除当然不可能
但那是一种追求
11F：推 abc0922001: 我是不太喜欢if else 里面还有 if else 07/25 00:10
12F：→ Abbee: 看到这篇很有共感,为了把if else去掉,我在写规格书时,整理 07/25 01:01
13F：→ Abbee: 了原程式里的差异和共通处,花了不少时间写规格书,因为原程 07/25 01:01
14F：→ Abbee: 式每段几乎一样,但又有一点点不一样,看到眼都花了,若是照翻 07/25 01:02
15F：→ Abbee: 写新程式,只是一样都复制贴上,不用花什麽时间,但下次再加一 07/25 01:02
16F：→ Abbee: 项,又要改程式走上线流程,把不同提出来放设定档,都不用再上 07/25 01:03
17F：→ Abbee: 线,但这只有好到维护的人,开发的人才不管这麽多 07/25 01:03
18F：→ Abbee: 不是放设定档的,也能之後只要加dll,而不动原程式,但新手无 07/25 01:05
19F：→ Abbee: 法理解这样作哪里好 07/25 01:05
我先去的地方比较偏做自己产品
会想说 当初前人要是程式多加个什麽
也许多花几天
但今天程式就会好维护很多
要知道维护的时间远远大於开发
省一点开发时间 是造成维护的十倍时间
後来去要支援别人的部门（类乙方）
思考是完全不同的
帮别人想 在外界看来就是手脚慢
後来想通了
其实像function 95% 一样
这个就是维护的甲方要负责去调整的
这不是乙方的工作
除非你也要负责维护
※ 编辑: chal (36.235.109.212 台湾), 07/25/2024 01:45:56
20F：→ brucetu: 现在你只要在甲乙丙下面写 let filename剩下的copilot会 07/25 10:05
21F：→ brucetu: 帮你完成，存档测试搞定 07/25 10:05
22F：→ brucetu: 所以这种单纯的案例未来再重写不会花什麽时间 07/25 10:06
23F：推 CRPKT: IoC 与 DI 都不是为了消灭 if else 07/25 10:21
24F：嘘 DrTech: 这例子根本不考虑，变数出现 a,b,c以外的特例。实务上常 07/25 13:13
25F：→ DrTech: 常就是bug的来源。 07/25 13:13
26F：→ DrTech: 正常，有规模与品质的公司，测试部门的unit test就不会过 07/25 13:14
27F：→ DrTech: 了啦。 07/25 13:14
28F：→ abccbaandy: 推楼上，一堆工程师自以为优化，实际上业务逻辑=程式 07/25 13:32
29F：→ abccbaandy: 是最理想的状况，业务逻辑bug最常出现在这 07/25 13:33
30F：→ DrTech: 不要认为有什麽 标准答案，或银弹。还是要看实际业务场景 07/25 13:37
31F：→ DrTech: 来判断程式该怎麽写。此文已经假设，永远只有a,b,c三种数 07/25 13:37
32F：→ DrTech: 值，并不符合所有业务状况。太多实际状况，就是会出现a,b, 07/25 13:37
33F：→ DrTech: c以外的数值，让你程式品质无法预期。 07/25 13:37
34F：→ DrTech: 这时候用else，真的比较好保证程式品质。 07/25 13:38
35F：→ DrTech: 万一a,b,c以外的状况有无限扩充，难以设条件，难道要不断 07/25 13:41
36F：→ DrTech: 写if？用else真的没那麽糟糕。 07/25 13:41
37F：推 viper9709: 推楼上 07/25 16:34
38F：推 anandydy529: 第一种写法至少有个else知道有不符合abc的条件 07/25 16:53
39F：→ anandydy529: 第二种写法运气不好直接喷一个NPE让你加班Hotfix 07/25 16:54
40F：→ anandydy529: 但不是说第二种写法不好，要先了解专案的历史再决定 07/25 16:56
41F：推 akito117: 同意楼上，要考虑abc以外的情况，至少要有个报错或防呆 07/25 18:44
其实这个需求很简单
就是先由系统提供选项a/b/c
系统再根据user的选择 显示 其选择
大家所担心的例外与其他
会处理 但不会在这里处理
一开始就给拒绝了
未来系统也可能新增d/e/f 选项
当然系统也要因此要做一些改动
但至少显示的这个功能 可以不用动
只要上传d.jpg e.jpg f.jgp 即可
其实我也不是在讲什麽银弹
我只是说 有很多地方的if else 根本没必要
以这个真实遇到的情况来说
其实就是图档名称与变数名称不同所造成的
所以只要顺手把图档名称改成与变数一样
那些if else就可以消除
※ 编辑: chal (36.235.109.212 台湾), 07/25/2024 21:54:47
42F：→ lazarus1121: 一般的写法是if a else b else c else Exception 07/26 07:50
43F：→ lazarus1121: 因为你先知道abc和jpg对应，但若这功能都是这类设计 07/26 07:55
44F：→ lazarus1121: 抛错时根本不知道是哪边漏什麽东西，只能逐行找 07/26 07:57
45F：→ lazarus1121: 如果真的很想一劳永逸拿掉if，你abc选项要从jpg来产 07/26 07:58
46F：→ lazarus1121: 出才行 07/26 07:58
exception else 其他情况都有考虑
在一开始判断不对就return 回去了
一开始就给拒绝了
例子聚焦重点 所以没有特别强调这些例外
47F：→ LiebeLion: 丢一个你没想到的变数 直接搞挂 赞啦 07/26 13:30
同上
48F：嘘 ck237: 喵的 突然想到同事写的一个拿档案的动作，就是前端给档名然 07/26 17:25
49F：→ ck237: 後当变数进去，结果人家就可以拿所有的东西，因为你提供一 07/26 17:25
50F：→ ck237: 个万用接口，为了这种东西还要防注入攻击太蠢了... 07/26 17:26
51F：→ ck237: 这种前端写久了的做法用来做後端真是谁倒楣谁接手 07/26 17:27
这个功能并无涉档案
这不是让user上传下载档案的功能
很单纯就是
系统根据user提供选项 显示user选择的选项
假设这是一个无法显示图档的古系统
user 选 a/b/c 系统就显示 a/b/c 其中之一
其实就只是这样的简单功能
52F：推 CoNsTaR: 不是什麽都抽象化就是好欸，该要 concrete 的地方最好还 07/26 22:24
53F：→ CoNsTaR: 是要 concrete，该 explicit 的地方就是该 explicit 07/26 22:24
54F：→ CoNsTaR: 你应该要以现实中的逻辑当基准来选择要用（由低到高）逻 07/26 22:24
55F：→ CoNsTaR: 辑分支/演算法/语言特性/程式架构来实作 07/26 22:24
56F：→ CoNsTaR: 以你的例子，if else 就是一种逻辑分支，你说的抽象成变 07/26 22:24
57F：→ CoNsTaR: 数就是一种演算法，实际要看哪一种描述原本的逻辑更贴切 07/26 22:24
58F：→ CoNsTaR: ，并没有哪一种一定比较好 07/26 22:24
但这例子就是实际的个案
把个案 抽像化成通案以後
再反过来看 当然就不适用所有个案
其实我只是要说 有些if else 不必要
但任何例子在特殊情况下当然有例外
※ 编辑: chal (36.235.109.212 台湾), 07/27/2024 00:02:17