Diferença entre Arquitetura e Design de Software

Muitos desenvolvedores normalmente acabam misturando os elementos entre arquitetura e design. Vou tentar exemplificar as diferenças entre design de software e arquitetura de software e tentarei mostrar a importância para um desenvolvedor conhecer um pouco sobre arquitetura de software e muito design de software.

Definição de arquitetura de software

Arquitetura de software é o processo de conversão de características de software como flexibilidade, escalabilidade, viabilidade, reutilização e segurança em uma solução estruturada que atenda às expectativas técnicas e de negócios. Segue alguns exemplos de padrão de arquitetura utilizados atualmente no mercado.

Arquitetura sem servidor

Arquitetura sem servidor é normalmente dividida em duas categorias principais. O primeiro é "Back-end como serviço (BaaS)" e o segundo é "Funções como serviço (FaaS)". A arquitetura sem servidor ajudará você a economizar muito tempo cuidando e corrigindo erros de tarefas regulares de implantação e servidores.

Arquitetura orientada a eventos

A idéia principal é desacoplar as partes do sistema e cada parte será acionada quando um evento interessante de outra parte for acionado. A característica mais importante neste padrão é gerador do evento não conheço quais são os ouvintes que estão ouvindo seu evento,  a idéia principal é dissociar as partes do sistema.

Arquitetura de microsserviços

A arquitetura de microsserviços se tornou a arquitetura mais popular nos últimos anos. Depende do desenvolvimento de serviços modulares pequenos e independentes, nos quais cada serviço resolve um problema específico ou executa uma tarefa exclusiva e esses módulos se comunicam por meio de uma API bem definida para atender à meta de negócios. 

Definição de design de software

O design do software é responsável pelo design do nível de código, como o que cada módulo está fazendo, o escopo das classes e os objetivos das funções, etc. Para um desenvolvedor é importante saber qual é o princípio do SOLID (mais informações em https://www.marcelogoberto.com.br/2020/04/principios-do-solid-que-todo.html) e como um padrão de design deve resolver problemas regulares. Aqui também temos alguns exemplos de padrões de design.

Factory Pattern

É o padrão de design mais usado no mundo OOP, permite às classes delegar para subclasses decidirem, isso é feito através da criação de objetos que chamam o método fábrica especificado numa interface e implementado por um classe filha ou implementado numa classe abstrata e opcionalmente sobrescrito por classes derivadas 

Design Patterns

O padrão é bem simples, vamos pensar o que acontece na vida real... Utilizamos nas nossas construções civis um padrão de tomadas e plugues, um belo dia saiu o padrão brasileiro de tomadas e plugues, quando você compra um aparelho que atende a essa norma logo pensa, vou ter que comprar um adaptador para adaptar esse plugue a tomada que está em casa, pois são padrões (modelos) diferentes.

Conclusão

Uma simples analogia exemplifica muito bem a principal diferença entre arquitetura e design de software, sendo a solução um corpo humano, a arquitetura é responsável pela composição corpórea (esqueleto, disposição do órgãos, vasos sanguíneos) e o design de software será responsável por garantir funcionamento de cada órgão. Em linguagem técnica, arquitetura é alto nível e design é nível de código.

Os arquitetos de software devem ter um bom conhecimento sobre as soluções existentes que os ajudam a tomar decisões corretas na fase de planejamento e um desenvolvedor de software deve saber mais sobre design de software e bastante sobre arquitetura de software para facilitar a comunicação interna dentro da equipe.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Estágios de um Desenvolvedor

Todo programador tem a oportunidade de escolher em que estágio sua carreira vai estar, para isso existem alguns comportamentos que podem alavancar ou prejudicar.

BONS HÁBITOS

MAUS HÁBITOS

Aprenda sempre algo novo Todo conhecimento adquirido pode ajudá-lo num próximo problema e Nomear métodos e variáveis corretamente O nome da variável e do método deve descrever perfeitamente o que esse código faz . Formatar o código Recuo é mágico! Você pode revelar toda a estrutura do código e editá-lo com uma compreensão clara de como ela funcionará. Planeje seu código Portanto, em vez de resolver problemas e programar em paralelo, é muito mais fácil descobrir o procedimento primeiro e depois escrever uma solução. Faça controle de versão Haverá momentos em que você cometerá um grande erro de programação e desejará voltar para uma versão anterior de um código. Concentre-se em uma linguagem por vez Escolha um e mantenha-o até dominá-lo, depois passe para o próximo. Ponha lógica por meio de comentários Escrevendo os comentários com lógicas, além de facilitar a implementação do código também ajudará na manutentabilidade. Seja proativo Você precisa se concentrar nas coisas que estão sob sua influência e que você possa oferecer ajuda. Comece com o fim no inicio Programadores eficazes geralmente têm objetivos muito convincentes em mente sobre seu futuro. Ofereça Vantagem ao Próximo Quer você seja ou não o único desenvolvedor trabalhando em um projeto, você não deve deixar seu ego fazer com que você pense apenas em si mesmo. Pratique Sinergia Não há dúvida de que grandes projetos são desenvolvidos por muitas pessoas que trabalham em equipe, logo equipes são mais importante que indivíduos.

Agir como se você tivesse todas as respostas Ninguém precisa e nem sabe todas as respostas e tudo bem. Estar na defensiva sempre que alguém critica seu código Esteja aberto a ter uma conversa aberta e direta sobre o seu código e como ele pode ser aprimorado. Desistir antes de tentar para valer Muitos programadores chegam tão perto de uma solução, apenas para desistir logo antes de resolverem o problema. Culpar os outros O desenvolvedor mais valioso é aquele que assume a propriedade e a responsabilidade pelo código que escreve. Ignorar  opiniões de outros desenvolvedores Uma das melhores maneiras de aprender e crescer como desenvolvedor é parear conhecimento com outros desenvolvedores. Super engenharia de problemas simples Não crie soluções confusas para problemas fáceis. Usar uma ferramenta errada Pare de tomar decisões com base em "está na moda ", esteja aberto para usar diferentes tecnologias, idiomas e estruturas. Evitando mensagens de erro. Erros de código ocorrem com frequência e eles também geralmente incluem informações muito valiosas sobre o que deu errado, por que aconteceu e quais linhas de acionamento dos problemas. Recusando-se a aprender com os erros Isso é contraproducente, recusar-se a aprender com seus erros fará com que você os repita. Resolver algo difícil e não documentá-lo Depois de passar horas decifrando o código por conta própria, é seu dever documentar para ajudar a próxima pessoa que encontrar o problema. Não gastar energia em revisões de código A equipe de desenvolvimento está unida e é responsabilidade de todos os membros da equipe garantir que o código que todos os outros membros estejam contribuindo cumpra os altos padrões da equipe.

Essa são alguns hábitos que podem nós levar a um dos extremos dos dois estágios de programador, o ideal é que tenham sempre em mente que estar no centro dessa escala com certeza irá nos tornar um profissional altamente eficiente e eficaz.

Marcelo Goberto de Azevedo
Arquiteto na GFT Brasil
//marcelogoberto.com.br

Dicas para melhorar o entendimento das SQL Querys

Consultas em SQL são basicamente códigos no final, logo é importantíssimo termos a preocupação de oferecer um código claro e objetivo para aumentar a manutenibilidade dele por outros desenvolvedores. Comandos mal formatados e/ou com escritas confusas podem aumentar mais erros e uma falta geral de motivação para revisar seu trabalho. Para quem simplesmente escreve a consulta pode fazer sentido e até funcionar, porém é fundamental que o código esteja num melhor formato possível para aumentar sua qualidade, vamos a alguma regras que podem ajudar.

Seja consistente e corente com a formatação

SELECT primeiroNome, count(*) from
Usuários WHERE ultimo_nome = 'silva' Group by primeiroNome

Vamos analisar alguns pontos:

• Veja que algumas partes estão em maiúsculas e outras não, procure manter um padrão único, por exemplo todas as palavras reservadas.
• É confuso identificar o que é coluna ou o que é comando
• A coluna do SELECT está em "camelCase", a usada no WHERE está "snake_case" e o nome da tabela em "PascalCase", crie um padrão geral, se começou errado, conserte.
• A utilização de caracter especial em definição de nomes, como na tabela Usuários

Veja um exemplo como deveria ser:

SELECT primeiro_nome, COUNT(*) from
usuarios WHERE ultimo_nome = 'silva' GROUP BY by primeiro_nome 

Use e Abuse da Identação 

SELECT g.id, COUNT(u.id) FROM usuarios u JOIN gruopos g on u.grupo_chave
= g.chave WHERE u.nome = 'Marcelo' AND  u.sobrenome
= 'Silva'  GROUP BY g.chave ORDER BY COUNT(u.chave) desc 

Para uma consulta pequena pode não fazer diferença para leitura quando tudo está sem um padrão de separação, agora imagine aquelas longas procedures com todos os comandos encavalados, não é mesmo?

Veja se o resultado fica melhor para o entendimento: 

SELECT 
	  g.id
	, COUNT(u.id) 
FROM usuarios u 
	JOIN gruopos g on u.grupo_chave = g.chave 
WHERE 
	    u.nome = 'Marcelo' 
	AND u.sobrenome = 'Silva'
GROUP BY 
	g.chave 
ORDER BY 
	COUNT(u.chave) desc

Dica: A utilização da virgula (,)antes de cada campo no SELECT, ou das conjunções AND / OR no WHERE, GROUP BY, ORDER BY facilita a identificação visual onde se inicia ou termina o grupo de campo, além de fornecer uma forma agíl de comentar um campo 

Se você utilizar 2 ou 4 espaços não surti efeito considerável, o importante é só manter o padrão em toda a codificação, a simplesmente utilização dessa formatação farão seu colegas adorarem ver suas consultas quase como obras de arte. 😃

Utilize sempre "Aliases" 

SELECT
    u.chave
    , u.nome
    , t.chave
    , t.nome
    , (SELECT COUNT(*) FROM titulos where nome = t.nome)
FROM usuarios u
    JOIN titulos t on u.titulo_chave = t.chave 

O resultado dessa consulta será: 

chave	nome	chave	nome	count
1	Marcelo Goberto	4	Arquiteto	6

Novamente num cenário minimalista é possível identificar o que é cada conteúdo, agora imagine isso num longo resultado com várias colunas, por isso é fundamental que você nomeie cada coluna para que possa facilitar o entendimento.

Veja como fica o resultado da mesma consulta acima com ajustes 

SELECT
   u.chave AS usuario_chave   
   , u.nome AS usuario_nome
   , t.chave AS titulo_chave
   , t.nome AS titulo_nome
   , (SELECT COUNT(*) FROM titulos where nome = t.nome) AS qtde_titulos
FROM usuarios u
   JOIN titulos t on u.titulo_chave = t.chave

O resultado dessa consulta será 

usuario_chave	usuario_nome	titulo_chave	titulo_nome	qtde_titulos
1	Marcelo Goberto	4	Arquiteto	6

Utilize números nas clausulas GROUP BY e ORDER BY 

Neste caso essa é uma preferência pessoal que acredito que auxilia muito no organização de uma consulta, veja um exemplo com essa aplicação 

SELECT
   nome
    , sobrenome
    , COUNT(*) AS total
FROM usuarios
GROUP BY 1, 2
ORDER BY 3 desc 

Algumas vantagens na adoção desse formato são:

• Economia de linhas: a utilização de muitas colunas em GROUP ou ORDER não aumentará sua consulta, pois todos estarão enfileiradas
• Manutenção: Se desejar trocar o agrupamento ou a ordenação, basta trocar as colunas de lugar dentro da clausula SELECT

Esses foram alguns pontos que sempre considero na hora de escrever uma consulta, não existe um melhor padrão ou formato único para SQL, mas com certeza existe o desafio que procurar fazer um ótimo trabalho que possa ter sua manutenção facilitada para os próximos e quem sabe para nós mesmo, porque se todos tivermos um consenso que garantir sempre um excelente padrão de código, todos se sairão ganhando.

Marcelo Goberto de Azevedo

Arquiteto na GFT Brasil

//marcelogoberto.com.br