Eu conheço esta situação muito bem. Quando fico preso dessa maneira, tento ter diferentes pontos de vista sobre o projeto.
1.) Ponto de vista do usuário / cliente - use feedback
Infelizmente, estamos presos em nosso código de uma forma que não conseguimos enxergar nossas próprias falhas porque usamos nossos aplicativos da maneira como os codificamos.
Veja como as pessoas o usam e tente descobrir qual seria a orientação mais intuitiva do usuário.
Brinque com protótipos de interface do usuário.
Isso parece ser divertido, mas se você descobrir que seria forçado a recodificar partes enormes de seu código apenas alterando a lógica de uso do que é hora de iniciar um ciclo de reformulação.
2.) Faça uma análise funcional do seu código e visualize-o
Alguns IDEs e estruturas empurram você para, por exemplo misturando UI e código backend. Se você deixar isso acontecer, em algum dia você enfrentará a situação em que sua base de código dificilmente pode ser mantida por causa de nebulosas e difíceis de quebrar dependências. Especialmente misturar o código de interface do usuário com outro código pode levar a código de espaguete e funcionalidade redundante.
Divida seu código em blocos funcionais, como por exemplo classes de banco de dados, classes de comunicação, classes de interface do usuário, classes principais, etc. e fornecem os nomes de fala dos blocos de função.
Então visualize a funcionalidade com uma ferramenta gráfica (eu uso uma ferramenta de mapeamento mental) para descobrir se sua estrutura é lógica e modular o suficiente para que você possa reutilizar blocos de códigos enormes para projetos diferentes e você pode substituí-los por versões mais novas sem grande dor.
A melhor maneira de fazer isso na minha experiência é criar um documento que visualize todas as dependências entre suas classes e suas chamadas do seu código. O resultado é uma visualização do design da sua interface.
Se este mapa de código se parece com um cluster completo *** do que é hora de agir.
Se ainda não aconteceu, você deve pensar em uma convenção de nomenclatura adequada que represente sua estrutura de código de uma forma que você não precise pensar em como chamá-la e o que ela faz.
3.) Use abordagens comuns para garantia de qualidade
Meu favorito é o FMEA. Em termos de codificação, isso significa não apenas analisar o que deu errado no passado, mas também pensar sobre o que poderia dar errado. Um exemplo bastante comum é uma conexão de rede descartada de repente. Depois de ter feito isso, você pode classificar as condições de erro por consequências, como perda de dados, falha, cálculo incorreto e julgar o impacto no usuário.
Se ainda não tiver feito isso, a definição de erros simplificados e as classes e rotinas de exceção podem ajudá-lo a manter seu código limpo e correto. A melhor maneira é implementá-las em cada nova paz de código antes mesmo de começar a escrever qualquer outra coisa. (Bem, eu sou culpado nem sempre para seguir este conselho eu mesmo.)
Além disso, ajudou-me a gerar e actualizar frequentemente uma "lista de propostas de melhoria" para o meu próprio código. (Para ser honesto ainda há muito código em meus projetos dos quais definitivamente não tenho orgulho.)
Também tento reservar tempo para coletar e dar uma olhada no código de práticas recomendadas de documentações da API, conferências de desenvolvedores ou revistas de desenvolvedores.
Até este ponto, não há necessidade de tocar no seu código. É simplesmente saber o que está errado e encontrar uma maneira de definir como melhorar seu código.
Finalmente, algumas dicas para o trabalho diário de um velho peido. Tente evitar morder mais do que você pode comer.
Isso leva a muita pressão para codificação limpa. Você raramente tem tempo para fazer isso direito, mas você terá que dedicar um tempo para consertar as falhas depois.
Nada é tão duradouro quanto a solução provisória, mas quando ela se rompe é sempre tarde para consertá-la a tempo. Exemplos são hacks desagradáveis ou exceções estranhas que eu usei para fazer algo funcionar, por exemplo, uma falha no framework ou sistema operacional subjacente. E então a falha é consertada ou a nova versão simplesmente descarta a API…
Se você está preso e forçado a encontrar uma solução alternativa do que fazer comentários e fazer anotações que devem ser revisadas de tempos em tempos.
Normalmente ficamos cada vez melhor porque aprendemos algo novo.
Se você encontrar uma maneira melhor de implementá-lo o mais rápido possível.
Caso contrário, você pode se encontrar codificando a solução alternativa para a solução alternativa e a exceção da exceção um dia.
(Aquele que está sem pecado entre vocês, deixe-me jogar o primeiro byte.)