You may implement this later: Cofunctors as partial implementations

No mundo da engenharia de software, construir um sistema muitas vezes parece como montar uma máquina complexa onde cada engrenagem deve ser escolhida antes que o primeiro parafuso seja apertado. Os engenheiros frequentemente enfrentam um dilema: precisam projetar a estrutura geral de um programa, como um banco de dados ou um serviço de rede, mas ainda não podem decidir sobre os detalhes específicos, como qual mecanismo de armazenamento usar ou como lidar com a replicação de dados. Os métodos tradicionais para lidar com essa incerteza geralmente envolvem fixar um único conjunto de escolhas para todo o sistema no início, ou esperar até o final para preencher as lacunas. Isso cria um processo rígido onde o caminho a seguir é fixado muito antes do destino estar totalmente claro. O desafio reside em encontrar uma maneira de construir sistemas que possam evoluir, onde as decisões tomadas precocemente possam moldar naturalmente as opções disponíveis mais tarde, sem forçar o programador a se comprometer com uma solução final prematuramente.

Um pesquisador da Universidade de Oxford propôs uma nova forma de pensar este problema, utilizando um conceito matemático chamado cofunctor para descrever como o software pode ser construído em etapas. A ideia central é tratar um sistema de software não como um produto acabado, mas como uma coleção de obrigações e escolhas que mudam conforme o sistema cresce. Imagine o projeto de uma casa que começa com um contorno básico. À medida que o arquiteto adiciona um novo cômodo, o projeto não apenas aumenta de tamanho; ele também atualiza a lista de materiais necessários. Se o arquiteto decidir adicionar um segundo andar, o projeto pode agora exigir uma fundação mais forte, uma escolha que não era relevante quando a casa era apenas de um andar. Esta nova abordagem permite que os engenheiros carreguem estas listas evolutivas de requisitos através do processo de design, garantindo que cada nova decisão seja compatível com as que vieram antes, enquanto ainda deixa os detalhes finais abertos para o futuro.

O artigo argumenta que as ferramentas existentes para gerir as configurações de software são frequentemente demasiado rígidas. Elas tipicamente exigem que um conjunto global de parâmetros seja definido logo no início, o que significa que o sistema não consegue adaptar-se facilmente se surgir um novo requisito durante o desenvolvimento. Por exemplo, escolher armazenar dados de uma determinada forma pode forçar mais tarde uma decisão sobre como replicar esses dados em diferentes servidores, mas os métodos padrão têm dificuldade em ligar estas duas decisões de forma dinâmica. O autor sugere que, ao visualizar um sistema de software como uma "implementação parcial", onde o estado atual do sistema dita quais escolhas estão disponíveis a seguir, podemos criar um processo de engenharia mais flexível. Isto não se trata apenas de adiar decisões; trata-se de estruturar o sistema de modo que o ato de tomar uma decisão atualize naturalmente o menu de opções para a próxima.

Para demonstrar isto, o autor utiliza o exemplo de um sistema de armazenamento de dados. Inicialmente, o sistema pode ser definido simplesmente como um lugar para guardar dados. Nesta fase, o engenheiro ainda não decidiu se usará um banco de dados local, um serviço remoto ou um formato de ficheiro específico. À medida que o design progride, o engenheiro pode adicionar um requisito para que os dados sejam persistentes, ou seja, que sobrevivam a falhas de energia. Este novo requisito atualiza o estado do sistema, introduzindo um novo conjunto de escolhas relativas à durabilidade. Mais tarde, se o engenheiro decidir replicar os dados em vários locais para segurança, o sistema atualiza-se novamente. Esta segunda mudança pode introduzir a necessidade de um protocolo de transação, um detalhe que não existia quando o sistema era apenas um repositório simples. A beleza desta abordagem é que o sistema verifica automaticamente conflitos. Se o engenheiro tivesse escolhido um formato de ficheiro simples que não consegue lidar com transações, o sistema sinalizaria isto como um conflito imediatamente quando o requisito de replicação fosse adicionado, em vez de esperar até que o código fosse escrito e falhar mais tarde.

O pesquisador mostra que este método permite a criação de planos de migração executáveis. Em vez de apenas escrever uma lista de requisitos, o sistema pode gerar um plano passo a passo de como transformar um repositório básico num complexo e replicado. Este plano pode ser construído em etapas, onde cada etapa é verificada contra o estado atual do sistema. Se um passo for saltado ou feito fora de ordem, o sistema pode detetar o erro. Por exemplo, um plano que tente replicar dados antes de criar um armazenamento durável seria rejeitado porque a base necessária ainda não existe. Isto garante que o sistema final seja construído sobre um caminho lógico sólido, onde cada mudança é consistente com o histórico das mudanças anteriores.

Uma das principais conclusões é que esta abordagem não exige que o engenheiro liste todos os estados futuros possíveis do sistema antecipadamente. Em muitos métodos tradicionais, deve-se definir todas as configurações possíveis de antemão, o que pode ser esmagador e leva frequentemente a uma explosão combinatória de opções. Aqui, o sistema rastreia apenas as obrigações que estão atualmente ativas. À medida que novos requisitos são adicionados, novas escolhas aparecem e, à medida que os antigos requisitos são satisfeitos, eles desaparecem. Isto mantém a complexidade gerível. O autor observa que, embora o enquadramento matemático por trás desta ideia seja sofisticado, a sua aplicação prática é direta: fornece simplesmente uma forma de gerir o fluxo de decisões de modo a respeitar as dependências entre elas.

O artigo também aborda por que esta ideia não tem sido amplamente adotada na programação anteriormente. O termo "cofunctor" tem sido historicamente confundido com outros conceitos, levando a uma falta de clareza sobre a sua utilidade específica. Além disso, tentativas anteriores de resolver problemas semelhantes, como as que envolvem atualizações de bases de dados ou programação modular, focaram-se frequentemente em aspetos diferentes, como manter a consistência dos dados ou fundir módulos de código, em vez da evolução dinâmica de escolhas de implementação. O autor sugere que, ao reestruturar os cofunctors como uma ferramenta para implementação parcial, o conceito torna-se muito mais acessível e diretamente aplicável ao trabalho diário dos engenheiros de software.

Em última análise, o trabalho oferece uma nova perspetiva sobre como construímos sistemas complexos. Sugere que a melhor forma de lidar com a incerteza não é congelar o design no lugar ou deixá-lo inteiramente aberto, mas sim criar uma estrutura onde o design evolui naturalmente. Ao tratar o software como um documento vivo de escolhas e obrigações, os engenheiros podem construir sistemas que são robustos, adaptáveis e mais fáceis de raciocinar. O resultado é um método que permite a montagem de sistemas intrincados, deixando os detalhes concretos finais para o momento em que são verdadeiramente necessários, garantindo que o caminho tomado seja sempre lógico e consistente.