Os 5 erros mais frequentes dos programadores de autómatos
Carlos Coutinho Phoenix Contact, S.A.
robótica
74
NOTA TÉCNICA
Todos os programadores de autómatos cometem erros quando escrevem código. Quer seja como resultado da pressão dos clientes, falta de café ou simplesmente ser distraído na hora errada, eis os 5 erros mais frequentes que os programadores de autómatos cometem e como evitá-los.
NÃO SEGUIR UMA ARQUITETURA BEM DEFINIDA Quando o programa começa a ser idealizado, o código de cada porção deve seguir uma ordem bem definida de integração numa arquitetura. Ao manter parcelas individuais, o programador verá mais facilmente o funcionamento global do programa. Ajudará também a fazer o debug do programa se alguma coisa correr mal, pois cada parte do código está encapsulada na sua própria arquitetura. Finalmente, o programa terá melhor aspeto e será mais fácil ler o código, pois a quantidade de linhas que aparecerá de uma só vez será baixa. Infelizmente, quando o próprio programador ou outros programadores trabalham, posteriormente, no código, este começa a perder a individualidade de cada parcela. As variáveis que antes eram locais passam a ser globais e, frequentemente, as saídas dos sinais digitais e/ou analógicos são escritas duas ou
mais vezes durante a execução do programa. O código fica desorganizado e a arquitetura inicial deixa de ser útil para facilitar o debug do programa e desenvolvimentos futuros. Por estes motivos manter a organização do código e o encapsulamento são comportamentos críticos para a longevidade do programa do autómato.
NÃO DOCUMENTAR O CÓDIGO Documentar o código à medida que é escrito e, mais tarde, em que é alterado é fundamental para manter o autómato em operação durante grandes períodos de tempo entre atualizações e correções. Frases sucintas em cada parcela principal do programa podem poupar muito tempo e dores de cabeça mais tarde. Pode ajudar também o programador a escrever os seus pensamentos no código, os quais poderão ser úteis em idealizar os próximos passos.
Mesmo que o código faça sentido no momento em que é escrito, os 5 minutos que são gastos a explicar o motivo da utilização de uma técnica específica serão rentabilizados quando, meses mais tarde, o mesmo programador ou outro têm de decifrar o que se está a passar. Frequentemente, o código original será afetado por correções, atualizações e novas funcionalidades. Se a documentação não é atualizada com o código, então observa-se o aumento da dificuldade de interpretação do programa e, consequentemente, perda de tempo em atualizações e, eventualmente, o perigo de provocar danos materiais do processo controlado pelo autómato.
CRIAR VARIÁVEIS REDUNDANTES É fácil criar variáveis redundantes, isto é, variáveis cuja utilidade é a mesma. À medida que as instruções do código são escritas, também as variáveis são criadas ou são utilizadas de uma tabela previamente escrita. Acontece que, num estado de desenvolvimento avançado dos programas, as variáveis são tantas que mais uma variável interna, ou flag, não tem impacto. O problema é quando estas flags são utilizadas pela executar parcelas do programa que não podem correr em simultâneo. Imagine ordens de avanço e de recuo: apenas uma destas ordens pode ser executada de cada vez; não faz sentido as duas ordens em simultâneo. O propósito das instruções de Texto Estruturado (Structured Text) IF e ELSE é precisamente para a lógica de OU EXCLUSIVO. Apenas uma variável é necessária. Se a variável é verdadeira executa uma parcela do código; caso seja falsa executa outra parcela. Mas nunca as duas parcelas são executadas em simultâneo.
NÃO REUTILIZAR CÓDIGO Além de ser mais fácil manter e interpretar o programa, a razão pela qual é muito importante isolar e encapsular parcelas