Criando Sistemas Manuteníveis

Criando Sistemas Manuteníveis # 4

Postado em Atualizado em

man-drawing-an-electrical-diagram-chamadaEscreva um código somente uma vez

Escreva um pedaço de código somente uma única vez, fazendo com que todas as outras partes que precise usar, reuse aquele código. Nunca copie e cole ou duplique um pedaço de código em outro lugar, mesmo que contenha alguma mínima variação. Caso aconteça situações de variações, faça alguma coisa para reusar o mesmo código: passando parâmetros, usando polimorfismo, programação dinâmica “duck type” e etc. Qualquer coisa, menos duplicação de código! Essa regra simples ira fazer toda a diferença depois que a solução virar um “monstro”. É exatamente essa prática que determinara depois se é você que ira controlar o software ou será ele que ira controlar você! Gostaria de aprender práticas de arquitetura de software? Veja nosso curso AQT M1 – Arquitetura de Software com Java.

Este post faz parte de uma serie de posts, veja o inicial.

“O teu amor é melhor do que a própria vida, e por isso eu te louvarei.” Salmos 63:3

Criando Sistemas Manuteníveis # 3

Postado em

man-drawing-an-electrical-diagram-chamada2 – Escreva unidades de código simples

Quanto mais caminhos alternativos a execução de um método tem, mais difícil será para raciocinar sobre eles. E quando um código é difícil de entender, mal-entendidos ocorrem e mal-entendidos leva a erros, erros levam a bugs. Por isso, não escreva métodos que contenham variações de execuções em caminhos de if/else acima de 4. Isto não só irá tornar os métodos mais fáceis de entender, mas também irá torná-los mais fáceis de testar

Este post faz parte de uma serie de posts, veja o inicial.

“Estou certo de que o SENHOR está sempre comigo; ele está ao meu lado direito, e nada pode me abalar.” Salmos 16:8

Criando Sistemas Manuteníveis # 2

Postado em Atualizado em

man-drawing-an-electrical-diagram-chamadaOrientações de Unidade

São práticas aplicadas em nível unitário, de baixo nível, em classes e métodos.

1 – Escreva unidades de código pequenas

A primeira diretriz indica que os métodos de uma classe devem ser curtos, normalmente não mais de 15 linhas de código. Isto não só melhora a legibilidade, menor número de linhas de código são mais fáceis de entender, mas também reduz a probabilidade de efeitos laterais ocultos. Além de tudo isso, um método curto terá menos variações, o que significa que será mais fácil para testar. Diferentes equipes podem usar critérios diferentes quando decidir o que constitui uma linha de código. Neste tópico, nós usamos o seguinte:

  • A assinatura e o colchete de fechamento do método não contam. Isto porque estas são linhas não podem ser removidos e, portanto, não têm qualquer influência na direção medir a complexidade do método.
  • As linhas em branco dentro do método contam. Isto porque, embora as linhas em branco não têm quaisquer instruções, programadores tendem a adicioná-los para separar grupos de linhas que executam tarefas intimamente relacionados, o que significa que ajudar a indicar a complexidade do método.
  • Se uma instrução é tão longa que precisa ser dividido em duas ou mais linhas, contamos cada uma dessas linhas de forma independente. Isto porque consideramos tais instruções para representar a complexidade extra.

Para os interessados em realmente se aprofundar nesse assunto, veja nosso curso ead AQT M1 – Introdução a Arquitetura de Software com Java  que cobre exatamente estas questões. Este post faz parte de uma serie de posts, veja o inicial.

“Que o amor de vocês não seja fingido. Odeiem o mal e sigam o que é bom.” Romanos 12:9-10

Criando Sistemas Manuteníveis # 1

Postado em Atualizado em

lrgLevou algum tempo, mas as empresas finalmente perceberam que, para um projeto ter sucesso, o foco tem de ser colocado no longo prazo. Ou seja, o importante no desenvolvimento do software não é na velocidade que se entrega e sim na qualidade estrutural da solução.

Manutenibilidade é a questão principal de tudo, e para que isso tenha um custo razoável, é necessário que seja cuidada desde o primeiro dia de projeto.

Depois de muitos anos de fracassos, a indústria de desenvolvimento de software vem gradualmente entendendo o que faz projetos ter sucesso. Práticas de projetos começaram a aparecer, por vezes, misturados com desinformação e alguns folclores técnicos, mas por tentativa e erro, as equipes ao redor do mundo começaram a separar o “joio do trigo”.

Este livro apresenta um estudo que mostra a maneira na qual projetos fazem manutenção de sistemas, identificando a diferença entre o sucesso e o fracasso. Depois de analisar casos de negócios em anos, este livro sugere dez orientações que, se seguido corretamente, pode fazer a diferença entre sucesso ou fracasso dos projetos. Estas orientações foram derivadas da análise de centenas de sistemas do mundo real, que fizeram seus projetos serem bem-sucedidos em seus ciclos de manutenção.

A partir de hoje, eu postarei gradualmente um resumo de cada uma dessas práticas de forma a usar o material como consulta rápida. Para os interessados em realmente se aprofundar nesse assunto, veja nosso curso ead AQT M1 – Introdução a Arquitetura de Software com Java  que cobre exatamente o assunto.

“Portanto, sejam humildes debaixo da poderosa mão de Deus para que ele os honre no tempo certo.” 1 Pedro 5:6