Portfólio backend: como sair do clone de tutorial

Você terminou um projeto seguindo uma aula, colocou o código no GitHub e agora não sabe se já pode chamá-lo de portfólio. Essa dúvida faz sentido: ter uma aplicação funcionando é um avanço, mas talvez você ainda não consiga explicar algumas das escolhas que estão ali.

O próximo passo pode ser menor do que parece. Escolha uma mudança que a aula não resolveu, implemente e reúna evidências de que ela funciona. Um bom projeto de portfólio permite entender o problema, acompanhar suas decisões e verificar o resultado. Você não precisa inventar uma ideia inédita para fazer isso.

Vou te mostrar como escolher essa mudança e transformá-la em uma demonstração que você consegue sustentar. O objetivo é chegar ao ponto em que uma pergunta sobre o projeto vira uma conversa sobre seu raciocínio.

Escolha um problema pequeno o bastante para terminar

Antes de abrir o editor, escreva quem usa o sistema, o que tenta fazer e qual erro precisa ser evitado. Essa descrição ajuda a escolher o que implementar e, mais tarde, o que testar. Se ela ainda estiver vaga, acrescentar bibliotecas provavelmente só vai aumentar o trabalho.

Agora vamos tornar isso concreto. Imagine que você já tem uma API em Java que cadastra equipamentos. Você decide adaptá-la para um laboratório que empresta notebooks: cada equipamento pode ter apenas uma reserva ativa por dia. A mudança passa a resolver um problema de atendimento, porque confirmar o mesmo notebook para duas pessoas criaria um conflito.

Para o primeiro recorte, considere uma única unidade do laboratório, datas do calendário local e reservas por dia inteiro. Não há reserva por hora nem fila de espera. Use somente estudantes fictícios, identificados por códigos, sem CPF, telefone ou e-mail real.

Com esse recorte, você consegue terminar uma versão e conferir se ela cumpre o combinado. Guarde outras ideias numa lista de melhorias. A reserva diária já exige decisões suficientes para uma boa conversa técnica.

Se o funcionamento de uma API ainda estiver nebuloso, acompanhe primeiro o caminho de uma requisição pelo backend. Você vai reconhecer onde a regra de reserva entra nesse percurso.

Escreva o contrato antes de aumentar o código

Contrato, aqui, é a combinação sobre o que o sistema recebe e devolve. Uma reserva precisa identificar equipamento, estudante e data. Defina também o que acontece quando o pedido não pode ser atendido.

Situação inicial	Pedido	Resultado esperado
Notebook 7 livre em 10/11/2026	Reservar para estudante A	Uma reserva ativa é criada.
Notebook 7 já reservado nessa data	Reservar para estudante B	Conflito; nenhuma segunda reserva ativa.
Notebook 7 reservado no dia 10	Reservar no dia 11	Permitido.
Notebook 8 livre no dia 10	Reservar no dia 10	Permitido, mesmo com o 7 ocupado.
Equipamento inexistente	Reservar	Pedido recusado, sem gravação.
Reserva cancelada	Outra pessoa reserva o mesmo dia	Permitido, preservando o histórico do cancelamento.

Escolha ainda o tratamento de datas passadas e de campos ausentes. Para este projeto, recuse os dois casos. Na API, você pode documentar 201 para criação, 409 para conflito de disponibilidade, 404 para equipamento inexistente e 400 para entrada inválida. São escolhas do contrato proposto, que precisam aparecer na implementação e nos testes.

As datas da tabela são ilustrativas. Na demonstração do README, escolha uma data futura no momento da execução. Nos testes automatizados, forneça um relógio controlado à regra — em Java, Clock permite fixar o instante consultado — para que a verificação não passe hoje e falhe amanhã apenas pela passagem do tempo.

O caso de cancelamento exige atenção: apagar uma linha e marcar uma reserva como cancelada são decisões diferentes. Vamos preservar o registro e alterar seu estado. Assim, consultar o histórico permite explicar por que o equipamento voltou a ficar disponível.

Essa tabela também organiza sua implementação em Java. Primeiro faça a regra funcionar; depois conecte entrada HTTP e persistência. Assim, quando aparecer uma divergência, você terá uma expectativa específica para investigar. O roteiro antes de Spring Boot ajuda se ainda estiver difícil separar essas responsabilidades.

Torne visível a decisão mais difícil

A primeira tentativa costuma consultar se existe reserva e, quando não existe, inserir uma. Isso pode funcionar com uma requisição por vez. Mas duas requisições podem consultar antes que qualquer uma tenha gravado. Ambas enxergam disponibilidade.

Uma proteção no banco pode impedir a combinação duplicada de equipamento e data entre reservas ativas. Como mantemos cancelamentos no histórico, a unicidade precisa considerar apenas os registros ativos. No PostgreSQL, um índice único parcial é uma possibilidade; confira a documentação de índices parciais antes de implementar.

Depois dessa proteção, ainda há trabalho na aplicação: reconhecer o conflito devolvido pelo banco e responder de acordo com o contrato. Se a operação fizer várias gravações, você também precisará estudar como mantê-las coerentes. Vale tratar uma dificuldade de cada vez e registrar o que cada mudança passou a garantir.

Registre a decisão em um arquivo curto: contexto, alternativa considerada, escolha e consequência. Por exemplo: “Mantive cancelamentos para consultar o histórico. A restrição vale apenas para reservas ativas. Um conflito de unicidade deve virar resposta de indisponibilidade, sem expor a mensagem interna do banco.”

Se ainda não implementou concorrência, escreva isso com clareza. Você pode apresentar a primeira versão sequencial e uma melhoria pendente. O problema é afirmar que a API impede reservas simultâneas tendo testado apenas chamadas sucessivas.

Teste o comportamento que você promete

Comece pelos casos da tabela. Um teste automatizado prepara um estado conhecido, executa uma ação e compara o resultado com uma expectativa. O teste de conflito precisa conferir tanto a resposta quanto o estado final: continua existindo apenas uma reserva ativa.

Separe três perguntas. A regra isolada recusa a condição correta? A aplicação realmente grava e consulta no banco de teste? A requisição HTTP devolve o status e o corpo combinados? Um teste pequeno de regra não comprova automaticamente as outras duas.

Para concorrência, prepare duas tentativas de reserva para o mesmo equipamento e data, coordenando sua execução para disputar a gravação. Confira que apenas uma termina com criação e que o banco conserva uma única reserva ativa. Não conclua que há proteção só porque apertar dois botões manualmente “deu certo”.

Use um banco exclusivo de testes, com dados descartáveis. Nunca execute limpeza automática sobre um banco compartilhado ou com dados reais. Documente como criar e remover esse ambiente.

Uma verificação especialmente útil é introduzir temporariamente um defeito: retirar a proteção contra conflito e observar qual teste falha. Restaure a proteção em seguida. Se nenhum teste perceber a quebra, falta evidência sobre a regra central.

Faça o README permitir uma segunda execução

Imagine alguém abrindo o repositório sem conhecer você. O README precisa apresentar o problema, as versões necessárias, os comandos realmente usados, as variáveis de configuração e uma demonstração reproduzível. A orientação do GitHub sobre READMEs é um ponto de partida para organizar essa entrada.

Inclua uma sequência com dados fictícios: criar a primeira reserva, tentar a duplicada, cancelar a primeira e reservar novamente. Mostre os resultados esperados. Informe também como rodar os testes e quais capacidades ainda faltam.

Ofereça um arquivo de configuração de exemplo sem senhas verdadeiras. Se uma credencial já entrou no histórico, apagá-la do arquivo atual não basta para torná-la segura: revogue ou substitua a credencial no serviço correspondente.

Credite o tutorial original, respeite a licença do material e descreva o que você acrescentou. Isso facilita distinguir estudo guiado de contribuição própria. Um histórico de commits com mudanças compreensíveis ajuda a acompanhar o raciocínio; quantidade de quadradinhos verdes não explica qualidade.

Prepare uma demonstração que você consegue defender

Apresente o problema, execute o caso normal e depois provoque o conflito. Abra o teste que protege essa regra e explique uma decisão de armazenamento. Termine mostrando uma limitação e o próximo incremento que faria.

Se perguntarem por que não há microsserviços, a resposta pode ser direta: o recorte não exigiu distribuição, e uma aplicação única permitiu acompanhar e testar a reserva inteira. Se perguntarem sobre autenticação, diga o que existe de fato. Identificar um estudante num campo não prova que o solicitante tem permissão para reservar em nome dele.

Peça a outra pessoa que tente executar o README e anote onde ela travou. Corrigir esse caminho também é desenvolvimento. Para expor uma demonstração, avance para como colocar uma aplicação no ar; uma URL pública traz responsabilidades que o repositório local não tinha.

Quando conseguir percorrer essa demonstração, você terá material concreto para apresentar sua aprendizagem. A contratação também depende dos requisitos e do processo de cada vaga; o projeto é uma das evidências que você leva para a conversa. Veja como organizar essas evidências para a primeira vaga. Se a tentativa revelou uma dificuldade em regras, banco ou testes, use-a para escolher seu próximo estudo na formação Build & Run.

Referências técnicas consultadas em 04/11/2026. O projeto descrito é um exercício proposto; implemente e verifique cada capacidade antes de apresentá-la como concluída no seu portfólio.