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

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

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

    影响到业务未来的,影响到性能的支持。炫技的自己一边玩儿去。。
        102
    mysunshinedreams   37 天前
    理解重构的意义,但并不支持。
        103
    wupher   37 天前
    能理解,不一定能支持。

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

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

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

    我觉得重构其实根本不需要任何的理解和支持。
    某段代码(因为需求原因)需要作修改的时候就直接顺便重构掉了。
        107
    liuzhaowei55   37 天前
    我是程序,理解也知道重构的好处,但是重构是在太难了。只能是在不断淘汰老业务的时候去演进。
        108
    no1xsyzy   37 天前   ♥ 1
    @CHYK 我觉得你说的根本不是重构,而是修改。
    重构的核心不是不发生任何改变吗?重构完除非调 commit 或者记得原本的代码否则根本不可能发现重构了。
    更何况重构不可能解决、也不太可能帮助解决千年虫问题和年号问题,要能解决一定是用了未定义行为,或者编译器或者运行时有 bug。
        109
    troycheng   37 天前
    参与了两个大规模的系统重构(其中一个彻底重写百科,没错,是百度的那个百科),如果没有特别强烈的需求(比比如已经严重拖累业务发展),一般是不会获得支持的,业务系统涉及非技术的因素太多。
        110
    CHYK   37 天前
    @no1xsyzy 我大概能理解你所说的理性化的,或者理论化的"重构",大概就是修改一个原型,接口的实现,而不改变接口本身。但是现实情况是,重构一般是长期,局部化的调整,甚至是架构调整,甚至是一个人或者团队的资源调整。
    (这个没有经历过的人大概不会明白,简单就是说,往往是以重构的名义,实际也是重构,但是期间会做转换核心资源的调整,可能原来是围绕 Amd 这个人,然后一点点慢慢局部替换,最后就编程 intel 了)
    换言之,人写代码,是既要考虑人,也要考虑代码。不能只考虑代码本身呀。(您应该不是 robot 发言)

    至于后面说的老大难的问题,甚至 bug,这个可以叫做 fix,但当时确实是可以支撑下去的。也就是我上面的核心观点:
    业务走不下去了么?需要提重构这种事儿。具体点儿,以往那个千年虫的问题,当时他就能解决,为什么他要甩锅给后来的人,且当时用的时候也是没有问题的,只不过 1900 和 2000 出现的时候(也就是他开发时的后面),那时才叫 bug,如果当时的人解决,就是重构了。然后这些前辈却没有,可想而知重构不是那么容易。(可能我没有说清楚)

    其实我可以反问您,我耗费这么人力,时间,财力搞的重构对于当前的业务有啥益处?后来的问题,后来的人不能搞么?这个东西为啥一开始没有就设计好?既然一开始没有设计好(又不是我们设计的原型),现在又能用,何故看了一本重构就来谈重构?

    私以为,所谓的重构,clean code,不过是程序员自己的消遣,在领导面前 show own profession,然做过独立开发者,自己要解决生存,赚钱问题时,这。。。

    总之,我不喜欢重构(尤其是前一个离职的人花两个礼拜写的东西,要我接下来的 2 个月都在维护和重构他的东西,所谓的兜底,所谓的擦屁股)。要么就推翻重来。要么就开始设计好。
        111
    fancymax   37 天前 via iPhone
    有强制的单元测试和 UI 测试覆盖率要求~没写测试的 pr 无法 merge
        112
    Yiki   37 天前
    重构不可能把
    直接重写吧……
        113
    qiumaoyuan   37 天前
    @no1xsyzy 有这样一个回复真的难得。
        114
    luozic   37 天前
    重構個鳥,直接運行不了就把老的幹死,假裝換個新的繼續。 那麽公司 /軟件都死了,不少一個新的垃圾系統。
        115
    iamjs   37 天前
    已经满足不了未来 1 年的业务需求。分出一个小 team 来逐步重构。完整测试后进行更迭。。
        116
    lovejunjie1   37 天前
    说点最近遇到的案例。之前追漫画用的大妈之家( dmzj )。最近他们老大说,为了以后的发展,我们要迁移服务器。可是网站用的祖传代码,已经多年没有维护了。新招的技术员一脸懵逼。啧啧,真的惨。现在已经四周了。技术员不知道重构到哪个部分了。现在晚上 12 点之后还是会断网的,大概是更新服务器的码子吧。
    这事儿怎么评价呢……是苟且苟出来问题了。被动重构,难受的一比……
        117
    Marlon   37 天前
    天天在重构,关键是产品流程细节都没理清楚。。。/(ㄒoㄒ)/~~
        118
    bluefalconjun   37 天前
    除非开发新模块 否则绝不重构...

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

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

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

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

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