SCRAP: Um checklist para código de qualidade

Olá, leitores!

Pois bem, para dar início aos artigos sobre Engenharia de Software, vou apresentar-lhes um checklist prático para validação da qualidade de código, conhecido como SCRAP, elaborado originalmente por Tyler Treat, autor do blog Brave New Geek. Confira!

Embora a tradução da palavra em inglês “SCRAP” seja “fragmento”, no contexto deste artigo ela recebe o sentido de um acrônimo. Cada letra de SCRAP foca em uma área-chave da qualidade de código, definidas logo abaixo. Além de servir como um excelente recurso para revisão de código, SCRAP também pode ser utilizado como um “guia” por desenvolvedores para escrever códigos de alta qualidade.

Scalability

A primeira letra do SCRAP se refere à escalabilidade da arquitetura do software. Já escrevi um artigo sobre este tema em junho de 2015, chamado Escalabilidade e sustentabilidade em um ambiente corporativo.

Uma arquitetura escalável é constituída de unidades de código capazes de serem evoluídas facilmente, sem impactos colaterais em funcionalidades já consolidadas do software. Para isso, a modelagem das classes deve ser bastante desacoplada, de forma que uma nova herança ou o reaproveitamento de componentes seja simples e viável.

Como exemplo, considere uma funcionalidade de geração de arquivos de remessa para serem enviados à uma instituição financeira. Algum tempo depois, devido à uma atualização de layout, a instituição passa a exigir que um segundo arquivo de remessa seja enviado, mas com diferentes formatações. Se a arquitetura do software for escalável, basta apenas criar mais uma herança da classe-base de arquivos de remessa e reaproveitar os métodos de exportação já existentes. Caso contrário, se a escalabilidade não for atendida, várias estruturas condicionais (If, Case…) terão de ser adicionadas, como já acontece muito hoje em dia.

Complexity

O segundo item do SCRAP é relacionado ao nível de complexidade de leitura, manutenção e evolução do código. Em outras palavras, quanto mais complexo, maior será o tempo dispendido para implementá-lo.

Uma ótima prática que vários profissionais recomendam (e eu assino embaixo) é adquirir o hábito de programar “para humanos”, e não para máquinas. Isso envolve uma mudança de pensamento. Vários desenvolvedores escrevem código considerando exclusivamente no sucesso da compilação, e esquecem que, indubitavelmente, outros desenvolvedores futuramente trabalharão na mesma implementação. Quando programamos já pensando nessa possibilidade, o código se torna mais compreensível e expressivo, como se quiséssemos facilitar o trabalho do próximo.

Quando tiver um tempinho, confira o artigo CODEsign: Faça duas vezes!.

Resiliency

Você sabe o que significa “resiliência”? É sinônimo de “recuperação”. Um lutador resiliente é aquele que leva um golpe e se levanta rapidamente para continuar lutando. A letra “R” do SCRAP define que um software também deve se comportar da mesma forma. Por exemplo, deve ser capaz de garantir a integridade de dados quando há uma falha na rede, reconectar-se à base de dados após uma queda dos servidores ou manter alguma contingência quando um serviço não está disponível. Ah, e talvez o mais importante: evitar travamentos e exceções ao máximo!

Ao escrever o código, devemos considerar a possibilidade de falhas tanto internas quanto externas, adicionando condições de guarda, tratamento de exceções, registros em log e métodos de recuperação. Isso é ser resiliente!

API

Interfaces colaboram para o baixo acoplamento e alta coesão de uma arquitetura de software. Porém, são mais do que isso. Interfaces também representam recursos que serão disponibilizados para os desenvolvedores da equipe, portanto, devem fornecer facilidade de implementação e integração. Pensando assim, podemos dizer que, quando disponibilizamos uma API, nossos clientes são os próprios desenvolvedores, concorda?

APIs devem ser bem documentadas e objetivas, com um propósito único. Eu diria que cada API deveria ter uma documentação sólida, como um manual de integração, explicando claramente a finalidade de cada método.

Eu já tive problemas em implementar algumas Interfaces devido ao excesso de métodos (muitos deles com nomes parecidos) e imprecisão da documentação. Interfaces assim são como produtos mal fabricados.

Performance

Por último, mas não menos importante, o foco no desempenho do software. Neste item, não ressalto somente a velocidade do software (veja o artigo A crueldade de um software lento), mas também outros aspectos técnicos que afetam indiretamente a performance, como consumo de memória, Memory Leaks, espaço em disco e funções que realizam leitura de arquivos (I/O).

O software precisa ter uma “boa reputação” no ambiente em que está trabalhando. Na minha opinião, este é um dos itens de mais importância na atividade de Code Review.

Uma característica notável nos sistemas atuais é a negligência em escalabilidade. Muitos softwares, principalmente antigos, apresentam um nível altíssimo de complexidade de código, já que, lá no início, ninguém pensou em longevidade. Como consequência, a manutenção desses sistemas, tanto corretiva quanto evolutiva, tornam-se muito custosas. Como diz o próprio autor do SCRAP

It’s also worth pointing out that without the ‘S’, all you have is CRAP

Espero que tenham gostado, pessoal.
Até a próxima!