qualidade no desenvolvimento de sistemas

Qualidade no Desenvolvimento de SistemasMelhores Práticas de ProgramaçãoAnderson Augustinho

Proibida cópia ou divulgação sem permissão escrita do CMG Brasil. 1

Agenda

Abstract

1 Filosofias de Programação

2 Boas Práticas Gerais de Programação

3 Boas Práticas de Programação - Código

4 POG – Programação Orientada à Gambiarra

5 Conclusões


Abstract

- Com a vinda da Internet, cada vez mais os sistemas são desenvolvidos para trabalhar em ambientes distribuídos, por exemplo: aplicativo web em um servidor, banco de dados em outro e assim por diante. Para que se obtenha o melhor potencial destes, é obvio que o desempenho dos ativos que o cercam têm que serem bom (servidores, ativos de redes, outros sistemas, entre outros), mas o foco principal deste artigo é o desenvolvimento do sistema em si.


Abstract

- Desenvolver utilizando as melhores praticas de programação, aproveitar todos os recursos que as linguagens dispõem e produzir um código limpo são primordiais para que se miniminizem as falhas e se construa um sistema de qualidade, assim será possível racionar os recursos envolvidos e minimizar os custos.



1.1 SOC - Separation Of Concerns

- Separação de interesses. Dividir rotinas em trechos pequenos quanto possível, e tanto quanto fizer sentido. Quando se tem um grande problema para resolver, deve-se começar separando esse “problemão”, em “problemas menores”, e resolver cada problema de uma vez. Isolando em pequenas partes focadas será privilegiado o reaproveitamento do código.



1.2 DRY – Don't Repeat Yourself

- Não repita a si mesmo. Se já existe um trecho de código que resolve uma dada situação e, logo mais adiante, se depara com a mesma situação, não deve-se desenvolver a mesma rotina ou muito menos replicá-la e sim usar o mesmo trecho. Sem Ctrl+C / Ctrl+V.



1.3 DIE - Duplication is Evil

- Duplicação é ruim. Ruim para o desenvolvedor, para o desenvolvimento, para futuras correções. Não duplique códigos. Exemplo: Se já existe uma rotina de conexão ao banco de dados, não duplicar essa rotina.



1.4 KISS = Keep It Simple, Stupid

- Manter simples. Descartar toda a complexidade que não for realmente necessária. Lógico que nem tudo é simples. Existem coisas que realmente não são. Porém a idéia do KISS, não é deixar fácil, mas sim evitar complicar. Evitar aumentar o custo e entregar exatamente o que foi requisitado. E apenas isso. A aplicação só ganhará com isso. KISS é fazer menos, e não fazer da forma mais fácil. Manter o foco.



1.5 YAGNI = You Aren’t Going Need It

- Parecido com o conceito anterior. “Você não vai precisar disso”. Resumindo: não complicar ou inventando o que não será usado. É uma tentação comum querermos desenvolver o sistema mais incrível do mundo, com as melhores funcionalidades. Seja racional. Preveja a expansão e escalabilidade, porém não fique dando voltas sem sair do lugar ou entregar o que não foi pedido, por estar implementando algo que nem era requisito e nem necessário naquele momento.



1.6 Teoria da Janela Quebrada

- Livro de George L. Kelling e Catherine Coles

- Imagine um edifício com algumas janelas quebradas. Se as janelas não são reparadas, a tendência é que vândalos quebrem mais janelas.

- Uma estratégia de sucesso para prevenir o vandalismo, dizem os autores do estudo, é resolver os problemas quando eles são pequenos, assim a probabilidade dos vândalos estragarem mais é menor.



2.1 Comentários

- No início de cada arquivo deve ter seu nome, uma descrição do que o arquivo contém, quem o criou e em qual data.

- Antes de cada função, deve ser explicado o que ela faz, o que ela retorna e qual o comportamento das variáveis. Use como premissa que alguém consegue definir se irá ou não usar a rotina e poderá usá-la apenas lendo o comentário, sem precisar conhecer o código.



2.1 Comentários

- Se a função ficar grande, é importante explicar na criação das variáveis o que elas fazem. Comente cada grande parte do código. Por exemplo: quando o programa entra em um if e quando entra em um else.

- Não precisa comentar coisas óbvias como explicar que contador++ está incrementando o contador.



2.2 Nomes Claros às Variáveis

- Uma variável não precisa ter nome e sobrenome, mas não deve ser chamada apenas por uma letra.

- Seu nome deve ter um significado lógico, de forma que alguém apenas lendo o nome consiga imaginar o que deve ser armazenado na variável.



2.3 Evite mapeamento mental

- Às vezes vemos variáveis nomeadas com uma letra só. Sem dúvida são perfeitamente aceitáveis em um loop (i é a mais comum), mas desde que o loop seja pequeno e não haja conflitos. Em outros contextos, as variáveis de uma só letra certamente serão problemáticas, pois o leitor terá que fazer mapeamento mental daquela letra para o seu real significado. Com o passar do tempo, nem o próprio autor do código lembrará qual o verdadeiro conceito daquela variável de uma letra só.



2.4 Declaração de variáveis separadas da lógica

- Ter como prática declarar todas as variáveis que um programa irá utilizar logo após o título da função. Desta forma fica muito mais simples para quem irá fazer a manutenção do código entendê-lo.



2.5 Use Tipagem Forte Logicamente

- Algumas linguagens são fracamente tipada. Ou seja, ele não checa se você está usando corretamente os tipos da linguagem. Você pode inserir um texto em uma variável numérica, por exemplo. Pode, mas não deveria.

- Tome o cuidado de usar variáveis do tipo correspondente ao seu uso.



2.6 Nomes de Classes

- Classes e Objetos devem ter nomes com substantivos como por exemplo Pessoa, Cliente, Conta.

- Evite usar verbos porque estes devem ser usados para métodos ou funções.



2.7 Princípio da Responsabilidade Única

- O princípio da responsabilidade única estabelece que uma classe ou módulo deve ter uma, e apenas uma, responsabilidade.



2.8 Nomes de Métodos

- Métodos (ou funções) devem ser nomeadas com verbos, como por exemplo realizarPagamento, apagarPagina ou salvar.

- Métodos que acessam, mudam ou predicam devem ser nomeados de acordo com o valor deles e prefixados com os verbos get, set ou is, como por exemplo getNome, isRealizadoPagamento ou setCor.



2.9 Use Comandos Claros e Usualmente Conhecidos

- A maioria das linguagens possuem mais de uma forma para resolver uma situação. Tente sempre usar a mais comum. Pode ser que a manutenção do programa seja feita por uma pessoa que não tenha muito conhecimento da linguagem e não conheça o comando utilizado.



2.10 Identação

- É algo simples e que facilita incrivelmente tanto a construção de um programa como sua manutenção.

- Usar, se possível, o próprio tab ao invés de espaços, para que seja fácil manter todas as linhas iniciando-se na mesma coluna.



2.11 Funções

- A primeira e mais importe regra é que funções devem ser pequenas. A segunda regra é que devem ser menores ainda.

- Funções pequenas são fáceis de entender e facilitam o cumprimento do princípio: "faça apenas uma coisa".

- A regra de ouro é: "Funções devem fazer uma coisa. Devem fazê-la bem. Devem fazer somente essa coisa."



2.11 Funções

- O melhor jeito de saber se a função está fazendo "mais do que uma coisa" é verificar se é possível extrair outra função de dentro dela.

- Funções devem fazer algo ou responder algo, nunca os dois. Ou a função deve alterar o estado de um objeto ou deve retornar alguma informação sobre o objeto. Fazer as duas coisas em geral leva a confusões.



2.12 Testes

- Construir um software não é somente escrever código e vê-lo funcionar, é saber que aquele código será manutenível e que outras pessoas vão alterá-lo. Por isto teste é fundamental.

- Quem desenvolve tem que ser responsável por aquilo que escreve e saber que seu sistema tem que continuar funcionando, por isto toda linha escrita deve estar testada.



2.12 Testes

- Muitas empresas veem testes como gastos maiores no projeto, o que de fato acontece, porém a qualidade do software produzido é algo significante. Quando não se produz teste automatizado, a quantidade de testes manuais são maiores e muitas vezes o custo desses testes também é maior.



2.13 Programe para os Outros e não para Você

- Lembre-se que na vida real poder ser que não seja você que irá corrigir o seu programa. Assim, deve-se sempre programar de forma simples e clara, de forma que qualquer pessoa que precise alterá-lo o faça facilmente.

- Se pensar que um programa confuso pode garantir seu emprego, provavelmente vai o perder rapidamente e muito dificilmente conseguirá recomendação para outro, dada a pouca qualidade do trabalho.



2.13 Programe para os Outros e não para Você

- Lembre-se: que você também precisará corrigir programas dos outros. Garanto que se os outros não seguirem as regras, você vai entender claramente porque elas são tão importantes.



- Para se ter um código bem enxuto e com boa qualidade não basta apenas termos convenção de nomes, classes, variáveis, entre outros. Precisamos ter um padrão para algumas situações para melhorarmos não somente a performance do código que está sendo escrito, mas também a qualidade de ordenação para que, futuros desenvolvedores, ao olharem o nosso código em uma manutenção, consigam facilmente identificar e assim trabalhar em cima do problema e não reaprender tudo o que foi feito, assim desperdiçando tempo e dinheiro.



- Na sequência serão apresentadas algumas técnicas que não são muito utilizadas no dia-a-dia dos programadores pois são pequenos detalhes que influenciam na performance e na escrita de um bom código. Essas boas práticas vão desde a ter um código elegante até como melhorá-lo.



3.1 Operadores de Curto Circuito

- Operadores que operam em curto-circuito fazem parte de algumas linguagens de programação. Esses operadores ajudam a poupar verificações desnecessárias em nosso código.

if(condicao1 && condicao2) { //… }

if(condicao1 || condicao2) { //… }



3.1 Operadores de Curto Circuito



3.2 Teste de Ordenação Lógica

- Um detalhe bastante importante que muitas vezes não se presta atenção é quando utilizamos o bloco switch. Neste caso, o ideal é sempre ordenar a lista de possibilidades da mais frequente para a menos frequente. Isso evitará que a avaliação seja feita em vários itens, tendo assim uma perda de performance, pois se o item frequente está na último posição a ser avaliada, ela deverá passar por todas as outras antes.



3.2 Teste de Ordenação Lógica



3.3 Fusão de Loops

- A fusão de loops é quando usam-se dois loops distintos para operar o mesmo conjunto de elementos e, em cada um deles, efetuar uma ação diferente. Na maioria das vezes utilizamos isso em coleções para alterar algum valor, ou algo do tipo.



3.3 Fusão de Loops



3.4 Minimizar Trabalho dentro de Loops

- Este é um dos pontos essenciais para ganharmos em performance na aplicação. Muitas vezes colocamos operações custosas dentro de loops, o que acarretará na execução desta operação o mesmo número de vezes que o loop for executado. Na maioria dos casos, esse código custoso faz sempre a mesma coisa, ou seja, é um cálculo que independe de qualquer valor proveniente do loop.



3.5 Busca de um Elemento em um Array

- Este é outro dos pontos essenciais para ganharmos em performance na aplicação. Muitas vezes colocamos procuramos um elemento dentro de um array. Ao localizarmos o elemento o correto é pararmos a busca, assim economiza-se um processamento precioso.



3.5 Busca de um Elemento em um Array



3.6 Code Caching

- Code caching significa salvar um determinado valor que é proveniente de algum cálculo mais complexo em um membro interno que, por sua vez, será exposto pela classe. Geralmente utilizamos essa técnica quando o valor é frequentemente utilizado e, se for sempre calculado, teremos uma perda de performance, já que o cálculo seria efetuado o mesmo número de vezes que a propriedade é invocada.



3.6 Code Caching



3.7 Números Mágicos

- Os números mágicos são aqueles números que temos no código que referenciam índices de arrays, campos de colunas do banco de dados, contadores, etc.. Em alguns casos, como por exemplo, para referenciar as colunas do ResultSet (consulta ao banco de dados) é sempre mais performático do que passar o nome do campo, mas isso dificulta a legibilidade do código, principalmente se precisar dar manutenção neste código mais tarde.



3.8 Atribuição de Valor com Somente Duas Possibilidades

- Para variáveis que somente poderão receber duas possibilidades de valores, baseadas em uma estrutura de condição SE, iniciar a mesma com o valor mais provável e somente alterar se a condição for verdadeira, assim elimina-se o processamento do SENÃO.



3.9 Execução de Funções Desnecessárias

- Mais um item para melhor a performance do sistema. Se a função não é necessária no momento, não a execute. Outras duas questões:

1) Se ela for necessária, será que está utilizando da forma correta?

2) Não existe uma função mais performática do que a que está utilizando?



3.9 Execução de Funções Desnecessárias



3.10 Abre e Fecha Chaves (Blocos de Comandos)

- Para a maioria das linguagens é opcional o uso do abre e fecha chaves ({ }) quando há somente uma linha de comando no bloco. O questão é que quando se insere mais uma linha elas devem ser colocadas, pois a execução do código não será a esperada. Dado isto, a sugestão é usar sempre.



3.11 CTRL+C/CTRL+V

- Nunca utilizar o CTRL+C/CTRL+V. Se precisar repetir um trecho de código, o melhor a ser feito, é criar uma função com o trecho e fazer os dois pontos chamarem a função.



- Esta solução é ótima, mas não temos tempo para isto. Faça a boa.

- A culpa é do Hardware.

- É só reiniciar que funciona.

- É fácil! Não vejo dificuldade em fazer isto. É só um if.

- Tive que arrumar no banco de dados. Se o problema voltar me avisa.



- O código está certo, deve ser problema com a massa de dados.

- Deixa estourar a bomba. Aí se vierem atrás de mim eu vejo o que faço.

- Eu fiz somente o que foi especificado.

- Quando eu cheguei já estava assim.

- É só um botão. O que pode dar errado?


5 Conclusões

- Economia de hardware;

- Facilidade na manutenção e inclusão de novas funcionalidades;

- Respostas mais rápidas (para o cliente);

- Principal: é de extrema importância colocar o que foi apresentado em prática, pois sem isto os benefícios citados não acontecem.


Perguntas


Referências

AÉCE, I. Boas Práticas de Programação. Disponível em: http://www.linhadecodigo.com.br/artigo/1310/boas-praticas-de-programacao.aspx. Acesso em 15 mar 2016.

BRUNO, W. Boas Práticas de Programação - Filosofias de Desenvolvimento. Disponível em: http://wbruno.com.br/php/boas-praticas-de-programacao-filosofias-de-desenvolvimento. Acesso em 01 mar 2016.

FILHO, J. O. M. Programação Orientada à Gambiarra. Disponível em: http://pt.slideshare.net/josenaldomatos/programao-orientada-a-gambiarra-30097904. Acesso em 28 mar 2016.

MARZAGÃO, L. F. Boas Práticas em Programação. Disponível em: http://dulimind.blogspot.com.br/2014/05/boas-praticas-em-programacao-parte-01.html. Acesso em 16 mar 2016.

TAVARES, L. Boas Práticas de Programação. Disponível em: http://www.devmedia.com.br/boas-praticas-de-programacao/31163. Acesso em 09 mar 2016.


Referências

UNIVERSIDADE ESTADUAL DE CAMPINAS. Linguagem e Técnicas de Programação - Boas Práticas. Disponível em: http://www.ft.unicamp.br/liag/wp/robocode_files/qualidade.pdf. Acesso em 08 mar 2016.

WIKIPEDIA. Teoria das Janelas Partidas. Disponível em: https://pt.wikipedia.org/wiki/Teoria_das_Janelas_Partidas. Acesso em 02 mar 2016.


Contato

Anderson AugustinhoAnalista de Sistemas

Professor e Instrutor Java

[email protected]


Obrigado!


qualidade no desenvolvimento de sistemas

Technology