Hoje, no #Dia5 do Diário de Bordo, o projeto começou a ganhar uma API robusta — mas com responsabilidade. Nada de controller gigante ou regra de negócio no model. Aqui a gente aplica MVC de verdade.
✅ Entregas do dia
Controllers enxutos, só delegando a lógica
Services para encapsular regras de negócio
Models focados em persistência e relacionamento
FormRequest para validações desacopladas
Resource para padronizar as respostas da API
Jobs + Events para ações desacopladas e assíncronas
Rotas versionadas com middleware e prefix (ex: /api/v1/leads)
🧠 Aplicando MVC com consciência
Muita gente acha que usa MVC. Mas na prática, mistura tudo no controller ou entope o model de regra.
Aqui, aplicamos:
Model → responsabilidade: banco e relações
View → no caso, é o Resource (output JSON padronizado)
Usar Laravel é fácil. Arquitetar bem usando Laravel é outra história.
Nos vemos no próximo capítulo do Diário de Bordo 🚀
Quem nunca voltou para um código meses depois e pensou:
“Que inferno é esse?”
Depois de anos codando projetos de todos os tamanhos, desenvolvi um processo próprio para estruturar cada projeto que começo. Neste artigo, compartilho meu estilo de programação — da documentação inicial às boas práticas no código e gestão do projeto.
Documentação: antes de escrever a primeira linha de código
Antes de qualquer comando no terminal, eu crio um documento PDF onde descrevo o projeto:
Visão geral do sistema
Descrição dos fluxos principais
Funcionalidades essenciais
Modelagem inicial do banco de dados
Depois disso, passo para diagramas e modelagens (como ERD – Entity Relationship Diagram) e crio os protótipos das telas usando o Figma.
Back-end: organização, padrão e clareza
Sou especialista em PHP e adoto o padrão PSR-12 para manter o código limpo e consistente. Minhas práticas incluem:
Comentários estratégicos nos pontos críticos do código, explicando decisões complexas.
Documentação de APIs com Swagger, automatizando a geração de documentação técnica.
Variáveis em inglês e camelCase como padrão de nomenclatura.
Retornos em inglês ou português dependendo da necessidade do projeto (pensando em whitelabel).
Modelagem de banco de dados relacional com relacionamentos claros e integridade referencial.
Arquitetura MVC para organização e escalabilidade.
Front-end: organização e modularidade
No front-end, minha filosofia é separar bem os blocos de código CSS:
Botões, títulos, formulários e animações recebem estilos específicos e modularizados.
Uso frameworks como Vuetify ou Bootstrap quando o projeto exige agilidade e consistência visual.
Organização: produtividade e rastreabilidade
Para organizar tarefas e acompanhar o progresso do projeto, utilizo o Jira. Isso ajuda a:
Documentar decisões tomadas.
Organizar sprints e tarefas.
Registrar históricos para auditorias futuras.
Repositório: controle de versão e organização
Todo projeto que desenvolvo é versionado com Git e hospedado no GitHub ou GitLab. Minhas práticas de repositório incluem:
Commits pequenos e frequentes, sempre com mensagens claras e padronizadas ([tipo]: descrição — exemplo: feat: criar endpoint de login).
Uso de branches para desenvolvimento de features, correções e testes (feature/, fix/, hotfix/).
README.md completo explicando como rodar o projeto, configurações e instruções básicas de deploy.
Licença e arquivo de contribuição (LICENSE e CONTRIBUTING.md), quando o projeto é open source ou colaborativo.
Documentação gerada e linkada (Swagger para APIs, Storybook para front-end).
Tiago’s Code Style: meu manifesto de boas práticas
📚 Documentação inicial antes do primeiro commit.
🧠 Código seguindo PSR-12 e princípios SOLID.
🐫 Nomenclatura em inglês e padrão camelCase.
🛡️ APIs documentadas com Swagger.
🏛️ Modelagem e relacionamento de bancos de dados robustos.
🎨 CSS modularizado e organizado por componentes.
📋 Jira para gestão e rastreabilidade.
📚 Repositórios Git bem documentados e versionados.
“Código não é só para rodar. Código é para durar.”
Esse é o meu jeito de construir software. E você? Qual é o seu estilo de programação?