作者bantime (景)
看板Soft_Job
标题Re: [讨论] 写程式的追求？
时间Thu Apr 3 11:28:36 2025
因为前人杂乱--＞所以造成维护上的难度？？？？
真的是杂乱造成的，还是自己不熟悉阅读别人程式码？
我甚至写个最基本的async/await都有人会嫌难以维护了
看不懂别人程式码通常有两种状况
一种是对方真的太烂，完全不想看
一种是你的程度无法跟上
就你一年半的经验我推测後者机会比较高
你的最终结果只有讲好的结果
模组化，好维护？（是你自己认为好维护），易读？(也是你认为易读)
有没有考虑坏的？
效能变差，新旧不相容，因为太着重架构，然後一些超出架构范畴的需求完全无法做，就
跟上级说架构要打掉重做，花费更多时间一事无成，或是终於做出来了但只有你知道怎麽
好维护好读（这些都是周围真实发生过的案例）
接手老古董的经验，我是新写的就用新的方式去做，不要再让污染扩大，旧的部分有需求
要异动调整才去小手术更动，QA也可以在不增加工作量的状况下协助测试
全部重构？唯一优点大概只有满足自己而已
不用讲这麽冠冕堂皇，为了後人
大概就是妈妈这样做都是为了你好的感觉
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 223.140.83.27 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1743650918.A.34F.html
1F：推 O187: 我也曾写c#的lamda被人呛 这只有你会写 没人这样写04/03 11:42
2F：推 O187: 也有开发一半的程式一离职被程度不佳的整个重写 後来他作不04/03 11:44
3F：→ O187: 出来也跑了04/03 11:44
4F：推 ILoveAMD: lamda等语法糖 很大的原因是原始设计偏向罗嗦 才改成04/03 11:46
5F：→ ILoveAMD: 这种奇妙的简写04/03 11:47
6F：推 stepnight: 曾经写个功能易於扩展，不用动旧Code04/03 12:48
7F：→ stepnight: 只要新增，在介面都写完整注解 04/03 12:48
8F：→ stepnight: 离职後听前同事说有个新人一来就说要重构 04/03 12:48
9F：→ stepnight: 整天说：这怎麽这样写、那怎麽这样写04/03 12:48
10F：→ stepnight: 後来过一阵子问前同事是重构成怎样了04/03 12:48
11F：→ stepnight: ：他後来发现好像也只能这样写了 04/03 12:48
12F：推 wulouise: 我写过c#到现在还是不懂linq04/03 14:01
13F：推 springfeel: 通常半调子的新人就是会有一堆美好想像 估计自己写的04/03 14:50
14F：→ springfeel: code後人来看也是嫌的像一坨屎04/03 14:50
15F：推 NDark: 其实不用後人 每个人半年後都抱怨半年前自己在写甚麽04/03 19:17
16F：→ NDark: 但都没想到 自己正在写的 半年之後的自己也会抱怨04/03 19:17
17F：→ NDark: 其实只有(商业)逻辑的"参数"才是黄金 程式码都能花钱造04/03 19:18
18F：→ NDark: 实作过程的所累积的经验在人身上 这样的人才重要04/03 19:19
19F：推 hobnob: 真的很多工程师不是自闭就是自傲欸04/03 20:23
20F：→ superpandal: 不然呢 重构本身就是要先帮助自己 虽然我通常是不重04/03 22:39
21F：→ superpandal: 构那个 因为应该是没收益04/03 22:40
22F：→ superpandal: 效能情况我没见过屎山效能好的 我自己从头开始整的 04/03 22:42
23F：→ superpandal: 效能倒是很不错04/03 22:43
24F：推 VScode: 超级讨厌过度设计的 搞到不知道在写三小 我宁愿看义大利04/03 22:43
25F：→ VScode: 面粪扣 也不想看一堆封装继承oop04/03 22:43
26F：→ superpandal: 我也讨厌过度封装 我一直视为前人的阴谋 但基本架构04/03 22:51
27F：→ superpandal: 还是要有的 否则全义大利面也是很痛苦04/03 22:51
28F：→ superpandal: 全义大利面只有给其它不相干的人最适合 可以搞生成co04/03 22:53
29F：→ superpandal: de 04/03 22:53
30F：→ superpandal: 自己内部看的与给别人的是不一样的 模版有无限可能 04/03 22:57
31F：→ superpandal: 现在前端也差不多这样 compile再compile04/03 22:58
32F：→ stepnight: 全义大利面code就是给免洗员工最佳架构04/03 23:08
33F：→ stepnight: 反正谁来都可以继续维护 04/03 23:08
34F：→ superpandal: 商业逻辑参数也都不是黄金 多半只是公司专用的产物04/03 23:09
35F：→ superpandal: 都免洗了还想维护义大利面code 稍微施加需求压力就爆04/03 23:11
36F：→ superpandal: 了的东西 当然是能省心就省心04/03 23:11
37F：→ superpandal: 有经验应该知道省心才是第一要务 其它根本不值得care04/03 23:22
38F：→ superpandal: 当然有些人会想别人不省心我不就省心了吗04/03 23:35
39F：推 jlhc: 全义大利面真心不行... 要修改都牵一发动全身..04/04 00:14
40F：→ viper9709: 推新写的用新方式,旧的有异动的部分再去调+104/04 01:07
41F：推 prag222: 之前我手上重构也是排自己的工时进去,就整理一下包成物件04/04 04:56
42F：→ prag222: 不然每次呼叫都一堆重复程式码跟麻烦的细节设定04/04 04:56
43F：→ prag222: 有的功能你用早期web程式一行一行跑script lang会搞死人04/04 04:58
44F：推 pot1234: 效能变差我就觉得不算成功的refactor了。前人写那麽差的 04/04 08:10
45F：→ pot1234: 话怎麽可能refactor到效能变差
因为重构的人只是看不惯以前的写法，能力却不够，新的写法反而差，例如前人写for/fo
reach看不惯，改成linq，却不熟延迟查询的特性，那就是地狱
04/04 08:10
46F：推 a12838910: linq 很棒欸04/04 08:56
47F：→ a12838910: 我自己是真的遇到前人 写很多累赘的程式码04/04 08:56
48F：→ a12838910: 在不影响逻辑的前提下优化後 少了很多行04/04 08:57
49F：→ shooter555: 架构变好 效能变差很有可能啊 因为为了封装 可能会多04/04 09:58
50F：→ shooter555: 了不少资料传递的动作04/04 09:58
※ 编辑: bantime (223.140.83.27 台湾), 04/04/2025 11:03:13
51F：→ alan3100: 第3种就同事平均程度太差 async/await不懂的其实很多 04/04 12:54
52F：→ alan3100: 就算小部分重构或新的才用新写法 最终还是只有你能维护 04/04 12:56
这部分扯到需求问题，不是为了重构故意使用非同步，而是效能需要才使用，其他人跟不
上就不是我的问题了。
但如果只是为了自己看得爽，看不惯一些陈旧写法而去重构，那就是自己的问题
※ 编辑: bantime (223.140.83.27 台湾), 04/04/2025 13:36:28
53F：推 devilkool: .NET开发者用async/await很基本了吧 除非传惨= = 04/04 13:52
54F：→ Firstshadow: = = 04/04 15:41
55F：推 art1: 用习惯了 .net 跟 js 的非同步，python 的好难用... 04/04 17:58
56F：→ Csongs: 就说是文人相轻 04/04 18:43
我不认为完全是文人相轻，毕竟是老古董，当年的技术程度写出那样已经很好了，只是没
有随着时代演进，我们现在觉得很好的方式几年後也许也会被当成垃圾，所以需要持续迭
代，拿手机来说许多当年的神机现在也只是垃圾一台
※ 编辑: bantime (223.140.83.27 台湾), 04/04/2025 19:54:33
57F：→ testPtt: 看程式的规模 例如你要写一套作业系统 不得不细分功能 04/04 20:21
58F：推 shortoneal: 这种议题没看到code一率都是保留态度，自我感觉良好的 04/04 21:51
59F：→ shortoneal: 人很多lol 04/04 21:52
60F：→ rogerlarger: 读别人的code就像吃别人的屎，吃习惯就好 04/04 23:09
61F：→ superpandal: 那就只有程式码表现方式不同 概念想法做法很久前就04/05 03:52
62F：→ superpandal: 有了 不会差太多 含效能 硬体拿来比就.... 04/05 03:53
63F：→ superpandal: 习惯当然会有效率不同的问题 只要自己不用再维护别人 04/05 03:56
64F：→ superpandal: 爱怎麽重构责任也不在你04/05 03:57
65F：→ superpandal: 架构变好效能变差多半不是封装导致 无用封装再多层 04/05 04:05
66F：→ superpandal: 也起不了作用 过於夸张的太少见 这也是为什麽框架可04/05 04:06
67F：→ superpandal: 以藉此滥用用来隐藏实作细节的原因04/05 04:07
68F：→ superpandal: 过度封装的问题点在於扰乱视听 04/05 04:14
69F：→ superpandal: 效能问题在不是太差的机器上你根本看不出来04/05 04:20
70F：推 wizozd84070: 学会习惯也是一种学习 04/05 08:02
同意，当年自己也是这样看不惯
心态转变後好很多了
※ 编辑: bantime (223.140.83.27 台湾), 04/05/2025 08:05:34
71F：推 VScode: 放下它 加入它 学会写粪code以後很爽的 自己维护很快 04/05 11:01
72F：→ VScode: 别人看不懂 效率upup 04/05 11:01
73F：推 hakama99: 我第一次看到lamda觉得是邪魔外道XD04/05 11:11
74F：推 NDark: 我觉得lamda就是一时爽 比复制贴上有得拚04/05 11:19
75F：→ NDark: 时程很赶没办法顾好品质是勉强用了 但长期维护就很难 04/05 11:20
76F：推 VScode: 我也不喜欢linq 底层封装太多东西了 表面看起来很方便 但 04/05 13:03
77F：→ VScode: 很容易踩到效能陷阱 还是自己手刻安心些 04/05 13:03
linq不是只有EF哦，我遇到蛮多把Linq跟EF划上等号的人，除此之外比较常见所谓的效能
陷阱大概都是延迟查询相关的部分，还是可以举例来说一下有什麽效能陷阱呢？
※ 编辑: bantime (223.140.83.27 台湾), 04/05/2025 18:55:38
78F：推 VScode: 我不是在讲EF 而是linq to object,做一些复杂查询时很容易 04/05 19:57
79F：→ VScode: 踩到雷 例如Where里做Contains、Any判断等等 04/05 19:57
80F：→ VScode: 加上GroupBy Aggregate等操作写了N层巢状的也很难debug 04/05 19:58
原来如此啊，但如果是这样应该不是linq的问题，因为就算不是在where内做，改成回圈
在里面做Any问题应该也是存在呢。
所以这些效能陷阱听起来不像是linq的锅，单纯使用上不熟所造成，我是这样认为啦。不
过无论什麽元件使用不熟对效能造成影响也是很正常的事情，但不认为锅要在元件上就是
了。
不过复杂逻辑也没人逼一定要一次用linq写完，拆分混用都可以。
※ 编辑: bantime (223.140.83.27 台湾), 04/05/2025 20:18:47
81F：→ superpandal: 只要不被要求deadline前做好 被事後检讨那习惯倒是 04/05 20:43
82F：→ superpandal: 还好 不然自己产出被检视也很麻烦 04/05 20:44
83F：→ superpandal: 只顾自己那不就是斗後人？ 由此可见职场风气真的差 04/05 20:46
84F：→ superpandal: 理解粪code并不是说绝对不好 但如果你是被压时间又要04/05 20:49
85F：→ superpandal: 理解别人的粪code那很痛苦 04/05 20:50
86F：→ stepnight: 不过你各位公司都没有规范/CR的吗？ 04/05 21:04
87F：→ superpandal: 异地而处马上又换嘴脸的太多了 粪code都不是最严重04/05 21:13
88F：→ superpandal: 最严重的是双标 大家互吃粪都还没那麽不平衡 04/05 21:16
嘛……我是不太喜欢粪Code这个词啦，虽然我也经历过骂人粪Code的阶段
但既然是前人的Code，蛮高机会应该都是上线的产品了，公司的营收这些程式码多少也有
贡献呢！
公司是赚钱的地方，不是拿来做学术理论的地方，我是这样想的，在维持公司营收有余裕
的前提下，再做动刀比较好。
那种为了後人啊，或是不重构就等着爆炸的话...嗯……通常是改了爆炸呢或是其他人接
手的时候又是说这啥粪Code呢～
除了自己的程式码以外很少有人看别人的程式码顺眼的吧？XD
※ 编辑: bantime (223.140.83.27 台湾), 04/05/2025 21:40:14
89F：推 strlen: 不是这个问题 粪不粪code当然不是你说了算 是团队说了算 04/05 21:45
90F：→ strlen: 所以要频繁跟人家吵架改code 偏偏工程师谁要跟人家吵这个 04/05 21:46
91F：推 ricky60324: 不写单元测试的我觉得才是最靠背的 有写单元测试架构 04/05 23:33
92F：→ ricky60324: 不会烂到哪边 因为写测试的时候很难写就会自己改了 04/05 23:33
93F：→ ricky60324: 遗留的code 没有规格书 没有单元测试 能赚钱也不代 04/05 23:34
94F：→ ricky60324: 表他不粪XD 而且技术债迟早要还的 04/05 23:34
95F：→ ricky60324: 当然大家都抱持着 不要爆在我手上就好 重构不是必要 04/05 23:35
96F：→ ricky60324: 也建议不要花时间重构 新的code再写好 旧的能动就好 04/05 23:35
97F：→ ricky60324: 不然等着背锅的就是重构的那位
这个要看产业/专案性质了，有些真的一点失误都很严重
如果都是内部EMP还是什麽的，出一点小包都还不会怎样，但是如果扯到钱或是安全问题
就大了
04/05 23:35
98F：推 tsaigi: async/await 感觉真的很多人不懂 之前整个公司十几个专案04/05 23:54
99F：→ tsaigi: 都用到有问题的写法 程式一直crash 还要我这个SRE下去修04/05 23:54
还有很多假非同步呢XD 以为写了非同步，结果内部还是同步作业
※ 编辑: bantime (111.71.68.236 台湾), 04/05/2025 23:57:28
※ 编辑: bantime (111.71.68.236 台湾), 04/06/2025 00:01:50
100F：推 viper9709: 推学会习惯也是一种学习XD 04/06 00:49
101F：推 nicetw20xx: 推有写单元测试，程式不会差到哪 04/06 09:00
102F：→ testPtt: 写成非同步有时候只是习惯 介面不会卡就懒得改了 04/06 09:37
非同步还有蛮多效能考量的，不只是UI，有机会练手我是就会练手，才不会等到真的要用
的时候才能够信手拈来。
我自己也遇到蛮多这种说辞的，就是这个情境速度要求没这麽快，不需要这样写，但我是
不太相信当速度要求提升的时候这些人是可以写得出来的
※ 编辑: bantime (111.71.68.236 台湾), 04/06/2025 09:52:17
103F：推 aa0983163178: 我觉得不懂的技术，反而不要用比较好，遇过同事为了04/06 11:01
104F：→ aa0983163178: 想写非同步，结果线上一堆奇怪且难以解释的bug XD 04/06 11:01
所以不懂的技术要找机会练习呀～
真正要用的时候才能够信手拈来
※ 编辑: bantime (111.71.68.236 台湾), 04/06/2025 12:28:52
105F：推 tsaigi: 不懂确实不该用 但如果每个新技术都不懂 就等着被淘汰吧 04/06 13:25
讲那个一点……我真的不认为Linq/async/await是“新”技术
※ 编辑: bantime (111.71.68.236 台湾), 04/06/2025 13:39:05
106F：→ superpandal: 最好有那麽多时间写测试 测试本来就是写的烂才需要保04/06 22:35
107F：→ superpandal: 证 赶快写好赶快休息才是真的 04/06 22:37
108F：→ superpandal: 给你写测试架构烂都是没救 万变不离其宗 掌握根本才 04/06 22:44
109F：→ superpandal: 是最省心的 我讲话也差不多这风格 04/06 22:45
110F：→ superpandal: 发散的东西就是屎04/06 22:47
111F：→ superpandal: 有脉络的程式程式才反而不差 04/06 22:48
112F：推 fatb: 我的经验是除非你是公认的大神 不然不会有谁想看别人的code04/07 18:05
就算是大神的Code也是很多人不想看呦～啾咪～
※ 编辑: bantime (111.71.68.236 台湾), 04/07/2025 19:30:39
113F：→ wulouise: 不写测试只爽到自己... 04/07 22:00
114F：推 waiwailove: 写C#还在串sql语法 call预存程序处理问题... 04/07 22:19
115F：→ alan5: 写测试很难写就会改？ 我通常只看到屎扣写了更大陀屎测试 04/09 16:29
116F：→ alan5: 来给你闻 04/09 16:29
117F：→ alan5: 有些code写一个测试就可以稳跑两三年 04/09 16:30
118F：→ alan5: 有些写了100个测试 还是只能撑30分钟 04/09 16:31
119F：→ alan5: 你觉得重要的是写测试？ 04/09 16:31
120F：→ superpandal: 楼上正解 有机会变成测试就是屎山 04/09 20:28
121F：→ superpandal: 搞到程式失控都没用 本身质量好就好写测试 锦上添花 04/09 20:32
122F：→ superpandal: 有时间可以做 不然光需求变更就挂了 04/09 20:32
123F：→ superpandal: 架构好通常只需要小补当然可以爽自己 也不见得不爽 04/09 20:37
124F：→ superpandal: 到别人 04/09 20:37
125F：→ h920032: C R A F T C O D E 04/11 18:14