Temos a responsabilidade de melhorar o código antigo?

Eu estava olhando sobre algum código antigo que escrevi. Funciona, mas não é um ótimo código. Agora sei mais do que sabia na época, para poder melhorá-lo. Não é um projeto atual, mas é atual, funcionando, código de produção. Temos a responsabilidade de voltar e melhorar o código que escrevemos no passado ou é a atitude correta "se não estiver quebrado, não conserte"? Minha empresa patrocinou uma aula de revisão de código há alguns anos e uma das principais sugestões foi que às vezes é apenas bom o suficiente; ir em frente.

Então, em algum momento, você deve apenas considerá-lo bom o suficiente e seguir em frente, ou deve tentar empurrar projetos para melhorar o código antigo quando achar que poderia ser melhor?

A menos que você faça alterações nesse "código antigo" para corrigir bugs ou adicionar recursos, eu não me incomodaria em melhorá-lo apenas por isso. Se você quiser melhorá-lo, verifique se você possui testes de unidade para testar o código antes de começar a refatorá-lo.

Você pode usar o "código antigo" para aprender melhores práticas. Se você fizer isso, é uma experiência de aprendizado de meio período e não deve esperar que esse código substitua o que é liberado ou implantado atualmente por clientes / clientes.

Refatore as áreas do código que você precisa modificar com mais frequência . Como você visita essas áreas com frequência, a refatoração aprimora a compreensão do código e a legibilidade para quando você precisar visitá-las novamente, enquanto não faz sentido refatorar o código para o qual ninguém nunca verá novamente.

Além disso, se você refatorar apenas áreas de código quando precisar modificá-las, isso fornecerá uma desculpa válida se sua refatoração causar uma regressão . Obviamente, tente cobrir suas refatorações com testes de unidade, mas isso nem sempre é possível, especialmente com código legado, e você deve esperar que grandes refatorações criem regressões de vez em quando.

Se você precisar adicionar recursos e seu design estiver atrasando ou causando duplicação, refatorar . Quando crio o código, quase nunca prevejo exatamente quais mudanças serão necessárias no futuro. No entanto, quando adiciono novos recursos, geralmente acabo refatorando o código compartilhado. No momento, adicionei um terceiro ciclo de recurso / refatoração, minha refatoração já está se pagando e meu código compartilhado é bastante estável.

TLDR: refatorar conforme necessário, não há obrigação.

Tudo o que você faz tem um custo. Você tem tempo limitado para programar. Tudo o que você faz na programação deve ser considerado: "Qual é o benefício de fazer isso?" e "Qual é o benefício de fazer outra coisa?"

Se você não levar em consideração o custo de oportunidade (qual é o custo de fazer outra coisa?), A qualidade será gratuita. É melhor melhorar seu código. Você aprenderá algo. Vai correr melhor. Vai vender mais.

A verdadeira questão é qual é a próxima melhor coisa que você poderia fazer com seu tempo? E então você tem trocas.

Será que vai vender mais do software?

Causará menos dores de cabeça para apoiar?

O que você vai aprender?

Será que vai se tornar mais esteticamente agradável?

Isso vai melhorar sua reputação?

Faça estas perguntas (e quaisquer outras relevantes para você) para esta e outras atividades em sua fila, e isso ajudará a responder se vale a pena consertar. Essas compensações são o motivo pelo qual a economia é importante para os programadores. Joel disse isso antes de mim, e um antigo mentor disse para mim mesmo antes de Joel.

Ou, se você quiser uma resposta mais simples, pare de assistir TV até corrigir o código. :-)

Eu acho que você deve começar se perguntando a pergunta que parece ter sido perdida. De que maneira o código é ruim? E com isso você está realmente se perguntando o seguinte:

• O código não faz o que deveria fazer?
• O código está causando problemas quando você está mantendo o software?
• O código é completamente independente?
• Você tem planos de atualizar ou substituir o código a qualquer momento no futuro próximo?
• Existe um caso comercial sólido que você pode fazer para atualizar o código que lhe interessa?

Se há uma coisa que aprendi ao longo dos anos, é que você não pode se dar ao luxo de adivinhar a si mesmo após o fato. Toda vez que você resolve um problema no código, aprende algo e provavelmente verá como sua solução - ou algo semelhante - pode ter sido uma solução melhor para um problema que você resolveu de maneira diferente anos atrás. Isso é bom, porque mostra que você aprendeu com suas experiências. A verdadeira questão, no entanto, é se o código que você escreveu antes provavelmente se tornará um problema legado que fica mais difícil de lidar ao longo do tempo.

O que realmente estamos falando aqui é se o código que o incomoda ou não é fácil ou difícil de manter, e qual o custo dessa manutenção provavelmente com o passar do tempo. Trata-se essencialmente de uma pergunta sobre Dívida técnica, e se vale a pena pagar essa dívida usando um pouco de manutenção cirúrgica agora ou se a dívida é pequena o suficiente para que você possa deixá-la deslizar por um tempo.

Essas são perguntas que você realmente precisa comparar com sua carga de trabalho atual e futura e devem ser discutidas longamente com seu gerenciamento e equipe para entender melhor onde investir seus recursos e se o seu código antigo vale a pena. o tempo que você pode precisar gastar com isso - se houver. Se você pode fazer um bom argumento comercial para introduzir mudanças, faça isso de qualquer maneira, mas se você estiver enfrentando o desejo de mexer no código porque se sente constrangido com a maneira como o escreveu, sugiro que não haja espaço para orgulho pessoal quando se trata de manter o código antigo. Funciona ou não, e é fácil de manter ou dispendioso, e nunca é bom ou ruim simplesmente porque a experiência de hoje não estava disponível para você ontem.

Definitivamente, não o melhore apenas para melhorá-lo. Como outros já disseram (e é senso comum), todos nós melhoramos (por algum valor de "melhor") à medida que o tempo passa. Dito isto, revisar o código (formal ou informalmente) geralmente ilumina esses fragmentos que provavelmente desejamos nunca mais ver a luz do dia.

Embora eu não acredite que tenhamos a responsabilidade de voltar e melhorar o código que não seja fundamentalmente quebrado, inseguro ou dependa de recursos em uma lista obsoleta / EOL, aqui estão algumas coisas que eu fiz no passado nesta situação :

• Identifique as pessoas da equipe que realmente gostam de voltar e melhorar o código, como uma espécie de limpeza cerebral ou tarefa agradável, do tamanho de uma mordida que dá uma sensação de realização, e encontre tempo no cronograma para fazê-lo regularmente. Eu sempre tive pelo menos um desses tipos de pessoas em uma equipe, e essa abordagem também pode aumentar o moral (ou pelo menos o humor) se estivermos todos em um período de descanso ou descontração.

• Use-o como base para um exercício de aprendizado. Para estagiários, estudantes ou membros novos / juniores da equipe, refatorar o código antigo com a orientação de membros seniores da equipe oferece a oportunidade de se comunicar com os novos membros da equipe, entender mais sobre o sistema e adquirir o hábito de escrever / atualizar testes de unidade e trabalhar com integração contínua. É importante observar que este exercício é feito com orientação e claramente enquadrado como um exercício para melhorar o código porque não está em conformidade com os padrões / normas atuais.

Portanto, não há responsabilidade de corrigi-lo, mas esse material antigo pode ser realmente útil. E testes de unidade e CI são seus amigos!

Não necessariamente. No entanto, se você estiver executando a manutenção do código e encontrar algo que poderia ser melhor, poderá alterá-lo, desde que tenha os testes de unidade apropriados para garantir que não tenha criado uma regressão.

Se esses testes não existirem e você não tiver certeza de que se comportará exatamente como deveria, é melhor deixá-lo em paz.

Da perspectiva de um engenheiro, com certeza gostaria muito de trabalhar no código antigo até que ele não possa mais melhorar. Mas existe um argumento comercial para isso? No final do dia, o código existe para contribuir com os resultados, a lucratividade do seu local de trabalho. Se não for, apenas deixe.

Existe uma grande ressalva: se, melhorando o código, você evitará que ocorra um erro (pensando nas grandes bolas Y2K aqui em cima ..) Eu definitivamente o abordaria com alguém mais alto, talvez seu gerente de unidade de negócios, e discuta as conseqüências de melhorar o código.

Quanto a mim, a pergunta pode ser reformulada e generalizada: "Por que alguém deveria gastar recursos adicionais (tempo, dinheiro, mental, etc.) se esse pedaço concreto de código funciona bem agora? Não é um desperdício de recursos? ? "

Sempre que encontro um código legado, penso em várias coisas que parecem importantes.

1. Para que eu vou fazer alterações?
2. Preciso dar suporte a este código? Em quanto tempo isso pode acontecer (futuro próximo / distante)?
3. Esse código é confortável o suficiente para trabalhar? (Agora mesmo)
4. Posso ter certeza de que todas as alterações que faço são seguras? Testes diferentes geralmente ajudam a responder a essa pergunta.
5. Que consequências posso enfrentar se cometer algum erro durante a modificação do código? É possível reverter minhas alterações rapidamente? Será uma perda de tempo?
6. ...

Na verdade, você deve se fazer muitas perguntas. Não existe uma lista completa e final deles. Somente você e provavelmente seus colegas de equipe podem encontrar a resposta.

PS: Percebi que costumo reescrever o código com muita frequência, enquanto meu amigo e colega de equipe tendem a deixá-lo intocado. Isso ocorre porque respondemos às perguntas mencionadas de maneira diferente. E eu tenho que dizer que nós respondemos errado muitas vezes ... porque não podemos prever o futuro.

A Microsoft precisa atualizar o Windows? Todas as * nix Distros precisam continuar evoluindo? Ou um exemplo mais prático: todo mundo ainda dirige os carros dos anos 70?

Normalmente, você pode escrever melhor o código na segunda vez. Aprendeu mais sobre o domínio, escrevendo-o inicialmente.

Não existe uma resposta simples para saber se vale a pena refacorar. Geralmente, você não deve, a menos que a) seja um bom exercício para você ou b) economize tempo a longo prazo com um código melhor. Lembre-se de todas as mudanças arriscam erros.

Como nota lateral, eu defenderia fortemente os testes de unidade. É muito fácil remover a refração, especialmente se você não tiver um comportamento atual claramente marcado com pausas automáticas.

Acredito que temos a responsabilidade de escrever o melhor código possível hoje. Isso significa usar tudo o que aprendemos no passado e recusar atalhos em nosso design. Se as pressões do cronograma causam alguma redução, não acredito que a qualidade do nosso software deva ser considerada, esse pequeno clipe de papel animado, por outro lado ...

Agora, se você estiver trabalhando e achar que o código com o qual você precisa interagir não está gravado no nível em que você é capaz de escrever, é razoável corrigi-lo se você puder fazê-lo de maneira metódica controlada. Pessoalmente, tenho uma experiência muito mínima com esse tipo de refatoração, como todo mundo (quase todo mundo?). Tentei o todo "vamos mudar tudo e rezar para que funcione" e fui mordido por isso o suficiente. Sugiro examinar as discussões de Martin Fowler ( seu livro ou um dos muitos artigos ) sobre o assunto. Ele parece ter inspirado a maior parte do pensamento atual sobre o processo.

Obviamente, às vezes você pode não conseguir limpar o código como gostaria. Joel Spolsky escreveu um artigo sobre por que você pode dedicar algumas semanas para simplesmente refatorar seu código. Leia aqui e sim, é um pouco antigo, mas acho que a informação ainda é relevante.

Espero que ajude

Eu sinto que refatorar / melhorar o código antigo define o próprio programador. Desejar melhorar o código que você escreveu um ano atrás mostra apenas seu progresso e, se ele melhorar o aplicativo e você tiver a capacidade, o tempo e a aprovação para aprimorá-lo, faça-o.

Melhor / melhorado é uma comparação de vários eixos. Você acha que pode torná-lo mais rápido, menor, mais eficiente em termos de recursos, mais legível, informações mais úteis, resultados mais precisos, mais flexíveis, mais gerais, capazes de rodar em mais sistemas, eliminar a dependência de um produto separado?

Por que sua empresa deveria pagar para você reescrever esse código, em vez de escrever um novo código ou reescrever outro pedaço de código?

Você deve fazer melhorias à medida que a oportunidade se apresentar, mas oportunidade significa que você já está trabalhando no código ou identificou um motivo comercial para fazer a alteração.

Pressionar uma mudança para a produção apresenta uma chance diferente de zero de quebrar coisas (os testes unitários e funcionais apenas reduzem essa chance, eles não a eliminam) e devem ser feitos apenas quando o benefício esperado exceder o risco.

Qual é outro ponto a considerar - você pretende levar essa mudança para a produção ou simplesmente para o ramo de desenvolvimento? A barra para os dois cenários é completamente diferente. Se ele está apenas entrando no ramo de desenvolvimento e pode nunca entrar em produção, então oportunidade significa basicamente que você está vendo o código por algum motivo, e isso não é demorado. Ele pode ser revisado conforme necessário, se um empurrão ocorrer, e deixado de fora se for considerado injustificado naquele momento. Se, por outro lado, está indo para produção agora, como eu disse acima, é preciso considerar se essa mudança vale o custo: em termos de tempo gasto com o push e os benefícios do uso do novo código.

Uma boa regra geral é que, se você levasse algum tempo para entender o que o código está fazendo, e se esse tempo pudesse ser reduzido daqui para frente por algumas refatorações bem escolhidas, você estará atendendo às necessidades dos negócios e de sua equipe seguindo estas etapas.

Se o código não se beneficiar da sua análise, se os nomes dos campos não se tornarem expressivos da intenção do código e os métodos não tiverem sido divididos em partes legíveis, a empresa perderá algo de valor: seu estado de compreensão. Com ferramentas como Visual Studio e ReSharper, esses tipos de refatorações são seguros, neutros em termos de lógica e potencialmente de grande valor na produtividade e confiança do desenvolvedor no futuro.

Como o tio Bob Martin diz: "Sempre deixe o acampamento mais limpo do que você o encontrou".

Esta é uma pergunta a ser feita à gerência da sua empresa.

Você tem tempo e recursos necessários para voltar e fazer alterações no código antigo?

Você tem tempo e recursos para uma equipe de controle de qualidade TESTAR o que mudou para garantir que ela não esteja quebrada?

Eu já caí nessa armadilha antes em que eu estaria em um módulo corrigindo um bug e veja o código que eu ou outra pessoa escrevemos que era ineficiente ou deselegante, altere-o e acabe com mais problemas para resolver do que se eu apenas corrigisse o bug que eu tinha a tarefa de corrigir.

Depende.

Se o código em questão for realmente quebrado, de modo que contenha erros que inevitavelmente surgirão em um ponto (por exemplo, algum contador que em algum momento transbordará e causará problemas desagradáveis), então consertá-los pode valer a pena - mas se você faça, coloque todas as salvaguardas possíveis em primeiro lugar para evitar a introdução de novos bugs: verifique se você tem testes de unidade significativos que cobrem tudo o que toca, que todas as suas alterações sejam revisadas por alguém competente, insista em fazer testes minuciosos, verifique se você pode voltar aos antigos versão a qualquer momento, faça backup de todos os dados antes de entrar em produção, implante primeiro em um ambiente de aceitação e faça os testes com usuários reais etc. Você também precisará obter aprovação antes de prosseguir: se o bug for realmente uma bomba-relógio , e seu gerente é um tanto competente,você poderá convencê-lo a corrigi-lo (e se você não obtiver aprovação, talvez seja um sinal de que está errado).

OTOH, se a sua reclamação é mera falta de elegância do código, não ouse tocá-la. Faz um serviço fiel na produção há um bom tempo, alterar o código apenas o satisfaria, mas não agregaria nenhum valor e, como toda mudança, existe o risco de que você quebre algo. Mesmo se não o fizer, seu tempo é valioso (literalmente: você está sendo pago pelo que faz, portanto, cada minuto do seu tempo custa dinheiro) e, como você não está adicionando nenhum valor real, essa mudança seria uma perda líquida para a empresa e o projeto.