Diretrizes de boas práticas para programação confiável

Um livro que tenho usado como base para o desenvolvimento do meu Projeto de Conclusão de Curso (conhecido TCC) é o de Engenharia de Software do Ian Sommerville, que se encontra na 9ª edição.

Lendo o capítulo de Engenharia da Confiança, que fala sobre o desenvolvimento de sistemas altamente confiáveis, encontrei um tópico onde ele cita 8 Diretrizes de Boas Práticas para Programação Confiável, independente de linguagem de programação ou padrões de desenvolvimento adotados. Seguem as diretrizes e um breve resumo sobre cada uma delas, quem se interessar, vale a pena ler na íntegra o que o autor propõe.

1 – Limitar a visibilidade de informação em um programa: cada um deve ter acesso aquilo que lhe compete é um princípio adotado em muitas áreas e na hora de desenvolver um sistema não pode ser diferente. O autor propõe que “os componentes de programa devem ter acesso apenas aos dados que necessitam para sua implementação”, evitando assim, que componentes que não deveriam usar determinadas informações as corrompam. Um exemplo é a utilização de tipos abstratos de dados.

2 – Verificar todas as entradas para validade: para toda e qualquer entrada de dados existe um valor esperado, se é um campo de telefone, por exemplo, sabemos que a entrada esperada é uma cadeia de números com um tamanho fixo. Garantir que os dados inputados sejam exatamente o que é esperado, reduz e muito a probabilidade de problemas, correções e vulnerabilidades de segurança. Nos Cenários de Teste temos os cenários de validação que nos mostram exatamente que comportamento esperar nas situações que o sistema irá enfrentar.

3 – Fornecer um tratador para todas as exceções: todo sistema deve ser capaz de lidar com fluxos de exceção e responder rapidamente “de forma que não causem falhas de sistema”.

4 – Minimizar o uso de construções propensas a erros: o autor cita algumas construções potencialmente propensas a erros e que devem ser evitadas quando possível:

– uso de declarações go-to (desvio incondicional, que tornam o código confuso – ainda são permitidas em algumas linguagens como C, mas em outras já foi excluída);

– números de ponto flutuante (pode tornar algumas comparações inválidas erroneamente – números de ponto fixo é mais seguro);

– ponteiros (se apontados para áreas diferente do que deveriam representar, podem causar muitos problemas);

– alocação dinâmica de memória, paralelismo, recursão entre outras (vale a pena pesquisar sobre elas).

5 – Fornecer recursos de reiniciação: em sistemas cujo tempo de execução de transações é muito longo, devido ao grande número de informações, permitir que seja recuperado um estado anterior a uma falha é imprescindível. “O recurso de reinício de sistema deve permitir que ele reinicie com cópias dos dados coletados em vez de ter que começar tudo de novo desde o início.”

6 – Verificar limites de vetor: algumas linguagens sempre verificam os intervalos dos vetores, mas em outras, onde essa verificação não é realizada, é necessário “incluir um código extra que faça essa verificação”, já que se não forem verificados corretamente os limites dos vetores, pode-se ter vulnerabilidades que podem trazer falhas.

7 – Incluir timeouts ao chamar componentes externos: para que componentes não fiquem, indefinidamente, esperando respostas para continuar seu processamento, é importante a definição de um timeout para presumir que houve falha e continuar o processamento.

8 – Nomear todas as constantes que representam valores do mundo real: é muito mais simples lidar com os nomes do que com números, até quando acontece um erro é mais fácil de detectar quando uma determinada variável não foi declarada.

Vale a pena experimentar adotar essas boas práticas pregadas pela Engenharia da Confiança para sempre melhorar a qualidade do que é desenvolvido.

*os trechos entre aspas foram reproduzidos do livro.

Fonte: SOMMERVILLE, Ian. Engenharia de Software. 9ª Ed. São Paulo: Person Editora, 2011. 247-252 p.