Como você se mantém produtivo ao lidar com códigos extremamente mal escritos?

Sinto dizer, mas nem todos os trabalhos estão cheios de sol e glamour. A maioria das tarefas de desenvolvimento envolve trabalho pesado como este. Triste mas verdadeiro.

Você é encarregado de um trabalho importante, mesmo que seja chato ao ponto de assistir a tinta secar. É importante por dois motivos: 1. Ele adiciona log muito necessário a um sistema grande para que, quando algo der errado, você tenha uma ferramenta para ajudá-lo a encontrá-lo. e 2. Você fica familiarizado com a base de código para que, se e quando algo der errado, você possa entrar e consertar.

Você está basicamente criando sua própria rede de segurança aqui. Glamores, não, mas importante sim!

Então, isso dito, como você deve se motivar? Quando tenho uma tarefa entorpecente no trabalho, estabeleço metas para mim mesmo. Termine de executar a tarefa x até o final da semana. Se eu fizer meu objetivo, eu recompensarei a mim mesmo. Novo restaurante que quero experimentar? Vá sexta à noite se eu terminar. Novo filme acabou de sair? Veja no fim de semana se eu terminar.

Acho que conversar com meu supervisor e deixá-lo saber onde estou e como estou progredindo me mantém responsável. Se eu lhes disser que estarei pronto na sexta-feira, sinto-me mais inclinado a fazê-lo até sexta-feira b / c. Disse-lhes que o faria.

Tenha fé que uma vez que você conclua esta tarefa e você tenha feito isso bem, dentro do prazo e do orçamento que as pessoas notarão e quando esse novo projeto aparecer, seu nome pode ser sugerido como aquele que o recebe. :)

Mantenha um arquivo de trechos de código de candidato para envio ao thedailywtf.com. Mesmo que você não tenha a intenção de enviá-los, isso lhe dará um lado positivo para encontrar algum código que seja ainda pior do que a média.

Eu estava em uma situação semelhante, com a tarefa de limpar um grande corpo de código mal escrito e copiado em massa e colado.

Para manter minha motivação e minha sanidade, escrevi um script chamado current_score que contava o LOC no projeto (que diminuía constantemente, eliminando a duplicação e mudando para melhores algoritmos) e comparando-o com o LOC quando comecei . Sempre que eu ficava desanimado ou frustrado com a montanha de código que estava enfrentando, executar current_score me daria uma sensação de progresso tangível e me lembraria de quanto eu já havia conseguido. E foi divertido ver o quão alto eu poderia acumular quando lidava com uma seção de código particularmente ruim.

Eu procuraria por métricas similares que você pudesse facilmente criar scripts para dar a si mesmo um senso de progresso e transformá-lo em um tipo de jogo. Linhas de código (apenas execute wc -l ), complexidade ciclomática (que deve diminuir conforme você limpa aqueles "ifs" aninhados desagradáveis, linhas de código que foram tocadas por você em vez de seu antecessor (eu acho que FishEye posso dizer-lhe isso por US $ 10), etc. Você pode até mesmo escrever um script Perl sem muita dificuldade para contar o número de blocos de código que ainda não possuem instruções de registro.

Eu vi este livro recomendado: Trabalhando efetivamente com o código legado , mas felizmente não tive um precisa lê-lo.

Como você está fazendo, refatorie o que precisa para entender o código e lembre-se de que está ressuscitando um sistema, que valerá a pena quando for mantido.
Isso deve colocar uma mola no seu caminho a caminho de casa.

Tente dividir o projeto em partes. Cada dia aprenda como um pedaço específico funciona. Tentar entender tudo de uma vez é provavelmente o que está estressando você.

Tenha orgulho em melhorar o projeto. Existem outros codificadores que você pode conversar? Ele ajuda a ficar em torno do bebedouro discutindo / rindo da última lógica que você encontrou. Eu tento fazer isso para manter uma atmosfera jovial no trabalho.

Faça anotações extensas para organizar suas dúvidas, pensamentos e compreensão do sistema. Isso funcionou maravilhas para mim ao lidar com grandes sistemas legados. Ajuda a cristalizar sua compreensão, ajuda a colocar as perguntas abertas em palavras e, como seus pensamentos já estão juntos, facilita a comunicação espontânea com os outros sobre problemas / dúvidas / ideias / etc.

Como exemplo, enquanto estou passando por uma parte do código, vou fazer anotações para mim constantemente. Esta é a minha conversa comigo mesmo. O simples ato de escrever ajuda a mais pensamentos e ajuda-me a entender melhor as coisas. Depois de um tempo eu posso ter um Eureka e preciso desenhar um pequeno diagrama com a "foto maior" no papel para ilustrar o que eu acabei de pensar ou quais peças eu acabei de montar. Eu sempre faço isso apenas no papel, me livrando de todas as distrações do computador. Isso me permite ser mais metódico e pensativo sobre o que estou fazendo.

Esta é basicamente uma maneira conveniente de ter uma conversa perpétua com um especialista no domínio :)

Eu sei que você pode se sentir improdutivo porque está olhando para ele do ponto de vista de "Só estou adicionando registro" quando, na verdade, você está adicionando registros e fazendo muita refatoração. Seu supervisor provavelmente está ciente da situação do código. Todos podem não gostar agora, mas quando você receber uma solicitação para adicionar um recurso realmente interessante e desafiador, ficará satisfeito em limpar o código.

Nestes casos, eu costumo reescrever uma seção de código. Para fazer uma área sugar menos e, em seguida, basta adicionar log em outro lugar. Em seguida, limpe um pouco mais de código. Código ruim só é ruim se você deixá-lo lá.

Gamifique seu trabalho. Por exemplo, dê a si mesmo 5 pontos cada vez que fizer uma boa pergunta sobre o código e 10 pontos a cada vez que responder. Dê a si mesmo um crachá a cada vez que você refatorar um método ou adicionar um novo recurso. Depois de acumular pontos suficientes, você obtém privilégios como coffee breaks ou biscoitos. Depois de concluir todo o projeto, você terá o privilégio de se dedicar a algo que realmente deseja.

O truque para não ficar entediado ou com raiva para que você continue sendo produtivo é aceitar que o código é mal projetado. Aceitar sua posição para ter que entender e atualizar o código permitirá que você não continue comentando sobre "o quão estúpido isso é" e, em vez disso, aceite-o tranquilamente e siga em frente.

Outro truque é ter uma boa homelife para esperar no final do dia. Namorada, amigos, jogos, qualquer coisa vai funcionar, para dar-lhe um objetivo de passar o dia e fazer valer a pena, mesmo com códigos ruins.

"Trabalhando efetivamente com código herdado" por Michael Feathers pode ajudar.

Se você está preocupado em quebrar coisas ao alterá-las, escreva alguns testes primeiro, certifique-se de que eles sejam aprovados antes e depois de fazer as alterações. Escrever o teste deve ajudá-lo a resumir e entender o que um determinado código faz e permitirá que você edite com confiança.