Criando Sistemas Manuteníveis # 7

6 – Acople os componentes da arquitetura de forma fraca

Primeiro, desenhe um diagrama com todos os componentes do sistema e conecte-os para representar suas dependências. Com isso tipo de diagrama, podemos olhar para os componentes que acumulam muitas dependências recebidas. Veja quais são os componentes que possuem maior dependência ou dependências múltiplas. Se existir, quebre esse componente “gordo” em outros menores, reduzindo o acoplamento, riscos e os impactos de manutenção.

Segundo, não exponha classes desnecessárias para fora de um componente no qual o outro o componente cliente não precisa saber de sua existência. Use sempre contrato por interfaces, classes protegidas ou privadas. Se lembre que a partir do Java 9, poderá ser usado o novo conceito de encapsulamento de módulos para expor somente o foi classes de contratos como parte de um componente Java JAR.

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

“Não façam nada por interesse pessoal ou por desejos tolos de receber elogios; mas sejam humildes e considerem os outros superiores a vocês mesmos.” Filipenses 2:3

Anúncios

Criando Sistemas Manuteníveis # 6

Orientações Arquiteturais

São as práticas aplicadas em nível arquitetural da solução, em módulos, componentes e frameworks.

5 – Separe as preocupações em módulos

Separe as responsabilidades entre as classes adequadamente seguindo o princípio básico da “responsabilidade única”, uma vez que afetara diretamente a coesão e acoplamento dos módulos da solução. Algumas heurísticas que podem ajudar:

  • O tamanho da classe além de 100 linhas parece suspeito para um único princípio.
  • Quantidade de métodos públicos versus métodos privados. Métodos privados em excesso podem indicar complexidades que pertencem a outro lugar.

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

Gostaria de aprender a como criar e separar uma solução em módulos com Java? Veja nosso curso AQT M1 – Introdução a Arquitetura de Software com Java.

“Porém, se vivemos na luz, como Deus está na luz, então estamos unidos uns com os outros, e o sangue de Jesus, o seu Filho, nos limpa de todo pecado.”1 João 1:726

Criando Sistemas Manuteníveis # 5

man-drawing-an-electrical-diagram-chamadaMantenha as interfaces das unidades simples

A maneira de manter as interfaces simples é detectar blocos de dados aglomerados, mantendo-as assinaturas método a um máximo de quatro parâmetros. A maneira de aplicar esta orientação é através do agrupamento de parâmetros em novas nova classe usadas como parâmetros, ao invés de passar como parâmetros individuais. 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.

“Ela terá um menino, e você porá nele o nome de Jesus , pois ele salvará o seu povo dos pecados deles.” Mateus 1:21

Criando Sistemas Manuteníveis # 4

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

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

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

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