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

Não tenho muita experiência em trabalhar na indústria de software, sendo autodidata e participando de código aberto antes de decidir aceitar um emprego. Agora que trabalho por dinheiro, também tenho que lidar com algumas coisas desagradáveis, o que é normal, é claro.

Recentemente, fui designado para adicionar log a um grande projeto do SharePoint, escrito por algum programador que obviamente estava aprendendo a codificar no trabalho. Após 2 anos de colaboração, o cliente mudou para a nossa empresa, mas o estrago estava feito e agora, de alguma forma, preciso manter esse código.

Não que o código fosse muito difícil de ler. Apesar dos problemas - cada projeto tem uma classe com vários métodos de copiar e colar if, aninhamentos enormes , sistemas húngaros, conexões indisponíveis - ainda é legível.

No entanto, eu me achei absolutamente improdutivo, apesar de trabalhar em algo tão simples quanto adicionar log. Basicamente, eu só preciso seguir o código passo a passo e adicionar algumas chamadas de rastreamento. No entanto, a idiotice do código é tão irritante que me canso dentro de 10 minutos após o início . No começo, eu costumava adicionar usingconstruções, reduzir o aninhamento ao inverter if, renomear as variáveis ​​para nomes legíveis - mas o projeto é grande e, por fim, desisti. Eu sei que essa não é a tarefa que eu deveria estar fazendo, mas pelo menos reduzir a bagunça me deu algum tipo de recompensa psicológica para que eu pudesse continuar. Agora o truque parou de funcionar e ainda tenho 60% do meu trabalho a fazer.

Comecei a ter dores de cabeça depois do trabalho, e não sinto mais a satisfação que costumava ter - o que normalmente me permitia codificar por 10 horas seguidas e ainda me sinto fresco.

Este não é apenas um grande discurso, pois realmente tenho uma pergunta:

Existe uma maneira de permanecer produtivo e não combater os moinhos de vento?

Existe algum tipo de truque psicológico para manter o foco na tarefa, em vez de pensar em "quão estúpido é isso ?" Cada vez que vejo outro truque inteligente do programador anterior? O problema com a adição de log é que eu realmente tenho que entender o que o código faz, e isso machuca meu cérebro de uma maneira desagradável.

Lamento dizer, mas nem todos os empregos são cheios de sol e glamour. A maioria das tarefas de desenvolvimento envolve trabalho árduo como este. Triste mas verdadeiro.

Você é encarregado de um trabalho importante, mesmo que seja chato a ponto de ver a tinta secar. É importante por dois motivos: 1. Ele adiciona o registro 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. Ele o familiariza com a base de código, para que, se e quando algo der errado, você possa entrar e consertá-lo.

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

Então, dito isso, como você deve se motivar? Quando tenho uma tarefa entorpecente no trabalho, defino metas para mim. Conclua a tarefa x até o final da semana. Se eu fizer meu objetivo, eu me recompensarei. Novo restaurante que eu quero experimentar? Vá sexta à noite se eu terminar. Novo filme acabou de sair? Vê-lo 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 disser a eles que terminarei na sexta-feira, sinto-me mais inclinado a fazê-lo na sexta-feira b / c.

Lembre-se de que, depois de concluir esta tarefa e executá-la bem, dentro do prazo e do orçamento que as pessoas notarão, e quando esse novo e brilhante projeto aparecer, seu nome poderá ser sugerido como quem o receberá. :)

Mantenha um arquivo de trechos de código candidato para envio para thedailywtf.com. Mesmo que você não pretenda enviá-los, é um aspecto positivo encontrar um código ainda pior que a média.

Eu estava em uma situação semelhante, encarregada de limpar um grande corpo de códigos mal escritos e copiados e colados.

Para manter minha motivação e minha sanidade, escrevi um script chamado current_scoreque contava o LOC no projeto (que diminuía constantemente, pois eliminava a duplicação e alternava para melhores algoritmos) e o comparava com o LOC quando comecei. Sempre que ficava desanimado ou frustrado com a montanha de códigos que eu estava enfrentando, correr current_scoreme dava uma sensação de progresso tangível e me lembrava o quanto eu já havia realizado. E foi divertido ver o quanto de pontuação eu consegui ao enfrentar uma seção de código particularmente ruim.

Eu procuraria métricas semelhantes que você poderia criar com facilidade para ter uma noção do progresso e transformá-lo em um jogo das sortes. Linhas de código (apenas executadas wc -l), complexidade ciclomática (que deve diminuir quando você limpa esses "ifs" desagradáveis), linhas de código que foram tocadas por você em vez de seu antecessor (acho que o FishEye pode lhe dizer isso por $ 10) etc. Você pode até 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 log.

Vi este livro recomendado: Trabalhando efetivamente com o código legado , mas felizmente não tive necessidade de lê-lo.

Como você está fazendo, refatorar o que você precisa para que você possa entender o código e lembre-se de que está ressuscitando um sistema, que será recompensado quando você o estiver mantendo.
Esperamos que isso dê um passo no caminho de casa.

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

Orgulhe-se de melhorar o projeto. Existem outros codificadores com os quais você pode conversar? Ajuda a ficar parado perto do bebedouro discutindo / rindo da lógica mais recente que você encontrou. Eu tento fazer isso para manter uma atmosfera jovial no trabalho.

Faça anotações extensas para organizar suas perguntas, pensamentos e compreensão do sistema. Isso fez maravilhas para mim ao lidar com grandes sistemas legados. Ajuda a cristalizar sua compreensão, ajuda a colocar as perguntas em aberto em palavras e, como seus pensamentos já estão reunidos, facilita a comunicação espontânea com outras pessoas sobre problemas / perguntas / idéias / etc.

Como exemplo, enquanto estou analisando um pedaço do código, anotarei para mim constantemente. Esta é a minha conversa comigo mesma. O simples ato de escrever ajuda a gerar mais pensamentos e me ajuda a entender melhor as coisas. Depois de um tempo, talvez eu tenha um Eureka e precise desenhar um pequeno diagrama com a "imagem maior" no papel para ilustrar o que eu acabei de pensar ou quais peças 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 atencioso com o que estou fazendo.

Esta é basicamente uma maneira conveniente de ter uma conversa permanente com um especialista em domínio :)

Sei que você pode se sentir improdutivo porque está olhando para ele da perspectiva de 'Estou apenas adicionando log' quando, na verdade, você está adicionando log e fazendo muita refatoração. Seu supervisor provavelmente está ciente da situação do código. Todo mundo pode não gostar agora, mas quando você recebe uma solicitação para adicionar um recurso realmente interessante e desafiador, ficará feliz por ter limpado o código.

Nestes casos, costumo reescrever uma seção do código. Para fazer com que uma área sugue menos, basta adicionar o log em algum outro lugar. Depois limpe um pouco mais de código. Código ruim só é ruim se você o deixar lá.

Gamify seu trabalho. Por exemplo, dê 5 pontos a 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á sempre que 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ê tem o privilégio de tratar-se de algo que realmente deseja.

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

Outro truque é ter uma boa vida em casa no final do dia. Namorada, amigos, jogos, tudo funcionará, para lhe dar uma meta de passar o dia e fazer valer a pena o código arrastado e ruim.

"Trabalhar efetivamente com o código herdado", de Michael Feathers, pode ajudar.

Se você estiver preocupado com a quebra de itens quando alterá-los, escreva alguns testes primeiro, verifique se eles passam antes e depois de fazer as alterações. Escrever o teste deve ajudá-lo a resumir e entender o que um determinado pedaço de código faz e permitirá que você edite com confiança.