Conter a complexidade do software com decisões claras

Um software útil pode começar com um propósito limitado e, ainda assim, precisar de espaço para crescer. O desafio não consiste em prever todas as funcionalidades futuras. Consiste em tornar as decisões atuais suficientemente claras para que alterações posteriores não exijam o esclarecimento de pressupostos dispersos por ecrãs, armazenamento, fluxos de trabalho e integrações.

Isto exige simplicidade seletiva, em vez de minimalismo a qualquer custo. Uma equipa pode aceitar a complexidade que representa um requisito real do produto, resistindo simultaneamente à complexidade criada por flexibilidade especulativa, regras duplicadas ou responsabilidades pouco claras. O modelo seguinte ajuda a distinguir essas categorias e a decidir onde uma estrutura adicional compensa o seu custo contínuo. Também mantém a revisão centrada em decisões identificáveis, em vez de preferências gerais sobre se um sistema parece simples.

Separar a complexidade do produto do esforço de implementação

A complexidade acidental é o trabalho criado pela forma como o software é concebido, e não pelo problema que resolve. Um produto pode realmente exigir vários estados de conta, opções de permissões ou percursos de recuperação. Estas são condições do produto. Em contrapartida, repetir a mesma regra em vários componentes é uma escolha de implementação que pode tornar essas condições mais difíceis de compreender e alterar.

Classifique cada fonte de complexidade antes de tentar eliminá-la. Alguma complexidade representa uma decisão visível para o utilizador, alguma protege os dados ou a fiabilidade e outra apenas preserva uma opção imaginada. Se a razão não puder ser expressa concretamente, considere a conceção uma candidata à simplificação, em vez de uma base permanente. Registe a razão junto da decisão relevante, para que uma revisão posterior possa distinguir uma estrutura deliberada de resíduos que já não servem o produto.

• Mantenha as regras que expressem um requisito confirmado do produto.
• Isole as condições das plataformas que ainda precisam de ser verificadas.
• Elimine a flexibilidade que não tenha um cenário concreto.
• Consolide as decisões duplicadas sob um único responsável claramente identificado.

Conceber em torno de decisões, não de futuros imaginados

Neste contexto, a arquitetura de software refere-se à organização dos componentes e às responsabilidades entre eles. A arquitetura deve apoiar decisões que o produto consiga identificar, e não todas as direções que poderia teoricamente seguir. Uma pergunta útil para o planeamento é: que alteração futura se tornaria difícil porque a implementação atual pressupõe apenas uma possibilidade?

Responda a essa pergunta com um pequeno conjunto de cenários concretos. Um método de início de sessão adicional e hipotético pode justificar a separação entre as regras de identidade e a disposição do ecrã. A possibilidade vaga de o produto se tornar uma plataforma abrangente não justifica, por si só, camadas de infraestrutura genérica. Preserve pontos de separação específicos onde possa ocorrer uma alteração identificada, sem transformar todos os pormenores num sistema configurável. Cada ponto de separação deve corresponder a um pressuposto que possa ser descrito, testado e reconsiderado de forma independente.

1. Descreva o requisito atual em linguagem simples.
2. Identifique uma alteração plausível que o ponha em causa.
3. Determine o limite mais pequeno que contenha o pressuposto.
4. Adie a flexibilidade adicional até surgir outro cenário concreto.

Dar a cada limite um propósito claro

Neste modelo, um módulo é uma parte do sistema com uma responsabilidade definida. Os módulos úteis agrupam decisões relacionadas e expõem apenas aquilo de que as partes adjacentes necessitam. Um módulo fraco pode dividir ficheiros sem separar responsabilidades. Antes de criar um limite, indique aquilo que este protege, aquilo por que é responsável e os tipos de alteração que devem permanecer no seu interior.

Uma abstração é uma interface simplificada destinada a ocultar os pormenores subjacentes. Considere adicionar uma abstração quando vários casos partilharem um conceito estável ou quando uma condição de implementação exigir uma verificação isolada. Se os componentes adjacentes ainda precisarem de compreender os pormenores ocultos, o limite poderá ser prematuro ou estar organizado em torno da responsabilidade errada. Um limite deve reduzir o número de locais que têm de interpretar uma decisão, e não introduzir outro vocabulário para o mesmo trabalho.

• Mantenha as regras do produto separadas da apresentação no ecrã.
• Coloque as integrações externas atrás de interfaces restritas cujos pressupostos possam ser verificados.
• Atribua aos dados partilhados um único responsável claramente identificado.
• Evite camadas genéricas que se limitem a mudar o nome de operações existentes.

Tornar visíveis as alterações de estado importantes

Um estado é a condição do produto relevante para um fluxo de trabalho num determinado momento, como pendente, disponível ou falhado. Uma transição de estado é a passagem de uma condição para outra. Modelar explicitamente estas transições proporciona à equipa um único local para decidir o significado de cada condição, em vez de permitir que componentes separados forneçam interpretações potencialmente contraditórias.

Mapeie o fluxo de trabalho central juntamente com a interrupção, a nova tentativa, o cancelamento e a conclusão parcial. O mapa não precisa de prever todas as falhas. Deve identificar onde o sistema regista o progresso, que operações se destinam a ser repetidas em segurança e que estado ainda exige uma decisão relativa ao produto. Quaisquer condições impostas pelas plataformas de destino ou por sistemas externos devem ser verificadas durante a implementação, em vez de serem incorporadas como pressupostos. As condições desconhecidas podem permanecer visíveis no mapa sem forçar uma resposta técnica antecipada.

Testar o crescimento através de exercícios de alteração

A preparação para o futuro pode ser analisada através de uma alteração proposta, em vez de através de designações gerais como escalável ou flexível. Escolha uma funcionalidade hipotética, identifique os componentes que esta afetaria e observe se o trabalho segue as responsabilidades existentes. Se uma pequena alteração ao produto atravessasse muitas áreas não relacionadas, reconsidere onde deve residir a decisão subjacente antes de adicionar outra camada.

Inclua a evolução dos dados no exercício. Neste contexto, uma migração de dados significa uma alteração controlada de uma forma ou de um significado dos dados armazenados para outro. Questione como seriam interpretados os registos existentes, se uma alteração interrompida deveria ser retomada e que pressupostos anteriores devem continuar legíveis. Isto pode revelar restrições específicas ao crescimento sem exigir infraestrutura para possibilidades indefinidas. O objetivo não é prever o produto completo, mas verificar se as responsabilidades atuais continuam compreensíveis perante uma alteração identificada.

1. Adicione uma opção hipotética a um fluxo de trabalho existente.
2. Acompanhe o seu efeito no estado, no armazenamento e na apresentação.
3. Assinale todas as regras duplicadas que a alteração exigiria.
4. Reveja apenas os limites que provoquem uma propagação desnecessária.

Manter a simplicidade associada a alterações concretas

A simplicidade é uma decisão ativa relativa ao produto, não uma propriedade permanente de uma base de código. Reveja a arquitetura quando uma alteração real revelar atritos e, em seguida, determine se a dificuldade resulta de um requisito necessário, de uma responsabilidade mal posicionada ou de uma implementação duplicada. Preserve os limites em torno da variação confirmada, das transições de estado visíveis e dos dados armazenados, mantendo simultaneamente os pormenores locais diretos.

A sequência prática consiste em classificar a complexidade, identificar cenários de alteração concretos, conter os pressupostos importantes, mapear as transições de estado e ensaiar uma pequena alteração futura. Em conjunto, estes passos proporcionam uma forma disciplinada de deixar espaço para o crescimento sem obrigar o produto atual a suportar estruturas destinadas a futuros que permanecem indefinidos. Quando uma camada proposta não puder ser associada a uma destas decisões, manter a implementação direta costuma ser a opção seguinte mais clara.