作者TonyQ (得理饶人)
看板Soft_Job
标题重构的几个迷思
时间Tue Jul 7 08:27:58 2020
觉得最近很多文章都有些不求甚解的问题，来写点论述。
1. 重构不是什麽了不起的事情
2. 变更程式码，重写旧的程式码成自己爽的样子，不一定是重构。
3. 重构是一种相对安全的工具型开发方法论，
但仍然有不少风险跟诱惑。
4. 如果你不应该或没权力改的程式码，
不要以为自称是重构就能取得变更的权力。
5. 测试(单元或整合)，是一种快速验证，
程式是否符合自己预期的工具，但并不是不会犯错的保证。
因为，自己的预期可能就是错的，也可能测试相依过深，
一时半刻没有足够好的介面，测不到真正的主要情境。
6. 不论重写或重构，所有的程式码变更都有一个本质，
要把时间花在刀口上，对重要的程式码优先处理，
不重要的程式码延後处理，程式码都有优先权问题。
所谓的程式码没坏就不要修他，
本质上是「如果他的现况不影响别的事情，暂时不用管他」。
但如果他已经卡到别的功能的扩充或维护，
造成 DEBUG 困难，常出问题等，修改他就有了价值。
那个状态就又是另一回事。
======
另外，有些话我觉得讲的不够白，做点翻译：
1. 东西没坏就不要改他：
你最近改坏的东西太多了/
你最近正常改好的东西太少了/
这段扣不关你的事情你没有权限可以碰。
2. 开发应该要先做测试：
你最近改坏的东西太多了/
你最近正常改好的东西太少了
3. 要重构之前应该要先做测试：
你现在的 CODE 搞不好都已经在乱写了，
再大规模改 CODE 会不会死的更难看。
4. 这 CODE 写的很烂：
我想把 CODE 改成我看起来爽的样子
=====
坦白说，你写程式品质高的话，要怎麽炫技都可以，
凡人登山要确保，很多高手可以无确保登山，
但这些人每隔几年也就会有一两个摔死上新闻。
嗯，反正说到底改程式码的权限是个政治问题。
打着重构或效能调整的名义变更是没关系，
但有没有做好，是一翻两瞪眼的事情。
个人 Credit 丧失事小，
把使用这个工具的人给搞成白痴事大，
还麻烦大家，量力而为。
自己烂，不会开发，不要牵拖工具方法论。
要重构先还是要测试先，会问这种问题的，
还不如先练习看看什麽是重构，什麽是测试。
-----
Sent from JPTT on my Google Pixel 3 XL.
--
网页上拉近距离的帮手 实现 GMail丰富应用的功臣
数也数不清的友善使用者体验 这就是ｊａｖａｓｃｒｉｐｔ
欢迎同好到 AJAX 板一同讨论。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 61.231.31.193 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1594081682.A.E16.html
1F：推 d1288999: 推推 07/07 08:48
2F：推 yyhsiu: 推前半，做事真的要看带来的价值 07/07 08:51
3F：推 bill0205: 推 07/07 09:00
4F：推 Gaitz: 推 07/07 09:27
5F：推 WTFCN: 台肯 07/07 09:36
6F：推 lovez04wj06: 除了半瓶水以外，真的有人喜欢没事就重购吗？ 07/07 10:46
比起有没有事(应该没多少人是真的没事的),
更重要的问题是很多人会看 code 看不顺眼. (不过这个行为本身不见得是坏事)
看到一个问题就想要去挑战更好的作法,
不论是求表现也好, 或是想找事情杀时间, 这是人之常情.
※ 编辑: TonyQ (210.61.209.201 台湾), 07/07/2020 10:49:27
7F：推 asd51052000: 是不是少了[心得]? 07/07 10:53
8F：→ x000032001: 加功能就容易伴随着重构 不然经常会变得叠床架屋 07/07 11:05
9F：推 ian90911: 中肯 07/07 11:38
10F：推 jhengsiaomin: 推 07/07 12:02
11F：推 tbpfs: 中肯 07/07 12:37
12F：嘘 iceman5566: 你的标题先重构一下吧 07/07 12:45
13F：推 Menderca: 中肯推 07/07 13:21
14F：→ longlyeagle: E 07/07 13:21
15F：→ shooter555: 加功能伴随重构 那应该会想打写架构的人 07/07 13:24
16F：推 TAKADO: 改扣之前先问问自己，这段程式这麽烂大家都有看到，为什麽 07/07 13:32
17F：→ TAKADO: 没有前人去改它，凡事必有因果。 07/07 13:32
我自己改过很多次, 通常原因都是前人能力不足/胆量不足.
所以要问问的应该是自己有没有比前人厉害.
18F：→ shooter555: 不过真的就是权限问题 权限够想把所有功能改掉 不用说 07/07 13:33
19F：→ shooter555: 物件化 拟人化都可以 每个功能帮它取个名子 07/07 13:34
20F：推 jixiang: 中肯 07/07 13:39
21F：→ x000032001: 哪来的万用架构都不用动就可以加功能 不需要dirty wo 07/07 13:39
22F：→ x000032001: rk 请务必让我见识怎麽设计出来的 07/07 13:39
23F：→ KeyFSN: 就是有阿 看过才会赞叹公司花大钱请 senior 不是没有原因 07/07 13:54
24F：→ as30385438: 能搞出万用架构应该也不是senior, 是神了 07/07 14:08
25F：→ as30385438: 不然就是一堆overdesign的garbage code自以为很神 07/07 14:08
※ 编辑: TonyQ (210.61.209.201 台湾), 07/07/2020 14:11:04
26F：推 Darkword1987: 我觉得要refactor要有理由 丑不算 07/07 14:18
27F：→ shooter555: 架构总要保留可以扩充跟相容的空间吧 加一个功能就要 07/07 14:29
28F：→ shooter555: 这就是有问题的 07/07 14:30
29F：→ shooter555: 重构 07/07 14:30
30F：推 hichcock: 年轻人应该多鼓励重构当练功, 但是请私下做 07/07 15:12
31F：→ hichcock: 不要影响到大家工作的环境, 重构下去你才会发现很多问题 07/07 15:12
32F：→ hichcock: 包含自己缺少的, 还有旧架构的涵义等等 07/07 15:13
33F：推 leveger0903: 如果该专案几乎没有後续需求的话 只是丑我可以 07/07 15:57
34F：→ leveger0903: 但是常常有後续一堆需求 加上前人刻意不照公司写程 07/07 15:58
35F：→ leveger0903: 式规范走 留下很多坑 东西又在线上 不得不选这条路 07/07 15:58
36F：→ lazarus1121: 站在管理者的立场就是没坏不要改，因为错了要担责任 07/07 17:37
37F：→ lazarus1121: 但站在开发者的角度，这东西不改我会很难维护跟除错 07/07 17:38
我是管理者而且我会改，反正我扛责任没人会说什麽。
这篇真正的立场叫做掂掂自己斤两。
38F：→ lazarus1121: 这篇的立场只是偏前者 07/07 17:39
39F：推 joery: 推能跑没问题再烂也不要动code,很难改不知道是否有地雷，可 07/07 18:42
40F：→ joery: 3会付出代价 07/07 18:42
41F：→ airtsubasa: 如果公司没有自己的规范呢？ 呵呵… 07/07 20:35
42F：推 simpleplanya: 推唷 07/07 21:36
43F：推 ericjc: 推一个 07/07 22:24
44F：推 clamperni: 说真的我到现在还没遇到真的懂重构的 2倒是一堆XD 07/08 00:03
45F：推 Csongs: 很多人只是看不惯别人写得而已 07/08 00:05
※ 编辑: TonyQ (61.231.78.150 台湾), 07/08/2020 05:24:43
46F：推 nenpow: 这篇整理得很清楚, 但多数人还是只会撷取自己想听的 07/08 08:44
47F：推 LuyTe: premature optimization is the root of all evil 07/08 09:53
48F：→ LuyTe: 重构跟讲英文很像，你会看到一堆英文很烂的人很有自信开口 07/08 09:57
49F：→ LuyTe: 讲，也会看到英文很好却不敢开口的人。你会看到一堆该重构 07/08 09:57
50F：→ LuyTe: 的人找理由不去重构，也会看到不该重构的人OCD发作改些没意 07/08 09:57
51F：→ LuyTe: 义的东西 07/08 09:57
52F：推 smily134: 推 07/08 11:01
53F：→ zx1986: > 凡人登山要确保 超中肯！Testing 先起来再说重构！ 07/08 13:49
54F：推 overhead: 抱持code没坏就不要改的，是烂主管。通常就是他自己cod 07/11 15:36
55F：→ overhead: ing能力差，不勤练，不好好写test。还因为他是这种人， 07/11 15:36
56F：→ overhead: 整个团队也慢慢变这种风格。 07/11 15:36