Depois de escrever o código, por que sinto que "eu teria escrito melhor" depois de algum tempo? [fechadas]


12

Trabalho no meu projeto de hobby em C ++ há mais de 2 anos. Sempre que escrevo um módulo / função, codifico-o com muita reflexão. Agora veja o problema,

do {
  --> write the code in module 'X' and test it
  --> ... forget for sometime ...
  --> revisit the same piece of code (due to some requirement)
  --> feel that "This isn't written nicely; could have been better"
} while(true);

Aqui 'X'está qualquer módulo (seja pequeno / grande / médio). Estou observando que isso acontece, não importa quanto esforço eu dediquei durante a codificação. Então, principalmente, eu me abstenho de ver um código funcional. :)

Este é um sentimento comum para muitas pessoas? Esse fenômeno é específico da linguagem? (Porque em C ++ é possível escrever a mesma coisa de maneiras diferentes).

O que devo fazer, se tiver esse sentimento de refatoração de um código de produção do mundo real, onde a alteração do código de trabalho não me renderá muitos elogios, mas poderá causar problemas se falhar.


14
Eu ficaria mais preocupado se nunca encontrasse problemas com meu código mais antigo. Isso mostra que suas habilidades estão se desenvolvendo.
Darren Young

1
Se você olhar para o seu código antigo e não pensar "caramba, por que não fiz isso dessa maneira ?!", então você não aprendeu o suficiente desde que escreveu o código.
Sb 22/12

Respostas:


17

Esse fenômeno é muito comum e não específico para programadores. Sempre que você executa uma tarefa intelectual, notará dezenas de lugares onde poderia ter melhorado - depois de se distanciar. Pergunte a qualquer homem sábio (wo-) que já escreveu uma tese, e eles vão dizer-lhe uma coisa: "Não olhe para ele Você vai encontrar um erro na primeira vista."

Existem basicamente duas coisas para evitar o loop de refatoração:

  1. Ao escrever e projetar, tente obter a perspectiva distante o mais cedo possível. Peça a um colega que veja seu design / código. Olhe novamente depois de um fim de semana. Olhe para ele quando estiver bêbado ou chapado (mas cuidado: não mude nada até ficar sóbrio).
  2. Viva com imperfeição. Se não for apenas bonito, mas funcionar bem (leia-se: faz um bom trabalho no cumprimento de todos os requisitos, incluindo extensibilidade e legibilidade), deixe-o em pé e se contente com o bom trabalho que você fez, sem se esforçar para obter o trabalho perfeito.


3

A refatoração contínua é o caminho a percorrer. Alterar o código de trabalho não causaria problemas e deve ser incentivado se feito corretamente. Se o seu código for totalmente testado em unidade, você pode redecorá-lo com confiança.

A única coisa que você pode prever sobre o código de produção do mundo real é: isso VAI mudar. Não tente adivinhar como isso mudará, quais novas técnicas você aprenderá amanhã. Em resumo, não tente tornar o seu código "perfeito". Apenas faça o melhor possível com o seu conhecimento atual. Além disso, verifique se o seu código é exaustivamente testado e extensível.

Passo 20 a 30% do meu tempo refatorando o código existente. Eu trabalho em uma empresa de tecnologia e a "gerência" nunca se queixou de alterar o código existente. No entanto, percebo que isso pode ser um problema em algumas empresas. Martin Fowler ainda tem uma seção sobre isso em seu livro de refatoração .

Em resumo, é um sentimento comum na minha experiência, mas não é negativo.


2

Todo módulo / função nasce e evolui em um mundo de prioridades. Uma vez que é suficiente para servir aos objetivos do mundo exterior, muitas vezes é deixado estagnar. É tudo, no final, andaimes em serviço para o propósito mais elevado. Sim, precisamos ser obsessivos com relação ao código, e sim, isso também pode nos fazer estagnar. Talvez seja uma boa jogada você desviar um pouco o foco do código em si e refletir mais sobre os processos que ocorrem dentro de você, o produtor do código.


2

Este é um sentimento comum para muitas pessoas? Esse fenômeno é específico da linguagem?

Isso significa que você está expandindo seus conhecimentos e pontos de vista.

Se você não possui tarefas de maior prioridade, sempre retorne e aprimore seu código.


"... volte e melhore o seu código." - quem pagará você para fazer isso? Depois que seu código funcionar, siga em frente. Ao aprender e crescer como programador, você SEMPRE encontrará maneiras melhores de fazer as coisas e sentirá que seus esforços anteriores poderiam ser aprimorados. Resista ao desejo de fazer qualquer coisa sobre isso - voltar e melhorar seu código antigo é principalmente uma suprema perda de tempo.
Dawood diz que restabelece Monica

1
@ David Wallace - Se ninguém tivesse que voltar ao código antigo, não faríamos tanto barulho por isso.
Jeffo

1
"Uma vez que suas obras de código, seguir em frente" - você não acreditaria que tipo de erros que eu vi no código de produção, porque o código trabalhou;)
BЈовић

@ Jeff O - isso é verdade. Se eu vou manter o código antigo, considero corrigi-lo, seja o meu código ou o de outra pessoa. Mas, a menos que exista um projeto com alguns dólares por trás e que exija a manutenção desse código, não há como justificar o tempo gasto para organizá-lo. A menos que seja de buggy, é claro.
Dawood diz que restabelece Monica

@VJovic - se houve bugs na produção, é porque o código NÃO FUNCIONA. Eu acho que o OP estava falando sobre código que funciona corretamente, mas é feio.
Dawood diz que restabelece Monica

2

Sempre achei que uma pessoa faz uma aula de matemática para fortalecer suas habilidades na aula anterior. A álgebra parecia difícil, até você pegar a álgebra II; Então as habilidades que você aprendeu em Álgebra se tornaram úteis. É a mesma coisa em programação, escrita, trabalho em madeira ou qualquer outra coisa.

Ao fazer um curso de programação, você aprendeu sobre o If-then-else, o que fez muitas coisas até você aprender sobre os switches. Quando você está aprendendo algo novo, passa por essa progressão, todo mundo faz.


2

Sinto o mesmo sempre que leio a maioria dos códigos escritos por mim no passado. Isso é bom, significa que seu conhecimento e estilo de codificação melhoraram ao longo dos anos.

Quanto à alteração do código de produção, isso é um grande não-não, a menos que você tenha detectado erros óbvios. Não apenas porque pode ser uma perda de tempo, mas mais importante, já que a grande maioria dos bugs de software criados é do tipo que é introduzido quando são feitas alterações nos programas lançados. Estatisticamente, é provável que você introduza erros imprevistos. Se não estiver quebrado, não conserte.


1

Desenvolver um aplicativo significa melhorá-lo e torná-lo melhor; esse é um processo contínuo, portanto, enquanto você programa, você ganha mais experiência e conhecimento. Também significa que você está desenvolvendo também; portanto, quando você olhar para o código antigo, poderá descobrir que ele pode ser aprimorado.

Se você não tiver esse sentimento, significa uma de duas coisas:

  1. Você ainda está no mesmo nível de habilidade.
  2. Seu código já está perfeito (improvável).
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.