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

62

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

Recentemente, fui designado para adicionar log a um grande projeto do SharePoint que foi 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 dano foi feito e agora, de alguma forma, preciso manter esse código.

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

No entanto, eu me achei absolutamente improdutivo apesar de trabalhar em algo tão simples quanto adicionar logging. Basicamente, eu só preciso percorrer o código passo a passo e adicionar algumas chamadas de rastreamento. No entanto, a idiotice do código é tão chata que eu fico cansado dentro de 10 minutos após o início . No começo, eu adicionava using constructos, reduzia o aninhamento invertendo if , renomeava as variáveis para nomes legíveis - mas o projeto é grande e, por fim, desisti. Eu sei que esta 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 para fazer.

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

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

Is there a way to stay productive and not to fight the windmills?

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

por Dan 22.02.2011 / 17:54
fonte

11 respostas

30

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. :)

    
por 22.02.2011 / 18:19
fonte
30

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.

    
por 22.02.2011 / 20:01
fonte
24

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.

    
por 22.02.2011 / 19:30
fonte
13

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.

    
por 22.02.2011 / 18:26
fonte
6

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.

    
por 22.02.2011 / 17:59
fonte
6

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 :)

    
por 22.02.2011 / 18:14
fonte
3

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.

    
por 22.02.2011 / 18:04
fonte
2

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á.

    
por 22.02.2011 / 18:11
fonte
2

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.

    
por 03.11.2014 / 14:26
fonte
0

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.

    
por 22.02.2011 / 18:18
fonte
0

"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.

    
por 23.02.2011 / 17:44
fonte