Avaliação em cursos de programação: além da prova

Avaliar em curso de programação funciona melhor com um conjunto de instrumentos contínuos do que com prova bimestral: exercícios corrigidos com devolutiva, a possibilidade de refazer e reentregar, uma explicação escrita com as próprias palavras e os sinais de entrega ao longo das semanas. A prova tradicional não é inútil, mas mede a pior hora do aluno — sozinho, com relógio correndo, sem poder testar o código — que é justamente o oposto de como se programa na vida real.

Isso não significa avaliar menos nem ser mais leniente. Significa avaliar mais vezes, em pedaços menores, com critério explícito e com a chance de corrigir o próprio erro. Um curso avaliado assim costuma ser mais exigente do que um com duas provas — só que a exigência acontece durante, e não depois. Tudo aqui foi pensado para caber na realidade de quem dá aula em curso livre e ainda precisa entregar uma nota para a secretaria no fim.

O que a prova tradicional mede mal

A prova de programação em papel, ou em máquina com tempo curto e sem consulta, mede quatro coisas que importam pouco e deixa passar as que importam.

Ela mede bem memória de sintaxe, velocidade sob pressão e capacidade de trabalhar isolado — e nenhuma das três distingue quem programa de quem não programa. Já o que ela mede mal é justamente o miolo da atividade:

• Depuração. Programar é, em boa parte, descobrir por que não funcionou. Prova com uma tentativa só transforma o erro em ponto perdido em vez de em processo observável.
• Persistência. O aluno que insiste três horas e resolve é exatamente o perfil que dá certo — e é o que a prova cronometrada elimina.
• Leitura de código alheio. Habilidade central no trabalho, quase nunca cobrada em prova.
• Consulta. Toda pessoa que programa consulta documentação. Proibir consulta na avaliação testa uma condição que não existe fora da sala.

E há um efeito colateral pedagógico: prova cara concentra o estudo na véspera. Quatro entregas espalhadas produzem quatro semanas de trabalho; uma prova produz uma noite.

Avaliação formativa: o exercício com devolutiva

O instrumento principal de um curso de programação deve ser o exercício corrigido com comentário. Formativa quer dizer simplesmente que a correção acontece enquanto ainda dá para mudar o resultado, e não depois de o assunto ter passado.

Para funcionar, três coisas precisam estar no lugar:

1. Critério anunciado antes. Três a cinco itens objetivos, ditos na hora de passar o exercício. Por exemplo: resolve o caso pedido; trata a entrada inválida; nomes de variável dizem o que guardam; não repete o mesmo trecho três vezes.
2. Devolutiva rápida. Feedback de cinco dias depois chega quando o aluno já esqueceu o que pensava. Dois ou três dias é o teto útil.
3. Feedback específico. "Faltou tratar o caso do zero na linha 12" muda comportamento. "Precisa estudar mais" não muda nada.

O fluxo de correção em detalhe está em como corrigir exercícios de programação online. Aqui interessa o efeito na nota: cada exercício corrigido é um dado a mais sobre o aluno, colhido em condição normal de trabalho.

Devolver para refazer é nota que ensina

Essa é a mudança que mais rende, e a mais simples de adotar: em vez de aprovar com 6 e seguir em frente, você devolve com uma orientação e o aluno reentrega. A nota final é da versão corrigida.

Objeção previsível: "isso não é dar a resposta e inflar a nota?". Não, por dois motivos. Primeiro, a orientação aponta o problema, não a solução — "seu programa quebra quando o valor é zero" obriga o aluno a descobrir por quê. Segundo, quem refaz aprendeu mais do que quem acertou de primeira, porque passou pelo ciclo completo: errar, entender o erro, corrigir. Recusar isso é premiar quem já chegou sabendo.

Regras que mantêm o refazer honesto:

• Limite de reentregas. Duas costuma bastar. Sem limite, alguns alunos usam você como compilador.
• Prazo para a reentrega. Uma semana. Sem prazo, tudo se acumula na última semana do curso.
• A devolutiva descreve o sintoma. Se você escrever o código certo no comentário, o aluno copia e não aprende.

Numa ferramenta que suporta o ciclo, isso é um estado e não uma gambiarra de e-mail. No Aulab, "devolver para o aluno refazer" é uma das duas ações de correção, ao lado de aprovar; a nova versão chega no mesmo lugar, junto do histórico. Se quiser ver esse ciclo montado antes de mudar o seu curso, dá para criar uma turma de teste com um exercício só.

Redação técnica: explicar com as próprias palavras

Um instrumento subutilizado e barato: pedir que o aluno explique, em texto corrido de cinco a dez linhas, um conceito ou a solução que ele mesmo escreveu. Não é redação de português — é explicação técnica, e revela compreensão de um jeito que o código não revela.

Por quê? Porque código pode ser copiado, adaptado ou obtido pronto, e ainda assim rodar. Explicação com as próprias palavras não sobrevive a isso: quem copiou não consegue dizer por que a condição está antes do laço.

Três enunciados que funcionam:

• "Explique, para um colega que faltou, o que o seu programa faz e por que você usou um laço aqui."
• "Qual foi o erro que mais te travou neste exercício e como você descobriu o que era?"
• "Este código funciona. Explique o que ele faz linha a linha." (com um trecho escrito por você)

O segundo é o mais revelador: a resposta mostra se o aluno tem método de depuração ou se tenta coisas ao acaso. Na composição da nota, entra com peso menor que o exercício, mas peso real — uma redação curta por unidade já muda o comportamento da turma, porque o aluno passa a estudar sabendo que vai precisar dizer, não só fazer.

Sinais contínuos contra fotografia única

Duas soluções para o mesmo problema podem ser igualmente corretas. Somar de 1 a 10 com for:

<?php
$soma = 0;

for ($numero = 1; $numero <= 10; $numero++) {
    $soma = $soma + $numero;
}

echo $soma;

Ou com while:

<?php
$soma = 0;
$numero = 1;

while ($numero <= 10) {
    $soma = $soma + $numero;
    $numero = $numero + 1;
}

echo $soma;

Saída: 55 nas duas. Um gabarito rígido reprovaria uma das duas por não bater com o esperado — e é exatamente por isso que correção humana continua importando em curso de programação, e por que uma nota única raramente descreve bem um aluno.

O que descreve bem é a série: quantos exercícios entregou, em quantos precisou refazer, se o atraso vem aumentando, se sumiu por duas semanas e voltou. Esse conjunto de sinais é matéria-prima de avaliação, e é sobre ele que trata como acompanhar o desempenho dos alunos. A diferença prática: com sinais, a conversa com o aluno em dificuldade acontece na semana 4; com prova, acontece na semana 9, quando não adianta mais.

Como compor uma média justa

Quase toda instituição exige um número no fim. Dá para chegar nele sem trair o método. Uma composição que funciona bem em curso livre de 60 a 100 horas:

Três cuidados na hora de fechar:

1. Peso na versão final, não na primeira. Se a nota vale pela primeira entrega, ninguém se arrisca — e você acabou de matar o refazer.
2. Descarte a pior nota do conjunto. Uma semana ruim acontece; ela não deve definir o semestre.
3. Trabalho em grupo precisa de um componente individual. Do contrário a nota do grupo vira nota do integrante mais forte. As formas de coletar esse sinal estão em exercícios em grupo na aula de programação.

Feedback que o aluno lê de verdade

Devolutiva longa não é lida. Devolutiva genérica é lida e ignorada. O que o aluno lê e usa tem três características: é curta, aponta um lugar específico e diz o próximo passo.

Um formato de três frases que cabe em qualquer correção:

1. O que está certo. Uma frase, concreta. "A leitura da entrada e a condição principal estão corretas."
2. O que precisa mudar, com endereço. "Quando a quantidade é zero, o programa divide por zero na linha 14."
3. O próximo passo. "Trate esse caso antes da divisão e me reenvie."

Evite três hábitos comuns: elogio vazio ("parabéns pelo esforço!"), lista de dez pontos de melhoria — corrija no máximo dois por vez — e comentário sobre a pessoa em vez do trabalho. "Seu código está desorganizado" é sobre o texto; "você é desorganizado" não ajuda em nada.

Uma última observação honesta: nada disso é automático. Correção com devolutiva custa tempo do professor, e é bom que custe — é onde o ensino acontece. Ferramenta boa só tira o atrito ao redor: fila organizada, entrega na tela, histórico e botão de devolver.

Perguntas frequentes

Prova vale a pena em curso de programação?

Como instrumento único, não. A prova cronometrada e sem consulta mede memória de sintaxe e velocidade sob pressão, e deixa de fora depuração, persistência, leitura de código alheio e uso de documentação — que são o miolo da atividade. Ela pode existir com peso pequeno, mas o corpo da avaliação deve ser formado por exercícios com devolutiva ao longo do curso.

Deixar o aluno refazer o exercício não infla a nota?

Não, se a devolutiva apontar o sintoma e não a solução, houver limite de reentregas (duas costuma bastar) e prazo definido. Quem refaz passou pelo ciclo completo de errar, entender o erro e corrigir, o que ensina mais do que acertar de primeira. Avaliar só a primeira entrega premia quem já chegou sabendo.

Como avaliar programação sem gabarito automático?

Com critérios objetivos anunciados antes do exercício — de três a cinco itens, como resolver o caso pedido, tratar entrada inválida e usar nomes de variável claros. Correção automática costuma recusar soluções corretas escritas de outro jeito: o mesmo problema resolvido com for ou com while dá o mesmo resultado, e as duas versões estão certas.

Como usar redação técnica para avaliar programação?

Peça de cinco a dez linhas explicando, com as próprias palavras, o que o programa do aluno faz e por quê, ou qual erro mais o travou e como ele descobriu a causa. Código pode ser copiado e ainda assim rodar; explicação escrita não sobrevive à cópia. Um peso pequeno já muda o comportamento da turma, porque o aluno estuda sabendo que vai precisar dizer, não só fazer.

Como compor a média final sem trair a avaliação contínua?

Uma divisão que funciona em curso livre: 50% para os exercícios do curso na versão final após refazer, 25% para projeto ou trabalho em grupo, 15% para redações técnicas e 10% para regularidade de entrega. Pontue a versão final e não a primeira, descarte a pior nota do conjunto e garanta um componente individual dentro da nota de grupo.