Controle de qualidade do código-fonte: não é mais apenas para desenvolvedores

Vinte anos atrás, quando eu trabalhava na indústria automotiva, o diretor de uma fábrica costumava dizer: “Temos um dia para construir um carro, mas nosso cliente tem uma vida inteira para inspecioná-lo”. A qualidade era da maior importância. De fato, em setores mais maduros, como as indústrias automotiva e de construção, a garantia de qualidade é uma consideração fundamental que é sistematicamente integrada ao processo de desenvolvimento de produtos. Embora isso seja certamente impulsionado pela pressão das companhias de seguros, também é ditado – como observou o diretor da fábrica – pela vida útil do produto resultante.

Quando se trata de software, no entanto, ciclos de vida mais curtos e atualizações contínuas significam que a integridade do código-fonte geralmente é negligenciada em favor de novos recursos, funcionalidades sofisticadas e velocidade de entrada no mercado. Os gerentes de produto geralmente despriorizam a garantia de qualidade do código-fonte ou deixam isso para os desenvolvedores lidarem, apesar de ser um dos fatores mais críticos na determinação do destino de um produto. Para gerentes de produto preocupados em construir uma base sólida para o desenvolvimento de produtos e eliminar riscos, é essencial definir e implementar uma avaliação sistemática da qualidade do código-fonte.

Definição de “qualidade”

Antes de explorar as formas de avaliar e decretar adequadamente um processo de controle de qualidade de código-fonte, é importante determinar o que “qualidade” significa no contexto de desenvolvimento de software. Esta é uma questão complexa e multifacetada, mas para simplificar, podemos dizer que qualidade se refere ao código-fonte que suporta a proposta de valor de um produto sem comprometer a satisfação do consumidor ou colocar em risco o modelo de negócios da empresa de desenvolvimento.

Em outras palavras, o código-fonte de qualidade implementa com precisão as especificações funcionais do produto, satisfaz os requisitos não funcionais, garante a satisfação dos consumidores, minimiza os riscos legais e de segurança e pode ser mantido e estendido de forma acessível.

Dado o quão ampla e rapidamente o software é distribuído, o impacto dos defeitos de software pode ser significativo. Problemas como bugs e complexidade de código podem prejudicar os resultados de uma empresa, dificultando a adoção de produtos e aumentando os custos de gerenciamento de ativos de software (SAM), enquanto as violações de segurança e de conformidade de licença podem afetar a reputação da empresa e levantar preocupações legais. Mesmo quando os defeitos de software não têm resultados catastróficos, eles têm um custo inegável. Em um relatório de 2018, a empresa de software Tricentis descobriu que 606 falhas de software de 314 empresas representaram US$ 1,7 trilhão em receita perdida no ano anterior. Em um relatório de 2020 recém-lançado, o CISQ colocou o custo de software de baixa qualidade nos EUA em US$ 2,08 trilhões, com outros US$ 1,31 trilhão em custos futuros incorridos por dívida técnica. Esses números poderiam ser mitigados com intervenções anteriores; o custo médio de resolver um problema durante o projeto do produto é significativamente menor do que resolver o mesmo problema durante o teste, que por sua vez é exponencialmente menor do que resolver o problema após a implantação.

Manuseio da batata quente

Apesar dos riscos, a garantia de qualidade no desenvolvimento de software é tratada de forma fragmentada e caracteriza-se por uma abordagem reativa em vez da proativa adotada em outros setores. A propriedade da qualidade do código fonte é contestada, quando deveria ser vista como responsabilidade coletiva de diferentes funções. Os gerentes de produto devem ver a qualidade como um recurso impactante em vez de uma sobrecarga, os executivos devem prestar atenção ao estado da qualidade e investir nele, e as funções de engenharia devem resistir a tratar a limpeza de código como uma “batata quente”.

Para agravar esses desafios de delegação está o fato de que as metodologias e ferramentas existentes não abordam a questão da qualidade do código como um todo. O uso de metodologias de integração contínua/entrega contínua reduz o impacto do código de baixa qualidade, mas, a menos que o CI/CD seja baseado em uma análise de qualidade completa e holística, ele não pode antecipar e abordar efetivamente a maioria dos perigos. As equipes responsáveis ​​por testes de controle de qualidade, segurança de aplicativos e conformidade de licenças trabalham em silos usando ferramentas projetadas para resolver apenas uma parte do problema e avaliar apenas alguns dos requisitos funcionais ou não funcionais.

Considerando o papel do gerente de produto

A qualidade do código-fonte joga em vários dilemas que um gerente de produto enfrenta durante o projeto do produto e durante todo o ciclo de vida de desenvolvimento de software. A dívida técnica é pesada. É mais difícil e caro adicionar e modificar recursos em uma base de código de baixa qualidade, e o suporte à complexidade de código existente requer investimentos significativos de tempo e recursos que poderiam ser gastos no desenvolvimento de novos produtos. À medida que os gerentes de produto equilibram continuamente o risco com a velocidade de entrada no mercado, eles devem considerar questões como:

• Devo usar uma biblioteca OSS (software de código aberto) ou construir funcionalidades do zero? Quais licenças e possíveis responsabilidades estão associadas às bibliotecas selecionadas?
• Qual pilha de tecnologia é mais segura? O que garante um ciclo de desenvolvimento rápido e de baixo custo?
• Devo priorizar a configurabilidade do aplicativo (alto custo/atraso de tempo) ou implementar versões personalizadas (alto custo de manutenção/falta de escalabilidade)?
• Quão viável será integrar produtos digitais recém-adquiridos, mantendo a alta qualidade do código, minimizando os riscos e mantendo os custos de engenharia baixos?

As respostas a essas perguntas podem afetar seriamente os resultados de negócios e a própria reputação do gerente de produto, mas as decisões geralmente são tomadas com base na intuição ou na experiência anterior, em vez de investigações rigorosas e métricas sólidas. Um processo completo de avaliação da qualidade de software não apenas fornece os dados necessários para a tomada de decisões, mas também alinha as partes interessadas, gera confiança e contribui para uma cultura de transparência, na qual as prioridades são claras e acordadas.

Implementando um processo de 7 etapas

Um processo completo de avaliação da qualidade do código-fonte resulta em um diagnóstico que considera o conjunto completo de determinações de qualidade em vez de alguns sintomas isolados de um problema maior. O método de sete etapas apresentado abaixo está alinhado com as recomendações do CISQ para melhoria de processos e visa facilitar os seguintes objetivos:

• Encontre, meça e corrija o problema próximo à sua causa raiz.
• Invista de forma inteligente na melhoria da qualidade do software com base nas medições gerais de qualidade.
• Ataque o problema analisando o conjunto completo de medições e identificando as melhorias melhores e mais econômicas.
• Considere o custo total de um produto de software, incluindo os custos de propriedade, manutenção e alinhamento de regulamentação de licença/segurança.
• Monitore a qualidade do código em todo o SDLC para evitar surpresas desagradáveis.

1. Mapeamento de produto para código: rastrear os recursos do produto de volta à sua base de código pode parecer um primeiro passo óbvio, mas, dada a taxa em que a complexidade do desenvolvimento aumenta, não é necessariamente simples. Em algumas situações, o código de um produto é dividido entre vários repositórios, enquanto em outras, vários produtos compartilham o mesmo repositório. É necessário identificar os vários locais que abrigam partes específicas do código de um produto antes que uma avaliação adicional possa ocorrer.

2. Análise de pilha de tecnologia: Esta etapa leva em consideração as várias linguagens de programação e ferramentas de desenvolvimento usadas, a porcentagem de comentários por arquivo, a porcentagem de código gerado automaticamente, o custo médio de desenvolvimento e muito mais.

Ferramentas sugeridas: cloc

Alternativas: Tokei, scc, sloccount

3. Análise de versões: Com base nos resultados desta parte da auditoria, que envolve a identificação de todas as versões de uma base de código e o cálculo de semelhanças, as versões podem ser mescladas e as duplicações eliminadas. Essa etapa pode ser combinada com uma análise de bugspots (hot spots), que identifica as partes complicadas do código que são revisadas com mais frequência e tendem a gerar custos de manutenção mais altos.

Ferramentas sugeridas: cloc, scc, sloccount

4. Revisão de código automatizada: Essa inspeção investiga o código em busca de defeitos, violações de práticas de programação e elementos de risco, como tokens codificados, métodos longos e duplicações. A(s) ferramenta(s) selecionada(s) para este processo dependerão dos resultados da pilha de tecnologia e das análises de versões acima.

Ferramentas sugeridas: SonarQube, Codacy

Alternativas: RIPS, Veracode, Micro Focus, Parasoft e muitas outras. Outra opção é o Sourcegraph, uma solução universal de pesquisa de código.

5. Análise de segurança estática: Esta etapa, também conhecida como teste de segurança de aplicativos estático (SAST), explora e identifica possíveis vulnerabilidades de segurança de aplicativos. A maioria das ferramentas disponíveis verifica o código em relação às preocupações de segurança que ocorrem com frequência identificadas por organizações como OWASP e SANS.

Ferramentas sugeridas: WhiteSource, Snyk, Coverity

Alternativas: SonarQube, Reshift, Kiuwan, Veracode

6. Análise de componentes de software (SCA)/análise de conformidade de licença: Esta revisão envolve a identificação das bibliotecas de código aberto vinculadas direta ou indiretamente ao código, as licenças que protegem cada uma dessas bibliotecas e as permissões associadas a cada uma dessas licenças.

Ferramentas sugeridas: Snyk, WhiteSource, Black Duck

Alternativas: FOSSA, Sonatype e outros

7. Análise de risco do negócio: Esta medida final envolve a consolidação das informações coletadas nas etapas anteriores para entender o impacto total do status da qualidade do código-fonte no negócio. A análise deve resultar em um relatório abrangente que forneça às partes interessadas, incluindo gerentes de produto, gerentes de projeto, equipes de engenharia e executivos C-suite, os detalhes necessários para avaliar os riscos e tomar decisões informadas sobre o produto.

Embora as etapas anteriores desse processo de avaliação possam ser automatizadas e facilitadas por meio de uma ampla variedade de produtos comerciais e de código aberto, não existem ferramentas que suportem o processo completo de sete etapas ou a agregação de seus resultados. Como a compilação desses dados é uma tarefa tediosa e demorada, ela é executada aleatoriamente ou totalmente ignorada, potencialmente comprometendo o processo de desenvolvimento. Este é o ponto em que um processo completo de inspeção de software geralmente desmorona, tornando esta última etapa indiscutivelmente a mais crítica no processo de avaliação.

Selecionando as ferramentas certas

Embora a qualidade do software afete o produto e, portanto, os resultados de negócios, a seleção de ferramentas geralmente é delegada aos departamentos de desenvolvimento e os resultados podem ser difíceis de interpretar para não desenvolvedores. Os gerentes de produto devem estar ativamente envolvidos na seleção de ferramentas que garantam um processo de controle de qualidade transparente e acessível. Embora as ferramentas específicas para as várias etapas da avaliação sejam sugeridas acima, há várias considerações gerais que devem ser levadas em consideração em qualquer processo de seleção de ferramentas:

• Pilha de tecnologia com suporte: lembre-se de que a maioria das ofertas disponíveis oferece suporte apenas a um pequeno conjunto de ferramentas de desenvolvimento e pode resultar em relatórios parciais ou enganosos.
• Simplicidade de instalação: Ferramentas cujos processos de instalação são baseados em scripts complexos podem exigir um investimento significativo em engenharia.
• Relatórios: Deve-se dar preferência às ferramentas que exportam relatórios detalhados e bem estruturados que identificam os principais problemas e fornecem recomendações para correções.
• Integração: As ferramentas devem ser selecionadas para facilitar a integração com as outras ferramentas de desenvolvimento e gerenciamento que estão sendo usadas.
• Preços: As ferramentas raramente vêm com uma lista de preços abrangente, por isso é importante considerar cuidadosamente o investimento envolvido. Vários modelos de preços normalmente levam em consideração coisas como número de funcionários da equipe, tamanho do código e as ferramentas de desenvolvimento envolvidas.
• Implantação: ao ponderar a implantação no local versus a implantação na nuvem, considere fatores como segurança. Por exemplo, se o produto que está sendo avaliado lida com dados confidenciais ou confidenciais, ferramentas e ferramentas no local usando a abordagem de auditoria cega (FOSSID) podem ser preferíveis.

Continuando

Uma vez que os riscos tenham sido identificados e analisados ​​metodicamente, os gerentes de produto podem tomar decisões ponderadas sobre priorização e triagem de defeitos com mais precisão. As equipes podem ser reestruturadas e recursos alocados para resolver os problemas mais emergentes ou predominantes. “Showstoppers”, como violações de licença de alto risco, teriam precedência sobre defeitos de gravidade mais baixa, e mais ênfase seria colocada em atividades que contribuem para a redução do tamanho e da complexidade da base de código.

Este não é um processo único, no entanto. A medição e o monitoramento da qualidade do software devem ocorrer continuamente em todo o SDLC. A avaliação completa em sete etapas deve ser realizada periodicamente, com os esforços de melhoria da qualidade começando imediatamente após cada análise. Quanto mais rápido um novo ponto de risco for identificado, mais barato será o remédio e mais limitadas serão as consequências. Tornar a avaliação da qualidade do código-fonte central para o processo de desenvolvimento do produto foca as equipes, alinha as partes interessadas, mitiga os riscos e dá a um produto sua melhor chance de sucesso – e esse é o negócio de todo gerente de produto.