Kenneth Freitas

 Bora conhecer alguns antipatterns de arquitetura, desenvolvimento e até gestão de projetos, que são um pouco conhecido, mas que acontecem várias vezes no dia-dia. Form de feedbacks

Bora aprender sobre arquitetura de aplicações, alguns padrões, ideias e princípios usados quando estamos arquitetando nossas aplicações. Vamos falar sobre MVC, MVP, MVVC, Multi-camadas, Hexagon, Clean Architecture e várias outras coisas. Form de feedback! 

Caching é uma prática quase que essencial para a maioria das aplicações hoje em dia. O alto consumo de informações, sistemas escalados horizontalmente e, claro, quando se usa vários serviços distintos, os benefícios do cache são claros, performance, redução dos custos de bancos e de carga nos serviços e etc. Sabendo disso, então bora analisar alguns tipos de caching e descobrir qual melhor se encaixa na sua aplicação. Single in-memory cache (IMDG/IMDB) Talvez o mais simples e mais conhecido, in-memory cache baseia-se na ideia de colocar um banco em memória (tipo o Redis) dentro de um serviço, salvando as consultas mais frequentes e evitando assim realizar um volume alto de queries no banco, o que aumenta a performance já que seu banco é poupado de algumas operações. Distributed cache O princípio é o mesmo do single in-memory cache, a diferença é que você realmente vai ter um banco apartado, onde vários serviços consomem dele antes de ir para a real fonte de dados. Por exemplo um Couchb...

Se tem uma coisa hoje que define o front-end moderno, é a componentização. Acabar com a duplicidade do código, criar páginas com recursos incríveis apenas encaixando componentes já prontos e claro ganhar velocidade na alteração do layout. Tem outros pontos positivos, mas já deu pra pegar a ideia. Mas até nesses três pontos citados, não são só flores. Um princípio que resume tudo na vida, SRP. Quando criamos componentes precisamos ficar muito atentos ao seu nível de abstração, pois aqueles pontos positivos podem virar negativos rapidinho. Faz de conta que vamos criar uma página web para um ecommerce que vem crescendo rapidamente, você escolhe suas tecnologias e começa a seguir o design. O designer criou vários componentes bonitinhos e construiu todos os elementos, páginas e etc, ótimo. Você, um cara sagaz, viu que de fato os itens foram replicados, logo você cria um componente para cada um e sai montando as páginas. Maravilhoso, job realizado, todos felizes, trabalho excelente, boa! Com...

Sempre que vamos começar um novo projeto, vem aquela velha discussão de começar pela interface, API, funcionalidade (shape up ou mais ágil) ou até pelo banco (galera mais antiga). Bem, cada uma tem suas vantagens e desvantagens já amplamente discutidas por aí. Mas e quando o seu produto é apenas uma API o que acontece? O problema com o desenvolvimento de serviços que são 100% por API para usuários finais é que geralmente fica muuuito a critério da parte técnica e isso tem alguns problemas. A API pode ficar com muitas abstrações (super simples, mas dificultando utilizações mais avançadas por parte do cliente) ou ela fica extremamente desacoplada (super complexa, com várias etapas até para coisas simples, fazendo com que o cliente precise construir muita coisa em cima) e às vezes com excesso de funcionalidades (que fogem do escopo ou que simplesmente ninguém vai usar, deixando mais trabalho para dar manutenção e podendo até abrir brechas na segurança. Ainda mais quando lançamos novas ver...

E para finalizar nosso papo sobre “Coupling, o inimigo em comum” vamos falar de coesão, claro! Coesão são as partes que devem ser contidas no mesmo módulo, ou seja, um acoplamento que faz sentido. Funcionalidades parecidas e que se complementam devem estar próximas umas das outras. Tenha em mente que sempre que separamos um módulo com coesão, estamos aumentando o acoplamento. Com isso vamos dar uma olhada nos tipos de coesão que existem: Functional Cohesion Quando todas as partes do módulo se relacionam fazendo com que o módulo tenha tudo para funcionar. Sequential Cohesion Quando dois módulos interagem de maneira que o output de um vira o input do outro. Communicational Cohesion Quando dois módulos operaram juntos para criar um output. Procedural Cohesion Quando dois módulos devem ser executados em uma ordem específica. Temporal Cohesion Quando módulos trabalham juntos de forma temporária para servir um outro módulo. Logical Cohesion Quando módulos compartilham uma lógica de operação...

Continuando nosso papo sobre o “Coupling, o inimigo em comum” , hoje chegamos em Connascence, que é uma métrica que nos permite avaliar o quão flexível está nosso código. Temos dois tipos de Connascence: Estático e Dinâmico. Static Connascence é quando temos “afferent” ou “efferent” coupling em nosso código, sendo eles: Connascence de nome (CoN): Quando temos que concordar com o nome de alguma coisa, exemplo: O nome do arquivo, da classe, função, etc. Connascence de tipo (CoT): Quanto temos que concordar com o tipo de algo, por exemplo, se uma função recebe um parâmetro do tipo inteiro, não podemos passar uma String. Connascence de significado (CoM) / Connascence de convenção (CoC): Quanto temos que concordar com um valor em particular de alguma coisa. Como por exemplo: A fim de evitar números mágicos, eu crio uma variável X que representa algo. Todos componentes que vão utilizar essa variável, vão ter que aceitar seu valor. Connascence de posição (CoP): Quando temos que seguir alg...

Continuando a série de “Coupling, o inimigo em comum” , agora que sabemos os tipos de coupling, está na hora de analisar os níveis de quanto eles estão engessando sua aplicação, começando dos mais fortes para os mais fracos. Pathological coupling A pior situação possível, é quando um componente depende de um funcionamento interno de outro componente, seja estaticamente ou temporalmente. Por exemplo, temos uma classe utilizando uma implementação concreta de outra classe ao invés de uma abstração, ou pior, parte dela, ou seja, qualquer mudança afetará diretamente essas classes. External coupling É quando seus componentes utilizam de formatos ou protocolos impostos por agentes externos. Bora pro exemplo: a velha discussão de colocar a “lógica” na controller. A partir do momento que você está fazendo isso, se você tem uma API Rest, automaticamente todos seus componentes estão limitados a aceitar apenas nesse formato. Caso algum dia alguém chegar usando gRPC ou qualquer outro protocolo/form...

Não importa o modelo arquitetural super maravilhoso que você implementou, ou quão lindo seja seu código, coupling sempre irá existir e uma hora ou outra vai te dar aquela dor de cabeça na manutenção do seu sistema. Então, bora analisar nossa estrutura para encontrar pontos de atenção o quanto antes. Um jeito (sendo o mais óbvio) para realizar essa análise, é claro, olhando o código-fonte da aplicação. Mas podemos (e devemos) nos afastar um pouco desta visão “micro”, até porque uma análise precisa no código é bem difícil de ser realizada. Ter uma visão do todo realmente faz a diferença para identificar componentes e elementos na nossa aplicação. Temos três principais alvos a serem identificados em nossa arquitetura, são eles: Static coupling, Temporal coupling e Component size. Static Coupling Em static temos duas distinções "afferent coupling”, quando vários componentes dependem de algum em específico. E “efferent coupling”, que é o contrário, quais ...

Programação funcional é um paradigma já bem conhecido e que nos últimos anos vem ganhando ainda mais força, principalmente depois do aparecimento do React e de algumas grandes empresas mostrando suas arquiteturas com linguagens 100% funcionais. Os “pilares” desse paradigma já são bem manjados, como: funções puras (uma função que sempre retornará o mesmo resultado, dado os mesmos argumentos, e claro, sem efeitos colaterais), imutabilidade, umas coisinhas mais avançadas como higher-order functions (uma função que recebe uma função como argumento ou também retorna uma função) e currying (que é uma função que recebe uma função e pode ir nessa várias vezes). Geralmente vemos a galera que trabalha com linguagens multiparadigma seguem apenas essas ideias, mas no mundo funcional podemos ir mais a fundo com o uso de Functors (basicamente uma função pega algum valor dentro de um contexto, aplica uma função, e devolve em um novo contexto), Applicatives (além de envolver um valor dentro de um novo...