Definição curta

Propriedade de um sistema cujos contratos entre APIs, regras de negócio e testes que descrevem o comportamento esperado são suficientemente localizáveis e separados para que um time saiba refazê-lo em outro lugar, em outra tecnologia.

Definição detalhada

A palavra circula em vários sentidos fora daqui. Em operação, designa a capacidade de regenerar um ambiente idêntico a partir das fontes e da configuração. Em arquivamento e em ciência de dados, designa a possibilidade de reencontrar um dado ou um resultado a partir do que foi conservado.

Nos artigos deste blog, o termo designa uma propriedade de compreensão, não de ferramental: um sistema é reconstrutível quando você saberia refazê-lo, o que pressupõe saber onde estão as fronteiras — por onde passa o contrato de uma interface, onde vivem as regras de negócio, quais testes dizem o comportamento esperado em vez da implementação atual. A reconstrução não precisa ser feita: ela serve como pergunta de controle, colocada no lugar de "isso funciona?".

O sentido normativo e o uso de campo divergem em um ponto. A norma gostaria da reconstrução idêntica, inclusive no detalhe da implementação. No campo, a pergunta é mais fraca e mais útil: será que saberíamos obter o mesmo comportamento com outros meios, partindo do que o sistema diz de si mesmo?

Uso no domínio

O termo entra em jogo como critério de qualidade de um desenvolvimento assistido por um assistente, ali onde a velocidade de entrega não diz mais nada sobre o domínio que se tem do sistema. Serve também nas decisões de arquitetura — impor contratos entre APIs, escrever a pirâmide de testes antes de desenvolver, recusar que o negócio fique espalhado pelos endpoints — e nas revisões de fim de obra, como pergunta que substitui a demonstração funcional.

Sinônimos e variantes

"Eu saberia reconstruir isso?" — a forma interrogativa é o uso corrente do termo. Variantes atestadas: "ter pontos de apoio no sistema", "pontos de ancoragem", "linhas de separação".

Não confundir com

• Dívida de compreensão — passivo acumulado por um time sobre um sistema que ele não explica; a reconstrutibilidade é o ativo correspondente, e um time pode não ter nem um nem outro sobre um sistema em que ainda não tocou.
• Reprodutibilidade de um build — propriedade de uma cadeia de fabricação que produz o mesmo artefato a partir das mesmas entradas; ela trata do ferramental e é verificada automaticamente, sem que nenhum humano tenha entendido o que o sistema faz.
• Portabilidade — aptidão de um software para funcionar em outro ambiente sem ser refeito; ela evita a reconstrução em vez de torná-la possível.
• Documentação de arquitetura — descrição do estado do sistema tal como ele é; ela pode estar completa e ainda assim deixar um sistema que ninguém saberia refazer, assim como pode faltar em um sistema cujos testes bastam para dizer o comportamento.
• Dívida técnica — fragilidade de concepção cujo tratamento foi decidido e orçado; um sistema pode estar fortemente endividado e ser perfeitamente reconstrutível, já que um qualifica a concepção e o outro o que se sabe dizer sobre ela.

Exemplos

"Se amanhã eu tiver que levar esta aplicação para outra tecnologia, eu sei onde estão os contratos, onde estão as regras de negócio, onde estão os testes que descrevem o comportamento esperado." — o uso de referência, aplicado a uma aplicação desenvolvida com um assistente.

Recusar uma abordagem DDD completa em um projeto que não a justifica, e ao mesmo tempo recusar que o negócio fique espalhado pelos endpoints, é uma arbitragem de reconstrutibilidade: não se busca a pureza do modelo, buscam-se linhas de separação localizáveis.

Ambiguidades / debates

A amplitude visada não está estabilizada: reconstruir o comportamento, reconstruir a arquitetura, ou reconstruir o código. O sentido adotado aqui é o primeiro.

A verificação está ainda menos. Ninguém reconstrói para verificar que teria sabido fazê-lo, o que deixa o critério no estado de pergunta feita em consciência — e, portanto, exposto à complacência de quem responde.