Não sou paranoico – sou prudente

Nick Hodges é um proeminente personagem do mundo da tecnologia, mais especificamente da comunidade Delphi, e provavelmente conhecido de muitos que estejam lendo esta publicação.

Vejam o que ele escreveu no twitter tempos atrás:

Então: olhar para os dois lados ao atravessar uma rua de mão única é prudência ou paranoia?

Pensando em termos de desenvolvimento de sistemas, imagine a seguinte definição de uma tarefa:

“Copiar o arquivo vendas.xls da pasta local para a pasta da rede”

Não importa qual ferramenta um programador utilize para implementá-la, é uma coisa notoriamente tão simples, que provavelmente pode ser realizada já no primeiro contato com esta ferramenta, no primeiro exercício da primeira aula.

Mas, e se:

• O arquivo a ser copiado não estiver mais na pasta local esperada?
• O arquivo estiver lá, mas o usuário que está executando a rotina não tem direito de acessar esta pasta?
• Estiver tudo certo com o arquivo e com a pasta, mas ele já está aberto em modo “exclusivo” por outro usuário e não pode ser reaberto para a cópia?
• Ele puder ser aberto sem problemas, mas não dá para acessar a pasta da rede onde ele deveria ser copiado?
• Não houver problemas em ler e gravar o arquivo, mas não tiver espaço suficiente no destino para todo o conteúdo a copiar?
• Estiver tudo certo com os pré-requisitos para a cópia (leitura e gravação), mas no meio da transferência do conteúdo cai a conexão de rede com o local de destino?

Bom, esta lista poderia crescer bem mais e talvez, se tornar um caso clássico de paranoia.

Mas a mensagem importante é que há muitas variáveis envolvidas mesmo na mais simples das ações. E os programadores precisam ser atentos a isso.

Do contrário, os códigos produzidos serão frágeis e sujeitos a vários bugs. E bugs do pior tipo: aqueles que só acontecem “às vezes sob circunstâncias bem específicas”.

Frases famosas como “mas estava funcionando antes” ou “falhou agora, assim do nada?”, muito provavelmente já foi dita ou ouvida perto de você.

Por isso, programadores e analistas que desejam gerar algoritmos com qualidade precisam conhecer bem as ferramentas que estão utilizando, para saber identificar quando que uma operação pode ou não falhar. E tratar a “exceção” e o “erro” tem de ser parte constante do fluxo lógico destes algoritmos.

E não é diferente com os produtos Magic.

Se estivermos desenvolvendo uma aplicação com o Magic xpa:

• Temos de atentar para o retorno das funções que usam TRUE/FALSE/NULL para indicar o sucesso (ou falta dele) de suas ações (exemplo: FileCopy).
• Devemos revisar as configurações de transação das tarefas, de todas elas, para ver se está de acordo com o que se deseja no momento da execução. Valores defaults são úteis, mas não vão atender nossas necessidades todo o tempo.
• O mesmo vale para as configurações de acesso exclusivo/compartilhado dos registros de dados.
• Todo acesso a uma base de dados, por definição, pode falhar. Devemos nos preparar para as exceções de acesso aos dados, e agir conforme a necessidade do momento.

Se estivermos desenvolvendo uma integração com o Magic xpi:

• Temos de atentar para o status retornado pelos componentes executados (c.sys.ErrorCode).
• Temos de desenhar desvios e ações específicas para serem tomadas em função de falhas reportadas pelos componentes (Error Handling).
• Temos de nos preparar para eventuais interrupções (crashs) nas execuções dos fluxos e definir políticas de recuperação.

Enfim, estes são alguns cenários apenas, que ilustram situações que os desenvolvedores/analistas Magic devem se atentar, para produzir um trabalho (projeto) com mais qualidade, correção, robustez e que melhor se adapte às diversas situações a que estarão expostos quando em produção.

Clientes não possuem a mesma compreensão e paciência com os bugs, que os técnicos possuem.

E nem precisam.

Por isso, um desenvolvimento “defensivo” e “cuidadoso” dos algoritmos deve ser sempre quesito inegociável em qualquer especificação.

E isso é uma questão de prudência, respondendo a pergunta inicial desta publicação.