Capítulo 9 — Programação II

Mapa da aula

Aula 09 publicada. Mapa, exemplo, EX025.

flowchart TD
  N0["9.1 Módulos e testes"]
  N1["9.2 Tratar entradas ruins"]
  N2["9.3 Relatórios repetíveis"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX025"]

Desenho lógico

flowchart LR
  N0["9.1 Módulos e testes"]
  N1["9.2 Tratar entradas ruins"]
  N2["9.3 Relatórios repetíveis"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX025"]

[9.1 Módulos e testes]
    |
    v
[9.2 Tratar entradas ruins]
    |
    v
[9.3 Relatórios repetíveis]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX025]

Objetivos de aprendizagem

Você vai (1) estruturar ferramentas de governança como módulos testados; (2) tratar entradas ruins com segurança; (3) produzir relatórios repetíveis a partir do código.

9.1 Módulos e testes

Em Programação II, Nadia reestrutura seu verificador de políticas em módulos: um lê os dados, outro aplica as regras e um terceiro escreve os relatórios. Cada módulo tem testes unitários feitos com o framework de testes da biblioteca padrão. Ela escreve um teste para cada regra, incluindo casos difíceis, como uma política com dois responsáveis ou uma data de revisão no formato errado. Separar a leitura da verificação permite reutilizar as mesmas regras depois em outros registros, como a lista de fornecedores, que também precisa de responsáveis e datas de revisão na Ardwell.

9.2 Tratar entradas ruins

Os dados reais de governança são bagunçados. As datas chegam em vários formatos, os responsáveis aparecem como nomes em algumas linhas e como endereços de e-mail em outras, e algumas linhas estão em branco. Nadia aprende a validar a entrada explicitamente e a relatar os problemas, em vez de pular linhas em silêncio. Uma linha pulada poderia esconder um risco sem responsável. Seu programa agora lista cada linha que não conseguiu ler, com o número da linha e o motivo, para que os donos dos dados corrijam a fonte. O Prof. Brenner chama isso de falhar ruidosamente, um hábito vital nas ferramentas de compliance.

9.3 Relatórios repetíveis

Nadia torna seus relatórios repetíveis: a mesma entrada sempre produz a mesma saída, com a data da execução, a versão do script e um resumo do arquivo de entrada impressos no topo. Se um auditor perguntar como um número foi produzido, ela pode executar de novo a versão exata sobre a entrada arquivada. Ela aprende que a repetibilidade transforma um script de conveniência pessoal em evidência organizacional, e que um relatório sem suas entradas e sua versão não pode ser conferido por mais ninguém depois.

Exemplo resolvido

Nadia divide o verificador em módulos testados, relata ruidosamente as linhas ilegíveis e carimba os relatórios com a data da execução, a versão e o resumo da entrada.

Caso sintético. Os registros e os dados são sintéticos.

Erros e limites

Os testes cobrem só os casos que alguém imaginou. As entradas arquivadas precisam de regras de retenção.

Exercícios

• EX025 — Divisão em módulos. Em que três módulos Nadia dividiu sua ferramenta?
  Mostrar critérios de avaliação

  Rubrica: 3 = leitura, verificação de regras e relatório;; 2 = três;; 1 = vago;; 0 = nenhuma.
• EX026 — Linhas puladas. Por que pular linhas ilegíveis em silêncio é perigoso?
  Mostrar critérios de avaliação

  Rubrica: 3 = pode esconder um risco sem responsável;; 2 = risco oculto;; 1 = vago;; 0 = nenhuma.
• EX027 — Cabeçalho do relatório. O que cada relatório imprime no topo?
  Mostrar critérios de avaliação

  Rubrica: 3 = data da execução, versão do script e resumo da entrada;; 2 = cabeçalho;; 1 = vago;; 0 = nenhuma.

Síntese

Módulos testados, falhas ruidosas e relatórios repetíveis tornam as ferramentas de governança confiáveis.