作者brucetu (sec)
看板Soft_Job
标题Re: [心得] 花了很多时间重构却被打枪用旧code
时间Mon Sep 15 12:12:40 2025
看到这篇原原PO在其他篇底下声称
「可读性+100%」
忍不住来回一篇
软体开发里面有一件很重要的事情是知识转移
又称 knowledge transfer 印度仔会简称 KT
你也可以拿这个词去搜寻 看看印度仔对这东西的看法
有一个很直白的解释是：在你的脑袋上按复制，在我的脑袋按贴上。
简单说
每当 A 完成了一个东西要并入主线
或者 B 要参与一个他本来不熟悉的模组
大家都需要 KT 一下
这件事情成本高到靠北
假如你手上有 3 张票
分给三个人做 用了一周做完
你以为接下来再给他们 3 张票 隔周还可以保持一样的生产力吗？ 错
隔周他们需要互相 KT，大家都对系统的更动有相当程度的共识之後，才能继续进行开发
所以隔周大概做不了什麽事情
否则你的系统很快就会东倒西歪
这也是为什麽大型的专案最好有严格的框架跟守则
我们希望尽量减少每个人重新学习的时间
当所有人遵循相同的框架在开发 就能更容易理解别人写的程式在做什麽
这也是模组解藕的好处之一，它可以缩小需要参与KT的人数，你不会希望每个commit都耗
费20个人的学习成本
所以回到最前面那句 「可读性+100%」
其实根本只有对重写的那个人而言可读性 ++
你读了原本的程式，你写了新的程式，新的程式你熟到不行，当然可读性很高
对我来说这就是一份全新的程式码
整包程式要拿来重新分析测试，才会知道里面到底在干麻
我要猜测你每个类别甚至每个函数的意图
可读性可能是 「-80%」
为什麽有些程式一开始看很屎
多看几次之後你觉得还满顺的
因为我们的脑子就是这样运作的啊
你疯狂加班重写了一整套系统
你当然觉得每个函数都一看就知道在做啥
--
要重构同时增加可读性
唯一的方法是一次改动一部分，并且确保每个人都有跟上你的改动
否则只是把知识的鸿沟从小水沟 变成大峡谷
你这样的改动方式
就好像我叫 AI 加个小功能
然後他给我一包 zip 说我重写了整套专案
测试过没问题了 你可以放心取代原本的专案
只有一种情况你这个做法会被接受：你同事跟老板完全不管程式 把你当 vibe coding 的
工具
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 223.137.128.194 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1757909562.A.E51.html
1F：推 FrozenMoment: 我推这个观点 09/15 12:43
2F：推 zyxx: 推 09/15 12:53
3F：推 ILoveAMD: 就算是自己今天可读性100% 难保下周同一个时间变50% 09/15 12:55
4F：→ brucetu: 熬夜到天亮 加上 AI 帮忙写 隔天连自己的扣都只剩 50% XD 09/15 13:31
5F：→ marra: 推推 09/15 13:37
6F：推 crowley: 自己写的code两周回来看都要看老半天 09/15 13:38
7F：推 jackwang01: 推 09/15 13:48
8F：推 chuegou: 昨天也想吐槽他推文这句 但你讲的比我有脉络多了 09/15 14:10
9F：推 HelloPPT: 推 09/15 14:26
10F：推 viper9709: 推这篇讲的好 09/15 16:07
11F：推 alihue: 推 09/15 16:23
12F：推 lytt: 推 09/15 17:00
13F：推 a5480277: 自己的code过一个月回来 就会想问问当初自己在写啥 09/15 17:49
14F：推 Obama19: 最可怕的是都不讨论 然後最後丢出一坨大便 09/15 17:51
15F：推 single4565: 推 09/15 18:52
16F：推 newhandfun: 推 09/15 19:31
17F：推 leokidd1976: 推，我连我自己一年前写的程式都看不懂了说 09/15 20:47
18F：推 hsiantinc: 大推 09/15 21:06
19F：推 abc0922001: 半年前写的code我都会看git blame看是不是真的我改的 09/15 22:28
20F：推 k7ji91ab5m: 这2年已经觉得甚麽SOLID 重构 抽象 真的有意义吗 09/15 22:31
21F：→ k7ji91ab5m: 不管谁看谁的code都觉得难懂难改 09/15 22:31
22F：→ brucetu: 真的常常 git blame 到自己 XD 09/15 23:10
23F：→ brucetu: 软体工程的各种pattern都是看情况用啦 有些原则比如说DRY 09/15 23:16
24F：→ brucetu: ，有时候当你能预估到不久後的将来，你正在做的这功能会 09/15 23:16
25F：→ brucetu: 客制化成某个很难跟别人相处的东西，那就直接复制过来改 09/15 23:16
26F：→ brucetu: 一改先用啊，有时候重复程式码看似脏，其实比较好。还有 09/15 23:16
27F：→ brucetu: 很多时候抱怨扣太屎的人，只是因为他扣看的还不够熟，等 09/15 23:17
28F：→ brucetu: 他上手两个月以上再来讨论要不要改 09/15 23:17
29F：推 knme: 推 09/15 23:50
30F：推 viper9709: 推楼楼上 09/16 01:08
31F：推 GoGoRoTM: 推 09/16 09:38
32F：推 wangyc: 推 09/16 09:40
33F：推 freezeio: 推这篇 09/16 11:38
34F：推 Eide: XDD 09/16 21:40
35F：推 ELivan: 推 09/18 00:35
36F：推 tim96tim: 谢分享 09/18 18:40
37F：→ Nicks: 推 这观点才合理 09/19 13:28
38F：推 FatFatPig: 推 09/20 23:56
39F：推 f0915034335: 推 09/21 14:20
40F：推 wawawa: 不要特别拉出一个时段或任务说要做重构，合格的工程师应 09/23 08:19
41F：→ wawawa: 该要让重构随时发生，小范围小范围的处理 09/23 08:19
42F：推 viper9709: 推楼上 09/23 16:59
43F：推 EricTao: 确实 之前问隔壁部门一个问题 那个人看了一眼code说 这 09/24 22:03
44F：→ EricTao: 段那个谁重写过了要问他。 09/24 22:03
45F：推 a42224a42224: 推 10/20 20:56