A importância da qualidade interna

A primeira vez que percebi o quanto a qualidade interna é importante, foi quando li o livro Scrum e XP direto das Trincheiras. Nele o Henrik Kniberg destaca que a qualidade interna do sistema é mais importante que a qualidade externa, tanto que ela é de responsabilidade da equipe e nunca (quase nunca) negocíavel com os clientes. E realmente é difícil discordar, uma vez que a qualidade interna irá acabar refletindo na qualidade externa do sistema, tanto que segundo o próprio Henrik: “[…] um sistema com baixa qualidade interna raramente terá uma qualidade externa alta.”

Mas qual a diferença entre qualidade interna e externa?

Em suma, qualidade interna é o sistema visto da perspectiva técnica, enquanto a qualidade externa é a visão do sistema, da perspectiva funcional.

Uma analogia seria a de uma montagem de um computador, você pode montar um computador com peças de vários fabricantes, e para o usuário pouco importará se a placa mãe é uma Asus, ou uma PCChips. O que o usuário verá será a qualidade externa, se o gabinete tem um design atraente se o computador não trava, essas coisas. Ele pouco irá importar se a memória RAM é Kingston ou não. O que importa na perspectiva funcional é realmente o funcionamento do computador e não como ele foi montado.

O que ocorre muito, é que há uma forte tendência no desenvolvimento do sistema ser guiado pelo “funcionou”, sendo que o “funcionou” pode ser um estado ainda crú da implementação da funcionalidade.

Monalisa

Citei a Monalisa no post anterior, desta vez ela será útil para nós, para entender como o processo de desenvolvimento de um software, é muito mais próximo do processo de pintura de um quadro, do que de um processo de construção civil.

Pesquisando na Internet encontrei informações de que a Monalisa foi pintada entre 1503-1514. Nesse período de mais de 10 anos, boa parte do tempo investido no quadro, foi em alterações técnicas, a base sempre foi permanecida.

Em outras palavras, podemos dizer que Leonardo Da Vinci levou 11 anos para finalizar o seu projeto, e boa parte do tempo, foi investido na manutenção do quadro, realizando refatorações e correções de bugs.

Uma característica que suponho que seja comum no processo de pintura de um quadro, principalmente quando ele é uma demanda, é a mudança constante. E mudança é uma das poucas certezas que temos no desenvolvimento de software, afinal um bom software está “sempre” em constante evolução/melhoria e quanto mais fácil for inserir mudanças no software, melhor será.

Mudar software é mais difícil do que mudar hardware

Vamos fazer uma breve viagem no tempo, o ano é 1946 e você está de frente ao ENIAC (foto abaixo). Se você perguntar para a pessoa na foto: o que é mais fácil mudar, o hardware ou o software? Ele com certeza, irá responder que é o hardware, e ainda irá achar a sua pergunta estúpida.

Agora voltando a 2010. O que é mais difícil, mudar o software ou o hardware?

Não há dúvidas que o software, não é? Hoje obter harware é MUITO fácil e barato, comparado a 1946. E com as VPSs da vida, ficou fácil obter hardware e uma ótima infraestrutura, você nem precisa sair de casa para ter o seu servidor rodando.

Monalisa, ENIAC, computação em nuvem e qualidade interna

Onde eu quero chegar com tudo isso?

Acredito que ficou claro que um dos grandes desafios para se desenvolver um software é conseguir mudar ele com o menor esforço necessário, mantendo o seu bom funcionamento. Costumo até dizer, que desenvolver software é fácil, comparado a manter o software.

Mas eu estou errado, pois desenvolver o software deveria ser mais difícil do que manter ele. Porém, seja por motivos externos (mudança frequente/drásticas de funcionalidades pelo cliente) e/ou motivos internos (pouca cobertura de testes, design fraco, falhas de comunicação, etc), manter o software acabou se tornando um tarefa mais difícil, do que a criação dele.

Voltando ao exemplo da Monalisa, vimos que Leonardo Da Vinci passou boa parte do tempo fazendo correções e melhorias no quadro, porém a sua essência foi mantida. Supunho que ele tenha feito um bom “design”, que permitiu inserir as correções e melhorias sem ter enfrentado maiores problemas.

O caso do ENIAC é interessante, pois mostra como as coisas mudaram MUITO do início da computação até hoje. Naquela época, e por um bom tempo, o hardware era o mais valorizado. Já hoje o software passou a ser o mais valorizado. E se antes os softwares eram escritos em cartões perfurados e pouquíssimas pessoas eram capazes de desenvolver software, hoje escrevemos software em linguagens quase naturais e conseguimos aprender a “desenvolver” por meio da Internet e de graça.

E a qualidade interna é peça fundamental para podermos conseguir alterar o código de forma “indolor”. E essa é apenas uma das vantagens que desenvolver software com uma boa qualidade interna traz. E vamos concentrar nela no próximo tópico.

Qualidade Interna

Qualidade interna também poderia ser traduzida em “fazer a coisa da forma certa”. Porém, essa tradução é muito simples e faz parecer que obter qualidade interna é fácil. Afinal seria só saber como fazer a “coisa” da forma certa, não é mesmo?

No entanto, há várias formas de fazer da forma certa no mundo do desenvolvimento de software. Por isso, uma das tarefas do desenvolvedor é fazer escolhas, e serão essas escolhas que irão influenciar diretamente a qualidade interna do software.

Os retornos com o investimento em qualidade interna ocorrem a médio e longo prazo, por causa disso, muitos acabam fazendo as escolhas “certas” a curto prazo, mas esquecem de avaliar o impacto que elas terão a médio e longo prazo.

E uma vez que escolhemos o caminho mais fácil, por exemplo adicionar mais um if, para atender uma alteração que o cliente pediu, ao invés, de extrair o comportamento para outro método, a tendência é acabar sempre escolhendo o caminho mais fácil.

Esse hábito, acaba sendo passado para os outros é acaba virando uma “cultura”. E aí, o caminho fácil será sempre tomado, e a possibilidade de tomar outras direções poderá nem passar pela cabeça mais. Sendo que essas direções diferentes, muitas vezes não representam um caminho difícil (ex.: escrever testes unitários), mas a mudança em si, é a parte difícil.

Desta forma, a qualidade interna acaba sendo colocada de escanteio. Porém, ao longo do desenvolvimento irão aparecer os sinais de que ela está muito baixa. Por exemplo: lançar uma nova versão demora cada vez mais tempo.

Como Obter Qualidade Interna

Algumas ações podem ajudar a desenvolvermos um software com uma boa qualidade interna:

• Refatoração: alterar o código sem alterar o seu comportamento, focando na melhoria do código para favorecer a manutenibilidade dele;
• Conhecer e utilizar boas práticas: princípios como o SOLID, ajudam a resolver os problemas com menos ruído e com soluções que favorecem a manutenção do software;
• Comunicação: uma boa comunicação é essencial para o desenvolvimento do software, tanto externa (cliente), como interna (equipe). Muitos bugs acabam sendo inseridos e códigos duplicados, simplesmente porque houve falha na comunicação;
• Estressar as soluções: geralmente, costumamos implementar a primeira solução que nos vem na cabeça, porém esquecemos que a primeira solução costuma não ser a melhor, por isso é importante pensar em outras formas de solucionar o mesmo problema e/ou conversar com alguém sobre;
• Aprendizado contínuo: é importante estar sempre nos aperfeiçoando, se você for olhar algo que fez há 6 meses atrás e achou que não tem nada a ser melhorado, é sinal que você não aprendeu muito nos últimos 6 meses;
• Saber quando parar: saber o momento de parar de ficar refatorando o código, é tão importante quanto saber quando é preciso melhorar ele, objetive a perfeição, mas não fique cego por ela;
• Valorize o seu tempo: a vida é muito curta para ficar gastando tempo tentando entender aquele método com mais de 30 linhas que você escreveu há 3 meses atrás, ou ficar corrigindo bugs que poderiam ter sido encontrados antes com testes. Só nestes momentos, que você realmente percebe, o quanto a qualidade interna é importante;
• Testes: por último e não menos importante, escreva testes. Além deles auxiliarem você a pensar melhor sobre as funcionalidades (se você usar TDD), eles irão te dá a tranquilidade necessária para refatorar o código. Afinal, refatorar sem testes, é algo muito difícil e arriscado, e isso incentiva a não refatoração e por consequência a uma baixa qualidade interna, portanto, escrever testes é fundamental para obter uma boa qualidade interna.

Conclusão

Enquanto a qualidade externa é a percepção do cliente para o software, a interna é a percepção dos desenvolvedores em relação a ele.

Devemos nos preocupar em manter uma boa qualidade interna, pois ela é essencial para a manutenção do software, e em cenários onde há entrega contínua do software (ex.: SaaS), a qualidade interna acabará sendo uma diferença competitiva. Afinal, uma das únicas certezas que temos no desenvolvimento de software, é que haverá mudanças, portanto, conseguindo reagir à tempo a elas, é fundamental para conseguir atender as demandas.

Os testes mais uma vez, representam um papel importante, pois é através deles que teremos a segurança necessária para refatorar o nosso código, implementar as alterações e novas funcionalidades.

Como anda a qualidade interna dos projetos que você está participando? A equipe tem consciência da sua importância?

Fique por dentro das novidades, assine o feed do QualidadeBR.