SONARQUBE É O PADRÃO MUNDIAL DE ANÁLISE ESTÁTICA DE CÓDIGO
Não aceite código com débito Técnico!
POLÍTICAS E MÉTRICAS: GARANTA UM DÉBITO TÉCNICO MENOR
Criamos o perfil de qualidade esperado por sua empresa no SonarQube e automatizamos a avaliação de qualidade de código em sua esteira de DevOps.
Desta forma, os seus débitos técnicos serão mais baixos e sua economia maior.
Política
O número de linhas duplicadas encontradas poderá ser até 3% do total de linhas.
Métrica
O número de linhas duplicadas superou a política de qualidade. Build não aprovado!
Métrica
Build não aprovado!
SAIBA QUAIS SÃO OS MELHORES (OU PIORES) DESENVOLVEDORES
Que tal ter dashboards que refletirão a qualidade de código de seus desenvolvedores ou mesmo fábrica de software que atende sua empresa?
ENTREGUE UM CÓDIGO CONFIÁVEL
Em nosso trabalho de Code Quality Assurance com SonarQube, garantimos o que será publicado é o melhor código possível. Avaliamos o seu código em +25 linguagens de programação, capturamos bugs complexos e difíceis de serem detectados e que previnem comportamentos não esperados.
DÉBITO TÉCNICO
A dívida técnica é um conceito bem conhecido que foi inventado por Ward Cunningham em 1992. Desde então, tem sido discutido inúmeras vezes em blogs e artigos. Não vou descrevê-lo em grandes detalhes aqui, prefiro recomendar que você leia o que é considerado como o artigo de referência sobre o assunto, por Martin Fowler. Abaixo uma parte deste artigo que possui uma visão sintética metafórica:
Fazer projetos da maneira "rápida e suja" nos coloca com um débito técnico, que é semelhante a uma dívida financeira. Como em uma dívida financeira, o débito técnico incorre em pagamento de juros, que vêm na forma de um esforço extra que temos de fazer no futuro desenvolvimento por causa da escolha de criar o "projeto rápido e sujo". Podemos optar por continuar pagando os juros, ou podemos pagar o principal escolhendo fazer o refactoring do "projeto rápido e sujo" para o melhor design. Embora custe pagar o principal, nós ganhamos nos pagamentos de juros reduzidos no futuro.
Esta metáfora parece ser aceita por muitos desenvolvedores já que a cada dia alguém reclama ou "tweeta" sobre a necessidade urgente para pagar o débito técnico. Mas além do conceito, quando chega a hora de avaliar o montante a ser reembolsado, simplesmente não há literatura sobre como calcular a dívida ou, pelo menos, abordá-lo. É como pedir dinheiro emprestado para comprar uma casa, mas 2 anos depois não ter como saber o que é o remanescente da dívida e quanto de juros estão sendo pagos a cada mês.
Como afirmado por Martin Fowler, os desenvolvedores são bons e às vezes fazem a escolha deliberada de contrair empréstimos a fim de ganhar tempo. Isso é verdade quando se inicia um novo desenvolvimento, como você sabe exatamente o montante do débito técnico... Ou seja, 0 (zero). Mas quando a extensão ou a manutenção de um aplicativo de legado, que é outra história que ninguém sabe exatamente como ela é ruim. Você ainda pode até não estar ciente de que você está pedindo dinheiro, quando um desenvolvedor simplesmente não segue as melhores práticas. É por isso que, avaliando-se aproximadamente o débito técnico previamente, este é muito útil.
Antes de introduzir esta política e métrica, aqui estão algumas citações engraçadas e relevantes sobre o conceito:
-
Manter uma aplicação sem quaisquer testes de unidade é como pedir o dinheiro cada vez que você adicionar ou alterar uma linha de código;
-
Ignorar a fase de design de um projeto é como tomar dinheiro emprestado para obter um retorno muito "rápido" e "previsível" do investimento;
-
Refatoração é como abater a dívida principal aos poucos;
-
A produtividade de desenvolvimento diminui quando os juros crescem;
-
Os gestores não se preocupam com a qualidade do código, basta pedir-lhes para pagar a dívida antecipadamente, a fim obter a sua atenção;
-
Falência é a extensão lógica do débito técnico descontrolado... chamamos-lhe uma reescrita do sistema.
