As Três Leis do TDD

 

Já enumerei as principais razões para utilização da metodologia de Desenvolvimento Orientado a Testes neste artigo (link) e também como praticar em sessões de Coding Dojo neste outro artigo (link), dessa vez quero abortar as leis do TDD (Test Driven Development), essas leis que podemos entender como regras são fáceis de entender e principalmente nos fornecem uma forma simples de validar o que estamos fazendo.

Essas regras foram definidas por Robert C. Martin (Tio Bob), principalmente no intuito de auxiliar no processo de iniciação na utilização da metodologia TDD, essas três regras são mecânicas, você deverá aplicá-las porque irá lhe forçar a escrever código de melhor qualidade e aumentará a facilidade de manutenibilidade.

Lei 1: Você não pode escrever nenhum código fonte, antes de escrever uma especificação de teste que falhe

Isso quer dizer basicamente, o principal e o óbvio para a metodologia, nenhum código pode ser criado, ou classes, ou interfaces, ou seja nada, antes que a especificação do testes seja escrita e falhe, que obviamente irá falhar porque não tem nenhum código para ser validado.

Lei 2: Você não pode escrever mais do que um teste para falhar (e não compilar é falhar)

Muitas vezes já queremos adiantar todas as possíveis soluções e cenários plausíveis para garantir que o que iremos desenvolver irá cobrir os testes e atendendo os resultados esperados, porém esses testes não são testes unitários, são especificação de testes de comportamento, ou seja, você terá que primeiro escrever uma especificação de teste, essa especificação falhará, você então irá codificar para passar no teste e só depois você poderá escrever uma nova especificação de teste para um novo comportamento, dessa forma a cada nova especificação, codificação, estará sendo criado uma pilha de testes que continuaram sendo validados sobre o que está sendo desenvolvimento com qualidade e sem quebras.

Lei 3: Você não pode escrever código fonte mais do que o suficiente para passar no teste que está falhando

Essa talvez seja a regra mais difícil de executar, porque como programador é natural durante o processo de implementação, já tentamos adiantar passos e prever condicionais, situações e comportamentos, porque dessa forma conseguimos escrever códigos que aceleram a implementação final, porém a metodologia nos obriga a dar um passo de cada vez para que possamos ter ciência e principalmente cobertura de todo o processo, com isso fica bem claro que o código fonte que devemos implementar tem que ter o propósito de fazer o teste ser passado e somente isso. Um exemplo básico para ilustrar, caso escreva um teste que precise validar a soma de dois valores (exemplo 1 e 3), sua função deve simplesmente retornar 4, isso fará o teste passar. O motivo por trás disso é forçar você a pensar e dar pequenos passos e ser muito mais produtivo do que tentar codificar em grandes etapas.

Essas três leis podem parecer simples e talvez irão criar um processo moroso inicialmente, entretanto a principal função do TDD é garantir qualidade de código gerado e principalmente cobertura de testes focadas na solução do problema. Ter implementações menores oferecem um poder de concentração maior num único ponto, o que potencializa sua capacidade de resolver o centro do atual problema, com o ponto resolvido, você passa para o próximo e assim até o final. É exatamente para isso que servem essas três leis.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

A Importância da Escalabilidade

 

Há um tempo atrás a maioria das empresas mantinha projeção de expansão programadas e limitadas, se imaginava uma estrutura final para as aplicações que sempre iria atender as necessidades por um longo tempo. Entretanto, o cenário atual possibilita cada vez o crescimento rápido e volátil de qualquer negócio, com isso se torna essencial criar soluções que se adaptem rapidamente aos novos patamares utilizando a escalabilidade para gerar estabilidade aos seus usuários.

Mas o que é escalabilidade? É basicamente a condição de uma solução de lidar com uma quantidade crescente de trabalho, minimizando o tempo de inatividade e erros, ou seja, é garantir que sempre seja possível atender a todos usuários com uma experiência de qualidade.

Existem dois tipos de escalabilidade, a mais utilizada é Dimensionamento (conhecido como horizontal), esse tipo é quando aumentamos o número de máquinas ou instâncias onde a aplicação está instalada, oferecendo através de balanceamento a distribuição de processamento de carga evitando a sobrecarga num único ponto. O outro é a Ampliação (conhecido como vertical), é quando efetuamos o aumento da capacidade computacional da máquina ou instância, para garantir que sempre haja recurso para processar as requisições. Não há uma opção ideal, é necessário a avaliação do cenário para definição de uma solução, e ainda pode ser considerada uma terceira opção que é a utilização de uma mistura entre as duas opções.

Além do fator mais importante, a disponibilidade da aplicação, o custo é outro fator que com a utilização da escalabilidade é beneficiado, isso porque através de uma estrutura altamente volátil podemos criar regras automatizadas de modificação de recursos que irão manter o ambiente do tamanho necessário para cada momento, reduzindo o investimento desnecessários, ou seja, estamos pagando pelo que está sendo consumido e não pelo achamos que será consumido.

Outro fator beneficiado também é a segurança, com a escalabilidade, a redundância e aumento de recursos de forma automática garante a disponibilidade e segurança dos dados. Falhas de hardware e gargalos que podem danificar os dados são corrigidos de forma praticamente automática.

A escalabilidade é cada vez mais um diferencial vital para qualquer solução, desde as monolíticas chegando nos micro serviços, por isso é fundamental fazer parte da concepção desde o início, porque dessa forma será possível garantir, disponibilidade, estabilidade, versatilidade, segurança e direcionamento de recursos.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Do Monólito ao Micro Serviço

 

Praticamente todas as empresas possuem aplicativos que foram construídos para solucionar seus problemas internos e esses foram, em sua maioria, construídos incorporando o máximo de funcionalidades possíveis para que atendessem o maior número possível de requisitos do negócio. Isso gerou grandes blocos, conhecido como monólitos, que precisam ser geridos do ponto de vista de manutenção, estrutura, estabilidade e principalmente evolução. Com as diversas necessidades de atualizações, essas aplicações têm se transformado cada vez mais em obstáculos do que facilitadores do processo, um exemplo,  simples implementação de uma regulamentação, como a LGPD, começou a exigir esforços gigantescos para sua concretização, isso tudo porque existe um alto grau de complexidade para essa manutenção.

E usando este ponto como partida, é que normalmente começa a jornada de transformação de uma aplicação, porque qualquer um que seja da área de tecnologia, já ouviu falar dos micro serviços, seja do seu conceito, dos benefícios, das referência de mercado ou até mesmo dos resultados de sua implementação que facilitam as adaptações às mudanças. Entretanto, essa jornada exige requisitos mínimos para garantir seu sucesso, entre eles, domínio do processos de negócios, mapa de contexto, definição de padrões, arquitetura de referência, abordagem DevOps e mais importante a observabilidade dos KPIs, logo diante de tantos requisitos, a simples incorporação dessa transformação se torna arriscada sem planejamento, e estando as empresas migrando para o modelo ágil se faz necessário algum plano antes da ação. Listamos algumas estratégias que podem guiar na obtenção dos requisitos em tempo de execução, ou seja, criar um plano de vôo em tempo de vôo.

Comece Algo Novo com o Novo

Sempre que uma aplicação monolítica necessitar de uma nova funcionalidade você deverá criar um micro serviços para atendê-la e não incorporá-la ao seu monólito, entretanto sabemos que a maioria das funcionalidades com certeza se utilizarão de informações essenciais  da aplicação, para isso devemos criar uma interface entre o micro serviço e a aplicação, também conhecida como "Glue Code", que nada mais é que um código para unificar ambos sistemas, que poderá no futuro ser trocado ou ajustado, além de oferecer uma barreira de segurança para que o micro serviço incorpore comportamentos e conceitos do legado. No diagrama abaixo exemplificamos a arquitetura sugerida.

A implementação de novas funcionalidades como micro serviços fará com que seu monólito não cresça mais e ao mesmo tempo oferecerá oportunidades de surgirem novas estruturas independente e acopláveis.

Separe as Camadas

Pensar em separadas as camadas de apresentação das de lógicas e acesso a dados oferecerá uma estratégia para encolher sua aplicação monolítica e muitas informações da situação atual. A ideia é simplesmente separar em um ou mais interface, sendo uma delas, o front-end e as demais em back-ends, preferencialmente em formato de API. Uma vez separados, o front-end irá fazer chamadas remotas ao back-end, o diagrama abaixo mostra essa transformação. 

Pode parecer puro retrabalho visto que estamos somente fazendo uma separação física, porém após essa estratégia, você terá várias API que poderão ser consumidas por outros sistemas e que ainda oferecerão estruturas isoladas que facilitarão a manutenibilidade, além de poder escalar separadamente os recursos para suas execuções.

Essas são algumas estratégias iniciais que podem oferecer o primeiro passo para iniciar essa transformação, oferecendo ao longo da sua implementação insumos e conhecimentos iniciais para contextualização do caminho que será necessário para atingir a maturidade na utilização de micro serviços. 

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br