Planejar o gerenciador: entender e decompor

O que o gerenciador precisa fazer

Um Gerenciador de Tarefas é aquele programa que guarda a sua lista de afazeres: adiciona uma tarefa nova, mostra tudo que falta fazer, marca uma como concluída e ajuda a achar uma tarefa específica. Simples de descrever, e é justamente por isso que serve tão bem de projeto final: cada operação dele usa uma peça diferente do curso. Antes de escrever qualquer código, aplicamos o passo mais importante do método dos quatro passos, entender. O que entra? Comandos do usuário e os dados de cada tarefa. O que sai? A lista atualizada e as respostas às consultas. Quais são as regras? Uma tarefa tem uma descrição e um estado (pendente ou concluída); não faz sentido concluir uma tarefa que não existe; a descrição não pode ser vazia. Já surgem os casos de borda antes mesmo de uma linha de código, exatamente como deve ser.

Com o problema entendido, vem a decomposição. Em vez de imaginar um programão único que faz tudo, listamos as operações e transformamos cada uma numa função com nome honesto. Adicionar uma tarefa vira adicionarTarefa. Mostrar a lista vira listarTarefas. Marcar como feita vira concluirTarefa. Procurar vira buscarTarefa. Cada função fará uma coisa só, seguindo a regra do módulo de código limpo, e o programa principal será um resumo legível que chama essas funções conforme o usuário pede. Repare que ainda não escrevemos nenhuma delas; estamos projetando o esqueleto, decidindo as partes e como elas se encaixam. Esse trabalho de cima para baixo é o que evita se perder depois: quando você começar a preencher cada função, já saberá exatamente o papel dela no todo.

O esqueleto no papel

O esqueleto do programa é o plano virado quase-código: você escreve as funções que vão existir e o laço principal que as chama, deixando os detalhes para depois. Esse esqueleto já revela decisões importantes. O programa vai rodar num laço, mostrando um menu e esperando o usuário escolher uma operação, até ele pedir para sair, uma clássica combinação de laço com sentinela que você aprendeu lá atrás. A escolha do menu pede uma decisão de vários caminhos, terreno do escolha-caso. E cada opção do menu chama uma das funções que decompusemos. Escrever esse esqueleto primeiro é como montar a planta de uma casa antes de levantar as paredes: você vê o todo, percebe o que falta e corrige no barato, no papel, antes de investir esforço no código detalhado.

// esqueleto do gerenciador (o miolo de cada função vem nas próximas aulas)
tarefas <- lista vazia

repita
  mostrarMenu()
  opcao <- lerOpcaoDoUsuario()
  escolha opcao
    caso "adicionar": adicionarTarefa(tarefas)
    caso "listar":    listarTarefas(tarefas)
    caso "concluir":  concluirTarefa(tarefas)
    caso "buscar":    buscarTarefa(tarefas)
    caso "sair":      escreva("Até logo!")
    caso contrário:   escreva("Opção inválida")
  fim
até opcao = "sair"

O esqueleto usa laço com sentinela (repita até sair) e escolha-caso (o menu). Cada opção chama uma função decomposta.

Por que planejar primeiro poupa tanto trabalho

Pode dar vontade de pular o planejamento e ir direto ao código, mas os minutos gastos aqui se pagam com juros. Ao decompor antes, você descobre problemas de projeto enquanto eles ainda são baratos de corrigir: um esqueleto no papel se refaz em segundos, um código emaranhado leva horas. Você também ganha um mapa: se um bug aparecer, saberá em qual função procurar, porque cada uma tem uma responsabilidade clara. E consegue trabalhar por partes, terminando e testando uma função de cada vez, com a satisfação de ver o projeto crescer em pedaços que funcionam, em vez de encarar um monstro único que só roda quando está inteiro. Este é o segredo que separa quem termina um projeto de quem desiste no meio: dividir o grande em pequenos, e atacar um pequeno de cada vez. Nas próximas aulas, é exatamente o que faremos, preenchendo o esqueleto função por função.