About me: I have been working in startups since 2004. I spent 10 years at Apontador/MapLink and was part of Creditas (fintech last valued at $4.8bi) from its early days. Initially, as an Advisor, I hired the first software engineers for Creditas. As the business developed, I joined the project full-time as VP. I scaled the technology team to 150 people and later led international expansion and new product initiatives. I left in 2022 and, after a sabbatical, started working as an independent consultant in 2023.
Um exemplo real de padrões claros
|
Leitor da newsletter e amigo de longa data Renato Viço me mandou uma resposta muito boa sobre o texto de padrões claros e consistência (compartilhado com permissão) Antes de qualquer coisa, vale reforçar: as boas práticas continuam valendo, e talvez sejam ainda mais importantes agora. Aqui vai a resposta dele, na íntegra: Acredito que um ponto que poderia agregar à discussão é que o básico precisa estar muito bem feito: uma suíte de testes funcional e um CI/CD com pipeline rodando corretamente. Sigo algo semelhante por aqui, além da documentação que você mencionou.
Hoje, mantenho uma pasta de documentos estruturada com features, integrações, arquivos base, assets e especificações técnicas de módulos complexos. Como utilizamos o Copilot Enterprise, cada repositório possui configurações específicas e "memories" compartilhadas entre todo o time. Também aplico configurações em nível enterprise para garantir práticas como código modular em toda a equipe.
O ponto mais importante tem sido o reforço de que especificações e unidades devem ser escritas antes da funcionalidade, utilizando cenários de Cucumber/Gherkin (sou adepto do BDD). Com isso, as funcionalidades costumam se "auto-gerar" a partir de comandos simples, mantendo a consistência entre todos os desenvolvedores.
Com o CI configurado, ao subir uma especificação, acontece um auto-review via Copilot. Se são detectados problemas ou "flakes", um agente baseado em Claude atua na correção. Para coordenar tudo isso, tanto localmente quanto no CI, utilizo o Tidewave.ai.
Achei um ótimo exemplo de como padrões, testes e automação começam a trabalhar juntos. Não só como suporte, mas como parte ativa do desenvolvimento. Se você tiver práticas parecidas ou diferentes que estejam funcionando no seu time, me responde esse email. Eu leio todas as respostas e posso compartilhar aqui com os demais leitores. |
Leo Andreucci - CTO Mentor
About me: I have been working in startups since 2004. I spent 10 years at Apontador/MapLink and was part of Creditas (fintech last valued at $4.8bi) from its early days. Initially, as an Advisor, I hired the first software engineers for Creditas. As the business developed, I joined the project full-time as VP. I scaled the technology team to 150 people and later led international expansion and new product initiatives. I left in 2022 and, after a sabbatical, started working as an independent consultant in 2023.
Un lector de la newsletter y amigo de hace muchos años, Renato Viço, me envió una muy buena respuesta sobre el texto de estándares claros y consistencia (compartida con permiso). Antes que nada, vale reforzar: las buenas prácticas siguen vigentes, y quizá son aún más importantes ahora. Aquí va su respuesta, íntegra: Creo que un punto que podría aportar a la discusión es que lo básico necesita estar muy bien hecho: una suite de tests funcional y un CI/CD con pipeline corriendo correctamente....
En el texto anterior, comenté que las especificaciones empiezan a ganar espacio como fuente de la verdad.Pero eso aún puede parecer abstracto. En la práctica, esto empieza a aparecer en algo bastante simple: archivos que describen cómo tu equipo construye software. Cosas como: README guías de código decisiones de arquitectura patrones de organización del sistema instrucciones sobre cómo contribuir Y, más recientemente, esto también aparece en formatos como: constitutions system prompts skills...
No texto anterior, falei que especificações começam a ganhar espaço como fonte da verdade. Mas isso ainda pode parecer abstrato. Na prática, isso começa a aparecer em algo bem simples: arquivos que descrevem como o seu time constrói software. Coisas como: README guidelines de código decisões de arquitetura padrões de organização do sistema instruções de como contribuir E, mais recentemente, isso também aparece em formatos como: constitutions system prompts skills e playbooks para agentes O...