Como provar que um aplicativo é construído em uma base de código incorreta?

Atualmente, estou analisando um sistema criado por alguns desenvolvedores que trabalharam anteriormente no meu trabalho. O sistema funciona muito bem do ponto de vista do usuário, mas ao investigar o código, é uma bagunça total. Estou mais do que convencido de que a maneira como o aplicativo é construído não aguenta atualizações futuras, muito menos aumentos altos no uso.

O problema é que eu sei o quão ruim é, mas meus superiores não. Como posso provar isso ao meu gerente para que ele realmente veja o problema e possa ser convencido a fazer uma triagem mínima na base de código atual e, no futuro próximo, iniciar uma nova linha de desenvolvimento para a próxima versão do aplicativo?

'Mas funciona agora' é a resposta padrão do gerenciamento às frustrações legítimas dos engenheiros de software. A primeira coisa que eu faria seria compilar a documentação (se houver) e usá-la para demonstrar contradições entre o código e a documentação.

Se puder, monte um conjunto abrangente de testes de unidade. Execute-os a cada alteração para documentar regressões que podem ser responsabilizadas na base de código existente.

Por fim, se você puder contratar um desenvolvedor de outro departamento cujo trabalho você confia, observe o código novamente. Um desenvolvedor dizendo 'isso é uma porcaria' é mais fácil de ignorar, do que quando um desenvolvedor sênior que já existe há algum tempo o atesta e diz: 'Não, Jim, ele está certo. Isso é besteira em uma porcaria de crack.

Obviamente, tudo depende do seu ambiente, tamanho da empresa etc.

Eu sempre recomendo dar uma olhada no Programador Pragmático, se você ainda não leu. Não apenas deve ser uma leitura obrigatória para todos os profissionais de software, mas também oferece boas sugestões para lidar com a gerência, colegas de trabalho, usuários etc. que não veem a engenharia de software como um ofício.

Do ponto de vista da gerência, não há nada de errado com o sistema e você está apenas reclamando porque [você só quer reescrevê-lo / não entende o que os engenheiros anteriores fizeram / deseja que seu trabalho seja fácil]. Um pouco tímido, mas quando alguém no topo vê que as coisas estão funcionando bem no momento, está inclinado a ver uma crise em que você está (tenho certeza de que há uma alegoria de mudança climática em algum lugar ...) .

Até certo ponto, eles têm razão. A gerência vê problemas quando as liberações vão muito além de sua estimativa original, as estimativas parecem muito altas para o trabalho que está sendo realizado, "isso é impossível com nossa base de códigos existente" e as altas ocorrências de bugs passando pelo controle de qualidade. Se as coisas estão ronronando bem, é fácil dar um tapinha na cabeça e pedir para você fazer o seu melhor, porque isso não está afetando os resultados.

O que fazer depende da sua organização e do próprio software. Fundamentalmente, porém, sugiro documentar todas as complicações que surgem como resultado de um código legado ruim. Ao estimar tarefas, deixe claro para a gerência por que você acha que demorará tanto tempo, com explicações detalhadas sobre quais aspectos da antiga base de códigos estão adicionando esse custo extra. Quando erros forem introduzidos no código, inclua os motivos pelos quais esse erro ocorreu e como os problemas na antiga base de códigos são responsáveis.

Eu sugiro que você expresse suas preocupações para as partes interessadas de uma maneira que sugira que o software superou seu design original e agora é problemático para continuar melhorando.

Existem várias ferramentas disponíveis que podem fazer cobertura e revisão de código. Ferramentas do Google adequadas para sua tecnologia, normalmente são ferramentas padrão do setor. Sugiro que você use essas ferramentas, elabore um relatório de qualidade de código e o apresente ao Manager. Certifique-se de que suas críticas sejam contrutivas e não políticas.

Escolha um exemplo que seja fácil de entender onde o gerenciamento consideraria uma simples solicitação de mudança, mas, devido ao design existente, é muito mais difícil.

Você não quer que eles insistam na solicitação específica, mas certifique-se de que eles saibam que é assim que QUALQUER solicitação de mudança será. Ninguém quer ser pintado em um canto com um aplicativo. Os desenvolvedores acreditam no YAGNI, mas a gerência acredita no CYA.

As sugestões para teste de carga podem ser uma boa abordagem, mas elas podem não estar convencidas de que o aumento das preocupações com o uso atenda a qualquer potencial de crescimento do mundo real (a empresa não vai dobrar em um ano).

Tudo é relativo. Eles podem não querer colocar os recursos nesse projeto quando tiverem planos para projetos mais importantes para gastar seu tempo. Não seja rotulado como não vendo o quadro geral.

Quando você fala sobre provar algo, todo esse método científico entra em jogo, e parte do que isso significa é que, se você aceita padrões objetivos de decidir o que é verdade, deve aceitar a possibilidade de que, sob investigação, esses fatos irritantes acabe por não estar do seu lado.

No seu caso, acho que há duas coisas a serem provadas.

Primeiro, que a base de código atual é "ruim". O que você provavelmente pode provar é que "a opinião profissional de quase todos os desenvolvedores que examinam esse código é que é ruim".

Segundo, é melhor que a empresa reescreva a base de código. Isso é um problema porque, mesmo que o primeiro ponto seja verdadeiro, o segundo pode não ser. Além disso, você não sabe o suficiente para fazer essa determinação. Esse é o trabalho da gerência e, se você quiser que eles respeitem seu julgamento profissional sobre o primeiro ponto, respeite o deles sobre o segundo.

Mas eles não podem determinar o segundo ponto sem as informações fornecidas. Você precisa comunicar o que sabe sobre como os problemas no código afetarão os negócios e o que sabe sobre como uma reescrita afetaria os negócios. Isso é difícil, pois ambos envolvem prever um futuro com muita incerteza.

Mas você pode tentar declarar o problema em termos comerciais. Quanto tempo extra é gasto em alterações e regressões? Quanto custaria uma reescrita? Com que rapidez os custos do sistema atual aumentam com o tempo se não forem reescritos? E se houver um aumento no uso, qual a chance de um desastre se o código atual for mantido? Você realmente não pode saber nada disso, mas pode adivinhar melhor do que qualquer outra pessoa. Dê um intervalo ou algo para comunicar com que precisão você acha que pode prever essas coisas.

A maioria dos desenvolvedores não gosta de manter códigos ruins. É por isso que pode ser lamentável que o código que não é necessário reescrever da perspectiva do desenvolvedor não valha a pena reescrever da perspectiva do negócio.

Por exemplo, mesmo que a reescrita acabe lucrativa, pode valer menos que o custo de oportunidade de gastar o dinheiro em outro lugar da empresa. Ou a base de código ruim pode levar mais tempo para mudar e ter mais regressões, mas não o suficiente para tornar uma reescrita lucrativa. Eles podem querer ser comprados nos próximos meses, e gastar dinheiro em uma reescrita aparecerá nos livros, mas o software de buggy não.

Tente pensar sobre isso da perspectiva dos negócios e não cozinhe os números para conseguir o que deseja. Uma grande reescrita quase nunca é um acéfalo do ponto de vista comercial. Se você quiser provar algo que não é diretamente comprovável, tente o seu melhor para refutá-lo. Se você continuar tentando o seu melhor para chegar a uma forma não reescrever a partir do zero, mas nada que você venha com faz sentido, talvez , em seguida, é realmente hora de reescrever a partir do zero. E esse esforço mostrará à sua gerência que você é sério sobre a representação dos interesses da empresa, e não o seu (você representa o interesse da empresa, não o seu, certo?).

Eu acho que depende do que há de ruim na base de código. Ser "não do jeito que eu faria as coisas" não significa que é uma base de código ruim.

Coisas que realmente fazem uma base de código ruim:

• Falhas de segurança

  Problemas que deixam o servidor, o aplicativo e / ou os dados vulneráveis. Especialmente qualquer coisa que deixe em risco os dados confidenciais da empresa, cliente ou cliente. Estes devem ser fáceis de documentar.

• Working Broken

  Ele está funcionando apenas porque você massageia os dados e realiza manutenção no aplicativo quase continuamente para mantê-lo funcionando. Se você fosse embora e ninguém aceitasse a folga, isso não funcionaria mais. - Documente quanto tempo você gasta fazendo isso. E observe quanto você poderia economizar. Muitas vezes, esses processos também são ineficientes para os usuários e você pode documentar isso também.

• Na verdade não funciona

  Parece funcionar, mas os resultados estão incorretos. Isso geralmente causa problemas na linha, como números não correspondentes, alta taxa de defeitos, etc.

O que não é uma base de código ruim (apenas não é boa):

• Escrito em tecnologia obsoleta e sem suporte. (VB6, COBOL, .net1.1 Etc.)

Observe as vantagens de migrar para uma nova tecnologia. Tente encontrar um caminho de migração que mova as peças de cada vez, para minimizar riscos e criar confiança no usuário e no gerenciamento. Verifique se a lógica funciona basicamente da mesma forma que o original.

• Código não documentado / mal formatado

É o mais fácil de corrigir, porque geralmente você pode adicionar comentários e corrigir a formatação sem afetar o código. Mas isso não requer uma reescrita. Se você acha que isso está combinado com outros problemas, a primeira coisa a fazer é corrigir isso para avaliar melhor a viabilidade do código.

Você respondeu sua própria pergunta de uma maneira.

A maneira de convencê-los a gastar dinheiro com o sistema é esperar até que não funcione bem para o usuário. Se você acha que não vai escalar, espere que isso aconteça ou faça um teste de carga para provar isso.

É então uma proposta simples de limpar essa escala, que custará X horas.

Essa é uma situação difícil, porque, na perspectiva do usuário, tudo está em um ponto aceitável e estável agora. Principalmente com gerentes não técnicos, não há nada com o que se preocupar no momento, mas pedir para reescrever a base de código é uma decisão enorme e que não deve ser tomada de ânimo leve, especialmente com a opinião e os esforços de um único homem (você mesmo) .

Portanto, você está em um ponto difícil de tentar defender uma reescrita por causa de uma dívida técnica esmagadora (na sua opinião, não temos exemplos e precisamos acreditar nisso), além de estar no ponto difícil de ter a dificuldade de manter e adicionar recursos a este sistema.

Suas estimativas para novos recursos serão altas, justifique esses números altos com fatos, provando que essas coisas realmente levarão muito tempo. Se você não transmitir isso corretamente, seu gerente poderá presumir que você é incompetente e você certamente não quer isso. Quando ele questionar as altas estimativas, explique por que você acha que a dívida técnica acumulada está dificultando a capacidade de adicionar recursos de forma rápida e barata ao software atual. Se o seu gerente tiver duas células cerebrais para esfregar, ele começará a entender muito rapidamente.

O ponto é que você não deve tentar convencer seu gerente, mas orientá-lo com informações apropriadas (e cuidadosamente selecionadas) de que ele / ela pode se convencer de que uma reescrita é um curso aceitável. Você precisa fazer o gerente pensar que foi ideia dele o tempo todo.

Primeiro, determine a dívida técnica acumulada na sua base de código. Em seguida, dê uma olhada nesta pergunta e respostas , onde é explicado como convencer a gerência a pagar a dívida técnica antes de prosseguir.

Há uma razão pela qual todo software maduro parece bagunçado:

1. Toda a bagunça está codificando a lógica crítica em que a empresa confia. Sem isso, nada funciona. Tudo foi necessário para resolver o problema do usuário.
2. Está usando uma tecnologia um pouco desatualizada. Os programadores atuais parecem pensar que, se não usar alguma mágica de modelo, é apenas uma bagunça. Esta é uma visão quebrada. Qualquer um que se atrase em um projeto maior terá esse estágio enquanto aprende todos os detalhes.
3. Os requisitos que eram críticos há algum tempo não são mais tão críticos. Isso ocorre porque o software já corrigiu esses problemas. Chegando atrasado ao projeto, pode parecer que o software é complexo sem uma boa razão - o problema não existe mais, mas a complexidade do código ainda está lá.