ti-enxame.com

Como você supera seus próprios preconceitos de codificação quando recebe um código legado?

Como programadores, muitas vezes temos um orgulho incrível de nossas habilidades e temos opiniões muito fortes sobre o que é código 'bom' e código 'ruim'.

Em qualquer ponto de nossas carreiras, provavelmente já tivemos algum sistema legado em nossas mãos e pensamos 'Meu Deus, esse código é uma merda!' porque não se encaixava em nossa noção do que um bom código deveria ser, apesar do fato de que pode ter sido um código perfeitamente funcional e sustentável.

Como você se prepara mentalmente ao tentar entender o trabalho de outro programador?

21
Bryan M.

Para qualquer base de código legada, a maneira correta de se preparar mentalmente para lidar com ela é comece escrevendo testes de unidade para ela.

Quer seja uma merda ou não, primeiro você precisa ter a confiança para ser capaz de alterá-lo sem quebrar coisas!

31
Jeff Atwood

Eu não posso te dizer quantas vezes eu disse "Oh, isso é totalmente errado", reescrevi e então descobri da maneira mais difícil porque aquele código foi escrito dessa forma. Normalmente, é algum requisito não escrito/não documentado não óbvio. Pelo menos, isso é verdade no código legado no qual estou trabalhando atualmente.

29
Frank Shearar

Você espera até que esteja por aí por tempo suficiente para encontrar seu próprio código legado de baixa qualidade. É uma experiência humilhante e parte do processo de aprendizagem. Anseio pelo tempo em que sabia tudo.

Acho que Fosco teve um grande ponto para ser capaz de colocá-lo no contexto de potenciais restrições de tempo e funcionalidade. Às vezes você é forçado a fazer algo funcionar.

E, por último, venha a entender que é por isso que você tem um emprego.

10
JeffO

Ria disso, tente muito não julgar muito e apenas supere. Não é bom ser um nazista de código de verdade ... Definitivamente existe algo como 'bom o suficiente' ou mesmo 'bom o suficiente no momento'. Muitas vezes, algo é desenvolvido ou enfaixado para consertar uma crise e nunca mais revisado.

Se estiver realmente ruim, veja se você pode argumentar para reescrevê-lo .. se não for importante, apenas entre e saia.

7
Fosco

Escolha suas batalhas. Saiba a diferença entre "Eu não escreveria desta forma" e "isso cria um sério desafio de manutenção ou suporte"

7
AShelly

Freqüentemente, acho útil ter uma ideia do que os desenvolvedores originais consideravam bom.

Procure padrões e temas para o que eles fizeram e, muitas vezes, você descobrirá que havia razões para algumas das decisões estranhas em primeiro lugar.

Às vezes você descobre que o desenvolvedor original era realmente ruim, mas você tem uma ideia do tipo de ruim que eles estavam vendendo naquela época.

De qualquer forma, depois de fazer isso, você deve ter uma imagem melhor de onde poderia começar uma reescrita ou como seria uma correção rápida sem ter que refatorar tudo.

Mais importante ainda, não presuma imediatamente que só porque é feio, é ruim. Nada faz você parecer mais tolo do que gastar tempo modernizando algo apenas para descobrir que é menos capaz do que o original.

4
Bill

Sempre penso que código feio é aquele que passou por muitas depurações, com muitas sutilezas que não são aparentes com uma inspeção superficial. Se eu o substituir ou redesenhar profundamente, preciso ter certeza de que entendo absolutamente todos os aspectos do que o código faz. Se não tenho tempo para chegar ao fundo, devo adotar uma abordagem de risco mínimo, fazendo a menor mudança possível para alcançar meus objetivos.

Normalmente farei uma pequena correção/alteração e proponho um recurso para desenvolvimento posterior que justificaria ir ao fundo das coisas e refatorar tudo. Então, faço o possível para ignorar o código até que o recurso acabe no roteiro.

3
Joeri Sebrechts

Quando o código legado tem mais de alguns anos, ele pode ter sido escrito dessa forma por causa das limitações na linguagem ou sistemas operacionais, etc. que existiam no momento em que o código foi escrito. Ei, parece ruim agora, mas estava ruim então? Tento presumir que o desenvolvedor teve uma razão para o que fez. Essa razão pode não se aplicar mais, mas assumir que houve uma em vez de apenas incompetência geral (jovens programadores estarão pensando a mesma coisa sobre o seu código em 5 anos, talvez até menos) deixa você menos irritado com isso. Se funcionar e não houver problemas associados a ele, valorize esse código legado, não importa o quão feio seja, pois ele permitirá que você resolva problemas mais interessantes.

3
HLGEM

Se eu tiver tempo eu ataco e mato o código mal escrito.

É uma guerra.

3
user1842

A menos que você esteja preparado para possuir o código e quaisquer correções necessárias no futuro, não mexa nisso. Você vai superar a tendência de querer consertar algo quando quebra algo que não escreveu porque não estudou bem o suficiente antes de mergulhar, e leva 2 dias e uma simulação de incêndio para fazê-lo funcionar novamente .

Não me interpretem mal ... existem razões legítimas para refatorar o código, mas se um negócio exige que o código funcione e você o "conserta" sem saber as consequências antes de pular, você está pedindo um mundo de dor .

1
CokoBWare

No passado, quando eu não tinha tempo para mijar no código de outra pessoa e transformá-lo no "meu" estilo, tive que recorrer a ser muito voltado para a tarefa:

O que estou tentando adicionar a este código/consertar/fazer funcionar?

O que estou fazendo está trabalhando para atingir esse objetivo? Se não, pare de fazer isso e volte para a última vez em que fiz alterações orientadas para a tarefa.

Terminei esta tarefa? Se sim, pare de mexer no código, mesmo que pareça que foi escrito por um molde marciano não-consciente.

1
Alex Feinman

Refatorar um pouco de cada vez pode ser útil, mas seja extremamente cuidadoso ao alterar qualquer aspecto minúsculo de como o código realmente se comporta, a menos que você entenda por que esse comportamento existe e o que ele afeta. Infelizmente, o código que mais precisa dele às vezes é o mais difícil de alterar sem alterar o comportamento, embora você geralmente possa corrigir partes dele ou pelo menos comentá-lo.

1
David Thornley

Com a experiência, vem o julgamento para saber quando o código é realmente ruim e quando é apenas escrito em um estilo diferente. Se for perfeitamente funcional e de fácil manutenção e houver uma boa cobertura de teste automatizado, então não é ruim e você só precisa abrir sua mente. Você provavelmente aprenderá algo. O código ruim não é funcional e sustentável.

Aqui estão alguns marcadores de código realmente ruim:

  • Grandes blocos de lógica foram duplicados em vez de refatorados.
  • Dependências circulares entre classes ou pacotes
  • Alto acoplamento; baixa coesão
  • Variáveis ​​não utilizadas, escrita em variáveis ​​que nunca são lidas, código inacessível.
  • Reimplementação de funções de biblioteca padrão, por exemplo formatação de data.
  • Lógica desnecessariamente complexa; ou seja, 50 linhas de código, onde 10 seria um bom desempenho.
  • Nenhum comentário descrevendo o propósito das classes ou métodos.
  • Comentários enganosos.

A falta de testes automatizados não significa que o código está ruim, mas significa que o projeto está ruim.

Isso não é uma questão de gosto; essas práticas tornam a manutenção do programa muito mais cara.

Como você se prepara?

Aceite o fato de que leva um tempo para conseguir trabalhar com êxito em uma nova base de código. Se for "perfeitamente sustentável" e houver uma alta cobertura de teste, leva menos tempo, mas ainda não acontecerá imediatamente. Se o código estiver ruim, a primeira coisa que faço é avisar as partes interessadas que ele está em mau estado e que o progresso inicial será lento. Se eles estiverem céticos, eu apoio minha afirmação, mostrando a eles uma amostra de problemas no código real e explicando como isso varia em relação às melhores práticas do setor.

0
kevin cline

Estou trabalhando quase exclusivamente em código legado atualmente e sempre penso "Oh sh% t, o que eles estavam pensando?" . Então eu começo a escrever testes de unidade para o código e é aí que eu realmente tenho que analisar o fluxo de controle e as dependências.

Às vezes, não é possível escrever facilmente testes de unidade. Mas enquanto tento, pego informações sobre o código e entenderei por que foi escrito dessa maneira. Às vezes, isso vai provar que o código é realmente uma bagunça, às vezes consigo entender o processo de pensamento dos desenvolvedores originais e posso adicionar documentação útil ou reescrever um pedaço de código quando quero adicionar uma nova funcionalidade.

Para mim, ajuda pensar que meu código terá a mesma aparência quando eu voltar a ele em 12 meses.

0
cringe