O código de refatoração cheira no código de formulários da Web ASP.NET atrás de arquivos: é arriscado? É sábio? É uma perda de tempo?

Seu plano, ou limpar a lógica nos ifs (nos casos em que a estrutura pacman é uma ordem ou exibição ineficiente das condições) é geralmente o local para iniciar o IMHO.

Quanto a se vale a pena o esforço:

• você espera estar mudando muito essa página?
• você tem dificuldade em entender o que está acontecendo lá ao ponto de ter medo de modificá-lo?
• você acha que está causando um problema de desempenho ou estabilidade?
• não há razão real de ter sido feito dessa forma em primeiro lugar?
• seria trivial validar manualmente a correção do re-fator?

IMHO, a menos que você tenha respostas "sim" strongs para essas questões, refazer o fator é um exercício questionável quando comparado ao risco de ter um erro e o fato de você estar acrescentando novo valor em outro lugar com seu tempo.

É arriscado na ausência de testes automatizados. É claro que você vai testar à medida que avança, mas isso é entediante e propenso a erros. O ideal seria você escrever testes unitários capturando o comportamento atual, mas isso nem sempre é viável.

Tendo estado nesta posição antes (com PHP), se o código realmente fede, refatore-o muito devagar e com muito cuidado.

Acho que o som do seu plano - pegue o método longo, divida-o com espaço em branco em parágrafos e experimente o método Extrair. A maneira como você faz isso depende de quantas variáveis estão em jogo e de como elas interagem. Tente rastrear as dependências de um parágrafo antes de começar.

Vale a pena? Se o código é realmente horrível, e seu horror está começando a se espalhar, então é hora de ficar preso lá. Se estiver funcionando bem por muito tempo, corre o risco de introduzir erros em algo que, por enquanto, apenas trabalha.

0. Descubra qual é a lógica das instruções if.

Muitas vezes, quando estou olhando para um conjunto de pac-mans, descubro que, se eu apenas extrair algo como uma tabela de verdade de todas as condições envolvidas, posso elaborar um caminho muito melhor para resolver o problema.

Dessa forma, você também pode avaliar se existe um método melhor, como você pode dividi-lo ainda mais (e esse é um grande problema com esse tipo de código) se existem falhas na lógica.

Tendo feito isso, você provavelmente pode dividi-lo em algumas declarações de switch e alguns métodos e salvar o próximo mook pobre que tem que passar pelo código de um monte de problemas.