楼主:
srwhite (鲁蛇阿白)
2018-11-12 02:04:38事情是这样的
小弟最近接到使用者需求
要增加几个跟之前很像的功能
旧的那只程式已经历经许多测试 目前正稳定的运作中
但最初的需求很单纯
因此设计得不是很有弹性 不利于扩充及更改
第一次接到需求的时候
我想了一下觉得重构有点麻烦
于是直接复制了一份然后改了需要改的地方
变成两只有八成像的程式 各做各的
但最近又要再增加一个
于是我开始犹豫该不该整个打掉重构
避免程式码继续这样扩张下去 感觉很不专业
之后再有需求也比较好调整
但如果复制改一改大概只要一个小时
打掉重构可能要一个礼拜 还不保证会不会有什么多出来的bug
想请教大家在类似的情况
都用哪些标准来决定什么时候应该重构
作者:
alog (A肉哥)
2018-11-12 02:26:00做事情是这样 如果你觉得某些事你这样做可以省到后面很多时间你可以做 但实际效果没有符合预期/有机会搞砸/婊到别人/自己扛责/你没有你想像中的专业有把握 你就不该随便乱动已经跑的很稳定的东西还有不要用感觉来判断专不专业 应该要仔细分析优缺点再来抓一个正确的作法
作者:
gs8613789 (Shang6029)
2018-11-12 08:25:00没事做的时候
作者:
Masakiad (Masaki)
2018-11-12 08:36:00你的状况应该是因为没写测试案例才会觉得重构容易有bug
作者: t64141 (榕树) 2018-11-12 09:04:00
维护越来越痛苦的时候
写久了都会有感觉哪边是应该要事先提出来复用的部分，很不科学但是真的是很吃肌肉记忆抽象一点的说就是会自动分类可变动与不可变动的部分吧
作者: t64141 (榕树) 2018-11-12 09:21:00
然后不要习惯复制贴上改一行，很可怕
作者:
Argos (Big doge is watching u)
2018-11-12 09:41:00看了上面一堆人排斥重构 就知道台湾软件业只会继续腐烂
作者:
MixBear (米克斯)
2018-11-12 09:41:00重构是持续进行的 比如你现在这时候遇到这状况 就要拉正，而不是持续放任歪楼
作者:
Argos (Big doge is watching u)
2018-11-12 09:42:00重构这种事有时根本就举手之劳而已 顺手改一点改一点老实说 会不会想去重构 跟工程师自身的修养有很大的关系你够不够认真看待你的专业 就决定你对重构的态度回到现实面 你要重构当然要跟上级讨论并且获得许可及时间如果上面管理方都同意 你当然应该要开始重构但这件事应该是由工程师自己发现问题 并主动向上面提出
作者:
MixBear (米克斯)
2018-11-12 09:45:00最讨厌维护复制贴上一堆相似程式，然后同样逻辑要改漏东漏西的
作者:
Argos (Big doge is watching u)
2018-11-12 09:45:00如果上面死都不愿给时程 那你还有借口让它放著烂没关系
作者:
MixBear (米克斯)
2018-11-12 09:46:00造成后人不便，自己也常埋地雷的程式片段
作者:
Argos (Big doge is watching u)
2018-11-12 09:47:00而不是听到要改Legacy就避之为恐不及
作者:
Argos (Big doge is watching u)
2018-11-12 09:48:00我讲的是态度方面 至于执行细节 原本Legacy连测试都没 怎么改 严格来说都不算是重构就是了 XD
作者: ghmsxtwo (YI) 2018-11-12 09:49:00
离职前
作者:
alihue (wanda wanda)
2018-11-12 10:40:00一堆人排斥重构，然后又嫌台湾软件业烂反正到最后也是牵拖到老板，不检讨自己市面上很多重构的方法，包含写完整的测试与ci/cd，确定你在可控的风险下重构。不重构只会让后人东补西补，踩地雷让台湾的软件缺一个比一个还屎
重构没那么简单 做得好没人理 出错被钉到死这是政治问题 不是软件问题
作者:
cphe (魔鬼藏在垃圾筒里)
2018-11-12 11:05:00打掉重练政治问题比较多，做久就知道为什么，有时候不是你想做就有办法执行除非上面决策的人打从心里想这么做
作者:
testPtt (测试)
2018-11-12 11:13:00重构最基本要有明确的spec
作者:
IDL (IDL)
2018-11-12 11:24:00想离职时
作者:
alihue (wanda wanda)
2018-11-12 11:36:00重构是一群小修改的集合...稍微抽出method或rename都算
https://martinfowler.com/books/refactoring.html虽然繁中译本已经绝版，但简体书大家也可以加减看一下作者就是定义重构的人Its essence is applying a series of smallbehavior-preserving transformations, each of which"too small to be worth doing".
我是会考虑重构对我是否Z>B 如果以后能省很多时间我就会重构 而不是以公司角度考量
作者:
Argos (Big doge is watching u)
2018-11-12 12:01:00政治的确才是真正的问题 但我上面在说的是工程师本身的态度一堆人就是宁可放在那边烂也不想去动 甚至上面给你时间叫你改你都千推万推找一堆借口 这种就是垃圾 软件界的毒瘤你想重构但上面不给你时间和资源那就算了阿 至少你提过了有想要重构的态度出来就行了 至少在这种心态下 你新产出的程式不会差到哪里去 因为过去的垃圾你都看不顺眼了但如果懒得去管过去垃圾 那非常有可能未来也是继续出垃圾
作者:
a926 (Aaron)
2018-11-12 12:06:00重构很难？
作者:
alog (A肉哥)
2018-11-12 13:33:00没有人排斥重构 是你本不该就随便乱动已经final的code 这种都是团体内有共同共识考量到长期维护同案/持续上线营运的才会慢慢修改 你一人专案或完全你负责要怎样改都是你的事只要是在合理的时间范围完成你要自high/练功都行重构都是会发生在有必要做的时候 而有必要做的时机是在你真的有看到明确的问题时候你知道怎么改比较正确 跟获得更大效益不是你在那里自high想改就在那里下刀动手小弟做系统帮专案做重构改了数百组核心也写了数百组测试不知道这个心得不知道够不够格上次一位只是改个function觉得没问题也测过了上线直接当天飞起来 你以为没压力啊
作者:
alog (A肉哥)
2018-11-12 13:42:00我刚好朋友也有主力的产品 一个系统的营收是用千万在计算 开个 Basecamp 看到满满记载要重构的地方 都是有原因跟理由的真的从来没看过用感觉在做事 干这件事的人已经飞上去了(上述那位）
作者:
iamshiao (CircleHsiao)
2018-11-12 18:12:00随时
作者:
solonwu (绝对的信仰可以革新命运)
2018-11-12 22:39:00有把握不会出包的话我会重构
作者: windlll (我要工作阿) 2018-11-12 23:09:00
旧的不动，新的慢慢写，然后拿之前的test跑三次确定没问题后才拿出来
作者:
ppHomer (三脚猫)
2018-11-13 11:50:00重构有很多层次 只是约分/提出一个共用的func 也算重构将某变量或函式 rename成比较有意义看得懂的名称也是重构将重复出现的字串 改成const variable来使用也是重构虽然都是小小的整理 都算是重构, 也都需要进行测试
作者: vul3kuo (Glory) 2018-11-13 13:27:00
长官看你都准时下班的时候
作者:
bobju (枯藤老树昏鸦)
2018-11-13 15:45:00既然你会犹豫,那就是想得不够彻底,想到你决定要做(或不要),那就对了
作者:
tvbic 2018-11-13 19:43:00Never
作者:
loadingN (sarsaparilla)
2018-11-14 01:15:00吃饱太闲? 自己开个branch去玩啦
作者: lnmlee 2018-11-15 15:10:00
你想要长期领养这只野猫的时候你就会想为他洗澡
作者: ak2840 (77529685) 2018-11-16 14:46:00
打掉就不是重构了 那是重练