Arquitetura: Restrições Obedecidas, Decisões Compartilhadas e Qualidade Garantida!

Já trabalhou em um projeto de software, seja ele back-end, front-end ou aplicativo móvel e ouviu a frase "Porque diabos fizeram deste jeito? Há uma maneira tão óbvia e melhor que é..."?

O problema é a falta de contexto. Se analisarmos simplesmente a estrutura de projeto, produto ou trecho de código-fonte, nenhum destes aspectos isoladamente farão sentido para a decisão do arquétipo ou caminho escolhido.

Como deixar evidente quais são as restrições existentes e que sejam obedecidas? Como deixar decisões claras e compartilhadas? Como garantir aspectos de qualidade que foram definidos?

A Arquitetura

Depois de muito tempo tentando explicar o que é arquitetura de software algumas mentes brilhantes simplificaram drasticamente o conceito. Ralph Johnson cita que arquitetura "são as coisas importantes (o que quer que sejam)". No livro Building Evolutionary Architectures arquitetura é definida como "são as partes difíceis de mudar depois".

Se arquitetura é algo "difícil de mudar depois" onde deixamos evidente quais eram os atributos qualitativos desejados, restrições e limitações (constraints)? As constraints podem ser sistema operacional, plataforma de desenvolvimento, linguagem de programação, tipo de armazenamento de dado.

Por exemplo, porque o projeto foi desenvolvido para uma estrutura on-premise no sistema operacional Windows ao invés de utilizar uma estratégia de conteinerização ou cloud computing com Serverless?

Sempre há limitações! A limitação pode ser a stack tecnológica disponível no cliente, falta de budget ou ainda contratual!

Quais são as suas limitações no ecossistema do seu produto? Como e onde você as documentou? Porque decidiu o arquétipo atual?

Como trazer as pessoas para o contexto correto?

As restrições devem ser deixadas explícitas, e toda e qualquer criação e/ou alteração no produto ou projeto deve respeitar estas restrições. Em outras palavras, se há uma restrição que toda estrutura de dados e armazenamento deve ser feito por uma base de dados relacional, em uma planning não pode haver definição que será feito em uma base de dados NoSQL, por exemplo.

Toda decisão tomada deve ir para um histórico de decisões onde pessoas que tomaram a decisão são citadas e a decisão devidamente documentada. Um exemplo (e que muitos já vivenciaram) pode ser:

Decisão:  Dívida com Unit Tests
Data: 03/06/2017
Presentes: Luke Skywalker, Han Solo, Chewbacca
Por limite de tempo e volume de demandas, testes unitários NÃO serão codificados e afetará diretamente cobertura de testes. Estima-se que cobertura atual de 90% caia para 60%.

Decisão: Armazenamento de Arquivos em File System
Data: 12/01/2019
Presentes: Rey, Kylo, Poe
Cliente possui software provisionado de forma on-premise em infraestrutura própria. Foi solicitado estrutura de storage/bucket para armazenamento de arquivos, contudo foi negado. Cliente solicitou que fosse utilizado o sistema de arquivos padrão do S.O. por conter disco provisionado e estratégia de backup pronta.

Atributos qualitativos devem ser definidos com cautela, afinal para cada há um ou mais trade-offs conhecidos. A própria teorema de Brewer é um exemplo:

"É impossível que armazenamento de dados distribuído forneça simultaneamente mais de duas das três garantias seguintes: consistência, disponibilidade e partição tolerante a falhas"

Não Envie E-mail!

Se uma decisão foi tomada não documente por e-mail ou por chat em sua ferramenta colaborativa. Pessoas novas, recém contratadas ou provenientes de outras áreas e times da empresa continuarão sem este contexto, pois não estavam em cópia ou no chat em questão.

Mantenha a documentação acessível e, preferencialmente, junto ao repositório do produto. Por exemplo, no GitLab, GitHub ou Azure Repositories, pode ser feito utilizando Wiki ou Readme com estrutura markdown, que carrega todo histórico de alterações.

A Garantia

Faça com que seu time tenha um checklist em seu rito de planejamento para que restrições e atributos qualitativos sempre sejam revisitados. Não adianta planejar entrega de uma funcionalidade em um aplicativo móvel se os usuários não terão dispositivos móveis disponíveis para acesso ou restrição de acesso a rede local por celular pessoal.

Caso decisões arriscadas, relevantes ou sensíveis sejam tomadas, armazene em seu histórico de decisão!

Seu definition of ready atualmente valida que Restrições serão obedecidas e Atributos Qualitativos garantidos na construção do seu produto ou funcionalidade?