BT

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

Postado por Marcelo Costa em 19 Set 2013 |

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

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

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

Receber mensagens dessa discussão

Sobre esta visão de trabalho by André Barroso

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

Receber mensagens dessa discussão

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

Receber mensagens dessa discussão

1 Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.