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

63

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.

Dan
fonte
Notação húngara não é ruim, leia o artigo original para ver o que ele estava falando :)
Woot4Moo
14
Eu sei que húngaro não é ruim. Foi exatamente por isso que escrevi Systems Hungarian, não Apps Hungarian (o original). Não vejo sentido em usar sistemas húngaros em c # porque ele tem um ótimo sistema de tipos e IDE. Ter 10 variáveis ​​no mesmo escopo em que tudo começa objé assustador, porque é basicamente ilegível.
Dan
2
Eu gostaria de poder dar a esta pergunta mais de um voto!
o6tech 23/02
9
Eu desabafo fazendo perguntas mal-humoradas na pilha que me deixam com votos negativos.
Erik Reppen

Respostas:

32

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

Tyanna
fonte
Gosto especialmente do argumento sobre a motivação de sexta-feira. É engraçado que o lançamento atual também esteja marcado para sexta-feira. Acho que vale a pena acrescentar que a motivação da gratidão é uma mudança. Você precisa garantir que alguém seja grato pelo seu trabalho ou mude o que está trabalhando. O sincero 'obrigado' muitas vezes reverte horas inquietas.
Dan
11
@gaearon - Fico feliz que as sugestões sejam úteis para você. Superar o trabalho árduo com um bom nível de motivação será recompensado no final. No ano passado, no meu emprego atual, tive que fazer algo semelhante ao que você está fazendo. Este ano, recebi um novo aplicativo para escrever do zero. As pessoas perceberão o que você faz e o quão bem você trabalha.
Tyanna 22/02
3
-1 Por que vincular sua vida profissional e pessoal? Isso soa semelhante a ficar horas extras de forma consistente -I didn't finish my under-estimated task by Friday - so I need to stay at home and feel bad.
Vorac
@Vorac ~ Eu disse que é isso que faço para me motivar. Todos são diferentes. E posso garantir que não trabalho OT de forma consistente. Encontre algo que o motive e use-o. Acho que uma recompensa material funciona melhor quando tenho uma tarefa que não quero fazer.
Tyanna
11
@IntegrityFirst ~ Para mim, sim. Ficarei até tarde para terminar minha lista de tarefas. Vou orçamento meu tempo para garantir que eu acerte. É minha integridade para mim e para meus colegas de trabalho concluir algo quando digo que vou concluir. Mas, se eu descobrir que algo não pode ser feito no tempo que eu disse, mudo o plano e informei meu supervisor. E se eu terminar um pouco tarde, o filme / restaurante estará lá na próxima semana. :)
Tyanna
30

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.

Peter Taylor
fonte
Eu gostaria de poder votar novamente mais uma vez. Acabou sendo uma ótima sugestão, agora que descobri que esses caras armazenam seus registros de alterações nos arquivos de configuração do aplicativo, imediatamente antes das configurações reais.
22411 Dan
24

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.

Josh Kelley
fonte
Eu uso o SourceMonitor
UmNyobe
13

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.

StuperUser
fonte
2
Este livro trata da refatoração do código existente para torná-lo testável; Eu não acho que isso vai ajudar muito no caminho da motivação.
Billy ONeal
2
Bom ponto @Billy ONeal, mas ter um código testável e as métricas associadas pode mostrar progressos que podem ser motivadores.
StuperUser
11
Eu li este livro. Definitivamente vale a pena ler. Na verdade, achei o WEWLC motivador apenas porque era bom saber que havia alguém por aí que entendia os tipos exatos de frustrações que eu estava tendo e criara maneiras eficazes de mitigar essas frustrações.
precisa
11
Esse livro é meio velho e desatualizado. Se você não leu, por que recomenda?
BЈовић
11
@StuperUser Enquanto o leio, posso dizer que está desatualizado e pode fornecer alguns conselhos úteis para usuários iniciantes.
BЈовић
6

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.

davidhaskins
fonte
Sim, estou trabalhando com partes, e já estou trabalhando nisso há algum tempo, por isso tenho uma idéia aproximada de cada componente. Ainda assim, não ajuda muito, porque são os pequenos pedaços de lógica que geralmente levam tempo para entender - e fico com raiva quando percebo que o método de 30 linhas em que passei 10 minutos pode ser reescrito em duas linhas. Quanto à empresa, infelizmente, sou o único desenvolvedor deste projeto e atualmente trabalho no escritório do cliente, para que não haja ninguém com quem eu possa conversar.
22411 Dan
@gaearon - O que impede você de implementar sua solução de 2 linhas? Você precisa descobrir como fazer o que recebeu a tarefa, o problema com o código pode ser resolvido mais tarde, quando você não estiver no escritório do cliente. Você deve manter suas anotações sobre o que fez, como algo funciona, para poder voltar mais tarde no futuro e implementar suas alterações para que revisões de código e testes de integração possam ser realizados.
Ramhound 22/02
@gaearon ah-ha! Você é o único codificador. Então o cara antes de você era o único programador. Você pode se safar muito quando é o único codificador (como você notou no seu antecessor). Lembre-se disso quando procurar seu próximo emprego. ;)
davidhaskins
@ Ramhound Aposto que não haverá nenhuma revisão de código. Aposto que não haverá nenhum teste formal de integração. Já trabalhei nessas posições algumas vezes. Geralmente, as pessoas só querem código que funcione suficientemente bem e o querem o mais rápido possível. Explicar as "melhores práticas" é como conversar com uma parede, IMHO.
Davidhaskins
@ Ramhound, não há testes para este projeto, e eu não quero ser responsável por arruinar o sistema por uma questão de código mais limpo. Existem muitos casos em que o código atual implica que as exceções sejam engolidas ou se baseia em outros tipos de mau comportamento que não são óbvios. Essa é uma das razões pelas quais estou adicionando log, a propósito.
Dan
6

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

Doug T.
fonte
3

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.

JeffO
fonte
Temo que acabe reescrevendo o projeto, já conversamos sobre isso. Embora eu goste mais dessa opção, ela não aumenta a produtividade no trabalho com código descartável. Eu sei que o log é necessário no próximo lançamento e, em seguida, posso seguir minhas coisas, mas é apenas ter que executar esse código na minha cabeça que me deixa louco. Eu sinto que estou ficando mais idiota depois de entendê-lo :-) #
Dan
11
"ele não aumenta a produtividade no trabalho com códigos descartáveis", garante . Você passa por grandes partes do código trabalhando para entendê-lo, enquanto executa uma tarefa de baixo risco (log). Esse conhecimento que você está adquirindo ajudará imensamente se se trata de uma reescrita. Se não houver uma reescrita, espere ansiosamente a recompensa que você sentirá ao limpar grandes quantidades do aplicativo, quão melhor será a base de código devido aos seus esforços consistentes e persistentes.
Quentin-starin
2

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

Erin
fonte
O sistema depende muito de práticas inadequadas, para reescrever um método corretamente, eu teria que reescrever todo o projeto (o que provavelmente o farei eventualmente, mas tenho alguns prazos para o lançamento atual).
Dan
Ya eu entendo acredite em mim. Acabei de escolher uma seção que eu possa limpar sem tornar minha vida dolorosa e limpá-la e depois para a próxima área. O código de correção é um processo para o qual você nunca tem tempo, mas sempre deve ter tempo.
Erin
2

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.

Richie Cotton
fonte
0

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.

Tim
fonte
0

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

Stephen Paulger
fonte
Infelizmente, é um projeto do SharePoint, o que significa que é quase impossível de testar. Eu escrevi um pouco de sandbox para o SharePoint no passado usando o Microsoft Moles, mas isso requer muito trabalho adicional.
23411 Dan