Temos uma responsabilidade de melhorar o código antigo?

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

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

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

Além disso, se você refatorar somente as áreas de código quando precisar modificá-las, fornecerá uma desculpa válida se a refatoração causar uma regressão . Claro, tente cobrir suas refatorações com testes de unidade, mas isso nem sempre é possível, especialmente com o 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 você ou causando duplicação, refatore . Quando eu crio 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 é razoavelmente 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 analisado: "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?), então a qualidade é gratuita. É melhor melhorar seu código. Você vai aprender alguma coisa. Vai correr melhor. Vai vender mais.

Venderá mais software?

Isso causará menos dores de cabeça?

O que você aprenderá?

Será mais esteticamente agradável?

Isso melhorará sua reputação?

Faça estas perguntas (e quaisquer outras que sejam relevantes para você) para esta e outras atividades em sua fila, e isso ajudará a responder se valer a pena consertar. Esses trade-offs são o motivo pelo qual a economia é importante para os programadores. Joel disse isso antes de mim, e um velho mentor disse isso para mim antes mesmo de Joel.

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

Acho que você deveria começar perguntando a si mesmo a pergunta que parece ter sido perdida. De que maneira o código é ruim? E com isso você está se perguntando o seguinte:

• O código não faz o que deve fazer?
• O código está causando problemas quando você está mantendo o software?
• O código é completamente autônomo?
• Você tem planos de atualizar ou substituir o código a qualquer momento no futuro previsível?
• Existe um caso de negócio sólido que você pode fazer para atualizar o código em questão?

Se há uma coisa que aprendi ao longo dos anos, é que você não pode se dar ao luxo de pensar duas vezes depois do fato. Toda vez que você resolve um problema no código, você 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 diferentemente 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 com o tempo.

O que estamos realmente falando aqui é se o código que incomoda é fácil ou difícil de ser mantido, e quão custosa é a manutenção com o passar do tempo. Esta é essencialmente uma questão sobre a Dívida Técnica, e se vale a pena pagar essa dívida usando uma pequena 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 avaliar em relação à sua carga de trabalho presente e futura, e devem ser discutidas com o seu gerenciamento e equipe para obter um melhor entendimento sobre onde investir seus recursos e se o seu antigo código vale a pena o tempo que você pode precisar gastar - se em tudo. Se você puder fazer um bom negócio para introduzir mudanças, então, de qualquer maneira, faça isso, mas se você estiver enfrentando o desejo de mexer com o código, porque você se sente envergonhado com a maneira como o escreveu, então sugiro que não haja nenhuma mudança. espaço para orgulho pessoal quando se trata de manter o código antigo. Ele funciona ou não, e é fácil de manter ou caro de manter, e nunca é bom ou ruim simplesmente porque a experiência de hoje não estava disponível para você ontem.

Definitivamente, não melhore apenas para melhorá-lo. Como outros já disseram (e é senso comum), todos nós melhoramos (por algum valor de "melhor") com o passar do tempo. Dito isto, rever o código (formal ou informalmente) geralmente ilumina essas partes que provavelmente nunca mais veremos a luz do dia.

Embora eu não acredite que tenhamos uma 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 Eu fiz no passado nesta situação:

• Identifique pessoas da equipe que realmente gostam de voltar e melhorar o código, como uma espécie de limpeza cerebral ou uma tarefa agradável que dá uma sensação de realização e encontrar tempo na agenda para que façam em uma base regular. 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 estamos todos em um período de calmaria ou inatividade.

• Use-o como base para um exercício de aprendizado. Para estagiários, alunos ou membros novos / juniores da equipe, refatorar códigos antigos com orientação de membros seniores da equipe dá a eles a oportunidade de se comunicar com novos membros da equipe, entender mais sobre o sistema e adquirir o hábito de escrever / atualizando testes unitários e trabalhando com integração contínua. É importante notar que este exercício é feito com orientação e claramente enquadrado como um exercício para tornar o código melhor porque não está em conformidade com os padrões / normas atuais.

Portanto, não há responsabilidade de consertar, mas coisas antigas podem ser realmente úteis. E os testes de unidade e CI são seus amigos!

Não necessariamente. No entanto, se você estiver executando uma manutenção de código e se deparar com algo que poderia ser melhor, você 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 puder ter certeza de que se comportará exatamente como deveria, é melhor deixá-lo sozinho.

Do ponto de vista de um engenheiro, eu gostaria muito de trabalhar com código antigo até que ele não possa mais ser melhorado. Mas há um caso de negócio para isso? No final do dia, o código está lá para contribuir para a linha de fundo, a rentabilidade do seu local de trabalho. Se não for, apenas deixe.

Há uma grande ressalva, se melhorando o código, você evitará que um bug ocorra, (pensando nas grandes bolas do Y2K aqui em cima ..) Eu definitivamente o traria para alguém mais alto, talvez o seu negócio gerente da unidade e discuta as conseqüências de melhorar o código.

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

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

1. Para que eu vou fazer alterações?
2. Precisarei dar suporte a esse código? Quanto tempo isso pode acontecer (próximo / futuro distante)?
3. Este código é confortável o suficiente para trabalhar? (Agora)
4. Posso ter certeza de que todas as alterações que faço são seguras? Diferentes testes geralmente ajudam a responder a essa pergunta.
5. Que consequências posso encontrar se cometer erro (s) 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 há uma lista completa e final deles. Só você e provavelmente seus colegas de equipe podem encontrar a resposta.

P.S. Tenho notado que costumo reescrever o código com muita frequência, enquanto meu amigo e colega de equipe tendem a deixá-lo intocado. Isso 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 Distros * nix precisam continuar evoluindo? Ou um exemplo mais prático, todos ainda dirigem carros dos anos 1970?

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

Não há uma resposta simples para o que vale a pena refrear. Geralmente você não deve a menos que: a) seja um bom exercício de aprendizado para você ou b) você economize tempo a longo prazo com um código melhor. Lembre-se de que cada mudança arrisca erros.

Como uma nota lateral, eu defendo strongmente os testes de unidade. É muito fácil acabar com o refrachamento, especialmente se você não tiver um comportamento atual claramente marcado com descansos automatizados.

Acredito que temos a responsabilidade de escrever o melhor código possível que pudermos hoje. Isso significa usar tudo o que aprendemos no passado e recusar-se a aceitar atalhos no nosso design. Se as pressões do cronograma fizerem com que algo seja cortado, eu não acredito que a qualidade do nosso software deva ser considerada, por outro lado, aquele pequeno clipe de papel animado ...

Agora, se você está trabalhando e descobre que o código com o qual você precisa interagir não está escrito no nível que você está atualmente apto a escrever, então é razoável corrigi-lo SE você for capaz de fazê-lo de maneira metódica e controlada . Eu, pessoalmente, tenho uma experiência mínima com esse tipo de refatoração, como todo mundo (quase todo mundo). Eu tentei o todo "vamos apenas mudar tudo e rezar para que funcione" e tive uma mordida ruim o suficiente. Eu sugiro olhar para as discussões de Martin Fowler (ou seu livro ou um dos muitos artigos ) sobre o assunto. Ele parece ter inspirado a maior parte do pensamento atual sobre o processo.

É claro que às vezes você pode não conseguir limpar o código como deseja. Joel Spolsky escreveu um artigo sobre por que você pode querer dedicar algumas semanas para simplesmente Refazer seu código. Leia isso aqui e sim, é um pouco velho, mas eu acho que a informação ainda é relevante.

Espero que isso ajude

Eu sinto que a refatoração / melhoria do código antigo define o próprio programador. Querer melhorar o código que você escreveu há um ano apenas mostra seu progresso, e se ele melhorar o aplicativo e você tiver a capacidade, o tempo e a aprovação para melhorá-lo, faça isso.

Melhor / melhorado é uma comparação multi-eixos. Você acha que pode tornar mais rápido, menor, mais eficiente, mais legível, mais informações ú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 deve pagar para você gastar tempo reescrevendo esse código, em vez de escrever um novo código ou reescrever outra parte do código?

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

Enviar uma mudança à produção introduz uma chance diferente de zero de quebrar as coisas (testes unitários e funcionais apenas reduzem essa chance, eles não a eliminam) e devem ser feitos apenas quando o benefício esperado superar o risco.

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

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

Se o código não se beneficiar de sua análise, se os nomes de campo 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 perdeu algo de valor: seu estado de compreensão . Com ferramentas como Visual Studio e ReSharper, esses tipos de refatoração são seguros, lógicos neutros e de grande valor potencial na futura produtividade e confiança do desenvolvedor.

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

Esta é uma pergunta para a 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 ter uma equipe de controle de qualidade? TESTE o que você mudou para ter certeza de que não está quebrado?

Eu caí nessa armadilha antes de estar em um módulo consertando um bug e ver o código que eu ou alguém escreveu que era ineficiente ou deselegante, alterá-lo e acabar com mais problemas para lidar do que se Acabei de consertar o bug que eu estava encarregado de corrigir.

Depende.

Se o código em questão estiver realmente quebrado, de tal forma que ele contenha erros que aparecerão inevitavelmente em um ponto (por exemplo, algum contador que em algum momento transbordará e causará problemas desagradáveis), então consertar esses erros pode valer o esforço - mas se você fizer isso, coloque todas as proteções possíveis primeiro para evitar a introdução de novos bugs: certifique-se de ter testes unitários significativos cobrindo tudo o que toca, revise todas as alterações de alguém competente, insista em fazer testes exaustivos, certifique-se de reverter para a versão antiga a qualquer momento, faça backup de todos os dados antes de começar a produção, implante primeiro em um ambiente de aceitação e teste-os por usuários reais etc. Você também precisará obter aprovação antes de prosseguir: se o erro for verdadeiro uma bomba-relógio e seu gerente é um pouco competente, você será capaz de convencê-lo a deixá-lo consertar (e se você não for aprovado, então talvez seja um sinal de que você está errado).

OTOH, se sua queixa é mera falta de elegância de código, então não se atreva a tocá-lo. Ele tem feito serviço fiel em produção por um bom tempo agora, mudar o código só iria satisfazê-lo, mas não adicionar qualquer valor, e como toda mudança, existe o risco de você quebrar alguma coisa. Mesmo que você não o faça, seu tempo é valioso (literalmente: você está sendo pago pelo que faz, então 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.