Reduzir a complexidade acidental sem fechar caminhos futuros

O software precisa de espaço para mudar, mas prepará-lo para todas as mudanças imagináveis pode tornar o produto atual mais difícil de compreender. Camadas, interruptores, abstrações e pontos de extensão adicionais podem parecer flexibilidade, ao mesmo tempo que aumentam discretamente o número de decisões necessárias para o trabalho habitual.

A distinção útil não é entre software simples e software sofisticado. É entre a complexidade que serve um requisito atual do produto e a complexidade criada por pressupostos sobre um futuro incerto. Uma equipa disciplinada pode preservar vias de crescimento credíveis sem implementar antecipadamente todos os destinos possíveis.

Separar a complexidade do produto da complexidade acidental

A complexidade do produto resulta do problema que o software escolheu tratar. A complexidade acidental é uma dificuldade adicional introduzida pela forma como esse problema é representado, dividido ou implementado. A distinção depende do contexto. Um modelo de permissões pode ser essencial para um produto e constituir uma estrutura desnecessária para outro.

Ao rever uma conceção, é necessário associar cada elemento móvel a um requisito atual, a uma restrição de implementação verificada ou a uma medida deliberada de fiabilidade. Tudo o que não tenha essa ligação merece outra pergunta. Pode ainda ser justificável, mas o respetivo custo não deve desaparecer por detrás de rótulos abrangentes como escalabilidade, flexibilidade ou preparação para o futuro.

• Identificar o requisito atual que cada abstração suporta.
• Distinguir as restrições verificadas dos pressupostos sobre necessidades posteriores.
• Registar o que se torna mais difícil quando é introduzida outra camada.
• Remover opções cujo único objetivo seja manter abertas possibilidades não especificadas.

Preservar caminhos em vez de construir destinos

Criar espaço para o crescimento não exige o desenvolvimento antecipado de funcionalidades futuras. Pode significar manter as decisões atuais compreensíveis e substituíveis. Uma fronteira interna restrita, um significado documentado dos dados ou uma regra clara de responsabilidade podem preservar um caminho sem criar um quadro geral de que o produto ainda não necessita.

Esta abordagem exige um próximo passo credível, em vez de uma arquitetura completa a longo prazo. Por exemplo, um produto pode manter um único processo de notificações num só módulo, separando simultaneamente as respetivas entradas dos detalhes específicos da entrega. Essa fronteira deixa um local para adaptação posterior, mas não exige agora vários sistemas de entrega, ecrãs de configuração ou regras de encaminhamento.

Utilizar deliberadamente fronteiras e pontos de controlo

Uma fronteira é um ponto definido onde uma parte do software interage com outra. Boas fronteiras podem limitar a distância percorrida por uma mudança. Fronteiras mal escolhidas podem dispersar decisões relacionadas por ficheiros, serviços ou definições. Por conseguinte, a questão de conceção não é saber se uma maior modularidade é melhor, mas quais separações correspondem a responsabilidades significativas do produto.

Os pontos de controlo tornam essas fronteiras visíveis durante o desenvolvimento. Um ponto de controlo pode ser uma revisão de uma transformação de dados, um passo de verificação antes de alterações de estado ou uma decisão documentada sobre o tratamento de falhas. Cada ponto de controlo deve responder a uma pergunta específica. Adicionar pontos de controlo sem um objetivo claro cria formalidade, em vez de controlo.

1. Mapear o menor fluxo de trabalho que conclui a tarefa atual do produto.
2. Assinalar onde as informações mudam de significado, responsabilidade ou estado.
3. Adicionar uma fronteira apenas quando uma mudança independente for plausível e identificável.
4. Colocar um ponto de controlo onde, de outro modo, um erro atravessaria essa fronteira sem ser detetado.
5. Rever o mapa quando um requisito real desafiar a estrutura atual.

Preferir decisões reversíveis quando a incerteza for elevada

Uma decisão reversível pode ser alterada sem reconstruir partes não relacionadas do produto. A reversibilidade não significa que todos os componentes tenham de ser permutáveis. Significa que as escolhas incertas recebem um isolamento proporcional, enquanto as escolhas estáveis e bem compreendidas podem permanecer diretas. Isto impede que a incerteza molde toda a arquitetura.

O custo da reversão também deve ser concreto. Substituir uma pequena regra interna pode ser menos dispendioso do que manter um motor de regras configurável. Em contrapartida, uma representação de dados que se estenda por muitas funcionalidades pode justificar uma camada explícita de tradução. A equipa deve comparar a provável superfície da mudança com o encargo contínuo da proteção proposta.

• Manter as regras incertas junto de um único responsável claramente identificado.
• Evitar expor representações internas de forma mais ampla do que o produto exige.
• Isolar condições externas de implementação apenas depois de verificar a fronteira relevante.
• Preferir planos de migração ao suporte permanente de todas as formas históricas.
• Documentar por que motivo uma escolha difícil de reverter é aceitável agora.

Avaliar o crescimento através de estados de fiabilidade

O planeamento do crescimento torna-se mais útil quando é expresso como estados que o produto poderá ter de tratar. Um estado é uma condição significativa, como dados incompletos, processamento interrompido ou um pedido que ainda não pode avançar. A equipa pode mapear qual componente é responsável por cada estado, como deve funcionar a recuperação e quais condições permanecem intencionalmente sem suporte.

Este mapa deve permanecer associado a cenários credíveis. Não exige o tratamento de todas as falhas teóricas. O respetivo objetivo é revelar onde uma expansão encontraria responsabilidades pouco claras, acoplamento oculto ou decisões de recuperação em falta. Um estado não resolvido pode permanecer visível sem impor uma solução imediata para toda a plataforma.

1. Dar um nome à operação central que deve permanecer compreensível.
2. Enumerar os estados envolventes que os requisitos atuais tornam relevantes.
3. Atribuir um responsável pela deteção e pelo tratamento de cada estado.
4. Assinalar explicitamente os estados sem suporte, em vez de os encobrir com um comportamento genérico.
5. Adicionar estrutura apenas quando o mapa revelar uma responsabilidade repetida.

Rever a complexidade como um orçamento contínuo

A complexidade é mais fácil de gerir quando é revista como um custo contínuo do produto, em vez de uma decisão de arquitetura tomada uma única vez. Uma nova estrutura deve compensar o respetivo custo através de um requisito atual, de uma restrição verificada, de uma responsabilidade mais clara ou de uma necessidade específica de fiabilidade. Quando essa justificação desaparece, a simplificação passa a ser manutenção legítima, em vez de uma limpeza cosmética.

Uma revisão prática pode utilizar quatro perguntas: Que necessidade existe agora, que fronteira a contém, até que ponto a decisão é reversível e que estados exigem tratamento explícito? Em conjunto, estas perguntas preservam vias úteis de crescimento, ao mesmo tempo que resistem a mecanismos especulativos. O objetivo não é obter o mínimo de código a qualquer custo, mas criar um produto cuja próxima mudança possa começar a partir de uma estrutura que a equipa ainda consiga explicar.