14 de agosto de 2019

Projeto “K”: A fase de maior complexidade

Projeto-K

O desenvolvimento do Projeto “K” segue adiante, no ritmo e “prazo” viáveis para este que vos fala. Atualmente estou na fase de maior complexidade – em termos de backend – do projeto: Processamento e Armazenamento. A complexidade aqui é extremamente interessante e este post é possivelmente o mais revelador do projeto, já que oferece detalhes que não revelei até o momento.

O core do functionamento do “K” consiste do seguinte:

  1. Obter um recurso on-line;
  2. Processar este recurso, dividindo-o em n entidades distintas, mas dependentes;
  3. Armazenar estas entidades.

Parece simples, certo? Um CRUD como outro qualquer, correto? Não. É muito mais complexo do que isso.

A maior complexidade se resume a o que fazer quando as coisas não funcionam como esperado. Ao encontrar um problema o “K” não pode simplesmente descartar o recurso, pois este não foi processado e isso gera um problema que vou chamar de “recurso eterno” – o recurso permanece ativo (existente) para posterior tentativa, e portanto temos uma espécie de loop infinito: um recurso que nunca será descartado pelo “K” e portanto sofrerá uma nova tentativa mal-sucedida quando a execução começar novamente.

O que torna esse problema interessante é o simples fato de que todas as soluções possíveis são ruins:

  1. Ignorar o recurso gera um “recurso eterno”, como comentei acima;
  2. Armazenar o recurso de forma incompleta deforma o recurso original;

Para todos os efeitos é um beco sem saída, mas o projeto precisa andar e portanto a única solução é uma espécie de combinação de soluções ruins, com a decisão do(a) usuário(a):

O “K” precisa presumir que tentou realizar o processamento de forma correta* e portanto o erro não é seu, mas do recurso em si: o recurso simplesmente não é válido. Se uma das entidades dependentes não pode ser armazenada um efeito cascata faz com que todo o recurso precise ser obrigatoriamente descartado. A partir disso as opções possíveis para o(a) usuário(a) são limitadas: ele(a) pode logar os detalhes do recurso para que seja possível solicitar manualmente uma correção ou simplesmete “confiar cegamente” no “K” e permitir que o recurso seja descartado sem registro da falha. Embora a segunda opção seja terrível em todos os termos possíveis acredito honestamente que a opção deva estar disponível e aí entram detalhes sobre o exato por quê disso que não estou pronto pra revelar ainda.

Bola pra frente.

(*) Processar e armazenar tudo corretamente é justamente o principal motivo pelo qual o projeto é tão complexo e longo de ser desenvolvido.

Share

Galvão

Presidente da ABRAPHP – Associação Brasileira de Profissionais PHP, Diretor da PHP Conference Brasil, Contribui para o desenvolvimento do PHP (traduções, decisões). Atua como Zend Framework Evangelist para o ZTeam, da Zend. Professor Convidado de Pós-Graduação, PR e SC. Mais de 22 anos desenvolvendo sistemas e aplicações com interface web (mais de 17 destes com PHP). Palestrante em eventos nacionais e internacionais, Instrutor de cursos presenciais e a distância.

You may also like...