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

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

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

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

Para qualquer base de código herdada, a maneira correta de se preparar mentalmente para lidar com ela é começar escrevendo testes de unidade para ela .

Seja uma merda ou não, você precisa primeiro ter confiança para poder alterá-la sem quebrar nada!

Não sei dizer quantas vezes eu disse "Oh, isso está totalmente errado", reescrevi e descobri da maneira mais difícil o motivo pelo qual esse código foi escrito dessa maneira. Geralmente, é um requisito não-escrito / não documentado não óbvio. Pelo menos, isso é verdade no código legado no qual estou trabalhando atualmente.

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

Eu acho que Fosco tinha um ótimo argumento para poder colocá-lo no contexto de possíveis restrições de tempo e funcionalidade. Às vezes, você é forçado a fazer algo funcionar.

E por último, entenda que é por isso que você tem um emprego.

Ria disso, tente não julgá-lo demais e apenas passe por isso. Não é bom ser um verdadeiro nazi de código ... Definitivamente, existe algo como 'bom o suficiente' ou 'bom o suficiente na época'. Há muitas vezes em que algo é desenvolvido ou enfaixado para corrigir uma crise e nunca mais revisitado.

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

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

Muitas vezes, acho útil ter uma idéia do que os desenvolvedores originais pensavam ser bom.

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

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

De qualquer forma, depois de fazer isso, você deve ter uma ideia melhor de onde poderia iniciar uma reescrita ou como seria uma solução rápida sem precisar refatorar tudo.

Mais importante, não assuma imediatamente que, apenas por ser feio, é ruim. Nada faz você parecer mais tolo do que gastar tempo modernizando algo apenas para descobrir que ele é menos capaz que o original.

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

É guerra.

Eu sempre raciocino que código feio é um código que viu muitas depurações, com muitas sutilezas que não são aparentes com uma inspeção superficial. Se eu substituí-lo ou reprojetá-lo profundamente, preciso ter certeza de que compreendo 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 alteração possível para alcançar meus objetivos.

Normalmente, faço uma pequena correção / alteração e proponho um recurso para desenvolvimento posterior que desculpe chegar ao fundo das coisas e refatorar a coisa toda. Depois, faço o possível para ignorar o código até que o recurso termine no roteiro.

Quando o código legado tem mais de dois anos, ele pode ter sido escrito dessa maneira devido a limitações no idioma ou nos sistemas operacionais etc. que existiam no momento em que o código foi escrito. Ei, parece ruim agora, mas foi ruim então? Eu tento assumir que o desenvolvedor tinha uma razão para o que ele ou ela fez. Esse motivo pode não se aplicar mais, mas presumir que houvesse um em vez de apenas incompetência geral (jovens programadores pensarão a mesma coisa sobre o seu código em cinco anos, talvez até menos) o deixa menos irritado com isso. Se funcionar e não houver problemas associados, aprecie esse código legado, não importa o quão feio, pois ele permitirá que você resolva problemas mais emocionantes.

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

O que estou tentando adicionar a este código / corrigir / tornar o trabalho?

O que estou fazendo está trabalhando para atingir esse objetivo? Caso contrário, pare de fazê-lo e volte para a última vez que estava fazendo alterações orientadas a tarefas.

Eu terminei com esta tarefa? Nesse caso, pare de mexer no código, mesmo que pareça ter sido escrito por um molde marciano não senciente.

A menos que você esteja preparado para possuir o código e as correções necessárias no futuro, não toque nele. Você superará a tendência de querer consertar algo quando quebrar algo que não escreveu, porque não o estudou bem o suficiente antes de mergulhar, e você leva 2 dias e uma broca de fogo para fazê-lo funcionar novamente .

Não me entenda mal ... há razões legítimas para refatorar o código, mas se uma empresa exigir que o código funcione, e você o "corrige" sem conhecer as consequências antes de entrar, está pedindo um mundo de mágoa .

Refatorar um pouco de cada vez pode ser útil, mas tenha cuidado extra 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 afeta. Infelizmente, o código que mais precisa é, às vezes, o mais difícil de mudar sem tocar no comportamento, embora você possa endireitar partes dele ou, pelo menos, comentá-lo.

Atualmente, estou trabalhando quase exclusivamente no código legado e sempre penso "Oh sh% t, o que eles estavam pensando?" . Então começo a escrever testes de unidade para o código e é nesse ponto que realmente preciso analisar o fluxo de controle e as dependências.

Às vezes, não é possível escrever facilmente testes de unidade. Mas enquanto eu tento, obtenho informações sobre o código e entendo por que ele foi escrito da maneira que é. Às vezes isso prova que o código é realmente uma bagunça, às vezes eu entendo o processo de pensamento dos desenvolvedores originais e posso adicionar documentação útil ou reescrever um pedaço de código quando desejar adicionar uma nova funcionalidade.

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

Com a experiência, chega o julgamento de saber quando o código é realmente ruim e quando é apenas escrito em um estilo diferente. Se for perfeitamente funcional e sustentável, e houver uma boa cobertura de teste automatizado , não será ruim e você só precisará abrir sua mente. Você provavelmente aprenderá alguma coisa. Código incorreto não é funcional e pode ser mantido.

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
• Acoplamento alto; baixa coesão
• Variáveis ​​não utilizadas, gravando em variáveis ​​que nunca são lidas, código inacessível.
• Reimplementação de funções padrão da biblioteca, por exemplo, formatação de data.
• Lógica desnecessariamente complexa; ou seja, 50 linhas de código onde 10 seria bom.
• Nenhum comentário descrevendo o objetivo de classes ou métodos.
• Comentários enganosos.

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

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 levar algum tempo para poder trabalhar com êxito em uma nova base de código. Se for "perfeitamente sustentável" e houver alta cobertura de teste, leva menos tempo, mas ainda não acontecerá imediatamente. Se o código estiver incorreto, a primeira coisa que faço é avisar às partes interessadas que ele está em mau estado e o progresso inicial será lento. Se eles são céticos, faço backup da minha reivindicação, mostrando a eles uma amostra de problemas no código real e explicando como isso varia de acordo com as melhores práticas do setor.