作者SkankHunt42 (凯子爸)
看板Soft_Job
标题Re: [心得] 花了很多时间重构却被打枪用旧code
时间Sun Sep 14 11:04:01 2025
※ 引述《kingofsdtw (塔绿班)》之铭言：
: 最近案子快收尾在收敛bug
: 身为救援大队长的老人我被指派到维护一个很老的API
: 老API的设计已经无法满足扩充需求
: 新的扩充功能造成BUG
: 於是我花了大量时间甚至debug到天亮甚至请无薪假
: 新的API经过我反覆测试各种case都完美无缺
: 但是code review却被质疑:
: 1. 是不是没找到root cause
: 2. 干嘛改动如此大? 只不过新加一点点功能干嘛改架构?
: 心中五味杂陈...
: 好歹我也是coding master，我说该重构了就是该开始还技术债了
: 更上头还是希望用最鸵鸟的方法继续用旧架构一堆workaound当作root cause
: 是该离职了吗? QwQ
分享我遇过的鬼故事
某公司里面有A team跟B team
B team负责维护的是一个堪称屎山等级的legacy code
A team觉得B team维护的程式码真他妈臭 隔了一个module都能闻到臭味
花费了半年多 去写了一个跟功能99%像的程式码 然後也有unit tests
现在问题来了 A team有没有要release他的杰作
答案是 没有
因为A team也没有勇气 原本B team的程式码虽然屎 但是整个产品的核心
一旦错 客户的机子不work FAE等着被干 (而且A team也不熟B team业务)
所以A team又搬出了一个天才的做法 说那我们就在软体中同时执行AB两个版本
只要AB两个版本结果不同 我们就能收集到错误case
这样方法搞了两三年 AB team每天都在忙着找 这个错误case到底是哪个版本的错
因为谁跟你讲legacy code 没有bug?
B team还是最熟这个feature的逻辑的人 所以基本上也都是B team在处理
几年过去後 A team的版本落地了吗？还是没有
但A team决定先剪彩 说：「我们要把这个新版本正式交接给B team」
B team接不接 B team心想 干0粮我接个鸡巴毛
但B team还是接了 因为开发部门的总主管是A team的
从这个鬼故事 我觉得有三种层级的经验可以学习
1. 有unit test比没有unit test好 但你的unit test是先射箭再画靶吗
你的test case能反映真实的使用状况吗
2. 这个module的owner到底是谁 谁平常要帮忙擦屁股
3. 你主管是谁 谁授意你去执行重构
这个三层级的经验中 实作只是最浅的那层 也是最不重要的那层
就算你能够证明你的程式码是对的 只要问题2 owner不是你 owner不可能接受
因为平常是他要擦屁股
但是在这个鬼故事中 最重要的是问题3
因为A team的主管最大 B team人微言轻 所以问题2跟问题1就显得更微不足道
只要你政治实力够强大 懒觉要塞谁嘴里就塞谁嘴里
反正永远都有需要这份工作的人
所以软体板到底要不要重构的月经文 频率越来越少 大家越来越懒得吵
因为干了几年就发现 程式码问题最小 人问题最大
况且谁能够证明自己的程式码是对的 你会写形式化证明吗
会写形式化证明也不会待在这种鸟公司
然後test 100%绿灯反对的人还是会说"又没有涵盖100%真实案例"
阿他是在杠吗 是阿 但人家讲的也有道理阿
所以吵这个没完没了 最後还是在炒 谁擦屁股 你主管是谁
※
可能有人以为我是那种"程式码好好的就不要去动他"的人
啊我自己是很喜欢重构啦 以前不是被派去救火 就是跟主管提案重构然後升等加薪
只是现在公司的程式码大家都写得比我好 我的code反而最屎的 每天被AI干
人要跳槽 比起被人抱大腿 抱别人大腿不管是待遇还是精神卫生 都比较香
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 146.70.205.94 (日本)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1757819043.A.D69.html
※ 编辑: SkankHunt42 (146.70.205.94 日本), 09/14/2025 11:05:00
1F：推 space20021: 推 09/14 11:17
2F：推 mozume: 这个故事好眼熟，应该在很多地方发生过 09/14 11:33
3F：推 tsaigi: 推 09/14 11:35
4F：推 kurtsgm: XD 看完这鬼故事笑了 但我好奇切换到A module之後是大爆 09/14 11:37
5F：→ kurtsgm: 炸还是真的顺利完成迭代 09/14 11:37
我不知道 我离职前还AB两个版本都还在双轨运行 算是开放式结局
※ 编辑: SkankHunt42 (154.47.23.51 日本), 09/14/2025 11:49:46
6F：→ fgh81113: 那A干嘛生类似的功能？是因为通通都要用B的程式？ 09/14 12:38
7F：推 jack0204: 可以强烈建议但不能不说直接做，因为责任是决定的人扛 09/14 12:52
8F：→ jack0204: 分两个版本不是不行，但要想好怎麽做才不会失败 09/14 12:54
9F：嘘 lturtsamuel: 你这又不是重构 是重写 先搞清楚问题在哪== 09/14 12:54
你琢磨是重构还是重写 问题的本质有变吗
甲
大刀阔斧重构 diff占整个module 80%
跟乙
大规模重写 diff占整个module 80%
你觉得区别在哪？ 有人会在意你的commit是用什麽方法论吗
改程式码就改程式码 不会因为你给他一个新的名字改变本质
10F：→ jack0204: 我是觉得RD应该要多了解infra相关知识才能避免一些问题 09/14 12:56
※ 编辑: SkankHunt42 (155.2.216.9 日本), 09/14/2025 13:00:52
11F：→ lturtsamuel: 重构就是要限缩范围 第一步是把一大坨屎改成许多坨小 09/14 13:05
12F：→ lturtsamuel: 屎 再把每一坨屎改正 中间每一步都要有足够的信心才 09/14 13:05
13F：→ lturtsamuel: 能走下去 当然这是理想情况很难完全做到 但你这做法 09/14 13:05
14F：→ lturtsamuel: 跟理想情况也差太多？ 09/14 13:05
这作法又不是我发明的 关我屁事XD
我入职时就已经是AB双轨并行了
我从B Team离职前就跟A team主管讲了阿 为什麽重构不用局部迭代的方式
他也说不上来阿 就说这是一次错误的经验
原PO内文讲的改动幅度我觉得不低啦 所以才举这个例子
你程式码差异幅度大到一个程度 本来就会被challenge
你讲的小屎逐步翻新那是常规状况 工作看到就要顺便修
有些重构是为了满足新feature就要整个模组架构跟流程改动的
那种PR一般不会小
※ 编辑: SkankHunt42 (155.2.216.9 日本), 09/14/2025 13:13:05
15F：→ lturtsamuel: 等整个东西都99%完成了才要对接 当然就是重写啊== 09/14 13:06
16F：→ watashino: 有改动AB test不是很正常吗 09/14 13:09
17F：推 gino0717: 我觉得维持两年换一份工作的良好职涯纪律可以避免这些事 09/14 13:21
18F：推 viper9709: 推人的问题最大+1 09/14 17:07
19F：→ MoonCode: 有测试是要先针对旧系统写 再来新系统测试 09/14 17:22
20F：→ lucky4283: A team是不是太闲，还有时间做重复的功能 09/14 21:04
21F：→ xam: 可以考虑job rotation吧.. 看是搬一些人过去或是两team互换 09/14 21:18
22F：推 darkMood: 不意外啊。 09/15 00:25
23F：推 marra: 故事好听，给赞！^_^ 09/15 03:30
24F：推 CRPKT: 重构有具体定义的啦，你要能确保行为不改变才是重构 09/15 11:17
25F：推 GooglePixel: 马上又有杠精跳出来 最後一段推给每一个人 09/15 11:18
26F：→ CRPKT: 很多时候靠既有手段重构无法走到你想要的地方 09/15 11:18
27F：→ CRPKT: 那个时候跳一小步就已经是重写了，重写很正常 09/15 11:19
28F：→ CRPKT: 是不用太纠结名词，但的确太多人重写都说自己在重构 09/15 11:20
29F：推 satanmaggie: 好赞，最喜欢开放式结局 09/15 12:45
30F：→ jonathan793: 喜欢你暖暖的文字 09/15 17:08
31F：推 holebro: 好听的故事 期待多多分享 09/16 16:04
32F：推 lwecloud: A team蛮爽的，不用maintain屎code没产值还不会被lay 09/16 23:08
33F：推 tim96tim: 干 真好听 09/18 19:56