Qualidade de Software para pessoas desenvolvedoras
Muito se fala de softwares de qualidade, mas quais critérios devem ser atendidos para que ele seja realmente bom? Em qual direção devemos seguir? O que devemos cumprir? O que nós, como desenvolvedores, podemos fazer para garantir a qualidade de software? Veja mais n̶o̶ ̶g̶l̶o̶b̶o̶ ̶r̶e̶p̶ó̶r̶t̶e̶r̶- neste artigo, em que discutiremos sobre algumas dicas práticas que adquiri no dia a dia como desenvolvedora. 🧐
Para iniciar, é preciso entender a definição de qualidade de software. A norma ISO/IEC 25010, que estabelece um conjunto de características e subcaracterísticas para avaliar a qualidade de um produto de software, possui a seguinte definição:
“A totalidade de características de um produto de software que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas.”
Ou seja, é o conjunto de atributos de um sistema que torna possível atender os requisitos funcionais e não funcionais da aplicação. Os requisitos funcionais são de fato as funcionalidades que aquele sistema deve ter, ou fazer. Já os requisitos não funcionais são aqueles que são invisíveis, como, por exemplo, funcionamento do sistema offline, bom desempenho de SEO, nível de segurança necessário, etc.
Agora que já entendemos a definição de qualidade de software, iremos falar um pouquinho sobre como podemos agir no dia a dia para garantir a qualidade de software.
Boas práticas de desenvolvimento
Inúmeros fatores contribuirão para a qualidade do seu software, como planejamento, boa gestão do projeto, priorização, recursos, cultura, entre outros. Mas neste tópico falaremos das boas práticas que podem ser adotadas no desenvolvimento da aplicação de fato.
1° Defina padrões
Certo dia, ouvi a seguinte frase há um tempo atrás, que nunca saiu da minha cabeça: “O pior padrão é melhor do que nenhum padrão”. Claro, não a interpretei como se eu pudesse criar padrões terríveis só porque eu precisava de um padrão. Mas ela me fez entender a importância de seguir um padrão.
Padrões estabelecem diretrizes e boas práticas a serem seguidas, fornecendo uma estrutura consistente e organizada para o código, que, por sua vez, torna o código muito mais fácil de ser lido e de ser compreendido. Quando você compreende os padrões que o projeto utiliza, entender arquivos e componentes que você ainda não teve oportunidade de conhecê-los será um desafio bem menos doloroso, pois você já terá alguma afinidade com aquele código, entendendo algumas regras e isso certamente facilitará o entendimento dos demais componentes da aplicação. A padronização pode ser implementada em diversos níveis no seu projeto:
2° Padrões de código
Podemos definir inúmeras regras de código, como formatos de texto para nomear variáveis, classes, métodos e arquivos. Também é possível estabelecer a ordem de importação de arquivos, regras para alertar quando temos uma variável inicializada sem uso, se as aspas serão simples ou duplas, se usaremos ponto e vírgula no final de cada linha, entre outras inúmeras configurações de regras para que seu código possua padronizações, trazendo organização e alinhamento. Para auxiliar nesta padronização, você pode configurar ferramentas como ESlint, que apontará problemas de acordo com as regras definidas por você, te poupando horas tentando encontrar uma variável com nome errado ou erros de implementação.
3° Formatação e indentação do código
Muitos dizem que escrever um código é como escrever um livro para outros leitores. Ou seja, escrevemos códigos não apenas para que o computador entenda, mas para que as pessoas leiam. Você imagina ler um livro sem parágrafos ou finais de frases bem demarcados, ou que o texto esteja disposto de maneira completamente desordenada? Seria muito difícil, certo? Por isto, um código bem formatado é mais legível e compreensível. A indentação correta, espaçamentos consistentes, quebras de linhas e organização do código facilitam sua leitura e assim, sua compreensão.
Para lhe auxiliar nesta tarefa, você pode configurar o Prettier, que irá impor um estilo de código consistente e formatar seu código automaticamente.
4° Padrões arquiteturais
A arquitetura do software é responsável pela organização e comunicação dos componentes da aplicação. No momento da definição arquitetural, determina-se como os componentes de software serão construídos, como irão se comunicar, como as responsabilidades serão divididas, etc. É neste momento, por exemplo, que decidimos se serão utilizados microfronts, microsserviços, ou se serão monolitos, como será o controle de estado da aplicação. E por aí vai.
Defina um padrão e o siga. Se escolheu seguir como microfronts, continue separando bem as responsabilidades. Cuidado para não começar bem, ir desandando, e, no fim, ter um microlito (microfront com monolito) 😛
5° Padrões de organização
Além de padrões arquiteturais, de formatação de código que, com certeza, irão auxiliar na organização do seu software, defina também padrões para organizar seus arquivos, padrões para criação de pastas dentro do seu repositório, definindo onde cada coisa será posicionada. Isso auxiliará muito na navegação entre os componentes da sua aplicação, aumentando a produtividade e melhorando a experiência de desenvolvimento.
Você pode pensar em separar por uso, por exemplo. Se você possui utilitários utilizados em várias partes do sistema, crie uma pasta utils ou commons. Separando por tipos, é possível criar pastas para mocks, para testes, para estilos. Ou você pode unificar estes tipos de arquivos para cada componente e separar por contexto: imagine uma pasta com um componente de button. Ali terá o button por si só, seus testes, seus estilos e até mesmo, seu arquivo do storybook. Enfim, existem muitas maneiras de organizar. Escolha uma ou combine várias para montar o seu padrão e o siga fielmente.
6° Código Limpo
No momento de codificar é importante nos preocuparmos com cada linha que escrevemos. Como disse anteriormente, nosso código é como um livro, que deverá ser lido e interpretado por outras pessoas — e até mesmo por você num futuro bem próximo, que já não se lembrará dos mínimos detalhes. E a preocupação não para por aqui. Códigos bem descritos aumentam sua testabilidade, manutenibilidade, facilita a busca por erros e inconsistências, diminui as chances de refatoração e por aí vai. Existem muitos materiais disponíveis que ensimam como escrever um código limpo, talvez o mais conhecido seja o “Clean Code do” do Robert C. Martin, por isso, não irei me delongar muito neste assunto, mas irei listar alguns pontos muito importantes que devemos nos preocupar:
Nomenclatura: os nomes de suas variáveis, métodos e classes devem refletir claramente a finalidade do que ele está representando. Evite abreviações e ambiguidades, evite nomes muito genéricos ou que não representem nada. Não tenha medo se os nomes ficarem um pouquinho grandes (claro, use o bom senso). Siga uma padronização ao nomear e utilize o ESlint para te ajudar a manter os padrões.
Funções: escreva funções simples e pequenas, com apenas uma responsabilidade, use nomes claros, evitando passar muitos parâmetros para suas funções. Faça com que as funções, que são partes importantes do código, sejam de fácil compreensão, para não haver efeitos colaterais.
Condicionais: evite condicionais muito longas, aninhadas e complexas. Divida a lógica em partes menores e atribua a variáveis com nomes descritivos, se necessário, para tornar a leitura mais clara. Evitar condicionais negativas também é uma boa dica, elas são mais difíceis de serem interpretadas.
Evite comentários: o código deve ser autoexplicativo, não deve haver comentários para explicar o que ele próprio deveria expressar. Os comentários mentem, pois facilmente podem ficar desatualizados com a realidade do código. É muito fácil que ele seja alterado, mas seu comentário fique como estava. A verdade deve estar no código, por isso, o interessante é sempre pensar em uma maneira de expressar o que está acontecendo usando o próprio código.
Evite repetições: A repetição de código pode causar inconsistências, pois qualquer alteração feita em um lugar precisará ser replicada manualmente para outros locais que repetem o mesmo código, aumentando o retrabalho e levando a inconsistências que causam erros que podem ser ainda mais difíceis de serem rastreados. Blocos de código repetidos podem se tornar funções, métodos ou componentes, centralizando as lógicas em um só lugar. Isso facilita a escalabilidade e a manutenibilidade.
Existem muitas outras dicas para tornar seu código limpo, estes foram alguns exemplos do que devemos nos preocupar ao escrevê-lo. Outros tópicos neste artigo também estão diretamente ligados a um código limpo, como o próximo.
7° Regra do escoteiro
A “regra do escoteiro” no desenvolvimento de software é um princípio que incentiva os desenvolvedores a deixarem o código em um estado melhor do que o encontraram. Essa regra é baseada no lema dos Escoteiros, que é “uma vez que você sai da área em que está acampando, você deve deixá-la mais limpa do que quando você a encontrou”.
A ideia por trás da regra do escoteiro no desenvolvimento de software é que, sempre que você trabalha em uma parte do código, você deve fazer melhorias nela, pode ser algo como dividir uma função complexa em vários métodos independentes, ou até mesmo renomear uma variável que não está com um nome muito claro, remover um código inutilizado ou somente organizar melhor o código. A mudança pode ser pequena, mas com certeza, se a cultura da regra do escoteiro se firmar, o saldo final será extremamente positivo para a melhoria contínua da aplicação.
8° Tratamento de erros
Quando os erros não são tratados adequadamente, podem ocorrer falhas, comportamentos inesperados e até mesmo a interrupção total do software. É importante que estratégias de tratamento de erros sejam aplicadas para que os problemas sejam comunicados e contornados da melhor forma.
Por isso, implemente seu código já imaginando o que poderia dar errado e que o mesmo precisa de fluxos ou tratamentos para diminuir os impactos, como, por exemplo, chamadas às APIs. Se uma chamada falha, o que aconteceria com o seu software? E se tiver um erro de código, como, por exemplo, um erro de javascript? Será que quebrará toda a aplicação?
Validando a entrada do usuário antes de tomar ações como enviar para o servidor, pode-se evitar muitas dores de cabeça, por isso, não negligencie os tratamentos de formulários da sua aplicação.
Tente prever alguns cenários para que você possa prevenir que comportamentos estranhos ocorram na sua aplicação.
Para os tratamentos de erros utilize mensagens claras para comunicar o ocorrido, utilize frases informativas e significativas, trazendo feedbacks para seus usuários, para que eles ao menos sintam que entenderam o que está acontecendo. Não adianta tratar um erro, mas exibir um grande erro 500 para seu usuário. Ele não sabe o que isso significa sem uma explicação.
Dependendo da maturidade do seu projeto, pode ser interessante pensar em uma estratégia de registrar os erros ocorridos, utilizando ferramentas de logs. Isto poderá ajudar nas investigações para correção de erros mais complexos
Por último e não menos importante, dê a oportunidade do seu usuário se recuperar do erro em questão. Dê opções do que ele pode fazer para poder resolver o problema, dê oportunidade para que ele possa continuar navegando no sistema se uma parte dele quebrar, enfim, tente tornar mais leve a frustração de encontrar um erro.
9° Escolha bem suas dependências
Ao adicionar uma dependência a uma aplicação é importante lembrar que estamos agregando à aplicação um código externo. Por isso, o primeiro passo é avaliar se ter uma dependência é realmente necessário ou se existe alguma outra alternativa que atenda às suas necessidades. (Calma, não precisa ser radical e nunca utilizar uma lib externa, não precisa reinventar a roda, só seja criterioso)
Ao optar por utilizar uma dependência é importante que façamos uma boa escolha, por isso, avalie a popularidade da dependência, se ela possui muitas stars e se há um bom engajamento nas interações com as issues do repositório. Analise se há engajamento na manutenção da dependência, se os problemas são resolvidos e se novas releases são geradas. Não se esqueça de verificar o tamanho do bundle, dependências muito grandes podem afetar o desempenho da sua aplicação. Não deixe de avaliar a documentação, verifique se é clara e se possui os exemplos necessários para que suas funcionalidades sejam compreendidas e utilizadas da melhor forma.
10° Testes de software
Testes são essenciais para garantir que o software funcione corretamente, atenda aos requisitos, e reduza os erros gerados. Os testes ajudam a verificar se o software está funcionando conforme o esperado, facilitando a manutenção contínua, pois estes permitem que os desenvolvedores verifiquem se as alterações feitas não introduzem novos problemas ou afetam negativamente as partes já existentes do código, garantindo a qualidade de software, o que, por sua vez, aumenta a confiança e a credibilidade do software. Escolha sua estratégia de testes e a aplique, e lembre-se, quanto mais se sobe na pirâmide de testes, mais a confiança do software aumenta, no entanto, com isto, também se aumenta o preço e o prazo de desenvolvimento. Tome decisões de acordo com o seu contexto e realidade.
11° Design System
Design system consiste em um conjunto de padrões, diretrizes, componentes e princípios de design. Permite estabelecer uma identidade visual consistente para toda aplicação, pois define paleta de cores, tipografia, ícones e estilo de componentização. A consistência visual contribui para uma experiência de usuário mais agradável e coesa, tornando a aplicação mais fácil de usar e compreender. Além disso, aumenta a eficiência no desenvolvimento, pois além de facilitar a comunicação de designers e desenvolvedores, possibilita a reutilização de componentes e estilos já pré-definidos, e que as atualizações sejam aplicadas de forma centralizada, reduzindo o esforço de implementação.
12° Documente
Documentações são fontes de informação cruciais para o sucesso de uma aplicação.
Elas fornecem um acesso rápido e facilitado sobre o funcionamento da aplicação, suas peculiaridades e padronizações. Várias decisões são tomadas a medida que uma aplicação vai sendo construída, muitos integrantes são inseridos ao time, outros o deixam para trás levando consigo todo o contexto e conhecimento sobre a mesma. Por isso, é importante que não se deixe o conhecimento sobre aplicação morrer. É importante que os padrões, decisões arquiteturais, partes complexas da aplicação sejam bem documentadas, facilitando a inserção de novos membros ao projeto, auxiliando na tomada de decisões, na análise de riscos e na manutenabilidade do sistema.
13° Code review
A revisão de código é uma peça crucial para manter a qualidade de software, pois é neste momento, que mais pessoas, com diferentes conhecimentos, irão analisar um novo código que será agregado à aplicação. Uma boa avaliação evita que novos erros sejam gerados, que o código seja degradado e que haja efeitos colaterais, auxilia que as documentações sejam atualizadas, os padrões sejam seguidos e que o conhecimento seja compartilhado entre a equipe, evoluindo a aplicação e a equipe.
Sugiro a leitura deste outro artigo que escrevi com mais detalhes e dicas para um bom code review.
Engajamento da equipe
No mundo do desenvolvimento de software, às necessidades técnicas são essenciais, mas são apenas uma parte do quebra-cabeça necessário para se criar um software de qualidade. É muito importante que todos os envolvidos estejam engajados e imersos, e para isso é necessário um ambiente que estimule não apenas o aprimoramento contínuo do software, mas também estimule e possibilite o crescimento pessoal e profissional.
Características de um software de qualidade
Antes de finalizar este artigo trouxe mais umas informações que não gostaria de deixar de fora, pois, julgo serem importantes para um melhor entendimento do que estamos falando aqui.
Esta seção foi escrita primordialmente no início do artigo para nos habituamos a alguns conceitos antes de falarmos sobre as implementações, mas, para ir mais rápido ao ponto principal e evitar que as pessoas abandonassem o artigo antes de chegarem na parte mais legal do texto, movi para o final.
Após ver tantas dicas de como construir uma aplicação de qualidade, talvez possamos nos perguntar: “Mas quais são as características de um software de qualidade? Com oque especificamente eu tenho que me preocupar?”
A norma ISO/IEC 25010 define oito características principais de qualidade de software. Vamos passar por elas rapidinho antes de entrarmos nas dicas práticas. Mais uma vez lembrando que estas definições irão nos ajudar a entender quais características queremos satisfazer para tornar um software de qualidade. As características são:
Adequação funcional: Refere-se à capacidade do software de fornecer as funções especificadas e atender às necessidades do usuário. Inclui aspectos como adequação, precisão, interoperabilidade e conformidade.
Confiabilidade: Diz respeito à capacidade do software de desempenhar suas funções de maneira confiável em diferentes condições e períodos de tempo. Inclui aspectos como maturidade, tolerância a falhas, recuperação de erros e tempo médio entre falhas.
Usabilidade: Refere-se à facilidade de uso e compreensão do software pelos usuários. Inclui aspectos como facilidade de aprendizado, eficiência, facilidade de uso, atratividade visual e acessibilidade.
Eficiência de Desempenho: Diz respeito à capacidade do software de realizar suas funções com eficiência em termos de recursos, como tempo de resposta e utilização de memória.
Manutenibilidade: Refere-se à facilidade com que o software pode ser modificado, corrigido, aprimorado ou adaptado. Inclui aspectos como analisabilidade, modificabilidade, estabilidade e testabilidade.
Portabilidade: Diz respeito à capacidade do software de ser transferido de um ambiente para outro. Inclui aspectos como adaptabilidade, instalabilidade, coexistência e substituibilidade.
Segurança: Refere-se à capacidade do software de proteger informações e dados, além de prevenir acesso não autorizado. Inclui aspectos como confidencialidade, integridade, autenticidade e não-repúdio.
Conclusão
Todos os pontos e dicas mencionados anteriormente irão ter impacto direto para que um software de qualidade seja construído. Esses fatores irão facilitar a inserção de novos desenvolvedores no time, prover uma convivência mais tranquila, um desenvolvimento mais organizado, aumento na produtividade e uma melhor experiência de desenvolvimento para os envolvidos. Um software deve evoluir sempre, e manter a qualidade no dia a dia fará toda diferença.
Quer conhecer mais sobre os times de tecnologia da Hotmart?
Acompanhe a nossa comunidade de tecnologia através do site Hot Hackers. Por lá você se inscreve em nossa newsletter mensal, nos eventos, acompanha o Podcast de tecnologia Pod&Dev, e não perde nenhuma novidade!
Não perca nenhuma edição do Troopers Life! Para se candidatar às vagas, acesse nossa página de Jobs.
