Re: [请益] 疴 遇到这种事情 是不是需要赶快离职了?

楼主: chal ( )   2024-07-24 20:27:43
我个人感觉程式语言也是有语感的
跟学历关系不大
我自己碰过一种写法
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% 的不同
这其实有风险
你要很懂系统 也要有完整的测试案例
其实会花更多时间
搞不好还会弄坏别人的功能
在乙方速度就是一切
因为台湾人找乙方就是为了快
我甚至认为理想的程式宇宙
不应该有乙方这种产业存在
但我也知道 现实社会就是有乙方需求
或许乙方应该一家独大 极大化
大到可以要甲方乖乖听话 慢慢写
我知道这里高手很多
但也明显有一些新人上来问问题
所以也就讲一下很基本的经验
作者: shieldsky (Gray wolf)   2024-07-24 20:43:00
但我觉得为了要弄懂那5%而改成共用函式,对于工作者本身的能力提升有帮助,当然也需要完整测试避免弄坏已经写好的功能。
作者: abccbaandy (敏)   2024-07-24 20:51:00
研究垃圾有啥帮助...
作者: NDark (溺于黑暗)   2024-07-24 20:52:00
a/b/c也是你事后才知道. 规格出现的时候可能根本没规格
作者: knives   2024-07-24 21:05:00
推楼上
作者: viper9709 (阿达)   2024-07-24 22:27:00
a/b/c有可能临时要多一个d,而且不只是印东西
作者: wuyiulin (龙破坏剑士-巴斯达布雷达)   2024-07-24 23:27:00
同意一楼,但是实务上通常很多需求都是追加,除非是有经验工程师/做同类型的产品做多了知道要哪里留接口,不然消除 if else 是一个假议题。
作者: abc0922001 (中士abc)   2024-07-25 00:10:00
我是不太喜欢if else 里面还有 if else
作者: Abbee (阿比)   2024-07-25 01:01:00
看到这篇很有共感,为了把if else去掉,我在写规格书时,整理了原程式里的差异和共通处,花了不少时间写规格书,因为原程式每段几乎一样,但又有一点点不一样,看到眼都花了,若是照翻写新程式,只是一样都复制贴上,不用花什么时间,但下次再加一项,又要改程式走上线流程,把不同提出来放设定档,都不用再上线,但这只有好到维护的人,开发的人才不管这么多不是放设定档的,也能之后只要加dll,而不动原程式,但新手无法理解这样作哪里好
作者: brucetu (sec)   2024-07-25 10:05:00
现在你只要在甲乙丙下面写 let filename剩下的copilot会帮你完成,存盘测试搞定所以这种单纯的案例未来再重写不会花什么时间
作者: CRPKT (crpkt)   2024-07-25 10:21:00
IoC 与 DI 都不是为了消灭 if else
作者: DrTech (竹科管理处网军研发人员)   2024-07-25 13:13:00
这例子根本不考虑,变量出现 a,b,c以外的特例。实务上常常就是bug的来源。正常,有规模与品质的公司,测试部门的unit test就不会过了啦。
作者: abccbaandy (敏)   2024-07-25 13:32:00
推楼上,一堆工程师自以为优化,实际上业务逻辑=程式是最理想的状况,业务逻辑bug最常出现在这
作者: DrTech (竹科管理处网军研发人员)   2024-07-25 13:37:00
不要认为有什么 标准答案,或银弹。还是要看实际业务场景来判断程式该怎么写。此文已经假设,永远只有a,b,c三种数值,并不符合所有业务状况。太多实际状况,就是会出现a,b,c以外的数值,让你程式品质无法预期。这时候用else,真的比较好保证程式品质。万一a,b,c以外的状况有无限扩充,难以设条件,难道要不断写if?用else真的没那么糟糕。
作者: viper9709 (阿达)   2024-07-25 16:34:00
推楼上
作者: anandydy529 (AndyAWD)   2024-07-25 16:53:00
第一种写法至少有个else知道有不符合abc的条件第二种写法运气不好直接喷一个NPE让你加班Hotfix但不是说第二种写法不好,要先了解专案的历史再决定
作者: akito117 (宗益)   2024-07-25 18:44:00
同意楼上,要考虑abc以外的情况,至少要有个报错或防呆
作者: lazarus1121 (...)   2024-07-26 07:50:00
一般的写法是if a else b else c else Exception因为你先知道abc和jpg对应,但若这功能都是这类设计抛错时根本不知道是哪边漏什么东西,只能逐行找如果真的很想一劳永逸拿掉if,你abc选项要从jpg来产出才行
作者: LiebeLion (IchLiebeDich)   2024-07-26 13:30:00
丢一个你没想到的变量 直接搞挂 赞啦
作者: ck237 (白色小鸡)   2024-07-26 17:25:00
喵的 突然想到同事写的一个拿档案的动作,就是前端给档名然后当变量进去,结果人家就可以拿所有的东西,因为你提供一个万用接口,为了这种东西还要防注入攻击太蠢了...这种前端写久了的做法用来做后端真是谁倒楣谁接手
作者: CoNsTaR ((const *))   2024-07-26 22:24:00
不是什么都抽象化就是好欸,该要 concrete 的地方最好还是要 concrete,该 explicit 的地方就是该 explicit你应该要以现实中的逻辑当基准来选择要用(由低到高)逻辑分支/算法/语言特性/程式架构来实作以你的例子,if else 就是一种逻辑分支,你说的抽象成变量就是一种算法,实际要看哪一种描述原本的逻辑更贴切,并没有哪一种一定比较好

Links booklink

Contact Us: admin [ a t ] ucptt.com