O que posso fazer para manter o respeito por uma base de código mal escrita? [duplicado]

4

No meu trabalho eu tenho que manter uma base de código mal escrita que é difícil de entender, tem toneladas de comentários que são simplesmente errados, tem um monte de decisões estranhas acontecendo e muito mais.

Eu faço basicamente correções de bugs que vão desde encontrar aquele pequeno comentário em algum lugar no código que faz alguma parte aleatória não funcionar, até entender complexas dependências circulares com algum tipo de singleton'a'palooza acontecendo, e ocasionalmente eu realmente escrevo algum código real, que é quando eu sou o mais feliz. Mas eu estou preocupado que a bruxa de correção de bugs que devo confessar muitas vezes acabe sendo desleixada porque eu não tenho mais tempo ou força mental para olhar o código horrendo.

Agora, o maior problema deste projeto não é que eu seja apenas um cara chorão, eu certamente não estou sozinho em ter mencionado os sentimentos acima sobre a base de código. O maior problema é provavelmente o custo de mantê-lo ... Mas eu divago.

O que eu estou querendo saber é se há algumas práticas que eu e meus colegas podemos tentar usar para recuperar algum respeito pela base de código que herdamos e estamos trabalhando para que não percamos o caminho da criação de mais código podridão?

    
por Daniel Figueroa 01.03.2013 / 20:11
fonte

4 respostas

4

Tendo trabalhado com alguns C # realmente horríveis no meu primeiro emprego, corri de cabeça para esse problema. Enquanto acabei saindo, no tempo que passei com ele, tomei a mentalidade de tratar o código como paciente.

Todo o código, não importa o quão horrível, cheio de WTF, mal concebido, inadequadamente implementado ou simplesmente bad foi pretendido pelos desenvolvedores para resolver um problema, com as ferramentas eles tinham à sua disposição. Isso faz o código bom? Não. Isso torna a manutenção menos dolorosa? Seguramente não. Claro, sua pergunta não é sobre a dor do desenvolvedor; É sobre se você pode olhar para este código dia e noite por quanto tempo você permanecer empregado em sua loja atual.

Para esse fim, ao trabalhar com código, vejo isso como um médico poderia: uma entidade que está exibindo sintomas de um traço específico.

Nós chamamos os sintomas do comportamento correto dos comportamentos pretendidos 'na maioria das vezes ... exceto quando o raciocínio por trás do comportamento' intencional 'é ruim. Quando essa circunstância ocorre, pode ser útil reunir algo que você possa apresentar ao seu gerenciamento para explicar o comportamento que está vendo e um processo ideal que melhore a forma como o aplicativo funciona e, finalmente, o conjunto de alterações mínimo para modifique esses sintomas . Se tudo correr bem, eles vão aprovar e deixar você fazer o que um desenvolvedor faz melhor: deixar o código em melhores condições do que você encontra. Se não? Pode não ser tão ruim, eles podem ter apenas uma razão comercial (muito pouco tempo, muito pouco dinheiro).

Quando encontro sintomas de um comportamento não intencional, prefiro seguir o fluxo de trabalho de relatórios de erros existente na minha loja; é a maneira mais rápida e eficiente de informar seus líderes sobre os problemas que afetam seu aplicativo. No meu primeiro emprego, houve alguns problemas que não conseguimos abordar por cerca de dois meses devido à natureza do setor em que estávamos operando, mas não reportá-lo (ou pior, fazer mudanças desonestos) teria sido muito pior -efeitos, o que leva a um respeito ainda menor pela sua base de código.

Melhor ainda, tente encontrar formas construtivas de fazer com que seus gerentes acelerem o processo pelo qual os bugs são respondidos (isso foi um problema na primeira loja minha), porque quanto mais tempo você sabe que um bug está em estado selvagem , menos seu respeito pelo código será no final do dia. Moral importa!

Quando vejo códigos malformados que não correspondem aos padrões da linguagem, não culpo o código por estar mal formado, mas considero o desenvolvedor que o escreveu; talvez eles não estejam familiarizados com a linguagem? (Eu encontrei este caso com um colega de trabalho que não tinha experiência em programação, mas um histórico rico como testador manual; essa pessoa escreveu um código de copiar / colar realmente horrível que demorei semanas para estabilizar).

Quando você encontrar este caso, você tem duas opções. Se o desenvolvedor estiver lá e tiver acesso fácil, disponibilize-se como um recurso de ensino; Você pode influenciar essa pessoa a escrever códigos de acordo com os padrões do seu idioma e da sua loja. Ajudá-los a ser um melhor desenvolvedor, as chances são de que eles estão tendo um momento difícil, mas estão colocando uma cara dura e fazendo caretas através dela, assim como você. Melhor ainda, você pode dormir mais fácil à noite, sabendo que os volumes de código ruim estarão diminuindo ao longo do tempo, o que é sempre bem-vindo.

Se a pessoa não tiver acesso fácil, ou já tiver saído, quando uma desculpa para revisar o código aparecer de forma positiva e de baixo risco, faça isso. Você está fazendo sua organização um favor por ser a mudança que você deseja criar.

Se em algumas semanas você tentou tudo isso e ainda não viu melhorias em sua própria consideração sobre sua base de código, e para o tratamento dos outros, não há nada para isso: você não deve apoiar algo que odeia, como você vai fazê-lo abaixo de fazer todos os sintomas que eu falei pior. Mas, antes de começar a conversar com o recrutador, certifique-se de que você tenha esgotado todas as opções para melhorar essa base de código e fazer seus colegas de trabalho fazerem o mesmo. Eu imagino que se você está se encolhendo com tanta dor, isso também não pode ser prazeroso para eles!

    
por 01.03.2013 / 23:40
fonte
19

Às vezes, você precisa entender essas coisas no contexto em que elas foram criadas, depois incorporadas e depois mantidas.

Alguns dos piores criminosos que eu já vi provavelmente começaram como programas muito bem escritos. Você pode ver um pouco da arquitetura bem pensada tentando sair da bagunça. Mas quando isso acontece, os requisitos mudam durante o final da compilação inicial, então algumas coisas ficam um pouco desleixadas, para garantir que os prazos sejam cumpridos, etc ... Então a equipe inicial de empreiteiros a entrega para a equipe interna de desenvolvimento que tem uma maneira diferente de fazer as coisas. Essa equipe pode ter uma dúzia de pessoas, e com um ou dois membros passando por ano, e com pessoas diferentes mudando seu foco no sistema, é fácil entender com que rapidez e facilidade uma boa base de código pode se tornar uma abominação. Quando cheguei lá, estava cheio de todos os tipos de "WTF" e excentricidades. Alguns deles não faziam sentido, alguns eram claros antipadrões, outros corrigiam problemas específicos da plataforma com um componente de fornecedor específico que pode ou não ter problemas em suas versões atuais (mas ninguém teve tempo de testar e código atual apenas funciona para que ninguém queira mexer nele).

Pelo menos é assim que as bases de código legíveis horríveis em que trabalhei evoluíram. É claro que provavelmente havia muitas coisas que poderiam ter sido feitas em muitos desses ciclos para mitigar o fator WTF, mas se isso tivesse acontecido, eu não teria nada sobre o que escrever. ;)

Quanto a trabalhar com ele: eu costumava pensar no meu trabalho em um desses sistemas como um avião de ataque de precisão: voar rápido e rápido através de terreno hostil e entregar aquela pequena linha de código que explode o bug para peças. Às vezes, era mais divertido pensar no processo de consertos maiores, mais envolvido, como um mistério de Sherlock Holmes: o caso da mensagem da fila confusa (ou algo parecido).

    
por 01.03.2013 / 20:26
fonte
6

Bem, você está direcionando muita energia para um objeto inanimado. Eu realmente lido com isso, saboreando o desafio, no concurso em si. É da mesma forma que você enfrenta um adversário no campo de esportes. Você quer ganhar. Eles são um obstáculo para você ganhar, mas você não os odeia por isso.

A próxima coisa que faço é uma etapa de refatoração primeiro , enquanto eu ainda estou tentando entender o código. Se a minha mudança precisa ir em uma função de 1000 linhas, eu quebro essa função. Se há código clichê repetido em todo o lugar, eu o ponho em sua própria função. Eu substituo números mágicos por constantes nomeadas. Não estou falando de um grande retrabalho que exija um profundo entendimento do código, apenas transformações simples que podem ser aplicadas quase mecanicamente.

Nesse ponto, estou pronto para fazer a minha alteração, e é muito mais fácil fazê-lo, geralmente mais do que compensar o tempo que passei na refatoração. Alguns dos meus melhores trabalhos acabam com uma perda líquida no número de linhas de código, mesmo quando eu adicionei novos recursos. Quando estou enfrentando uma batalha difícil, tento lembrar como isso vai ser bom quando terminar.

    
por 01.03.2013 / 22:00
fonte
1

Talvez não haja orgulho no código, mas você não o escreveu. O que você pode reconhecer é tornar a experiência do usuário melhor removendo os bugs. Não é glorioso, mas os usuários vão adorar você por isso.

Além disso, você deixa o código um pouco melhor para o próximo cara.

    
por 01.03.2013 / 21:07
fonte