BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Uma solução para a dívida técnica?

Uma solução para a dívida técnica?

Favoritos

Henrik Kniberg, respeitado agilista e autor de um dos livros mais populares do InfoQ, Scrum e XP direto das Trincheiras, publicou recentemente em seu blog um artigo que sugere como melhorar, com o auxilio da equipe, as deficiências encontradas com o dívida técnica.

A dívida técnica é um assunto polêmico, muito discutido em listas de métodos ágeis no Brasil e no exterior.

Henrik Kniberg inicia o artigo com o questionamento:

Você é parte de uma equipe de desenvolvimento que tenta ser ágil? Na próxima vez que sua equipe estiver reunida, faça a seguinte pergunta a cada um dos desenvolvedores: "Numa escala de 1 a 5, o que pensa sobre a qualidade do código que desenvolve?"

O valor 5 é para o caso de acreditar que o código é muito bom e 1 para o código de baixíssima qualidade. Compare os resultados, plote esse resultado em um gráfico e deixe exposto para que todos percebam. O primeiro passo para identificar um problema é visualizá-lo, defende Kniberg. Por meio de perguntas que devem ser realizadas e analisadas em conjunto com a equipe, ele sugere pontos a serem levantados, os quais detalhamos a seguir.

Queremos continuar a escrever código dessa forma? Se não, qual a qualidade do código buscada?

A maioria dos desenvolvedores querem estar em um nível de qualidade 4 ou 5. Essa escala é arbitrária e subjetiva, mas ainda assim é útil. Caso ocorram fortes divergências de opiniões, é preciso ter uma discussão sobre o que se entende por qualidade e o que se deseja alcançar como equipe.

Kniberg sugere usar as quatro regras da simplicidade propostas por Kent Beck como ponto de referência. E diz que é difícil resolver o problema se a equipe não concordar com a qualidade de código que se deseja obter.

Qual é a causa do problema?

Lixo entra no código porque desenvolvedores colocam lixo nele! Expondo essa situação de forma mais clara: código ruim é criado por desenvolvedores. O desenvolvedor usa um teclado real para construir código real para um computador real. Independentemente de outras circunstâncias, são as ações do desenvolvedor que determinam a qualidade do código.

O primeiro passo para resolver a dívida técnica, portanto é admitir e aceitar que ela existe. Porém, muitos desenvolvedores argumentam: "herdamos um monte de código legado de baixa qualidade; não escrevemos isso!". Mas nesse caso, a qualidade do código melhorou ou piorou desde o legado?

Estamos produzindo um código de baixa qualidade?

Henrik Kniberg fez essa pergunta várias vezes para vários tipos de equipes e identificou tendências fortes.

Essa situação NÃO acontece porque o desenvolvedor não sabe como escrever código de qualidade. As habilidades na equipe podem variar, mas certamente algumas pessoas na equipe serão capazes de escrever bons códigos; além disso há vontade nos demais desenvolvedores de aprender. Combine-se isso com a prática de revisão de código ou de programação em pares, e a maioria das equipes serão perfeitamente capazes de escrever código que classificariam no nível 4 ou a 5, desde que tenham o tempo que consideram necessário para isso.

Kniberg cita ainda a síndrome da janela quebrada como um fator que colabora para a existência de código de baixa qualidade.

Código de baixa qualidade convida código pior ainda, porque as pessoas tendem a se adaptar à nova forma de escrever código, seguindo a mesma qualidade do que já existe.

Quando esta situação for identificada, é necessário decidir simplesmente por parar de escrever, e fazer uso de revisão de código ou programação em pares para se policiar. Kniberg indica, ainda, que a razão mais provável para que os desenvolvedores estejam escrevendo código de baixa qualidade é a pressão.

Muitas vezes ouço comentários como "não temos tempo para escrever código limpo" (essa afirmação é na pior das hipóteses uma mentira e na melhor das hipóteses uma desculpa esfarrapada). A verdade não é que não se tem tempo para escrever código limpo, e sim que se decidiu não o fazer.

Sobre a questão da pressão, Henrik Kniberg relata que pode ser feita uma análise de causa e efeito para descobrir as causas e questionar-se a si mesmo. É uma pressão real? Será que essas pessoas realmente querem que se escreva código de baixa qualidade? Essas pessoas sabem o resultado gerado por código ruim? Elas realmente acreditam que vale a pena o esforço para entregar código de qualidade?

Não há sentido para um negócio escrever código de baixa qualidade. Podemos ter um objetivo extremamente importante no curto prazo, que se precisa alcançar a todo custo, ou se pode fazer a construção de um protótipo descartável para validar rapidamente no mercado. Mas isso deve ser a exceção, não a regra. Se não for limpa a bagunça construída logo quando o objetivo a curto prazo for alcançado, ou se realmente não for jogado fora o protótipo descartável, então certamente iremos acabar com um caso crônico de código de baixa qualidade.

O fato de o desenvolvedor ser responsável pelo problema é uma boa notícia. Pois isso significa que o desenvolvedor é capaz de resolvê-lo. E a solução é simples: parar de escrever código ruim.

Simplesmente pare de escrever código ruim

Apesar dessa afirmação simples, há uma diferença real. Segundo Kniberg, se você continua a escrever código ruim, suas atividades ficam cada vez mais lentas com o passar do tempo, pois se perde mais tempo lutando contra esse código ruim.

Como equipe, está na mão dela a decisão de quanto trabalho deve ser alocado para ser realizado. Esse é um dos princípios fundamentais tanto para os métodos ágeis quanto para o Lean. Este princípio existe nos métodos ágeis como no Sprint Planning do Scrum, em que a equipe escolhe quantos itens do backlog vai incluir no sprint, e o mesmo ocorre no XP durante o Jogo do Planejamento. No Kanban a equipe tem um limite em seu WIP (Work in Progress) e só puxa o próximo item quando o atual é concluído. De forma clara, a equipe possui pleno poder e responsabilidade sobre a qualidade.

Um questionamento que sempre deve ser realizado é: qual é a qualidade do código produzido no último sprint, em uma escala de 1 a 5? Se for menos 4 ou 5, a equipe, no próximo sprint, deverá puxar menos histórias. A sugestão de Henrik Kniberg é de que a equipe continue fazendo isso até que encontre o seu ritmo sustentável.

O Product Owner (ou a pessoa que define as prioridades dos negócios) terá que priorizar mais. Essa pessoa, está acostumada a ver de 8 a 10 histórias saírem de cada sprint. Agora essa pessoa só verá de 6 a 7. Com isso, precisará decidir quais histórias não serão necessárias construir.

A diminuição na quantidade de entregas levará a discussões e debates difíceis. A verdadeira fonte de pressão (se houver) se revelará. A qualidade é invisível no curto prazo, e precisa ser explicada.

Qualidade no código não é o mesmo que qualidade no produto

Código não é tudo. Há mais pessoas envolvidas no desenvolvimento de um produto que apenas desenvolvedores de software. Todos os envolvidos são coletivamente responsáveis pela qualidade do produto que está sendo construído. Qualidade no código é um subconjunto de qualidade do produto. É possível se ter um grande código, mas ainda assim acabar com um produto que ninguém quer usar, porque ele simplesmente resolve o problema errado. Henrik Kniberg destaca que:

Tecnicamente, é possível construir um bom produto com código de baixa qualidade. Algumas equipes conseguem ir bem longe seguindo essa ideia. Mas estender e manter o produto é lento, caro e doloroso, uma vez que o produto é basicamente podre por dentro. É uma proposta perde-perde ao longo do tempo e os melhores desenvolvedores certamente vão deixar a equipe por simplesmente não quererem mais dar manutenção no lixo com o qual são obrigados a conviver.

E quanto ao código ruim e legado?

O próximo passo é decidir se é possível viver com a dívida técnica existente, ou realmente fazer alguma coisa para melhorar a situação. Se a equipe decidir reduzir o dívida técnica, a consequência é que vai desacelerar ainda mais no curto prazo - mas acelerar no longo prazo.

Às vezes vale a pena, às vezes não. A resposta não é óbvia e é uma decisão de negócios; por isso certifique-se de envolver na discussão as pessoas que estão pagando por isso.

Se decidir reduzir a sua dívida técnica atual, faça com que isso fique muito claro para todos os envolvidos com uma concordância do tipo "Vamos parar de escrever código ruim e gradualmente limpar o código velho".

Uma vez que todos concordarem com essa decisão (e essa é a parte mais difícil), há muitas técnicas de como concretizá-la. Henrik Kniberg sugere duas técnicas que em sua experiência sempre funcionam muito bem:

Adicione à sua definição de pronto: "redução da dívida técnica". E para as áreas que terão maior código corrigido, crie um "backlog técnico" e reserve tempo para isso.

Conclusões

Uma dedução clara do artigo de Kniberg é que o desenvolvedor possui em suas mãos tanto o problema como a solução para a dívida técnica. Não há necessidade de se preocupar ou ter vergonha do passado. Em vez disso, deve-se ficar orgulhoso do que foi feito e usar o que tiver a seu alcance para fazer alguma coisa sobre isso − tomar uma dura decisão de parar de escrever código de baixíssima qualidade. Isso irá iniciar uma cadeia de eventos positivos e provavelmente prosseguirá no longo prazo.

Sobre o Autor

Marcelo Costa (LinkedIn, Twitter) é pós-graduado em Engenharia de Software pela UNICAMP. Atua em sistemas de alta complexidade desde 2002, coordenando equipes multidisciplinares no desenvolvimento de software nas áreas de educação, saúde e finanças. Especializa-se na coleta inteligente de informações na internet e de conteúdo eletronicamente disponível; atualmente é Growth Hacker e Engenheiro de Software na Collect-In Tecnologia. Possui experiência com Lean, Kanban, Scrum, SOA, ALM, PostgreSQL, Shell Script e PHP.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

  • Sobre esta visão de trabalho

    by André Barroso,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Acredito ser o melhor dos mundos.
    Se a equipe, toda a equipe, se comprometer a trabalhar desta forma, sempre teremos um desenvolvimento produtivo e de qualidade, que nos permitirá mantê-lo de forma hábil e organizada.

    Minhas congratulações ao autor do artigo, que expôs muito bem o assunto.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT