Qualidade no desenvolvimento de sistemas

Qualidade no
Desenvolvimento de
Sistemas
Melhores Práticas de
Programação
Anderson 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.

Possibilidades

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 Augustinho
Analista de Sistemas
Professor e Instrutor Java
andersonaug@celepar.pr.gov.br

Obrigado!

Qualidade no desenvolvimento de sistemas

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Qualidade no desenvolvimento de sistemas

Semelhante a Qualidade no desenvolvimento de sistemas (20)

Mais de Joao Galdino Mello de Souza

Mais de Joao Galdino Mello de Souza (20)

Último

Último (8)

Qualidade no desenvolvimento de sistemas