Qualidade de código: estratégia de Code Review, métricas e governança

Fundamentos de qualidade do código - Apresentação

Apresentando o instrutor e realizando audiodescrição

Olá! Meu nome é Daniel Sintra, e meu nome está projetado na tela. Antes de começar, vou me autodescrever.

Audiodescrição: Sou um homem branco, uso óculos pretos, tenho cabelo castanho-escuro, barba curta e visto uma camisa preta do Grupo Alura. Ao fundo, há uma parede branca e duas luzes, uma rosa e outra azul, que combinam com a identidade visual da Alura.

Contextualizando experiência e tema do curso

Atualmente, trabalho como Tech Lead (liderança técnica) no banco Itaú, sou instrutor na Alura, professor universitário na FIAP e possuo certificações da AWS (Serviços Web da Amazon). Tenho aproximadamente 19 anos de experiência em tecnologia, com atuação em mentoria e evolução de equipes técnicas. Sou especialista em arquitetura de software e sistemas escaláveis e, além das certificações da AWS (Serviços Web da Amazon), também possuo certificações em metodologias ágeis.

Este curso tem como tema qualidade de código, estratégia de revisão de código e padrões. Vamos discutir como realizar uma revisão de código eficiente, quais padrões adotar e quais ferramentas utilizar para nos auxiliar no dia a dia, elevando a qualidade do que entregamos.

Estruturando as aulas do curso

O curso está dividido em cinco aulas. Em todas as aulas, ao final, realizamos uma parte prática: primeiro desenvolvemos a fundamentação teórica e, em seguida, partimos para a prática.

• Aula 1: Fundamentos de qualidade e de revisão. Apresentamos métodos para revisar e princípios para apoiar a verificação do código, incluindo code smells (indícios de problema no código), Clean Code (código limpo) e boas práticas de refatoração.

• Aula 2: Revisão de código profissional, abordando camadas, checklists (listas de verificação) e comunicação.

• Aula 3: Uso do Sonar para revisão estática de código e incorporação desse processo de forma automatizada, utilizando a pipeline (esteira) do GitHub.

• Aula 4: Aplicações de IA para apoiar revisão e melhoria de código e elaboração de testes. Utilizaremos duas ferramentas: Devin, uma solução de engenharia de software autônoma, e Cursor, uma IDE (ambiente de desenvolvimento integrado) para o dia a dia de desenvolvimento — sempre com validação humana.

• Aula 5: Processo no time, fluxo de Pull Request (solicitação de alteração), média de dívida técnica e noções de governança.

Definindo público-alvo e perfis indicados

Para quem é este curso? Este é um curso mais avançado, que requer boa base de Git, revisão de código, entrega contínua e alguns conhecimentos de configuração. Se você está em nível júnior ou semissênior, pode acompanhar, mas, por ser mais avançado, haverá conceitos que não cobriremos aqui. Para pessoas sênior, o curso é totalmente indicado — especialmente se não utilizam um processo estruturado ou desejam aprimorar o processo de revisão de código e qualidade no time. Ele é particularmente relevante para quem atua como Tech Lead (liderança técnica), pois faz parte da trilha de Tech Lead (liderança técnica). Vamos abordar, a partir desse papel, como criar cultura, estabelecer processos, definir métricas e outros pontos essenciais.

Também é indicado para pessoas que atuam como revisoras, incluindo profissionais de QA (garantia de qualidade), que podem conduzir ou participar da revisão de código.

Este curso é indicado para todas as pessoas profissionais focadas em engenharia de software.

Estabelecendo pré-requisitos e orientações iniciais

Como dissemos, por ser um curso avançado, assumimos que você já tem alguma experiência e estabelecemos alguns pré-requisitos para aproveitar melhor o conteúdo. Isso não significa que, se não tiver algum desses pontos, não poderá acompanhá-lo, mas talvez tenha mais dificuldade para segui-lo. É importante conhecer programação e, claro, ter experiência real em desenvolvimento de software, uso de PRs/pull requests (solicitações de alteração) e entendimento do ciclo de entrega. Não é necessário ser especialista em integração contínua, pipelines (fluxos de integração/entrega) nem em SonarCloud, pois cobriremos isso no curso. E, sobretudo, é essencial ter interesse em impacto coletivo e curiosidade sobre o padrão do time, revisão e processo, além da entrega individual: como compartilhamos e como ajudamos a criar uma cultura de qualidade, de processos, de métricas e afins.

Como tirar o máximo proveito do curso? Recomendamos não apenas assistir, mas fazer pausas e refletir. Quando trouxermos um conceito, reflita: já conhece? Não conhece? Deve aprofundar mais? Isso já é utilizado na sua empresa? Não é? Vale a pena propor?

Praticando junto e utilizando materiais de apoio

E, sobretudo, nas aulas práticas, codifique junto conosco; tente fazer ao nosso lado, porque apenas assistir não permite assimilar 100% do conteúdo. Ao fazer junto, você assimila muito mais. Nós explicamos em detalhes e disponibilizamos materiais auxiliares. Há um repositório no GitHub que você poderá usar, referente ao projeto que utilizaremos neste curso.

Pratique: faça junto conosco, pause o vídeo, implemente um pouco, depois assista mais um trecho e assim sucessivamente. Traga seu contexto: considere como é seu processo hoje, faça comparações, anote em seu caderno como realiza o processo de qualidade e de revisão atualmente e, conforme avançarmos no curso, faça uma comparação, crie uma checklist (lista de verificação) do que você faz e do que não faz e revise os resumos. Sempre que terminar uma aula, retorne e verifique se conseguiu compreender todo o conteúdo; se houver algum vídeo que precise rever ou se for necessário fazer mais anotações, faça-o, pois isso ajuda a consolidar o conhecimento.

Apresentando objetivos, resultados e encerramento

O objetivo deste curso é apresentar alguns pontos principais. Você sairá daqui muito mais preparado para qualidade — de forma geral, entregas, métricas, processos e criação de cultura. Porém, queremos focar em alguns tópicos: fundamentos de qualidade; smells (indícios de problemas); Clean Code (código limpo); refatoração intencional; revisão de código estruturada utilizando uma estratégia por camadas; práticas de checklist (lista de verificação); comunicação profissional; análise estática usando o SonarCloud integrado, para ajudar a criar outra camada de revisão de código de qualidade e gerar insumos sobre como criticar o código de maneira eficiente. Também trabalharemos com IA consciente: uso de IA nos processos de qualidade para melhorar ainda mais, acelerar processos e o desenvolvimento. Aqui abordaremos Devin e Cursor, já mencionados. Além disso, buscamos que você chegue ao final com um processo maduro de CI/CD (integração e entrega contínuas), com Quality Gate (barreira de qualidade) e com governança do time.

Os resultados esperados são: conseguir definir qualidade para além do gosto pessoal, com evidências objetivas; realizar revisões que realmente reduzam defeitos; aplicar a análise estática no CI (integração contínua) com sucesso — mostraremos aqui, passo a passo, toda a configuração — e ganhar mais confiança no uso de IA.

Esses são os resultados que esperamos que você alcance ao final deste curso. Esperamos que este vídeo introdutório tenha despertado sua curiosidade e sua vontade de realizar o curso. Nos vemos no próximo vídeo. [♪]

Fundamentos de qualidade do código - Funcional x Sustentável

Dando as boas-vindas e introduzindo o tema

Olá, sejam muito bem-vindas e bem-vindos de volta.

No vídeo anterior, eu fiz uma breve introdução sobre o curso e sobre mim. Agora, neste vídeo, nós vamos falar sobre o tema Funcional versus Sustentável.

Explicando a metáfora do iceberg e a estratégia de qualidade

Nesta lâmina que aparece à esquerda, mostramos um iceberg. Um iceberg é uma estrutura de gelo que geralmente aparece nos oceanos e tem uma parte visível acima do nível da água e uma parte muito maior invisível abaixo d’água. Um código sustentável é semelhante a um iceberg: há uma parte visível para fora, mas existe uma base que, se não for bem cuidada, não fica tão visível e pode se tornar um problema maior. A estrutura que fica embaixo e sustenta esse iceberg — a estrutura que sustenta o código — precisa estar muito bem pensada, definida e fundamentada.

Qualidade é uma estratégia de sobrevivência. O valor de negócio é entregue por meio do software. O meio de produção é o código. Qualidade não é um luxo. Não é algo a ser feito apenas se sobrar tempo, equipe ou orçamento. Qualidade deve ser um requisito prévio, porque é a estratégia que vai garantir a sobrevivência do produto.

Se não tivermos cuidado, enfrentaremos um custo composto:

• retrabalho;
• medo de mudança;
• incidentes que se acumulam silenciosamente;
• velocidade insustentável.

Isso leva a um ritmo acelerado sem padrão, resultando em colapso no médio e no longo prazo.

Defendendo método reprodutível e padrões de equipe

Se tivermos método reprodutível, revisões e padrões, transformaremos a experiência em processo de equipe. Sem método reprodutível e sem padrões, cada revisão será feita de um jeito, cada pessoa revisora analisará o código de uma forma, e acabaremos com um código “Frankenstein”, pensado de formas distintas por cada pessoa, baseado em gosto e opinião, e não em uma ideia coesa e unificada, na qual a equipe define os melhores padrões, aplica esses padrões e utiliza também referências do mercado.

Aqui vale um adendo: não existe a melhor técnica ou o melhor padrão absoluto. Não existe bala de prata. Cada equipe definirá o que é melhor conforme seu contexto e área de atuação, utilizando padrões de mercado, mas também fazendo acordos internos. É importante combinar essas duas frentes: usar frameworks — que, inclusive, vamos mostrar aqui — e respeitar os acordos da equipe, aplicando o que foi definido para uso nas revisões de código.

Apresentando as ferramentas e o escopo do curso

Antes de continuar, após essa breve introdução, queremos deixar claro que, neste curso, daremos prioridade a ferramentas de SaaS (software como serviço), ferramentas que rodam na nuvem, para evitar preocupações com servidores e provisionamento de infraestrutura. Assim, é muito mais simples conectar ferramentas já disponíveis na internet para uso imediato.

A única ferramenta que não seguirá esse padrão é o CURTOR, que vamos usar aqui. É um IDE (ambiente de desenvolvimento integrado) de código. Ele estará em execução local, em nossa máquina, e nós vamos escrever o código tal como no dia a dia.

Com essa única exceção, usaremos o SonarCloud, hospedado na própria infraestrutura da Sonar. Nós apenas o conectaremos à nossa conta no GitHub, seguindo a sequência.

Nós também vamos usar o GitHub para armazenar e versionar o código. O repositório, as pull requests (solicitações de alteração) e a branch protection (proteção de ramificações) serão o núcleo do nosso fluxo, conectando-se ao SonarCloud.

No GitHub, nós temos também o GitHub Actions para criar as pipelines (esteiras) de execução do nosso código e de nossas métricas de qualidade. A própria integração com o SonarCloud será executada nessa pipeline. Podemos criar convenções para que elas ocorram automaticamente na pipeline.

Neste curso, nós não vamos cobrir testes integrados. O foco não é falar de testes, e sim de revisão de código. No entanto, GitHub e GitHub Actions são ferramentas nas quais também é possível incorporar testes na pipeline.

Contrastando código funcional e sustentável

Seguindo para o tema deste vídeo, propriamente dito: funcional versus sustentável. Código funcional satisfaz o teste de hoje. Código sustentável permitirá mudanças previsíveis amanhã, com custo de erro controlado.

Hoje, se pensarmos apenas no momento atual, quando estamos escrevendo o código, e fizermos um código que “funciona”, o teste vai passar e o deploy (implantação) vai acontecer. Porém, se a estrutura tiver nomes opacos, lógica altamente acoplada e testes apenas nas extremidades — ou seja, sem garantir testabilidade, extensibilidade e a possibilidade de adicionar mais parâmetros ou funções sem quebrar o comportamento original — o impacto, a longo prazo, será negativo. Não teremos um código sustentável, e sim um código que simplesmente funciona naquele momento, mas não se sustenta no longo prazo. Em outras palavras, sustentável é sinônimo de funcionar no longo prazo: é um código que seguirá sendo utilizado por muito tempo, receberá atualizações e incrementos, e não precisará ser refeito por completo para continuar funcionando.

Pensando em amanhã: chega a mudança; quem for modificar tem receio; o impacto é pior do que o esperado. Para evitar isso, precisamos de:

• legibilidade, para reduzir a carga cognitiva;
• manutenibilidade e mais testes, garantindo mudança segura.

Se o código é legível, fácil de interpretar, ele impõe menor carga cognitiva para quem precisa mantê-lo ou evoluí-lo. Se é fácil de manter e testável, a mudança é segura, porque qualquer alteração não deve prejudicar o funcionamento original. Os testes fornecem o indicativo de se a alteração preservou o comportamento esperado.

Também precisamos tornar os trade-offs explícitos. Não é possível maximizar tudo ao mesmo tempo. Precisamos decidir, conforme o momento do projeto, se vale mais a pena construir algo extremamente organizado e distribuído, ou entregar uma versão mais simples, mas muito bem construída, compreensível e fácil de manter. Não teremos tudo que gostaríamos de imediato. Talvez precisemos de mais tempo para construir algo de longo prazo, sem abrir mão do que realmente importa.

Detalhando as dimensões da qualidade

Por fim, temos cinco dimensões da qualidade. Qualidade é multidimensional; portanto, é uma decisão de engenharia e não pode se basear apenas em opinião. Dentre elas:

• Correção: o software faz o que deve fazer em todos os cenários relevantes.
• Testabilidade: código que pode ser verificado automaticamente com esforço razoável.

Se o código é testável, facilmente testável, isso é um indicativo de que ele é bom e adequado para ter uma longa vida útil.

Segurança significa ausência de vulnerabilidades exploráveis: autenticação, dados, injeção.

Legibilidade implica uma intenção clara para qualquer membro da equipe, não apenas para a pessoa autora. Costumamos afirmar em aula que o grande desafio não é escrever código para que a máquina entenda; o grande desafio é escrever código que outra pessoa entenda. A máquina pode executar um código muito mal escrito, com nomes de funções dúbios, nomes de variáveis pouco claros e funções que fazem muitas coisas ao mesmo tempo. Mesmo que, em uma leitura humana, não fique claro de imediato e exija tempo para interpretação, a máquina o executará. Porém, imagine outra pessoa que precisa assumir esse código sem nenhum contexto, sem tê-lo criado, e precisa ler tudo e entender. Se o código não foi pensado para que outra pessoa pudesse lê-lo — isto é, foi escrito apenas para “funcionar” e não foi organizado de forma adequada — isso compromete a manutenção.

Por último, observabilidade: logs, métricas e traces que permitem entender o sistema em produção. Também não vamos cobrir observabilidade aqui. O foco não são testes, mas também não é observabilidade. Não vamos chegar ao ponto de conectar uma ferramenta de observabilidade, usar um código ótimo, um Datadog. Contudo, ao pensar em qualidade como um todo, não podemos deixar esse tema de fora. É necessário considerá-lo no futuro, além do conjunto de tópicos que vamos tratar aqui ao falar de revisão de código. Para ter um código em produção que seja facilmente mantido e corrigido, precisamos considerar testes e observabilidade, além dos itens desta aula.

Exemplificando com versão original do código

Agora, vamos a um exemplo mais prático. Temos, na tela, duas versões do mesmo código.

Na versão original, há uma função calc, recebendo os parâmetros o, p entre (), e abrindo {} para começar a função. Em seguida, let t = 0, um for com let i of o e {} abrindo o bloco. Depois, um if i.t === p, seguido de t += i.v. Logo de início observa-se que isso é um código medíocre. O nome da função é genérico e não comunica exatamente o que ela faz; indica que vai calcular algo, mas o quê? Os nomes das variáveis estão reduzidos a letras: let t — o que é t? O que representa isso? let i of o — i não comunica nada, e o comunica menos ainda. i.t complica ainda mais. Portanto, os nomes das variáveis e o nome da função não dizem absolutamente nada para quem for ler no futuro. Vai funcionar? Sim, a máquina interpretará. No entanto, está longe de ser um código bem escrito, pensado para que uma pessoa possa interpretá-lo e dar manutenção.

Para materializar essa primeira versão, observe o trecho abaixo:

function calc(o, p) {
    let t = 0;
    for (let i of o) {
        if (i.t === p)
            t += i.v;
    }
    return t;
}

Resumindo os problemas dessa versão:

• Nomes opacos.
• Intenção invisível.
• Onboarding (integração inicial) difícil.
• Medo de alterar no futuro.

Refatorando para uma versão legível e sustentável

Em seguida, trazemos uma versão muito mais pensada e organizada, com a função sumPricesForType (corrigindo o nome para refletir a intenção do código). Aqui indicamos explicitamente o que queremos fazer: somar preços por tipo. Apenas lendo o nome da função já temos uma pista do que ela realiza. Como parâmetros, recebemos orders e productType, o que indica claramente que trabalhamos com uma lista de pedidos (orders) e um tipo de produto (productType).

O código está em inglês porque existe uma convenção internacional de escrever o código em inglês e só colocar no idioma nativo mensagens que se comunicam diretamente com a pessoa usuária. Escrever código em inglês facilita a manutenção por pessoas de outros países. Diferentemente de escrever código em português, por exemplo: se uma pessoa dos Estados Unidos entrar no projeto, terá dificuldade para manter um código em português; o mesmo para uma pessoa da Alemanha, da França ou de qualquer outro país. O inglês, hoje, é mais universal.

Seguindo com a explicação, há um retorno que aplica orders.filter(...), onde comparamos o.type === productType. A letra o, neste caso, é aceitável porque está explícito que usamos um método de filtragem que recebe um callback (função de retorno) e, aí, o representa um elemento do array que estamos percorrendo. Não é necessário um nome mais descritivo nesse ponto específico porque o contexto do filter() deixa claro que o é um objeto de orders. Nos demais pontos, tudo está explícito: o.type é o nome da propriedade que queremos capturar, o que é muito diferente de usar o.t, por exemplo. productType é um parâmetro que veio como requisito da função.

Depois, aplicamos reduce, isto é, realizamos a soma, usando sum e o objeto o (instância de Order), fazendo sum + o.price, partindo de 0. Nesse caso, temos nomes de domínio, responsabilidade clara, facilidade para testar e facilidade para revisar.

Veja como essa segunda versão se apresenta no código:

function sumPricesForType(
    orders, productType) {
    return orders
        .filter(o => o.type === productType)
        .reduce((sum, o) => sum + o.price, 0);
}

A diferença prática aparece em termos de qualidade de onboarding (integração inicial), ocorrência de bugs (defeitos) e medo do deploy (implantação), não no número de linhas de código. Em quantidade de linhas, ambos os códigos têm volume semelhante; talvez o segundo tenha um pouco menos. Porém, o importante não é o código ser grande ou pequeno, e sim legível. Se, ao ler uma vez, já entendemos o que está acontecendo, atingimos o objetivo. No segundo exemplo, conseguimos isso; no primeiro, não. No primeiro, seria necessário interpretar, testar e passar por um onboarding mais complexo, isto é, uma iniciação mais trabalhosa naquele código.

Reforçando pilares de qualidade e encerrando o vídeo

Qualidade é igual a decisão repetível. Qualidade não é “sorte” da pessoa desenvolvedora experiente; é um padrão explícito, com revisão e automação sempre que possível.

• Padrão explícito: o código precisa estar documentado, acordado e com responsabilidade compartilhada por toda a equipe.
• Revisão de código: é uma barreira humana que garante a aderência à base de conhecimento. É o momento em que outra pessoa critica o código para verificar se algo foi esquecido ou se algum padrão não foi seguido.
• Automação: SONAR, LINT e testes fecham o que o olho humano não consegue captar todos os dias. O SONAR avalia detalhes como cobertura de testes e possíveis smells (indícios de problema no código). O LINT verifica se os padrões acordados com a equipe estão sendo seguidos — por exemplo, usar ponto e vírgula (;) ou não no código. Haverá projetos em que o uso de ponto e vírgula será obrigatório e o LINT acusará se faltar; em outros, não será. Esse é apenas um detalhe entre muitos outros em que o LINT ajuda. E os testes verificam se o código é testável e se está passando, evitando que uma pessoa precise testar manualmente cada alteração a cada nova linha adicionada.

Bom, isso é o que eu tinha para este vídeo. Eu espero que vocês tenham gostado e nos vemos em um próximo vídeo.

Fundamentos de qualidade do código - Clean Code

Contextualizando o objetivo do vídeo

Olá! Seja bem-vinda, bem-vindo e bem-vinde de volta. No vídeo anterior, eu falei sobre a diferença entre código que funciona e código que é sustentável. Neste vídeo, eu quero contar um pouco sobre Clean Code (Código Limpo) e algumas ferramentas. Atenção: minha intenção não é abordar Clean Code por completo, pois é um tema amplo que renderia facilmente uma aula inteira ou até um curso dedicado apenas a isso. A ideia aqui é trazer algumas ferramentas que já farão diferença no dia a dia, especialmente ao aplicar Code Review (revisão de código) e transformar um código que simplesmente funciona em um código realmente sustentável.

Clean Code é um tema em destaque e aparece em praticamente todas as vagas para níveis mais avançados. No entanto, sem método, pode virar micro refatoração que não move a agulha do time — refatoração pela refatoração. O objetivo real deve ser reduzir bugs (defeitos), melhorar o tempo de onboarding (integração inicial) e o tempo de mudança. Precisamos facilitar para que outras pessoas possam dar manutenção nesse código de forma mais fácil e rápida — e não simplesmente reduzir linhas ou tamanho de arquivo.

A refatoração deve ser intencional e focada em um objetivo específico, pois existe diferença entre refatorar por performance (desempenho) e refatorar com o propósito claro de mantenibilidade. Se já tivermos escrito o código e feito a refatoração original pensando em mantenibilidade, conforme entendermos mais sobre o domínio e o código evoluir, será muito mais simples aplicar melhorias de desempenho em algo que já foi estruturado para ser mantido e escalado.

Neste vídeo, nós vamos falar sobre quatro princípios — DRY, SRP, KISS e SDDC — que devem servir para tornar o código mais simples, claro e sustentável, e não para complicá-lo.

Aplicando o princípio DRY

DRY — Don't Repeat Yourself

• A sigla DRY significa Don't Repeat Yourself (Não se repita).
• Exemplo prático: existiam dois métodos, CHECKOUT VIP e CHECKOUT NORMAL. Ambos faziam exatamente a mesma coisa: checkout (finalização de compra) de produtos. A diferença é que um tinha viés para pessoas VIP e o outro para pessoas não VIP, mas a lógica era idêntica.

Para visualizar, considere as duas funções separadas:

checkout_vip()
checkout_normal()

• Aplicando DRY, podemos transformar CHECKOUT VIP e CHECKOUT NORMAL em um único método, CHECKOUT CART, com um parâmetro TYPE para diferenciar se a pessoa usuária é normal ou VIP.

Uma versão unificada e parametrizada poderia ficar assim:

checkout_cart(type = "normal")

• Assim, temos uma única função que realiza toda a lógica de checkout. Caso precisemos refatorar essa lógica, haverá um único ponto de manutenção, e não dois.

Atenção ao aplicar DRY:

• Use o conceito com responsabilidade. Ele não se aplica a todos os casos; não é uma bala de prata (e já sabemos que bala de prata não existe).
• Avalie se o trecho realmente faz sentido para unificação. Métodos podem ser parecidos, mas não exatamente iguais.
• Forçar a unificação pode violar outros princípios, como o de responsabilidade única (que veremos a seguir).
• Reflita sobre onde aplicar DRY para facilitar a manutenção futura do código.

Sugestão prática:

• Vale olhar exemplos do dia a dia e refletir se há algum contexto de código no trabalho atual ou em projetos pessoais onde DRY não está sendo considerado. Is it possível melhorar o código aplicando esse princípio?

Aplicando o princípio SRP

SRP — Single Responsibility Principle

• SRP significa Single Responsibility Principle (Princípio da Responsabilidade Única).
• Um sinal de que algo precisa mudar: função cujo nome requer um “e” geralmente está excessivamente acoplada.
• Exemplo do material: Validate and Create User (validar e criar pessoa usuária).
  • Indica claramente que a função faz várias coisas e não deveria existir dessa forma.

Como anti-exemplo, observe a função única acoplada:

VALIDATEANDCREATEUSER

• Ao aplicar SRP, separamos em duas novas funções: uma para criar a pessoa usuária (Create User) e outra para validá-la (Validate User).

Primeiro, a separação das responsabilidades em duas funções distintas:

VALIDATEUSER

CREATEUSER

Em seguida, levando a intenção também para a forma de nomear no código (mais expressivo e idiomático), podemos ter:

validateUser

createUser

Diferença em relação ao caso DRY:

• No caso de checkout, a ação era a mesma e variava um único parâmetro (tipo de pessoa usuária).
• Aqui, as ações são distintas. Criar pessoa usuária é uma coisa; validar pessoa usuária é outra, completamente diferente.

Impacto na manutenção:

• Se tudo permanecer junto, ao dar manutenção na validação, alguém pode quebrar sem querer a criação, e vice-versa.
• Separando bem, garantimos que mudanças na criação afetem apenas a criação e mudanças na validação afetem apenas a validação.

Como identificar rapidamente em Code Review (revisão de código) se uma função precisa de SRP:

• O simples fato de o nome da função ter um “e”/“and” é um sinal de alerta.
• O PR (Pull Request, solicitação de alteração) mistura duas razões para mudar? Considere separar.
• Uma alteração de regra de negócio afeta persistência? Pode haver acoplamento indevido.

Mantendo a solução simples com KISS

KISS — Keep It Simple, Stupid

• A sigla KISS significa Keep It Simple, Stupid (Mantenha isso simples). Vamos omitir o termo “Stupid” por ser pejorativo, preservando a ideia de simplicidade.
• O objetivo é manter o código o mais simples possível, sem torná-lo tão simples a ponto de não ser eficiente ou de não cumprir suas responsabilidades.
• A menor solução que cumpre o requisito com segurança é o ideal — não é “código curto a qualquer custo”.

Como aplicar KISS:

• Código simples, solução direta, legível, testável, que cumpre o requisito sem surpresas.

O que não é KISS:

• Código desnecessariamente complexo.
• Tentar prever o futuro ou sofisticar demais sem necessidade.

Sabemos que o código está em constante evolução. Tentar prever agora o que uma função pode se tornar no futuro é perda de tempo e não vale a pena. Ao fazer isso, acabamos deixando muita complexidade, muitas variáveis e muitos blocos que ainda não servem para nada, apenas porque estamos pensando em uma evolução futura. Vamos focar na melhor versão do código para hoje, o mais simples possível.

Para praticar o princípio KISS (mantenha simples), teremos que fazer trade-offs (compensações). A simplicidade pode limitar a generalidade, e a escolha deve ser intencional, não acidental. Não podemos buscar simplicidade a qualquer custo, prejudicando o funcionamento do que é necessário ou a performance (desempenho) da função. Devemos fazer um equilíbrio: pode ser simples, mas, para que seja simples, precisaremos abrir mão de algo. Talvez dividir em mais funções, conectando também com o princípio SRP.

Deixamos no slide (lâmina) um exemplo de uma função ruim, que não aplica KISS, e uma função boa — a mesma função, em duas versões diferentes. No primeiro caso, temos a function isAdult com o parâmetro age. No escopo da função, usamos if age >= 18 para return true; else, return false. Como podemos melhorar isso para aplicar KISS? Podemos ter simplesmente a function isAdult recebendo o parâmetro age, mas, dentro da função, não precisamos de um if. Podemos simplesmente retornar o resultado da comparação. Por quê? Porque, geralmente, as comparações já devolvem um valor booleano, true ou false. Assim, não precisamos de um if para decidir se retornamos true ou false; retornamos diretamente o resultado da operação. Portanto, return age >= 18 já nos devolve true ou false. Esse é um exemplo didático, muito simples, e dificilmente veremos exatamente assim no mundo real.

Primeiro, a versão mais verbosa:

function isAdult(age) {
    if (age >= 18) {
        return true;
    } else {
        return false;
    }
}

Aplicando KISS, simplificamos retornando diretamente o resultado da comparação:

function isAdult(age) {
    return age >= 18;
}

Seja por muita experiência, seja por estarmos começando e ainda aprendendo, é possível que criemos versões de funções mais complicadas pensando que estamos fazendo o correto. Vamos fazer uma pausa e refletir: no dia a dia, existem funções ou trechos de código que escrevemos que estão complicados ou desnecessariamente complexos? Poderiam ser muito mais simples? Temos o hábito de, sempre que escrevemos a primeira versão de um código, fazer uma refatoração e pensar: como podemos deixar isso legível e ainda mais simples? É uma prática que construímos ao longo do tempo.

Principalmente você, como pessoa de liderança técnica (tech lead), que está assistindo a este curso: é sua responsabilidade ajudar a criar uma cultura de refatorações desse tipo. Não apenas esta, mas todas as outras diretrizes e princípios que estamos vendo. Falta um por cobrir, e vamos aproveitar o gancho para falar dele: o SDDC. O termo SDDC não é oficial, mas é amplamente aceito na comunidade. Significa Self-Documenting Code (código autoexplicativo).

Escrevendo código autoexplicativo (SDDC)

O que é um código SDDC? É um código autoexplicativo, com nomes claros. Funções e variáveis dizem exatamente o que fazem. Ao ler o nome de uma variável, já sabemos para que ela serve; ao ler o nome de uma função, já temos uma ideia clara do que ela faz, sem precisar ler o conteúdo da função.

O que é ruim? O que não é um código autoexplicativo? Nomes genéricos, como data, value, process, handleTem, entre outros. São nomes ruins, que não dizem nada e são amplos demais. O código deve ter intenção explícita e se explicar sem precisar de comentários. Há pessoas que costumam colocar comentários em tudo. Comentários não são necessariamente ruins, mas, se precisamos de muitos comentários para que o código fique claro, talvez exista um problema, porque não deveria ser necessário. Comentários são importantes em alguns pontos, para complementar a documentação do código, mas não podemos chegar ao extremo de ter mais comentário do que código.

Levando para a vida real, trazemos um exemplo de código ruim, que não aplica SDDC e não é autoexplicativo. Um exemplo seria a function calc com os parâmetros a e b, retornando a * b. O nome calc — o que está calculando? Não sabemos; só descobriremos ao ler o conteúdo. Os parâmetros a e b — o que significam? O que se espera que seja passado? São valores numéricos? Inteiros? Decimais? Booleanos? O cálculo indica que provavelmente são números, mas não é possível ter 100% de certeza, porque os nomes são um mistério. E o return a * b simplesmente pega os parâmetros recebidos e faz a multiplicação.

Veja o exemplo problemático:

function calc(a, b) {
    return a * b;
}

Como seria uma versão boa disso? Podemos fazer o seguinte: function CalculateTotalPrice. Veja a diferença: não dizemos apenas “calcular”; dizemos “Calcular Preço Total”. Fica claro o que a função faz. Nos parâmetros, pedimos explicitamente a quantidade e o preço unitário. Assim, sabemos que o resultado do preço total é a quantidade de produtos que a pessoa usuária está comprando multiplicada pelo preço de cada produto. Naturalmente, a função vai retornar a multiplicação entre a quantidade e o preço unitário.

Uma alternativa autoexplicativa:

function calculateTotalPrice(quantity, unitPrice) {
    return quantity * unitPrice;
}

A mensagem final sobre SDDC é: se precisamos explicar o código, o nome já falhou. Há até uma brincadeira comum em empresas em que trabalhamos: quando o sistema está muito complexo, dizemos que é “código da NASA”. A ideia da piada é que a NASA costuma lidar com coisas muito complexas e gigantescas. O código não deveria ter esse estereótipo de “código da NASA”. Não é que “NASA” seja algo pejorativo — não é —, mas usamos o termo para reforçar que o código não deve ser complexo; deve ser o mais simples possível.

Encerrando com próximos passos

Se fecharmos agora este vídeo e aplicarmos estes quatro princípios, já estaremos fazendo uma melhora significativa no código. É o momento de parar e refletir: o que podemos fazer no nosso código para melhorar? O que podemos extrair destes princípios e aplicar em um código real? Vamos fazer um experimento: pegar algum código nosso, ou um projeto pessoal já publicado no GitHub ou, no trabalho, selecionar um trecho do código e validar minimamente se estes quatro princípios estão sendo respeitados. Vamos usar ferramentas de IA para ajudar nisso — hoje existem várias. Podemos usar a que for mais acessível e pedir: “Verifique se o meu código segue estes quatro princípios e quais melhorias posso fazer”. Com certeza, surgirão bons indícios.

Eu espero que tenha sido muito útil e nos vemos no próximo vídeo.

Sobre o curso Qualidade de código: estratégia de Code Review, métricas e governança

O curso Qualidade de código: estratégia de Code Review, métricas e governança possui 276 minutos de vídeos, em um total de 49 atividades. Gostou? Conheça nossos outros cursos de Liderança em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Fundamentos de qualidade do código
• Refatoração Manual - prática
• Code Review Profissional
• Análise estatística com Sonarcloude
• Inteligência Artificial no fluxo
• Processo e Liderança