Eu sempre tento escrever código facilmente legível que esteja bem estruturado.
Enfrento um problema específico quando estou mexendo com algo novo. Eu continuo mudando o código, a estrutura e muitas outras coisas. No final, eu olho para o código e estou irritado com o quão complicado se tornou quando eu estava tentando fazer algo tão simples.
Depois de concluir algo, refato-o fortemente para que fique mais limpo. Isso ocorre após a conclusão na maioria das vezes e é irritante porque quanto maior o código, mais irritante é a reescrita.
Estou curioso para saber como as pessoas lidam com tanta agonia, principalmente em grandes projetos compartilhados entre muitas pessoas.
programming-practices
code-quality
Reza M.
fonte
fonte
Respostas:
Enquanto você está refatorando, está fazendo certo.
Considere o seguinte: a qualquer momento você pode traçar uma solução para o problema. No entanto, à medida que o tempo avança, você está descobrindo cada vez mais sobre o problema que o leva a encontrar soluções melhores. A primeira iteração pode ser reversa, e a última é esperançosamente elegente. Se você continuar refatorando à medida que seu conhecimento cresce, sempre terá melhores resultados. Não há atalho para pular para a solução mais elegante imediatamente sem seguir as etapas de 'aprendizado', a menos que você já tenha encontrado um problema semelhante, seja capaz de generalizar problemas anteriores ou ter sorte.
fonte
fonte
"hooby projects"soa como código escrito por Bill Cosby. "Com os IDEs e as metodologias ágeis, os KIYDS não sabem ... que código de baixo nível ... TEM TUDO SOBRE." ;)Bem, eu faço TDD com testes de unidade. Todo o mantra do TDD gira em torno do seguinte ciclo:
Como estou usando TDD, sou forçado a escrever testes de unidade. Se um teste é difícil de escrever, é um sinal de que meu design é muito complicado e precisa ser simplificado.
O ciclo não termina, a menos que você refatore para remover a redundância; portanto, na maioria das vezes, a refatoração é feita em pequenos pedaços e não consome tempo. Além disso, após cada refatoração, executo todos os casos de teste para garantir que não quebrei nada.
fonte da imagem: http://www.javacodegeeks.com/2012/05/test-driven-development-win-win.html
fonte
Todo mundo aprende a escrever um programa, escrevendo-o. A refatoração faz parte do processo, porque você está mais qualificado para escrevê-lo na segunda vez. O truque não é tentar evitar a refatoração, mas fazê-lo mais cedo e com mais frequência. Refatore assim que notar um problema, em vez de esperar até o "fim".
fonte
Depois de escrever e depurar o código, reserve esse código e escreva-o novamente de uma maneira diferente. Varie as estruturas de dados. Ou as estruturas de controle. Experimente designs malucos. Repetir. Geralmente, a estrutura de código mais limpa não é imediatamente óbvia e, ao tentar diferentes abordagens, você pode encontrar uma solução melhor.
fonte
Detectou na minha prática que escrevo um código mais claro e simples quando entendo completamente o domínio do problema. Infelizmente, os clientes geralmente não conseguem esclarecer exatamente o que desejam e essa é uma situação de trabalho normal. Se você entendeu errado o domínio, ele será refletido no seu código. E se você é um líder de projeto, uma de suas principais tarefas é ajudar o cliente a ter uma nova visão da solução de negócios que ele deseja que você implemente. Portanto, tente dedicar mais tempo para uma análise de domínio e isso ajudará você a escrever um código mais simples e claro.
fonte