※ 引述《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干
人要跳槽 比起被人抱大腿 抱别人大腿不管是待遇还是精神卫生 都比较香
作者:
mozume (米虫)
2025-09-14 11:33:00这个故事好眼熟，应该在很多地方发生过
作者: tsaigi (菜鸡) 2025-09-14 11:35:00
推
XD 看完这鬼故事笑了 但我好奇切换到A module之后是大爆炸还是真的顺利完成迭代
作者:
jack0204 (Jarbar王朝)
2025-09-14 12:52:00可以强烈建议但不能不说直接做，因为责任是决定的人扛分两个版本不是不行，但要想好怎么做才不会失败
作者:
jack0204 (Jarbar王朝)
2025-09-14 12:56:00我是觉得RD应该要多了解infra相关知识才能避免一些问题
重构就是要限缩范围 第一步是把一大坨屎改成许多坨小屎 再把每一坨屎改正 中间每一步都要有足够的信心才能走下去 当然这是理想情况很难完全做到 但你这做法跟理想情况也差太多？等整个东西都99%完成了才要对接 当然就是重写啊==
作者:
gino0717 (gino0717)
2025-09-14 13:21:00我觉得维持两年换一份工作的良好职涯纪律可以避免这些事
作者:
MoonCode (MoonCode)
2025-09-14 17:22:00有测试是要先针对旧系统写 再来新系统测试
作者: lucky4283 (KENNY) 2025-09-14 21:04:00
A team是不是太闲，还有时间做重复的功能
作者:
xam (听说)
2025-09-14 21:18:00可以考虑job rotation吧.. 看是搬一些人过去或是两team互换
作者:
marra (Marra)
2025-09-15 03:30:00故事好听，给赞！^_^
作者: CRPKT (crpkt) 2025-09-15 11:17:00
重构有具体定义的啦，你要能确保行为不改变才是重构
作者: GooglePixel (谷哥批索) 2025-09-15 11:18:00
马上又有杠精跳出来 最后一段推给每一个人
作者: CRPKT (crpkt) 2025-09-15 11:18:00
很多时候靠既有手段重构无法走到你想要的地方那个时候跳一小步就已经是重写了，重写很正常是不用太纠结名词，但的确太多人重写都说自己在重构
作者:
holebro (穴弟弟)
2025-09-16 16:04:00好听的故事 期待多多分享
作者:
lwecloud (CloudEX)
2025-09-16 23:08:00A team蛮爽的，不用maintain屎code没产值还不会被lay