Tiago Luvizoto Neves

Tag: Boas Práticas

  • Clean Code não é perfumaria. É o seguro de vida do seu time.

    Clean Code não é perfumaria. É o seguro de vida do seu time.

    Tem gente que acha que organizar o código é perda de tempo. Que separar responsabilidades em controller, service e job é “frescura” ou “over engineering”.

    Até o sistema quebrar. O estagiário entrar. O cliente pedir algo urgente. E ninguém conseguir mexer.

    Clean code não é enfeite. É seguro de vida.

    👨‍💻 Código feio vicia a empresa em você

    Tem dev que acha que “centralizar tudo” é uma prova de competência. Quando na verdade, está sabotando o próprio time.

    O código vira um refém da cabeça de quem escreveu. E se essa pessoa sai? Ninguém mais entende. A empresa trava.

    🧠 Arquitetura não é frescura. É responsabilidade.

    Separar responsabilidades, escrever nomes claros, documentar o mínimo… tudo isso é um ato de respeito com quem vem depois. Até com o “você do futuro”.

    • Controller cuida do fluxo
    • Service cuida da regra
    • Job cuida do que pode esperar

    Simples. Elegante. Sustentável.

    🚨 Dev sênior que não compartilha, sabota.

    Se você é sênior e guarda tudo na cabeça, está atrasando a equipe. Liderar é preparar o terreno para que outros consigam andar sem você.

    Quer crescer na carreira? Comece escrevendo como se alguém que você ama fosse manter seu código amanhã.

    👇 E você? Já sofreu com sistemas que só o “criador” entendia?

    Compartilha aí nos comentários. Vamos abrir esse debate.

  • Meu estilo de programação: Como penso, documento e organizo meus projetos

    Meu estilo de programação: Como penso, documento e organizo meus projetos

    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?