V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Livid
V2EX  ›  程序员

在你所服务的公司里,你的直接上级能够理解和支持重构的意义吗?

  •  
  •   Livid · 2019-04-12 11:01:38 +08:00 · 13614 次点击
    这是一个创建于 1812 天前的主题,其中的信息可能已经有所发展或是发生改变。
    156 条回复    2019-04-13 11:26:35 +08:00
    1  2  
    hp3325
        101
    hp3325  
       2019-04-12 14:42:22 +08:00 via Android
    我就是上级,基本原则就是能跑的东西不要动!

    影响到业务未来的,影响到性能的支持。炫技的自己一边玩儿去。。
    mysunshinedreams
        102
    mysunshinedreams  
       2019-04-12 14:45:37 +08:00
    理解重构的意义,但并不支持。
    wupher
        103
    wupher  
       2019-04-12 14:51:53 +08:00
    能理解,不一定能支持。

    我自己也是,尤其是大规模重构,尤其是底层架构重构。

    越是深年旧坑越是如此,重构后引发的问题往往比之前还多,填坑的小伙伴也往往从踌躇满志到心力交瘁。

    现在我宁可建议搞新系统,然后从业务上逐渐予以淘汰,或将旧业务予以迁移。
    xomix
        104
    xomix  
       2019-04-12 14:53:37 +08:00
    做上级的时候理解过,在老项目里面引入新框架做过重构,然后,今后再有机会宁可重做也不重构了。
    undefinedz
        105
    undefinedz  
       2019-04-12 15:01:11 +08:00
    不能,业务稳定第一,老大的意思是:你来重构,多出的测试工作量,运维工作量谁来做?如果出了产线问题谁来担责?
    no1xsyzy
        106
    no1xsyzy  
       2019-04-12 15:05:07 +08:00   ❤️ 1
    看完感觉说的 “重构” 都不是一个事。

    我觉得重构其实根本不需要任何的理解和支持。
    某段代码(因为需求原因)需要作修改的时候就直接顺便重构掉了。
    liuzhaowei55
        107
    liuzhaowei55  
       2019-04-12 15:05:29 +08:00
    我是程序,理解也知道重构的好处,但是重构是在太难了。只能是在不断淘汰老业务的时候去演进。
    no1xsyzy
        108
    no1xsyzy  
       2019-04-12 15:12:34 +08:00   ❤️ 1
    @CHYK 我觉得你说的根本不是重构,而是修改。
    重构的核心不是不发生任何改变吗?重构完除非调 commit 或者记得原本的代码否则根本不可能发现重构了。
    更何况重构不可能解决、也不太可能帮助解决千年虫问题和年号问题,要能解决一定是用了未定义行为,或者编译器或者运行时有 bug。
    troycheng
        109
    troycheng  
       2019-04-12 15:13:05 +08:00
    参与了两个大规模的系统重构(其中一个彻底重写百科,没错,是百度的那个百科),如果没有特别强烈的需求(比比如已经严重拖累业务发展),一般是不会获得支持的,业务系统涉及非技术的因素太多。
    CHYK
        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 个月都在维护和重构他的东西,所谓的兜底,所谓的擦屁股)。要么就推翻重来。要么就开始设计好。
    fancymax
        111
    fancymax  
       2019-04-12 15:32:01 +08:00 via iPhone
    有强制的单元测试和 UI 测试覆盖率要求~没写测试的 pr 无法 merge
    Yiki
        112
    Yiki  
       2019-04-12 15:40:33 +08:00
    重构不可能把
    直接重写吧……
    qiumaoyuan
        113
    qiumaoyuan  
       2019-04-12 15:43:54 +08:00
    @no1xsyzy 有这样一个回复真的难得。
    luozic
        114
    luozic  
       2019-04-12 15:45:00 +08:00
    重構個鳥,直接運行不了就把老的幹死,假裝換個新的繼續。 那麽公司 /軟件都死了,不少一個新的垃圾系統。
    iamjs
        115
    iamjs  
       2019-04-12 15:45:44 +08:00
    已经满足不了未来 1 年的业务需求。分出一个小 team 来逐步重构。完整测试后进行更迭。。
    lovejunjie1
        116
    lovejunjie1  
       2019-04-12 15:53:08 +08:00
    说点最近遇到的案例。之前追漫画用的大妈之家( dmzj )。最近他们老大说,为了以后的发展,我们要迁移服务器。可是网站用的祖传代码,已经多年没有维护了。新招的技术员一脸懵逼。啧啧,真的惨。现在已经四周了。技术员不知道重构到哪个部分了。现在晚上 12 点之后还是会断网的,大概是更新服务器的码子吧。
    这事儿怎么评价呢……是苟且苟出来问题了。被动重构,难受的一比……
    Marlon
        117
    Marlon  
       2019-04-12 15:54:48 +08:00
    天天在重构,关键是产品流程细节都没理清楚。。。/(ㄒoㄒ)/~~
    bluefalconjun
        118
    bluefalconjun  
       2019-04-12 16:03:55 +08:00
    除非开发新模块 否则绝不重构...

    N 年的客户你说扔就扔吗... 别说 CEO 了 光销售就得过来骂娘了...
    wormcy
        119
    wormcy  
       2019-04-12 16:08:28 +08:00
    不理解不支持 不增加新功能的重构是个笑话
    otakustay
        120
    otakustay  
       2019-04-12 16:11:28 +08:00
    @lovejunjie1 我是真从来没见过大妈之家这种敢在线上重构的玩法……
    crs0910
        121
    crs0910  
       2019-04-12 16:12:16 +08:00   ❤️ 1
    # 怎么对经理说
    “该怎么跟经理说重构的事?”这是我最常被问到的一个问题。毋庸讳言,我见过一些场合,“重构”被视为一个脏词——经理(和客户)认为重构要么是在弥补过去犯下的错误,要么是不增加价值的无用功。如果团队又计划了几周时间专门做重构,情况就更糟糕了。如果他们做的其实还不是重构,而是不加小心的结构调整,然后又对代码库造成了破坏,那可就真是糟透了。
    如果这位经理懂技术,能理解“设计耐久性假说”,那么向他说明重构的意义应该不会很困难。这样的经理应该会鼓励日常的重构,并主动寻找团队日常重构做得不够的征兆。虽然“团队做了太多重构”的情况确实也发生过,但比起做得不够要罕见得多了。
    当然,很多经理和客户不具备这样的技术意识,他们不理解代码库的健康对生产率的影响。这样的情况下我会给团队一个较有争议的建议:不要告诉经理!
    这是在搞破坏吗?我不这样想。软件开发者都是专业人士。我们的工作就是尽可能快速创造出高效软件。而我的经验告诉我,对于快速创造软件,重构可带来巨大帮助。如果需要添加新功能,而原本设计又使我无法方便的修改,我发现先重构再添加新功能会更快些。如果要修补错误,就得先理解软件的工作方式,而我发现重构是理解软件的最快方式。受进度驱动的经理要我尽可能快速完成任务,至于怎么完成,那就是我的事了。我领这份工资,是因为我擅长快速实现新功能。我认为最快的方式就是重构,所以我就重构。

    —— 摘录自《重构-第 2 版》第 2 章 ”重构的原则“
    chiu
        122
    chiu  
       2019-04-12 16:12:42 +08:00 via Android
    有重构的工作内容和工作量,不过优先级会比较低
    gaocc
        123
    gaocc  
       2019-04-12 16:18:16 +08:00
    基本不支持,没有实际效益,而且出错锅没的甩,反而有损失。
    所以架构特别重要的了,重写很多时候不然重新写,很现实
    lovejunjie1
        124
    lovejunjie1  
       2019-04-12 16:19:36 +08:00
    @otakustay 2333333,这下你看到了。大妈之家的同志辛苦了。如果他在看 V2,估计应该会看到这个帖子吧。(最近肯定是没空了。哈哈哈哈哈哈)
    robinlovemaggie
        125
    robinlovemaggie  
       2019-04-12 16:25:09 +08:00
    我的老板只喜欢他看得见的符合他审美的重构,除此之外,都是无稽之谈。
    saulshao
        126
    saulshao  
       2019-04-12 16:29:04 +08:00   ❤️ 1
    首先,要说清楚什么是重构。我理解重构是指将代码的实现方法在不改变输入输出的前提下,修改内部结构。这可能包括但是不限于下面的事情:
    1. 将原本在某个函数内的几行代码移出,使其成为一个新的函数。
    2. 将某些(少量)代码重写,以提高效率或者增加可读性。
    3. 将整个包的文件夹结构调整,新增或者删除某些文件 /文件夹。
    4. 将整个项目重写,期待之后达到一个理想的效果。
    其实上述的这些事情,后面的 2 个会严重影响整个项目的“可运行性”,可能需要运行完整的业务场景测试才敢干。我不建议制定一个长期的计划干后面的 3 和 4。
    如果只是 1 和 2,我的建议是不要告诉经理,自己干就行了,至于重构之后是更好还是更差了,其实是一个见仁见智的事情。因为可读性其实不是一个客观标准。举个例子:有人认为射雕英雄传更容易理解,而有的人则认为西方哲学史更简单易懂。
    而效率则需要运行某些测试或者遇到特定的场景才能够证实。
    因此,我的结论是:重构不是一个总是正确的事情,既然如此,那就应该基于个人的选择来决定。
    linergoudan
        127
    linergoudan  
       2019-04-12 16:38:43 +08:00
    重构是不可能重构的,只要能跑,就算是屎也要让你在屎里翻滚
    thfurior
        128
    thfurior  
       2019-04-12 16:40:46 +08:00
    不能,先不说重构花的时间,那么多的测试用例谁来写?
    reus
        129
    reus  
       2019-04-12 16:56:59 +08:00
    @thfurior 重构难道不是可以用旧的测试用例?
    lincanbin
        130
    lincanbin  
       2019-04-12 17:14:05 +08:00
    看重构能不能被认可为绩效和产出,能就会推动,不能就不会。
    Michaelssss
        131
    Michaelssss  
       2019-04-12 17:20:17 +08:00
    没有重构,当业务发生变更后,用新业务替换掉老业务...你学到的新的视野什么的再新业务里面做完就好了,反正之后还是一坨屎
    CoCoMcRee
        132
    CoCoMcRee  
       2019-04-12 17:25:10 +08:00
    用新东西开发, 一般大家讨论下, 做下技术选型,觉得坑能趟过去的 那就干.
    要是老代码, 业务不变的话, 基本会可能回去重构.
    qiyuey
        133
    qiyuey  
       2019-04-12 17:54:11 +08:00
    取决于“成本”和“收益”
    KunMinX
        134
    KunMinX  
       2019-04-12 17:54:35 +08:00 via iPhone
    又不是不能用,又不是用户痛点,谁在乎你因为架构反人类而加班呢。

    何况,十个人里边有 9 个人并不真正的懂得重构及其价值,他们对重构的理解仅仅停留在形式上,而不是事实规律原则上。

    重构的目标是解藕,解藕的本质是职责上的分离,而不是形式上的假分离。都 9102 年了,某些社区还在疯传 MVP 架构,这是 3 年前就已弃用的违背原则的垃圾架构。
    huisezhiyin
        135
    huisezhiyin  
       2019-04-12 17:55:46 +08:00 via iPhone
    我一度以离职来胁迫和告诉领导重构的意义
    jinhan13789991
        136
    jinhan13789991  
       2019-04-12 18:24:28 +08:00
    java 编程思想里有一句话:
    继续错误的责任由他人承担,而承认错误则由自己承担。
    你愿意承担别人的错误吗?
    no1xsyzy
        137
    no1xsyzy  
       2019-04-12 19:53:44 +08:00
    @CHYK 我同意你说的 “以重构的名义”,但我不认可你说的 “实际也是重构”。
    你这个叫 “重架构”( restructuring —— 我瞎编的,不清楚有没有这个词,或者更正确的词)和技术性调整而不是 “重构”( refactoring )。甚至可能同时进行重构和其他事情。
    不要同时做两件事,更不要在同时做两件事时以为自己在做一件事。
    一个简单的判断:重构应该能够在 20 分钟内完成(或者按自己的番茄钟时间),并且这 20 分钟就好像从未存在一样消失了。
    tairan2006
        138
    tairan2006  
       2019-04-12 19:56:09 +08:00
    代码规模小,重构不如重写
    diggerdu
        139
    diggerdu  
       2019-04-12 20:08:04 +08:00 via iPhone
    有个组整个双月的计划都是重构
    fsafdasfsdafsd
        140
    fsafdasfsdafsd  
       2019-04-12 20:11:05 +08:00
    @CHYK
    看你的回答,我觉得你没理解重构。
    no1xsyzy
        141
    no1xsyzy  
       2019-04-12 20:14:53 +08:00
    @CHYK 至于千年虫,我感觉更像是重构时 **意外** 解决的,这我有过不少经历,事后的感觉就是 “欸?这么说我原本的代码是有 bug 的?”。
    可能某些时候算是代码健壮性的一部分,健壮性也确实是重构的目的之一,但不是靠重构本身完成的,而是重构期间形成的可读性。有人说:没 bug 的代码只有非常复杂以至于看不出 bug 和非常简单以至于看出没 bug 两种。重构的一个目标就是尽可能将前一种变成后一种。
    min
        142
    min  
       2019-04-12 20:20:35 +08:00
    在前司,本上级的团队基本没有做过重构,新的活架构做好一点就行了,精力主要华仔逐步引入更合理的架构设计风格和工具、框架行。
    没有空闲的资源去重构老项目。
    gimp
        143
    gimp  
       2019-04-12 20:27:12 +08:00
    理解并支持,当然,团队小,项目也小
    banxi1988
        144
    banxi1988  
       2019-04-12 20:38:26 +08:00
    我想重构,老大想重写。
    polun
        145
    polun  
       2019-04-12 20:39:20 +08:00
    不能。
    ezreal
        146
    ezreal  
       2019-04-12 20:40:12 +08:00 via Android
    不能
    anyele
        147
    anyele  
       2019-04-12 20:42:07 +08:00 via Android
    能,因为上级是技术出身
    qiumaoyuan
        148
    qiumaoyuan  
       2019-04-12 21:58:20 +08:00   ❤️ 1
    @no1xsyzy 其实掌握重构的程序员,从来不会把问题积累到需要专门拿出大段时间来做所谓的“重构”,脑子里设置好了各种触发器,一遇到 bad smell 很容易就识别出来,并警觉起来分析代码需要不需要整理。而另外的程序员即使专门花了大块时间做所谓的“重构”,也依然会留下很多糟糕的代码。我觉得这种事情很难存在处于中间状态的人,要么从来不留需要清理的代码,要么即使“重构”了他也必然清理不干净。有句话叫时时勤拂拭,勿使惹尘埃,我觉得在重构这件事上很适用。

    现在多数程序员连“消除重复代码”的必要性都还认为是需要讨论的事情,在这种意识普遍存在的前提下,我觉得重构很多时候无从谈起。像 110 楼倒数第二段话这种价值观完全相反的,我根本没有讨论的欲望。
    b0x
        149
    b0x  
       2019-04-12 23:20:21 +08:00
    可以简化成一个成本问题.
    所以要看这个"直接上级"是站在什么角度来考虑成本了.
    niubee1
        150
    niubee1  
       2019-04-12 23:35:52 +08:00
    不定期重构的系统, 迟早会腐坏
    sampeng
        151
    sampeng  
       2019-04-12 23:39:09 +08:00
    分情况。。比如服务器支撑不了更多业务需求。不重构你就别来埋怨服务器老崩。。
    sampeng
        152
    sampeng  
       2019-04-12 23:43:35 +08:00
    @crs0910 我其实也是这么干的。。。有把握的根本不会告诉上级,做了再说。。。当然。这也是有风险的。所有负责的测试总是说我这为什么出些莫名其妙的问题。还好频率很低,不然就哪凉快哪呆着了。。
    wikiisviki
        153
    wikiisviki  
       2019-04-12 23:51:25 +08:00 via iPhone
    支持,平时闷声不吭随手就重构才是好习惯,代码不是一次性写完美的,随手就改随手就改随手就改。
    把重构花费的时间和人力平摊到每时每刻才是真正的成本。
    单独花时间重构就像是跟老板说我之前有好多问题没解决,快要爆了,给我点时间。但是你之前跟老板承诺的时间可能很短。
    软件开发流程中也没有把重构列为单独一项
    而重构是编码过程中的基本意识和操作。
    我也在实践。
    pipinstallpy
        154
    pipinstallpy  
       2019-04-13 08:12:39 +08:00
    根据实际情况看,一般来说不会轻易的重构
    CHYK
        155
    CHYK  
       2019-04-13 09:45:08 +08:00
    @no1xsyzy 求同存异。人类一思考,上帝就发笑。阶段性认识,或许我之后也会随着阅历成长,经验堆积有同意你的看法。赞👍。
    mintist
        156
    mintist  
       2019-04-13 11:26:35 +08:00
    不能,不见兔子不撒鹰,,,
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   958 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 20:38 · PVG 04:38 · LAX 13:38 · JFK 16:38
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.