Todas as
camadasde uma vez.

Contexto do projeto

Refazer em C a corretora que eu já tinha escrito em Python, só que com uma exigência nova: agora existem duas pessoas usando o sistema. O investidor deposita, saca, compra, vende e consulta a própria conta. O administrador cadastra e exclui investidores, cadastra e exclui moedas, consulta a conta de qualquer investidor e atualiza as cotações do mercado.

O jeito preguiçoso seria escrever dois programas com a lógica financeira copiada dos dois lados — e ter que corrigir cada bug duas vezes. Em vez disso, os dois executáveis são compilados por um Makefile a partir do mesmo módulo de regras: cada um tem só o seu menu, e as operações de conta existem uma vez só. Foi a primeira vez que eu tomei uma decisão de arquitetura em vez de só resolver o exercício.

• Dois executáveis, um núcleo. admin e investidor compartilham o módulo de regras via Makefile.
• Conta por CPF em arquivo. Cada investidor cadastrado gera o seu arquivo de conta e o seu arquivo de extrato.
• Administração de verdade. O admin pode criar moedas novas e atualizar cotações, não só olhar o que já existe.
• Cadastro que habilita o acesso. Ao criar um investidor, o admin já define o login e a senha com que ele entra no outro programa.

Contexto do projeto

Projeto de Arquitetura de Software e Programação Orientada a Objetos, no 3º ciclo. A tarefa era reproduzir o fluxo de um delivery no estilo iFood — do cadastro do usuário até a avaliação do pedido entregue — mas o que estava sendo avaliado não era a tela: era como o código estava organizado por trás dela.

O sistema segue MVC com padrão DAO. As telas em Swing não conversam com o banco: elas chamam um controller, que chama o DAO, que é o único lugar do projeto que sabe escrever SQL. Os alimentos saem de uma classe abstrata, com comida e bebida herdando dela, e a bebida ainda implementa a interface de imposto sobre álcool — o cálculo do tributo mora no tipo que precisa dele, não espalhado em if pela tela.

A parte que eu mais gosto é a finalização do pedido. Ela grava o cabeçalho, recupera o id gerado pelo banco e insere todos os itens com setAutoCommit(false). Se qualquer passo falhar no meio, o rollback() desfaz tudo — o banco nunca fica com meio pedido gravado.

• Busca com JOIN. Procurar um prato específico varre o cardápio de todos os restaurantes de uma vez.
• Carrinho que agrupa. Três unidades do mesmo item viram uma linha "3x", em vez de três linhas repetidas.
• Histórico completo. Cancelar muda o status, excluir remove do histórico e avaliar grava uma nota de 0 a 5 — um UPDATE, um DELETE e outro UPDATE.
• PostgreSQL via JDBC, com cinco tabelas relacionais e a conexão isolada numa classe só.

Contexto do projeto

O GymFEI nasceu de um app de treinos que eu já tinha feito no ciclo anterior, na matéria de Front-End. A base era a mesma ideia, mas ali ela morria na tela: era interface sem nada por trás. Refiz o projeto do zero em React Native com Expo, agora com autenticação de verdade, banco na nuvem e um app que continua funcionando depois de fechar.

São duas áreas na mesma base de código. O personal cadastra, edita e organiza treinos por grupo muscular; o aluno faz login, vê o que foi montado para ele, executa e acompanha o próprio progresso. Quem entra determina para onde a navegação leva, e o Firebase cuida tanto do login quanto dos dados.

• Soft delete. Treino excluído não some do banco: vai para uma lixeira e pode ser restaurado. É a mesma decisão que sistemas de produção tomam para não perder dado por clique errado.
• Firebase Auth + Firestore para login e persistência, com AsyncStorage guardando a sessão em cache no aparelho.
• Doze telas em navegação por stack, com as rotas do personal e as do aluno separadas.
• Histórico por grupo muscular, para o aluno enxergar a evolução em vez de só marcar treino feito.