23 个回答

无药可救,放任不管。如果没有重构任务建议还是保持最小化修改的思想去做方案和写代码。这动一下可能就是三天的无偿加班了还会安一个菜b的title。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

先分析出什么问题,是逻辑bug 还是业务需求变更,需要在当前逻辑增加新逻辑

1.如果是逻辑bug先调试 看看能不能打补丁修复,能的话就更好,修复不了 就需求想想怎么重写代码
2.如果是增加新逻辑的话 就没必要重写了 直接增加新逻辑

已参与 「极客观点」 ,欢迎正在阅读的你也加入

情况一:

时间充裕的话,走走断点,梳理梳理;

情况二:

赶工期的话,能不动则不动,代码和你有一个能跑就行;

情况三:

本着负责任的心态,建议新拉分支,在已完成需求的情况下,加班加点优化,并添加注释;

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

重构解君愁。不过重构开始前,最好有测试框架和足够的测试用例做保障。

if ... else ... 是比较常见的重构标的,经过整理一般都能收获不错的效果。常见方法有:

  1. 条件语义化。即把 if (a === b && getAppType(a) === AppType.SomeType) 这样很长的条件,修改为 if (checkAIsSomeType(a)) 这样较短且能描述逻辑的函数。
  2. 提前退出。减少 else 的使用,尽量 if (xxxx) return oooo
  3. 过程语义化。即把比较长的代码整理成函数返回结果。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

站在旁观者角度,我也许很冷漠的瞄一眼,然后会对你说“调试分析看看不就得了,不调试分析你怎么知道问题在哪儿?”

哈哈,开个玩笑,大家同在一个技术社区,都是兄弟,将心比心,我对这种遭遇表示非常同情,甚至是情感共鸣。如果楼主经常遇到类似情况。
我的建议是选择一个跑吧,要不代码跑,要不你跑。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

能运行的代码千万不要修改,这种一但修改BUG不断

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

如果你能保证自己修改而不出问题的话,那就可以动,如果不能还是放任不管吧,反正动了,你需要测试完全没有问题,给自己增加工作量的事情就算了吧。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

新手上路,请多包涵

如果有丰富的时间,那么了解完整整体逻辑后重构,把那些超长的判断逻辑提取出来,进来简短。
否则请不要管他,能跑就行!

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

能跑通, 别动

有 bug, 小 bug 可以改一下, 大改, 评估工期了解完整业务再动


已参与 「极客观点」 ,欢迎正在阅读的你也加入。
新手上路,请多包涵

不改变逻辑的情况下,可以根据功能分解成方法,然后在方法内再进行梳理,不过要确保不要改出bug

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

我觉得这种屎山已经没得救了,包括我自己目前也在公司项目中发现大量屎山,但是我根本不会管,我只会尽量让我自己避免写出这样的代码。只要能跑就不要动他,老板不会因为你清理了一座屎山而夸奖你,相反的,你要是把屎山搞崩了不能运行了老板一定会骂你[手动滑稽]。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

粗看了一眼,每次if完事,return就可以了

不需要else的部分,直接缩进左移

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

如果没有时间,一定程度上来说不建议重构,因为这可能比你想象中要花费的时间多的多。
我粗略看了代码,感觉有点像是构建返回的视图结果之类的。
代码复杂程度不高,优化空间肯定是有的,可以尝试封装函数,将代码变得更加语义化。
如果这些代码复用性不高,我建议还是不要尝试重构了,收获不高。
如果是秉承着学习的态度,想要试着如何优化代码,那我觉得还是拯救一下的,前提是多准备点测试用例。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。
新手上路,请多包涵

既然代码能跑通就不要轻易改动,
也有可能是历史原因,不断修改业务罗就有现在这种情况了。


已参与 「极客观点」 ,欢迎正在阅读的你也加入。

如果没有重构,程序的内部设计(或者叫架构)会逐渐腐败变质。当人们只为短期目的而修改代码时,他们经常没有完全理解架构的整体设计,于是代码逐渐失去了自己的结构。程序员越来越难通过阅读源码来理解原来的设计。代码结构的流失有累积效应。越难看出代码所代表的设计意图,就越难保护其设计,于是设计就腐败得越快。经常性的重构有助于代码维持自己该有的形态。

主动请求作战,你不维护,就是下一个人维护;你不痛苦,就是下一个人痛苦;
程序开发并不是为了把痛苦和快乐留给谁;而是撸出一个健壮好、易维护、少bug的系统

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

看你想不想改了,如果你决心要优化,就得从头把逻辑理一遍,可能会花费大量时间。
我的建议是,非必要情况下,可以把优化作为TODO,先把当前优先的任务完成再说。

那么从代码层面来说,条件判断流程,最好能够扁平化,也就是一次判断进入后,即可完成逻辑。多个条件判断可以使用一个对象来优化,比如

const caseRes = {
    isPost: a && b,
    hasBorder: c || d
}

当然扁平化只是理想状态,很多时候还是会需要嵌套的逻辑判断,那就可以抽成函数,尽量作为通用的逻辑判断。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

千万不要让写这块代码的兄弟辞职,重金保留!不然除了他,没人改的了!23333.

玩笑归玩笑。这个还是要考虑投入产出比再决定何去何从的。比如这块代码是很重要的项目里的核心代码吗?是否需要长期维护啊?如果是的话,建议还是跟领导提一下(或者找有小迭代的机会),说明利弊,要时间重新梳理重构下吧,后续真的没法维护了,再加业务逻辑,我感觉这个危楼就要倒啦。
但如果是个两年才迭代一下的很成熟的项目,而且自己手上有更重要、或更有技术挑战的事情做的话,还是离它远点吧。

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

大致看了下,条件太多,不建议改动,条件稍微不对,改了容易出问题。
如果时间充裕的话,就像楼上说的,把条件定义在一个变量里面,看起来会好一点。


已参与 「极客观点」 ,欢迎正在阅读的你也加入。
新手上路,请多包涵

结合实际情况来吧,如果有需求变动,即便是shi一样的代码那还不是要去改,结合新需求来分析出到底是重构好一点,还是在原来的基础上去做变动,大的需求变更对这种代码肯定是重构更好一点

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

我觉得如果公司愿意给你足够的时间让你重构,可以尝试重构;如果时间紧、任务重,那就暂时放下自己的重构想法,只要能正常运行就行。这种嵌套是历史难题,神仙遇到都会怕三分,所以还是慎重重构。
已参与 「极客观点」 ,欢迎正在阅读的你也加入。

代码和你,只有一个能跑

已参与 「极客观点」 ,欢迎正在阅读的你也加入。

如果自己能理清楚逻辑,可以试试重构。
不然的话 还是建议别动...

尽量不要动它,如果非要动。单元测试必须先行

已参与 「极客观点」 ,欢迎正在阅读的你也加入。
撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进