这是一个创建于 2052 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
101
hp3325 2019-04-12 14:42:22 +08:00 via Android
我就是上级，基本原则就是能跑的东西不要动！
影响到业务未来的，影响到性能的支持。炫技的自己一边玩儿去。。 |
 |
102
mysunshinedreams 2019-04-12 14:45:37 +08:00
理解重构的意义，但并不支持。
|
 |
103
wupher 2019-04-12 14:51:53 +08:00
能理解，不一定能支持。
我自己也是，尤其是大规模重构，尤其是底层架构重构。 越是深年旧坑越是如此，重构后引发的问题往往比之前还多，填坑的小伙伴也往往从踌躇满志到心力交瘁。 现在我宁可建议搞新系统，然后从业务上逐渐予以淘汰，或将旧业务予以迁移。 |
 |
104
xomix 2019-04-12 14:53:37 +08:00
做上级的时候理解过，在老项目里面引入新框架做过重构，然后，今后再有机会宁可重做也不重构了。
|
 |
105
undefinedz 2019-04-12 15:01:11 +08:00
不能，业务稳定第一，老大的意思是：你来重构，多出的测试工作量，运维工作量谁来做？如果出了产线问题谁来担责？
|
 |
106
no1xsyzy 2019-04-12 15:05:07 +08:00  1
看完感觉说的 “重构” 都不是一个事。
我觉得重构其实根本不需要任何的理解和支持。 某段代码（因为需求原因）需要作修改的时候就直接顺便重构掉了。 |
 |
107
liuzhaowei55 2019-04-12 15:05:29 +08:00
我是程序，理解也知道重构的好处，但是重构是在太难了。只能是在不断淘汰老业务的时候去演进。
|
|
108
no1xsyzy 2019-04-12 15:12:34 +08:00 1
@CHYK 我觉得你说的根本不是重构，而是修改。
重构的核心不是不发生任何改变吗？重构完除非调 commit 或者记得原本的代码否则根本不可能发现重构了。 更何况重构不可能解决、也不太可能帮助解决千年虫问题和年号问题，要能解决一定是用了未定义行为，或者编译器或者运行时有 bug。 |
 |
109
troycheng 2019-04-12 15:13:05 +08:00
参与了两个大规模的系统重构（其中一个彻底重写百科，没错，是百度的那个百科），如果没有特别强烈的需求（比比如已经严重拖累业务发展），一般是不会获得支持的，业务系统涉及非技术的因素太多。
|
 |
110
CHYK 2019-04-12 15:27:32 +08:00
@no1xsyzy 我大概能理解你所说的理性化的，或者理论化的"重构"，大概就是修改一个原型，接口的实现，而不改变接口本身。但是现实情况是，重构一般是长期，局部化的调整，甚至是架构调整，甚至是一个人或者团队的资源调整。
(这个没有经历过的人大概不会明白，简单就是说，往往是以重构的名义，实际也是重构，但是期间会做转换核心资源的调整，可能原来是围绕 Amd 这个人，然后一点点慢慢局部替换，最后就编程 intel 了) 换言之，人写代码，是既要考虑人，也要考虑代码。不能只考虑代码本身呀。(您应该不是 robot 发言) 至于后面说的老大难的问题，甚至 bug，这个可以叫做 fix，但当时确实是可以支撑下去的。也就是我上面的核心观点： 业务走不下去了么？需要提重构这种事儿。具体点儿，以往那个千年虫的问题，当时他就能解决，为什么他要甩锅给后来的人，且当时用的时候也是没有问题的，只不过 1900 和 2000 出现的时候(也就是他开发时的后面)，那时才叫 bug，如果当时的人解决，就是重构了。然后这些前辈却没有，可想而知重构不是那么容易。（可能我没有说清楚） 其实我可以反问您，我耗费这么人力，时间，财力搞的重构对于当前的业务有啥益处？后来的问题，后来的人不能搞么？这个东西为啥一开始没有就设计好？既然一开始没有设计好(又不是我们设计的原型)，现在又能用，何故看了一本重构就来谈重构？ 私以为，所谓的重构，clean code，不过是程序员自己的消遣，在领导面前 show own profession，然做过独立开发者，自己要解决生存，赚钱问题时，这。。。 总之，我不喜欢重构(尤其是前一个离职的人花两个礼拜写的东西，要我接下来的 2 个月都在维护和重构他的东西，所谓的兜底，所谓的擦屁股)。要么就推翻重来。要么就开始设计好。 |
 |
111
fancymax 2019-04-12 15:32:01 +08:00 via iPhone
有强制的单元测试和 UI 测试覆盖率要求~没写测试的 pr 无法 merge
|
 |
112
Yiki 2019-04-12 15:40:33 +08:00
重构不可能把
直接重写吧…… |
 |
113
qiumaoyuan 2019-04-12 15:43:54 +08:00
@no1xsyzy 有这样一个回复真的难得。
|
 |
114
luozic 2019-04-12 15:45:00 +08:00
重構個鳥，直接運行不了就把老的幹死，假裝換個新的繼續。 那麽公司 /軟件都死了，不少一個新的垃圾系統。
|
 |
115
iamjs 2019-04-12 15:45:44 +08:00
已经满足不了未来 1 年的业务需求。分出一个小 team 来逐步重构。完整测试后进行更迭。。
|
 |
116
lovejunjie1 2019-04-12 15:53:08 +08:00
说点最近遇到的案例。之前追漫画用的大妈之家（ dmzj ）。最近他们老大说，为了以后的发展，我们要迁移服务器。可是网站用的祖传代码，已经多年没有维护了。新招的技术员一脸懵逼。啧啧，真的惨。现在已经四周了。技术员不知道重构到哪个部分了。现在晚上 12 点之后还是会断网的，大概是更新服务器的码子吧。
这事儿怎么评价呢……是苟且苟出来问题了。被动重构，难受的一比…… |
 |
117
Marlon 2019-04-12 15:54:48 +08:00
天天在重构，关键是产品流程细节都没理清楚。。。/(ㄒoㄒ)/~~
|
 |
118
bluefalconjun 2019-04-12 16:03:55 +08:00
除非开发新模块 否则绝不重构...
N 年的客户你说扔就扔吗... 别说 CEO 了 光销售就得过来骂娘了... |
 |
119
wormcy 2019-04-12 16:08:28 +08:00
不理解不支持 不增加新功能的重构是个笑话
 |
 |
120
otakustay 2019-04-12 16:11:28 +08:00
@lovejunjie1 我是真从来没见过大妈之家这种敢在线上重构的玩法……
|
 |
121
crs0910 2019-04-12 16:12:16 +08:00 1
# 怎么对经理说
“该怎么跟经理说重构的事？”这是我最常被问到的一个问题。毋庸讳言，我见过一些场合，“重构”被视为一个脏词——经理（和客户）认为重构要么是在弥补过去犯下的错误，要么是不增加价值的无用功。如果团队又计划了几周时间专门做重构，情况就更糟糕了。如果他们做的其实还不是重构，而是不加小心的结构调整，然后又对代码库造成了破坏，那可就真是糟透了。 如果这位经理懂技术，能理解“设计耐久性假说”，那么向他说明重构的意义应该不会很困难。这样的经理应该会鼓励日常的重构，并主动寻找团队日常重构做得不够的征兆。虽然“团队做了太多重构”的情况确实也发生过，但比起做得不够要罕见得多了。 当然，很多经理和客户不具备这样的技术意识，他们不理解代码库的健康对生产率的影响。这样的情况下我会给团队一个较有争议的建议：不要告诉经理！ 这是在搞破坏吗？我不这样想。软件开发者都是专业人士。我们的工作就是尽可能快速创造出高效软件。而我的经验告诉我，对于快速创造软件，重构可带来巨大帮助。如果需要添加新功能，而原本设计又使我无法方便的修改，我发现先重构再添加新功能会更快些。如果要修补错误，就得先理解软件的工作方式，而我发现重构是理解软件的最快方式。受进度驱动的经理要我尽可能快速完成任务，至于怎么完成，那就是我的事了。我领这份工资，是因为我擅长快速实现新功能。我认为最快的方式就是重构，所以我就重构。 —— 摘录自《重构-第 2 版》第 2 章 ”重构的原则“ |
 |
122
chiu 2019-04-12 16:12:42 +08:00 via Android
有重构的工作内容和工作量，不过优先级会比较低
|
 |
123
gaocc 2019-04-12 16:18:16 +08:00
基本不支持，没有实际效益，而且出错锅没的甩，反而有损失。
所以架构特别重要的了，重写很多时候不然重新写，很现实 |
|
124
lovejunjie1 2019-04-12 16:19:36 +08:00
@otakustay 2333333，这下你看到了。大妈之家的同志辛苦了。如果他在看 V2，估计应该会看到这个帖子吧。（最近肯定是没空了。哈哈哈哈哈哈）
|
 |
125
robinlovemaggie 2019-04-12 16:25:09 +08:00
我的老板只喜欢他看得见的符合他审美的重构，除此之外，都是无稽之谈。
|
 |
126
saulshao 2019-04-12 16:29:04 +08:00 1
首先，要说清楚什么是重构。我理解重构是指将代码的实现方法在不改变输入输出的前提下，修改内部结构。这可能包括但是不限于下面的事情：
1. 将原本在某个函数内的几行代码移出，使其成为一个新的函数。 2. 将某些（少量）代码重写，以提高效率或者增加可读性。 3. 将整个包的文件夹结构调整，新增或者删除某些文件 /文件夹。 4. 将整个项目重写，期待之后达到一个理想的效果。 其实上述的这些事情，后面的 2 个会严重影响整个项目的“可运行性”，可能需要运行完整的业务场景测试才敢干。我不建议制定一个长期的计划干后面的 3 和 4。 如果只是 1 和 2，我的建议是不要告诉经理，自己干就行了，至于重构之后是更好还是更差了，其实是一个见仁见智的事情。因为可读性其实不是一个客观标准。举个例子：有人认为射雕英雄传更容易理解，而有的人则认为西方哲学史更简单易懂。 而效率则需要运行某些测试或者遇到特定的场景才能够证实。 因此，我的结论是：重构不是一个总是正确的事情，既然如此，那就应该基于个人的选择来决定。 |
 |
127
linergoudan 2019-04-12 16:38:43 +08:00
重构是不可能重构的，只要能跑，就算是屎也要让你在屎里翻滚
|
 |
128
thfurior 2019-04-12 16:40:46 +08:00
不能，先不说重构花的时间，那么多的测试用例谁来写？
|
 |
130
lincanbin 2019-04-12 17:14:05 +08:00
看重构能不能被认可为绩效和产出，能就会推动，不能就不会。
|
 |
131
Michaelssss 2019-04-12 17:20:17 +08:00
没有重构,当业务发生变更后,用新业务替换掉老业务...你学到的新的视野什么的再新业务里面做完就好了,反正之后还是一坨屎
|
 |
132
CoCoMcRee 2019-04-12 17:25:10 +08:00
用新东西开发, 一般大家讨论下, 做下技术选型,觉得坑能趟过去的 那就干.
要是老代码, 业务不变的话, 基本会可能回去重构. |
 |
133
qiyuey 2019-04-12 17:54:11 +08:00
取决于“成本”和“收益”
|
 |
134
KunMinX 2019-04-12 17:54:35 +08:00 via iPhone
又不是不能用，又不是用户痛点，谁在乎你因为架构反人类而加班呢。
何况，十个人里边有 9 个人并不真正的懂得重构及其价值，他们对重构的理解仅仅停留在形式上，而不是事实规律原则上。 重构的目标是解藕，解藕的本质是职责上的分离，而不是形式上的假分离。都 9102 年了，某些社区还在疯传 MVP 架构，这是 3 年前就已弃用的违背原则的垃圾架构。 |
 |
135
huisezhiyin 2019-04-12 17:55:46 +08:00 via iPhone
我一度以离职来胁迫和告诉领导重构的意义
|
 |
136
jinhan13789991 2019-04-12 18:24:28 +08:00
java 编程思想里有一句话：
继续错误的责任由他人承担，而承认错误则由自己承担。 你愿意承担别人的错误吗？ |
|
137
no1xsyzy 2019-04-12 19:53:44 +08:00
@CHYK 我同意你说的 “以重构的名义”，但我不认可你说的 “实际也是重构”。
你这个叫 “重架构”（ restructuring —— 我瞎编的，不清楚有没有这个词，或者更正确的词）和技术性调整而不是 “重构”（ refactoring ）。甚至可能同时进行重构和其他事情。 不要同时做两件事，更不要在同时做两件事时以为自己在做一件事。 一个简单的判断：重构应该能够在 20 分钟内完成（或者按自己的番茄钟时间），并且这 20 分钟就好像从未存在一样消失了。 |
 |
138
tairan2006 2019-04-12 19:56:09 +08:00
代码规模小，重构不如重写
|
 |
139
diggerdu 2019-04-12 20:08:04 +08:00 via iPhone
有个组整个双月的计划都是重构
|
 |
140
fsafdasfsdafsd 2019-04-12 20:11:05 +08:00
@CHYK
看你的回答，我觉得你没理解重构。 |
|
141
no1xsyzy 2019-04-12 20:14:53 +08:00
@CHYK 至于千年虫，我感觉更像是重构时 **意外** 解决的，这我有过不少经历，事后的感觉就是 “欸？这么说我原本的代码是有 bug 的？”。
可能某些时候算是代码健壮性的一部分，健壮性也确实是重构的目的之一，但不是靠重构本身完成的，而是重构期间形成的可读性。有人说：没 bug 的代码只有非常复杂以至于看不出 bug 和非常简单以至于看出没 bug 两种。重构的一个目标就是尽可能将前一种变成后一种。 |
 |
142
min 2019-04-12 20:20:35 +08:00
在前司，本上级的团队基本没有做过重构，新的活架构做好一点就行了，精力主要华仔逐步引入更合理的架构设计风格和工具、框架行。
没有空闲的资源去重构老项目。 |
 |
143
gimp 2019-04-12 20:27:12 +08:00
理解并支持，当然，团队小，项目也小
|
 |
144
banxi1988 2019-04-12 20:38:26 +08:00
我想重构，老大想重写。
|
 |
145
polun 2019-04-12 20:39:20 +08:00
不能。
|
 |
146
ezreal 2019-04-12 20:40:12 +08:00 via Android
不能
|
 |
147
anyele 2019-04-12 20:42:07 +08:00 via Android
能，因为上级是技术出身
|
|
148
qiumaoyuan 2019-04-12 21:58:20 +08:00 1
@no1xsyzy 其实掌握重构的程序员，从来不会把问题积累到需要专门拿出大段时间来做所谓的“重构”，脑子里设置好了各种触发器，一遇到 bad smell 很容易就识别出来，并警觉起来分析代码需要不需要整理。而另外的程序员即使专门花了大块时间做所谓的“重构”，也依然会留下很多糟糕的代码。我觉得这种事情很难存在处于中间状态的人，要么从来不留需要清理的代码，要么即使“重构”了他也必然清理不干净。有句话叫时时勤拂拭，勿使惹尘埃，我觉得在重构这件事上很适用。
现在多数程序员连“消除重复代码”的必要性都还认为是需要讨论的事情，在这种意识普遍存在的前提下，我觉得重构很多时候无从谈起。像 110 楼倒数第二段话这种价值观完全相反的，我根本没有讨论的欲望。 |
 |
149
b0x 2019-04-12 23:20:21 +08:00
可以简化成一个成本问题.
所以要看这个"直接上级"是站在什么角度来考虑成本了. |
 |
150
niubee1 2019-04-12 23:35:52 +08:00
不定期重构的系统, 迟早会腐坏
|
 |
151
sampeng 2019-04-12 23:39:09 +08:00
分情况。。比如服务器支撑不了更多业务需求。不重构你就别来埋怨服务器老崩。。
|
|
152
sampeng 2019-04-12 23:43:35 +08:00
@crs0910 我其实也是这么干的。。。有把握的根本不会告诉上级，做了再说。。。当然。这也是有风险的。所有负责的测试总是说我这为什么出些莫名其妙的问题。还好频率很低，不然就哪凉快哪呆着了。。
|
 |
153
wikiisviki 2019-04-12 23:51:25 +08:00 via iPhone
支持，平时闷声不吭随手就重构才是好习惯，代码不是一次性写完美的，随手就改随手就改随手就改。
把重构花费的时间和人力平摊到每时每刻才是真正的成本。 单独花时间重构就像是跟老板说我之前有好多问题没解决，快要爆了，给我点时间。但是你之前跟老板承诺的时间可能很短。 软件开发流程中也没有把重构列为单独一项 而重构是编码过程中的基本意识和操作。 我也在实践。 |
 |
154
pipinstallpy 2019-04-13 08:12:39 +08:00
根据实际情况看，一般来说不会轻易的重构
|
 |
156
mintist 2019-04-13 11:26:35 +08:00
不能，不见兔子不撒鹰，，，
|
Select Language