O nosso código é uma merda e eu sou incapaz de corrigi-lo.Ajuda![fechado]

Question

O nosso código é uma merda.Na verdade, deixe-me esclarecer isso.Nossa idade o código é uma merda.É difícil depurar e é cheio de abstrações que poucas pessoas entendem, ou mesmo se lembrar.Ontem eu passei uma hora de depuração em uma área que eu trabalhei para a mais de um ano e dei por mim a pensar, "Uau, isso é realmente muito doloroso." Não é qualquer pessoa da culpa - eu tenho certeza que tudo fez perfeito sentido inicialmente.A pior parte é que normalmente Ele Só Funciona...desde que você não pedir a ele para fazer alguma coisa fora de sua zona de conforto.

O nosso novo código é muito bom.Eu acho que nós estamos fazendo um monte de coisas boas lá.É claro, consistente, e (espero) de fácil manutenção.Nós temos um outro servidor em execução para a integração contínua e temos o início de um teste de unidade suite no lugar.O problema é a nossa gestão a laser é focado em escrever Código Novo.Não há tempo para dar-Código Antigo (ou até mesmo o antigo Código Novo) o TLC, ele precisa tão desesperadamente.Em qualquer dado momento, nosso scrum backlog (para seis desenvolvedores) tem cerca de 140 itens e cerca de uma dezena de defeitos.E esses números não estão mudando muito.Estamos adicionando as coisas o mais rápido possível gravá-los para baixo.

Então, o que posso fazer para evitar as dores de cabeça da maratona de sessões de depuração mergulhados nas profundezas do Código Antigo?Cada sprint é cheio até a borda com o desenvolvimento de novos e showstopper defeitos.Especificamente...

• O que posso fazer para ajudar a manutenção e tarefas de refatoração se alta o suficiente prioridade a ser trabalhada?
• Há alguma C++específicas estratégias que utilizam para ajudar a impedir que o Novo Código de decomposição tão rapidamente?

Answer 1

Sua gerência pode estar focada em colocar os recursos de trabalho no produto e mantê -los funcionando. Nesse caso, você precisará defender um caso de negócios para refatorar as coisas antigas; nisso, por X Investimento de tempo e esforço, você pode reduzir o tempo de manutenção necessária no Y sobre o período Z. Ou sua administração pode ser fundamentalmente sem noção (isso acontece, isso acontece, isso acontece, isso acontece, isso acontece, isso acontece, isso acontece, isso acontece, isso acontece, isso acontece, isso acontece, isso acontece com o tempo de manutenção, no período Y durante o período Z. Mas com menos frequência do que a maioria dos desenvolvedores parece pensar), nesse caso, você nunca obterá permissão.

Você precisa ver o ponto de vista dos negócios. Não importa para o usuário final se o código é feio ou elegante, apenas o que o software faz. O custo do código ruim é a falta de confiabilidade potencial e a dificuldade adicional de alterá -lo; O sofrimento emocional que isso causa ao programador raramente é considerado.

Se você não conseguir obter permissão para entrar e refatorar, sempre poderá experimentá -lo por conta própria, um pouco de cada vez. Sempre que você consertar um bug, faça um pouco de reescrita para tornar as coisas mais claras. Isso pode ser mais rápido que a correção mínima possível, principalmente na verificação de que o código agora funciona. Mesmo que não seja, geralmente é possível levar um pouco mais de tempo em uma correção de bugs sem ter problemas. Só não se empolgue.

Se você pode deixar o código um pouco melhor cada vez que entrar, se sentirá muito melhor com isso.

Answer 2

Reuniões de pé

Eu posso ir ao meu mecânico e temos uma pequena reunião de stand-up de manhã:

Eu digo a ele que quero minhas rodas alinhadas, meus pneus giravam e meu óleo mudou. Menciono que "ah, a propósito, meus freios se sentiram um pouco macios no caminho. Poderia [ele] dar uma olhada neles? Em quanto tempo posso recuperar meu carro porque preciso voltar ao trabalho?"

Ele coloca a cabeça debaixo do meu carro, aparece e diz que meus freios estão vazando óleo e começando a falhar. Ele precisará de uma parte que chegará às 10h30. Seu homem não vai terminar antes do almoço, mas eu deveria recuperar meu carro às 13:30. Ele está reservado sólido para que não possa fazer nenhuma das outras coisas hoje e terei que marcar outra consulta.

Pergunto se ele pode fazer as outras coisas e volto para o freio. Ele me diz que realmente não pode me deixar sair de lá sem consertar os freios, porque eles podem causar um acidente, mas se eu quiser ir a outro mecânico, ele pode pedir um reboque.

Como o carro será feito logo após o almoço, pergunto se o homem dele pode almoçar tarde para que eu possa recuperar meu carro uma hora antes.

Ele me diz que seus homens chegam às 8h e geralmente trabalham à noite. Eles ganham cada pausa que recebem, e seu homem merece almoçar com todos os outros.

Nada disso é o que eu queria ouvir. Eu queria saber que iria sair de lá em meia hora com minhas rodas, pneus e petróleo.

Meu mecânico era direto e honesto comigo. Você é direto e honesto com sua gerência? Ou você evita dizer a eles coisas que eles não querem ouvir?

Teste de unidade

Eu não tocaria em uma linha de código que não entendi e não verificaria uma nova linha de código que não testei completamente. (Pelo menos, não intencionalmente.)

Sua pergunta parece sugerir que, de alguma forma, um grande corpus de código mal documentado tornou a revisão anterior sem testes de unidade. Talvez você tenha participado disso, e talvez não o fizesse. Todos os envolvidos precisam aceitar a responsabilidade por isso-incluindo a gerência. Independentemente disso, o que está feito é feito. Você não pode voltar e mudar isso.

No entanto, agora, no momento, é responsabilidade de todos Pare o comportamento Isso levou ao problema em primeiro lugar. Você diz que passou um ano trabalhando no código que acha difícil de entender e que não possui testes de unidade. Durante esse ano, enquanto você trabalhou duro para melhorar sua compreensão, Quantos testes de unidade você escreveu para documentar e verificar esse entendimento?

Enquanto você lutava com o código lentamente ganhando entendimento, quantos comentários você acrescentou para não precisar lutar na próxima vez?

Backlog scrum

Pessoalmente, acho que o termo "backlog scrum" é um nome impróprio. Uma lista de coisas a fazer é apenas uma lista-uma lista de compras, se você quiser. Eu tinha uma lista quando fui ao mecânico. Minha reunião com o mecânico foi realmente mais uma reunião de planejamento de sprint.

Uma reunião de planejamento de sprint é uma negociação. Se a sua gerência é o boxe do tempo sem essa negociação, eles não estão gerenciando nada. Eles estão simplesmente tentando enfiar 10 libras de merda em um saco de 5 lb, e é sua responsabilidade contar isso a eles.

Quando você aparece em uma reunião de planejamento de sprint, espera -se que você se comprometa com um corpo de trabalho, e é sua responsabilidade se preparar para isso. A preparação significa ter uma idéia do que você terá que fazer para concluir cada item da lista-incluindo o tempo necessário para entender o código obscuro e o tempo necessário para escrever testes de unidade.

Se alguém o convida a uma reunião de planejamento onde você não terá tempo para se preparar, recusar a reunião e sugerir quando reagendar para que você tenha tempo.

Se você tiver um corpo de código existente sem testes de unidade e um recurso pode afetar a operação desse código, você precisa gravar testes de unidade para o máximo do código antigo que pudesse ser afetado. Quando você se compromete a escrever o recurso, está se comprometendo a fazer esse trabalho. Se isso deixa muito pouco tempo para se comprometer com algum outro recurso, apenas diga. Não se comprometa com o outro recurso.

Quando você se compromete a corrigir um defeito, você se compromete a testar seu trabalho. Obviamente, isso significa escrever um teste de unidade para o defeito. Mas se envolver código antigo, sem testes de unidade, também significa escrever testes de unidade para coisas que ainda não estão quebradas, mas poderão quebrar devido à sua mudança. De que outra forma você vai testar a correção?

Se sua lista de defeitos permanecer um tamanho constante, sua equipe regredirá tanto quanto conserta. Explique educadamente a quem precisa entender que os testes de unidade impedem que as regressões que atualmente impedem sua lista de defeitos.

Se você não conseguir escrever esses testes de unidade porque se compromete com muitos recursos, De quem é a responsabilidade?

Reestruturação

Quando você refatora o código, você deve testar tudo isso, e isso significa escrever testes de unidade para tudo isso. Se você tiver um grande corpo de código sem testes de unidade, terá que escrever todos esses testes de unidade antes da você refatora.

Eu sugiro que você adie a refatoração até que esses testes de unidade estejam em vigor. Enquanto isso, se você insistir em incluir testes de unidade em suas estimativas para o trabalho com o qual você se compromete, eventualmente todos esses testes de unidade estarão lá. E então você pode refatorar.

A única exceção é refatorar a testabilidade. Você pode achar que parte do código não foi projetado para teste e que você precisa refatorar para coisas como injeção de dependência antes de criar seus testes de unidade. Quando você se compromete a escrever o recurso que requer o teste de unidade, você se compromete a tornar o código testável. Inclua isso na sua estimativa quando você se compromete com o recurso.

Compromisso + responsabilidade = poder

Você diz que é impotente. Quando você aceita a responsabilidade e se compromete a fazer o que precisa fazer, acho que você descobrirá que tem todo o poder que precisa.

PS Se alguém reclamar de alguém "desperdiçando tempo" escrevendo vários testes de unidade ao consertar um único defeito, mostre -os Este vídeo na regra 80:20 e na libra "agrupamentos de defeitos" em seus cérebros.

Answer 3

É difícil dizer muito das informações que você fornece. Algumas perguntas que eu teria é um motivo lógico para escrever um novo código é substituir o código antigo. Se é isso que você está fazendo, abandone o código antigo.

Também é um código antigo que tem defeitos de exibição? Se sim, de onde eles vêm? O código antigo não possui defeitos "Showstopper", apenas se aproxima cada vez mais de uma parada. Afinal, é um código antigo - ele deve ter os mesmos defeitos antigos e as mesmas velhas limitações, não coisas que precisam ser analisadas imediatamente. Os defeitos do showstopper são novos defeitos de código. Parece que há desenvolvimento ativo no código antigo.

Se você está escrevendo todo esse novo código no topo do código antigo que é péssimo, sem planos de corrigi -lo de uma vez por todas, desculpe, há muito que você pode fazer quando estiver ocupado demais enterrando -se para se desenterrar.

Se o último for o caso. Você deve reconhecer para onde está indo e tentar se destacar um pouco. Tudo vai entrar em colapso eventualmente, se você planeja estar por perto, economize suas forças para uma batalha que vale a pena.

Enquanto isso, tente pegar alguns padrões de design. Existem vários que podem pelo menos ajudar a proteger seu novo código das coisas antigas, mas ainda assim, em última análise, é difícil escrever um bom código contra o código ruim.

E seus sprints parecem confusos. Não existe uma direção geral? Isso deve determinar quanto backlog você tem, embora as coisas possam mudar mês a mês, não há uma sensação clara de avançar em direção a algum objetivo final?

E novo código apodrecendo? A maneira como você evita que seja um design significativo, uma direção significativa e uma equipe de qualidade comprometida com a qualidade do trabalho e a visão do design. Se você tem isso, a disciplina é o que mantém a qualidade. Se você não sente muito, basicamente estava escrevendo código sem propósito. Estava basicamente podre na videira.

Não sendo crítico, apenas tentando ser honesto. Respire fundo. Desacelerar. Você parece que precisa disso. Veja o que você escreveu aqui. Não diz nada. Você fala de refactor, scrums, showstoppers, defeitos, código antigo, novo código. O que isso significa disso? Está tudo confuso.

E os "novas iniciativas versus sistemas legados"? "Precisa refatorar o código do ciclo de sprint precoce em termos de entendimento mais recente etc." Na verdade, são exibidos "componentes iniciais das atuais iniciativas corporativos foram divulgados, mas estão enfrentando problemas e nenhum tempo é orçado por causa do novo desenvolvimento".

Estes seriam conceitos significativos. Você não nos deu nada. Eu entendo que é intenso. Meus sprints também são loucos, adicionamos muitas costas; itens PG porque não conseguimos obter muitos requisitos antecipadamente (muitos dos meus novos requisitos resultam de ter que lidar também com órgãos regulatórios externos, o processo de negócios normal nem sempre está disponível ).

Mas, ao mesmo tempo, estou movido pela grande magnitude do que deve ser feito e da hora de fazê -lo. Tudo o que é adicionado ao meu backlog precisa estar lá. É uma loucura, mas ao mesmo tempo tenho uma idéia muito clara de onde estive, para onde preciso ir e por que a estrada é mais difícil.

Dê uma volta, limpe seus pensamentos, descubra o mesmo - onde você esteve e para onde está indo. Porque se você souber disso, com certeza não é óbvio. Se você não pode comunicar nada que seus colegas possam entender, até onde você vai chegar com um gerente de negócios?

Answer 4

Código antigo sempre é uma merda.Há provavelmente algumas raras exceções escritos por pessoas com nomes como Kernighan ou Thompson, mas, para o típico "código escrito em um escritório" coisas, com o tempo ele vai cheirar mal.Os desenvolvedores obter mais experientes.Mais recentes práticas, tais como integração contínua, alterar o jogo.Coisas obter esquecidos.Novos mantenedores não compreendem desenhos e desejo de re-escreve.Então, o melhor aceitar isso como normal.

Algumas coisas aleatórias que podem ajudar...

• Falar sobre isso com sua equipe.Compartilhe suas experiências e as suas preocupações, evitando "o homem seu código antigo chupa" (por motivos óbvios) e veja o que o consenso é.Você provavelmente não está sozinho.
• Esqueça os seus gestores.Não expô-las a esse nível de detalhe, eles não precisam pensar sobre novos vs. decódigo antigo e, provavelmente, não entendo se o que eles fazem.Este é um problema para a sua equipe para enfrentar e, se necessário, para fazer a sua nota de encomenda ciente de
• Estar aberto para a possibilidade de que você pode ser capaz de jogar coisas fora.Alguns dos que o código antigo, provavelmente, relaciona-se com características que não estão mais sendo usados ou não conseguiu ser aprovado pelos usuários em primeiro lugar.Para fazer este trabalho para você, você realmente precisa ir a um nível mais alto e pensar em termos de onde o código realmente oferece usuário ou o valor do negócio vs.onde é apenas uma bola de lama que ninguém é corajoso o suficiente para tomar uma decisão.Quem não arrisca, não petisca.
• Relaxe a sua visão de arquitetura de consistência.Há sempre uma forma de tocar em um sistema de trabalho com o novo código em algum lugar, e que pode permitir que você lentamente migrar para uma nova abordagem mais inteligente, preservando o antigo tempo suficiente para não quebrar as coisas existentes.

No geral, a vitória neste tipo de situação é menos sobre habilidades de codificação e muito mais sobre o smart opções de manuseio e os aspectos humanos.

Espero que ajude.

Answer 5

Eu recomendo acompanhar quantos bugs e mudanças de código envolvem seu "código antigo" e apresente isso ao seu gerente ou aos seus colegas desenvolvedores em sua próxima reunião de equipe. Com isso na mão, deve ser simples o suficiente para convencê -los de que mais precisa ser feito para refatorar seu "código antigo" e colocá -lo emparelhar com seu "novo código".

Também seria prudente documentar as partes do seu "código antigo" que são mais difíceis de entender. Essas também seriam as partes do seu "código antigo" que você deve refatorar primeiro depois de obter a aprovação.

Answer 6

Algo para tentar:grupo de alunos de sua classe para - dizer - pior, 10%, o melhor de 10%, e o resto.Entregar a lista para o seu gerenciamento, dizendo: "eu diria que a maioria dos bugs mais próximo trimestre será encontrado no primeiro set." Com base no comprimento, cyclomatic complexidade, cobertura de teste - as ferramentas são úteis e confortável para você.Em seguida, sentar e assistir e estar certo.Agora que você tem alguma credibilidade, algumas alavancagem, quando você diz, "eu gostaria de investir alguns recursos para fazer o nosso código incorreto melhor, para reduzir erros e custos de manutenção - e eu sei onde investir essa energia, está a ver?"

Answer 7

Você pode criar diagramas e esboços de como o novo código de obras e de como as classes e funções estão relacionadas uma com a outra.Você pode usar FreeMind ou talvez Dia.E eu definitivamente concordo com a Documentar e comentar o seu código.Uma vez eu tive um problema com isso também.Eu escrevi uma letra de classe para J2ME para minha própria língua.Foi horrível por estas razões que, talvez, você também pode ver no seu código.

• Sem Comentários ou documentação
• Menos orientada a objeto
• ruim variável / função nomes
• ...

Mas depois de alguns meses, eu era forçado a escrever a coisa toda de novo.Agora eu aprendi a usar significativa nomes de variáveis que são às vezes MUITO longa.escrever comentários mais do que escrever códigos.E usando diagramas para as aulas do projeto e suas relações.

Eu não sei Se foi uma resposta real, mas ele definitivamente funcionou para mim.e para os antigos códigos que você pode realmente ter de reler a coisa toda e adicionar comentários quando você lembrar de funcionalidades.

Espero que isso ajudou.

Answer 8

Fale com o proprietário do seu produto! Explique que o tempo investido na refatoração do código antigo lhe trará benefícios da maior velocidade da equipe em novos recursos assim que esse obstáculo for removido.

Answer 9

Além das abordagens mencionadas acima, que são boas, você também pode tentar:

Para manter o código futuro limpo

• Experimente a programação de pares, pelo menos para peças que fazem sentido. É uma maneira eficaz de ser revisada, o código refatorado uma prática.
• Tente refatorar -se na definição de "feito". Em seguida, fará parte do processo de estimativa e alocado de acordo. Portanto, a definição de concedida pode incluir: codificado, testado em unidade, testado funcionalmente, desempenho testado, código revisado, refatorado e integrado (ou algo assim).

Para limpar o código antigo:

• Os testes de unidade são ótimos para ajudá -lo a refatorar e descobrir como as coisas funcionam.
• Concordo com os comentários que um caso de negócios precisa ser feito para a refatoração em larga escala. Porém, a refatoração em pequena escala pode ser facilmente incluída na estimativa e fornecerá retorno imediato. IE: Passo 2 horas reescrevendo uma peça, mas eu teria passado esse tempo procurando bugs de qualquer maneira.

Você também pode considerar que o proprietário do produto e o Scrummaster capturar uma velocidade separada para o código antigo versus o novo código e usá -lo de acordo.

Answer 10

Se houver um novo recurso desejado e você poderá delinear um pedaço de código que não existe o que está no caminho, poderá obter a bênção da gerência para substituir o código antigo pelo novo código que possui o novo recurso desejado. Quando fiz isso, tive que escrever uma camada de calço um tanto feia para encontrar as antigas interfaces da parte do software que eu não iria tocar. E um chicote de teste que poderia exercer o código existente e exercer o novo código para garantir que o novo código, como visto através da camada de calço, poderia enganar o restante do aplicativo para pensar que nada havia mudado. Ao retrabalhar a parte que reformulamos, fomos capazes de mostrar enormes benefícios de desempenho, compatibilidade com o novo hardware desejado, a redução em cada um dos necessidades de conhecimento do nosso site de administração de espaço para o aplicativo - e o novo código foi muito mais sustentável. Esse último ponto era importante para os usuários, mas as outras vantagens do retrabalho eram atraentes o suficiente para "vender" os usuários por méritos de uma conversão de banco de dados um tanto dolorosa.

Outra história de sucesso mais modesta: tivemos um sistema decente de rastreamento de problemas que tinha literalmente anos de história. Havia um subsistema de nosso aplicativo que era famoso pela velocidade com que ele queimaria programadores de manutenção. Claramente (bem, claramente em minha mente), precisava de uma grande reescrita, mas a gerência não estava entusiasmada com isso. Conseguimos cavar a história nos dados de rastreamento de problemas para mostrar o nível de pessoal que havia realizado para manter esse módulo e, por todo esse esforço, os bilhetes de problemas por mês contra esse módulo continuaram a chegar a uma taxa constante. Quando confrontado com dados reais como esse, mesmo os gerentes relutantes que há muito tempo tinham sido apertados sobre o trabalho de pessoal desse subsistema podiam ver o mérito de atribuir a equipe para refazer esse módulo.

A abordagem como antes era deixar a entrada e a saída desse módulo sozinho. A boa notícia era que jogar a memória virtual no novo código com suas novas estruturas de dados sofisticadas deu uma melhoria perceptível de desempenho no módulo. A má notícia é que quase terminamos a reimplementação antes de realmente entendermos o que havia de errado na implementação original, de modo que funcionasse na maioria das vezes, mas conseguiu falhar em algumas das transações em alguns dias. O primeiro corte reproduziu fielmente esses bugs, mas os bugs eram mais fáceis de entender no código retrabalhado, então agora tivemos uma chance de realmente resolver o problema real. Em retrospecto, talvez tenhamos sido mais inteligentes por ter capturado dados que produziram os problemas e tenhamos cuidado melhor para garantir que a versão retrabalhada não reproduzisse esse problema. Mas, a verdade é que ninguém entendeu o problema até que estávamos muito longe na reescrita. Portanto, o reescrito deu um melhor desempenho aos usuários e um melhor entendimento aos programadores atuais, de modo que o problema real poderia realmente ser resolvido finalmente.

Um exemplo de falha: havia mais um módulo incrivelmente feio que persistentemente era um ponto dolorido. Infelizmente, eu não era inteligente o suficiente para poder entender as interfaces de defacto nessa colméia miserável de escória e vilania, pelo menos não no prazo do cronograma de liberação nominal. Eu gostaria de acreditar que, dado mais tempo, poderíamos ter descoberto um plano adequado para reformular essa parte do sistema também, e talvez uma vez que o entendamos, poderíamos até identificar melhorias desejadas pelo usuário que poderíamos nos encaixar no reescrever. Mas não posso prometer que você encontrará um prêmio em cada caixa. Se a caixa for totalmente obscura para você, é difícil cortar um pedaço dela e substituir essa peça por código limpo. O cara que se encarregou desse módulo é provavelmente aquele que estava melhor posicionado para descobrir um plano de ataque, mas viu os frequentes acidentes e pedidos do campo para obter assistência como "segurança no trabalho". Eu não acho que a gerência realmente reconheceu que ele precisava ser deixado de lado para alguém com fome de mudança, mas é isso que provavelmente era necessário.

Desenhou