Como argumentar contra a redução dos padrões de qualidade da base de código herdada? [fechadas]

28

Temos aqui uma grande base de código herdada com código incorreto que você não pode imaginar.

Definimos agora alguns padrões de qualidade e queremos cumpri-los em uma base de código completamente nova, mas também se você tocar no código legado.

E reforçamos aqueles com o Sonar (ferramenta de análise de código), que já possui milhares de violações.

Agora, a discussão surgiu para diminuir as violações do legado. Porque é legado.

A discussão é sobre regras de legibilidade. Como quantos ifs / for aninhados .. pode ter.

Agora, como posso argumentar contra diminuir nossa qualidade de codificação no código legado?

code-quality static-analysis legacy-code

— keiki
fonte

2

é a discussão sobre a redução dos limites da ferramenta? ... ou eu entendi errado. Está escrito de uma maneira confusa.

— Dagnelies

13

Como explico $ {something} para $ {someone}?

— Gnat

4

A questão tem algumas partes muito pouco claras. "diminuir essas violações" - você quer diminuir o número real de violações (reescrevendo o código antigo), o número de regras testadas pelo Sonar na base de códigos herdada ou o número de regras do seu padrão de codificação que você deseja seguir ao alterar algo no código legado?

— Doc Brown

4

Também temos um produto legado de terrível qualidade de código. Como ele será substituído pelo novo produto, quase não há valor em limpar esse código antigo. Isso significa: aceitamos um padrão mais baixo na base de códigos herdados.

— Bernhard Hiller

4

@keiki: ainda não está claro: a nova base de código está separada o suficiente para ter regras de validação diferentes para o antigo e o novo código? E as partes que você altera na base de código herdada? O seu problema é que elevar as peças alteradas para um padrão mais alto causa muito esforço ou você não pode separar essas peças na validação do Sonar, para possibilitar a validação completa apenas das peças alteradas?

— Doc Brown

73

O código é apenas um meio para atingir um fim. O que esse fim pode ser varia, mas geralmente é lucro.

Se é lucro; então, argumentar com êxito qualquer coisa que você queira mostrar que aumentará o lucro - por exemplo, aumentando as vendas, reduzindo os custos de manutenção, reduzindo os custos de desenvolvimento, reduzindo os salários, reduzindo os custos de reciclagem etc. Se você não pode / não mostra que isso melhorar lucro; então você está apenas dizendo que seria uma maneira divertida de jogar dinheiro no vaso sanitário.

— Brendan
fonte

15

Acredito que há outra dimensão nesta discussão que é o profissionalismo, em muitas profissões, se seu chefe pedir para você cortar custos, você pode se recusar a fazê-lo com base na moral (às vezes até a lei o apóia), eu não entender por que os desenvolvedores de software devem se comportar de maneira diferente.

— Alessandro Teruzzi

21

@AlessandroTeruzzi Você pode se recusar a fazer qualquer coisa por motivos morais (pessoais) em qualquer lugar, independentemente do profissionalismo. Não garante que você continuará trabalhando naquele local.

— Kromster diz apoio Monica

Além disso, como as bases de código costumam ser extremamente complicadas, seria difícil provar qualquer uma das coisas mencionadas, mesmo que um desenvolvedor experiente possa saber por experiência própria que cortar custos irá custar caro a longo prazo.

— Mkataja

17

Nada de errado nesta resposta, mas, no entanto, IMHO não é útil para a maioria das situações do mundo real. Melhorar a qualidade de uma base de código geralmente reduz o custo de manutenção, especialmente a longo prazo, mas esses efeitos raramente são quantificáveis. Portanto, geralmente é uma decisão estratégica.

— Doc Brown

2

@DocBrown Eu concordo provisoriamente, mas acho que o desenvolvimento orientado por números aninhados de ifs, como um OP, não é uma abordagem eficaz para melhorar uma base de código herdada.

— brian_o

44

Eu, eu e eu, fomos produtores e mantenedores de código legado. Se a sua ferramenta está gerando "milhares de violações" (ou mesmo centenas), esqueça a ferramenta, isso é inaplicável à situação ...

Suponho que os desenvolvedores originais se foram e não estão disponíveis para discussão. Portanto, ninguém por perto entende o porquê e o porquê do estilo de design e codificação. Corrigir centenas ou milhares de violações não será uma questão de reescrever algumas linhas de código aqui e ali. Em vez disso, requer, sem dúvida, refatoração / decomposição re-funcional. Você tenta fazer isso em qualquer grande base de código existente, sem entender profundamente seu design atual, e é obrigado a apresentar um novo conjunto de bugs / problemas / etc. Apenas uma nova lata de vermes ainda pior do que a que você possui agora (ou pior do que a sua ferramenta >> pensa que você tem agora).

A única abordagem sensata para resolver "milhares de violações" seria reescrever do zero. Um esforço longo e caro e quase impossível de vender para a gerência. E, neste caso, eles provavelmente estão certos ...

O código herdado normalmente requer apenas ajustes. Como no y2k, ou quando as ações passaram de 256th para decimal. Eu fiz um monte de ambos que cr * p. E muitas outras coisas semelhantes. É tipicamente bastante "preciso", pois você pode "ler" o estilo às vezes ruim, a decomposição funcional ruim, o mau etc, e localizar a coleção de locais que precisam ser modificados. E então, o que acontece "entre esses lugares", ou seja, qual é o fluxo de mais alto nível, pode permanecer um mistério para você. Apenas certifique-se de entender a funcionalidade localizada que está sendo alterada e, em seguida, teste, teste, teste de quaisquer efeitos colaterais, etc., seu conhecimento localizado não será capaz de antecipar.

Se você não conseguir visualizar o código dessa maneira, talvez não seja a melhor pessoa para manter o código herdado. Algumas pessoas podem começar com uma tela em branco e escrever programas bonitos, mas não podem começar com uma grande base de código do código de outras pessoas e mantê-lo. Outras pessoas podem manter o código, mas não podem começar do zero. Alguns podem fazer as duas coisas. Verifique se as pessoas certas estão mantendo seu código legado.

Os momentos ocasionais em que você pode redesenhar e reescrever sua base de código herdada do zero são quando os requisitos de negócios (ou outros) mudam a tal ponto que os "ajustes" básicos não podem mais acomodar os requisitos alterados . E, nesse ponto, você pode começar escrevendo um novo documento de requisitos funcionais, certificando-se de que todas as partes interessadas estejam a bordo. É basicamente um jogo totalmente novo.

A única coisa >> errada >> a fazer é tentar tratar a manutenção de código legado da mesma maneira que você faria no desenvolvimento. E essa coisa errada parece ser exatamente o caminho que você gostaria de seguir :) Acredite na minha palavra, não é isso que você quer fazer.

— John Forkosh
fonte

2

Isso responde a uma pergunta "O legado deve ser reescrito". Mas o OP não está perguntando como corrigir os avisos ou se a reescrita deve ocorrer. A pergunta era sobre padrão de qualidade - basicamente um requisito para que todas as alterações não aumentassem a contagem de avisos de validação.

— Basilevs

9

Isso aborda diretamente a pergunta, que não é sobre reescrita. O OP quer argumentar por 'tratar a manutenção de código legado da mesma maneira que você faria com o novo desenvolvimento'. Esta resposta diz "WOAH! Você não deve fazer isso!" Pode não ser a resposta que o OP ou você queria ouvir, mas responde totalmente à pergunta.

— Jonathan Eunice

11

@Basilevs (e @ JonathanEunice). O que Jonathan disse. E note que comecei dizendo diretamente "esqueça a ferramenta, é inaplicável à situação", que aborda diretamente a questão, embora de forma negativa. Mas, como diz o ditado, se você vai criticar, faça críticas construtivas. Então eu não poderia simplesmente dizer "não faça isso". Eu também tive que sugerir o que fazer (e isso ficou um pouco mais demorado do que eu esperava quando comecei a escrever).

— precisa saber é o seguinte

11

Ao trabalhar com projetos de código legado, às vezes gosto de criar uma camada de interface que fica entre o código antigo e o novo. Isso permite uma divisão limpa entre as peças antigas e as novas e facilita a solução de problemas das peças novas do que se elas fossem introduzidas com um monte de código que eu não entendo.

— supercat

@supercat Se isso puder ser feito, é certamente uma boa abordagem. Mas, lembrando de vários dos meus projetos de correção do y2k, você só precisava "mergulhar" no meio do código existente e mexer com ele. Não é possível (re) fatorar para o antigo / novo possível (sem >> massivo << reescrever). Por exemplo, em vez de adicionar dois bytes aos campos de data por um ano com formato de cíclico de quatro bytes, exigindo atualizações de atacado para bancos de dados maciços, apenas interprete yy> 50 como 19yy e yy <= 50 como 20yy. Mas a única implementação sensata para isso envolve muitas pequenas mudanças em todos os lugares em que yy é usado.

— precisa saber é o seguinte

13

A questão não é quão bom ou ruim esse código é. A questão é quanto você se beneficia de quanto investimento.

Então você tem uma ferramenta que encontra milhares de coisas das quais não gosta. Você pode ignorar os resultados da ferramenta ou investir trabalho para mudar milhares de coisas. Isso é muita coisa. As pessoas não serão focadas, nem durante as alterações, nem durante a revisão, e isso não será testado adequadamente, pois leva séculos para descobrir como testar (ou apenas para experimentar) todas as alterações, para que haja erros. Então, até encontrar e corrigir esses erros, você investiu muito tempo e dinheiro com resultado negativo geral.

Por outro lado, as ferramentas podem encontrar coisas que elas não apenas "não gostam", mas que são bugs ou bugs em potencial. Se o código legado ainda estiver sendo amplamente utilizado, a ferramenta correta poderá encontrar bugs. Portanto, ativar os avisos do compilador um por um, verificar se são úteis (nem todos são úteis) e corrigir esses avisos pode valer a pena.

— gnasher729
fonte

2

Uma vez cheguei a um projeto que foi feito rapidamente (avisos de compilação ignorados etc.). O projeto estava uma bagunça, houve um erro. Um número estava transbordando. A equipe estava procurando por 2 semanas. Configurei o ambiente do compilador com todos os sinalizadores de aviso (a contagem passou de 500 para vários milhares de avisos). Eu passei por todos os avisos. Depois de apenas 3h, recebi 0 avisos. Por alguma razão, o código funcionou. Mas não sabíamos o porquê. Eu comprometi o código a cada alteração em minha ramificação. Depois de um pouco de pesquisa eu encontrei. Uma função declarada implicitamente, que fez C garble o valor de retorno.

— precisa saber é o seguinte

7

Se não está quebrado, não conserte

Isso praticamente deve ser tatuado em todo desenvolvedor e gerente de software, para que nunca o esqueçam.

Sim, ele quebra todas as convenções de codificação modernas. Sim, está escrito no FORTRAN-77 com um invólucro em C para que possa ser invocado no Python. Sim, esses são GOTOs não estruturados. Sim, há uma sub-rotina com três mil linhas. Sim, os nomes das variáveis só fazem sentido para um croata. etc etc.

Mas se tiver sido testado com raiva por mais de uma década e já passou, deixe-o em paz! Se a modificação necessária for pequena, mantenha-a o mais pequena e local possível. Qualquer outra coisa corre o risco maior de quebrar algo que não precisava ser consertado.

Obviamente, às vezes você descobre que é realmente um kluge impossível de manter e que a única maneira de acomodar a "pequena" modificação é reescrever do zero. Nesse caso, você precisa voltar para quem está pedindo a mudança e dizer a ele quanto vai custar (em dólares ou horas-homem para a reescrita, e em suor e lágrimas de sangue pelos novos e inevitáveis erros).

Há muito tempo, houve uma série de falhas em uma das unidades de disco da Digital. Acabaram lembrando e substituindo todos eles na gord sabe quanto custa. Aparentemente, havia uma gota de cola segurando um filtro dentro do HDA. O manifesto de engenharia dizia da cola "Não especificado parametricamente, NÃO SUBSTITUTOS ACEITÁVEIS". Um contador de feijão "economiza" menos de um centavo por unidade de disco, adquirindo outra cola. Ele emitiu um vapor dentro do HDA que matou a unidade após alguns anos de serviço. Não estava quebrado até que ele consertou. Sem dúvida "foi apenas uma pequena mudança ..."

— nigel222
fonte

2

Você quer dizer Western Digital ? Foi esse recall ? Você pode fornecer fontes para fazer backup de sua história?

— Lightness Races com Monica

3

Tenho certeza de que ele se refere à Digital Equipment Corp, cujo brilho ainda pode viver no fundo do coração negro da Hewlett Packard.

— precisa saber é o seguinte

11

Sim - Digital também conhecido como DEC.

— precisa saber é o seguinte

5

Definitivamente, não há razão para reduzir o nível de qualidade do código legado. Também não há necessidade de corrigir avisos imediatamente. Apenas garanta que todas as suas "novas" alterações em todos os componentes do seu projeto estejam seguindo um alto padrão de qualidade. Ou seja, nenhum commit deve aumentar a contagem de avisos.

É uma abordagem simples e uniforme.

Ele permite que o código antigo antigo funcione como está (porque nenhuma modificação desnecessária é feita nele). Garante que o novo código seja de alta qualidade. Nenhum custo adicional está envolvido.

— Basilevs
fonte

Eu posso ter uma exceção com a palavra sempre no final do seu primeiro parágrafo. Se, digamos, algumas dezenas de linhas de alterações forem necessárias no meio de uma função de várias centenas de linhas cujo estilo está levantando avisos, ainda vou tentar seguir o estilo existente, desde que não seja defeituoso. extensão da ilegibilidade. Quero tornar a vida o mais fácil possível para o próximo pobre coitado que aparecer e precisar revirar as coisas. Misturar estilos por nenhuma outra razão senão satisfazer os padrões de algumas ferramentas é, por si só, um estilo ruim. Em vez disso, siga os padrões / estilos originais o máximo possível.

— John Forkosh

Eu disse comprometer, não linha ou função. Supostamente você limpa bastante bagunça na edição, para ter um orçamento para um lugar problemático.

— Basilevs 22/01

3

Controle de risco….

O código na grande base de código herdada foi testado pelo menos pelo uso na vida real do software.
É muito improvável que o código na grande base de código herdada seja coberto por testes de unidade automatizados.
Portanto, qualquer alteração no frio na grande base de códigos herdada é de alto risco.

Custo….

Fazer o código passar por um verificador de código enquanto você está escrevendo o código é barato
Fazer isso em um estado posterior é muito mais caro

Benefício

Você espera que manter um padrão de codificação leve a um melhor design do código.
Mas é muito improvável que alguém gaste muitas semanas alterando o código apenas para remover avisos de uma ferramenta de verificação padrão de codificação, resultará em uma melhoria no design do código.
O código simples é mais claro e tende a ser mais fácil de entender, a menos que o código complexo seja dividido em métodos curtos por alguém que não o entende….

Recomendação….

Se uma seção de código tiver muitos bugs ou precisar de muitas alterações para adicionar funções adicionais, gaste o tempo 100% entendendo o que faz.
Também gaste o tempo adicionando um bom teste de unidade a essa seção do código, pois você tem uma necessidade comprovada deles.
Você poderia então refatorar o código (agora você entende) para que ele também passasse na nova verificação de código.

Experiência pessoal….

Em outros 20 anos de trabalho como programador, nunca vi um caso em que a mudança cega de idade para remover toda a saída de um novo verificador padrão de codificação tivesse algum benefício além de aumentar a renda dos contratados que foram instruídos a fazê-lo.
Da mesma forma, quando é necessário criar um código antigo para passar nas revisões de código (o TickIt / ISO 9001 foi feito errado), isso exigiu que o código antigo se parecesse com o novo padrão de codificação.
Eu já vi muitos casos em que o uso de ferramentas de verificação padrão de codificação em novos códigos teve grandes benefícios ao reduzir os custos contínuos.
Eu nunca vi uma empresa falhar nos custos de manutenção de código antigo usado em um produto com muitos clientes.
Vi empresas fracassarem por não receberem a receita dos clientes por serem muito lentas no mercado….

— Ian
fonte

0

A discussão é sobre a redução dos limites da ferramenta? ... ou eu entendi errado. Está escrito de uma maneira confusa. Caso contrário, descarte minha resposta.

IMHO, seria uma boa idéia reduzir a sensibilidade da ferramenta. Por quê? Porque destacaria os pedaços de código mais cabeludos. A alternativa é produzir relatórios com milhares de violações, tornando-se inútil por seu tamanho.

... além disso, apenas converse sobre isso com as pessoas envolvidas e ouça suas razões também.

— dagnelies
fonte

0

Eu tentaria separar o código legado do novo código limpo. No Eclipse, por exemplo, você pode fazer isso colocando-os em diferentes projetos que se utilizam. projeto 'limpo' e projeto 'legado' .

Dessa forma, você pode analisar os dois projetos no sonar com diferentes padrões de qualidade. Os padrões devem diferir apenas na importância das regras. As regras em si devem ser as mesmas. Dessa forma, você pode ver no projeto 'legado' o que precisa ser 'corrigido' para atender aos padrões do projeto 'limpo' .

Sempre que você conseguiu elevar algum código legado aos padrões mais altos, você pode movê-lo para o projeto 'limpo'.

Em todos os dias de trabalho, você não pode realizar para elevar todas as aulas que você toca aos padrões do projeto 'limpo' por causa do atraso de tempo. Mas você deve tentar chegar lá em pequenos passos, tentando melhorar um pouco o código legado sempre que tocá-lo.

— MrSmith42
fonte