极客观点
项目管理
HarmonyOS
情况一：
时间充裕的话，走走断点，梳理梳理；情况二：
赶工期的话，能不动则不动，代码和你有一个能跑就行；情况三：
本着负责任的心态，建议新拉分支，在已完成需求的情况下，加班加点优化，并添加注释；
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
重构解君愁。不过重构开始前，最好有测试框架和足够的测试用例做保障。
if ... else ... 是比较常见的重构标的，经过整理一般都能收获不错的效果。常见方法有：
- 条件语义化。即把
if (a === b && getAppType(a) === AppType.SomeType)这样很长的条件，修改为if (checkAIsSomeType(a))这样较短且能描述逻辑的函数。 - 提前退出。减少
else的使用，尽量if (xxxx) return oooo。 - 过程语义化。即把比较长的代码整理成函数返回结果。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
站在旁观者角度，我也许很冷漠的瞄一眼，然后会对你说“调试分析看看不就得了，不调试分析你怎么知道问题在哪儿？”
哈哈，开个玩笑，大家同在一个技术社区，都是兄弟，将心比心，我对这种遭遇表示非常同情，甚至是情感共鸣。如果楼主经常遇到类似情况。
我的建议是选择一个跑吧，要不代码跑，要不你跑。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
如果你能保证自己修改而不出问题的话，那就可以动，如果不能还是放任不管吧，反正动了，你需要测试完全没有问题，给自己增加工作量的事情就算了吧。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
我觉得这种屎山已经没得救了，包括我自己目前也在公司项目中发现大量屎山，但是我根本不会管，我只会尽量让我自己避免写出这样的代码。只要能跑就不要动他，老板不会因为你清理了一座屎山而夸奖你，相反的，你要是把屎山搞崩了不能运行了老板一定会骂你[手动滑稽]。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
如果没有重构，程序的内部设计（或者叫架构）会逐渐腐败变质。当人们只为短期目的而修改代码时，他们经常没有完全理解架构的整体设计，于是代码逐渐失去了自己的结构。程序员越来越难通过阅读源码来理解原来的设计。代码结构的流失有累积效应。越难看出代码所代表的设计意图，就越难保护其设计，于是设计就腐败得越快。经常性的重构有助于代码维持自己该有的形态。
主动请求作战，你不维护，就是下一个人维护；你不痛苦，就是下一个人痛苦；
程序开发并不是为了把痛苦和快乐留给谁；而是撸出一个健壮好、易维护、少bug的系统
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
看你想不想改了，如果你决心要优化，就得从头把逻辑理一遍，可能会花费大量时间。
我的建议是，非必要情况下，可以把优化作为TODO，先把当前优先的任务完成再说。
那么从代码层面来说，条件判断流程，最好能够扁平化，也就是一次判断进入后，即可完成逻辑。多个条件判断可以使用一个对象来优化，比如
const caseRes = {
isPost: a && b,
hasBorder: c || d
}当然扁平化只是理想状态，很多时候还是会需要嵌套的逻辑判断，那就可以抽成函数，尽量作为通用的逻辑判断。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
千万不要让写这块代码的兄弟辞职，重金保留！不然除了他，没人改的了！23333.
玩笑归玩笑。这个还是要考虑投入产出比再决定何去何从的。比如这块代码是很重要的项目里的核心代码吗？是否需要长期维护啊？如果是的话，建议还是跟领导提一下（或者找有小迭代的机会），说明利弊，要时间重新梳理重构下吧，后续真的没法维护了，再加业务逻辑，我感觉这个危楼就要倒啦。
但如果是个两年才迭代一下的很成熟的项目，而且自己手上有更重要、或更有技术挑战的事情做的话，还是离它远点吧。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
大致看了下，条件太多，不建议改动，条件稍微不对，改了容易出问题。
如果时间充裕的话，就像楼上说的，把条件定义在一个变量里面，看起来会好一点。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
我觉得如果公司愿意给你足够的时间让你重构，可以尝试重构；如果时间紧、任务重，那就暂时放下自己的重构想法，只要能正常运行就行。这种嵌套是历史难题，神仙遇到都会怕三分，所以还是慎重重构。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。
撰写回答
你尚未登录，登录后可以
- 和开发者交流问题的细节
- 关注并接收问题和回答的更新提醒
- 参与内容的编辑和改进，让解决方法与时俱进
无药可救，放任不管。如果没有重构任务建议还是保持最小化修改的思想去做方案和写代码。这动一下可能就是三天的无偿加班了还会安一个菜b的title。
已参与 「极客观点」 ，欢迎正在阅读的你也加入。