Ao longo dos anos acabei por desenvolver um tipo de “paranoia” por performance. E por performance não compreenda performance da aplicação código, mas sim de “escrita de código”: “O que eu preciso fazer para codar mais rápido”? Na minha cabeça, cada segundo ganho, ao final de um período poderia representar um ganho significativo na entrega. Nunca parei para validar essa proposição, mas inegavelmente esse comportamento me ajudava a me sentir produtivo, o que impacta a autoconfiança, melhorando engajamento e refletindo realmente na produtividade. Quem produz feliz, produz mais. Ao longo desse artigo, quero trazer alguns insights que podem ajudar você a codificar mais rápido.
Para codar mais rápido, diminua a tentativa e erro
Você puxou aquele card para a coluna de desenvolvimento. O repasse técnico foi bom, então você acredita que nem precisa ser o card de novo. Então você simplesmente abre a sua IDE, coloca música no fone de ouvido e coda como se não houvesse amanhã. Quem nunca?
Essa prática é bem legal quando estamos codando pra relaxar (e sim, eu codo para relaxar). Mas não é nem um pouco profissional. Além da possibilidade de estarmos fazendo confusão enquanto codificamos a história/feature, também não temos certeza do que encontraremos pela frente; se a solução que vamos adotar, faz sentido para o código; qual vai ser o extensão da modificação que faremos no código. Esso comportamento nos faz abusar da tentativa e erro durante o processo de desenvolvimento. O que pode causar impactos de todos os tamanhos, sendo que os grandes afetam toda a entrega do time.
O código mais rápido e certeiro é aquele que você já escreveu antes ou que já sabe o que escrever. Portanto, antes de abrir a IDE, gaste um bom tempo lendo o card e desenhando a solução na sua cabeça, por mais simples que a tarefa ou a sua solução seja. Se for o caso, até desenhe no “papel de pão”. Experimente o desenho para validar com alguém do seu time a sua ideia. Feito isso, abra o código e procure antever mudanças que você precisará fazer no design de código da aplicação. Tendo certeza da estratégia de desenvolvimento, as expectativa de retrabalho diminui drásticamente. E quanto menor o retrabalho causado por você, melhor é a percepção da sua performance.
Para codar mais rápido, adote padrões
Todo time possui uma padronização de nomenclatura, e esse é um assunto polêmico. Pouco antes da pandemia, começou a ser disseminada a ideia de que pessoas desenvolvedoras eram artistas digitais, cujo código era uma expressão da sua criatividade e identidade. Essa ideia criou mais forças durante a pandemia e vez ou outra, eu ainda encontro pessoas que defendem essa linha de pensamento.
Particularmente eu não tenho nada contra ela, inclusive já fui entusiasta. No entanto, eu tenho um contraponto: A Capela Sistina, sem sombra de dúvidas, é uma das maiores expressões artísticas da humanidade, cuja assinatura é de ninguém mais, ninguém menos que Michelangelo. Mas não se engane, ele não fez tudo sozinho. Um batalhão de outros artistas o ajudaram com o gesso, a mistura da tinta, o traçado dos desenhos. E mesmo assim, ao olhar para o teto da capela, está claro o estilo do artista.
Se Michelangelo leva a fama pela casa de oração, no ramo dos códigos, quem leva a fama pela entrega é o time. E a adoção de padrões facilita isso. Lembre-se que todos nós somos passageiros em uma empresa. Qualquer vicissitude da vida pode nos levar para outro lugar e o time que fica, precisa manter aquilo que construímos. Um código dentro dos padrões ajuda a diminuir o esforço para entender o que cada solução faz. E isso deve ser uma das coisas garantidas durante o processo de code review: Que aquele código possui a cara do time. Mas a adoção de padrões ajuda em outros pontos na sua performance.
Para codar mais rápido, automatize tarefas cotidianos
Nem todo tempo de desenvolvimento é gasto escrevendo uma funcionalidade. Existem tarefas que nós precisamos fazer cotidianamente. Quer exemplos? Levantar partes do ambiente localmente; alterar ou conferir configurações do sistema; renomear ou alterar partes do design de código; ver quais serviços estão usando essa ou aquela API. E se em cada artefato você está fazendo isso de modos diferentes, investigar e modificar isso vai exigir um trabalho muito maior de conferência.
Eu já sofri essa dor quando, enquanto consultor em uma empresa, fui obrigado a escrever e manter quatro aplicações e duas bibliotecas praticamente iguais, mas que por exigência do arquiteto, cada uma deveria ter o seu próprio repositório. Na terceira mudança em lotes que eu precisei fazer, gastei algumas horas pesquisando na internet, e automatizei o processo de manutenção dessas aplicações, aumentando consideravelmente a minha percepção de performance, praticamente igualando o cycle time de quem estava trabalhando com um artefato apenas.
Essa prática eu ainda mantenho enquanto Arquiteto. Apenas para exemplo, eu tenho scripts bash para mover cards, abrir pull requests em vários repositórios simultaneamente (e dependendo do caso, até fazer o merge), scripts que atualizam todos os repositórios localmente, pipelines que fazem a atualização de pacotes, rodando testes de unidade e abrindo Pull Request. Fora isso, tenho no histórico do meu terminal vários comandos que me ajudam a localizar trechos de código, sanar rapidamente dúvida sobre configurações do sistema… Enfim. Tudo isso, graças ao time que pensa e mantém os padrões que estabelecemos.
Para codar mais rápido, teste localmente antes de testar remotamente.
Histórias bem escritas possuem critérios de aceite bem claros. Escrever testes de unidade baseados neles é uma boa forma de garantir que a sua implementação irá passar pelo controle de qualidade. Contudo, só isso não basta. Quem gosta de garantir a qualidade das suas entregas não abre mão de ver o código rodando. E o melhor lugar para essa aferição é a máquina do desenvolvedor.
Isso porque, rodando localmente, você tem a oportunidade de debugar o código e entender porque a sua aplicação está se comportando de um jeito completamente diferente do que você esperava. Também tem a oportunidade de ver melhorias de observabilidade (ok, essa percepção vai ser bem melhor na nuvem, mas localmente é um começo). Localmente você tem oportunidade de simular cenários caóticos (indisponibilidade de componentes, timeout, concorrência com banco de dados e etc.) garantindo que a sua aplicação está suficientemente resiliente.
No entanto, especialmente em cenários de micro serviços, rodar localmente não é uma tarefa fácil. Iniciativas como o .Net Aspire buscam reduzir o esforço. Mas na minha singela opinião, o bom e velho docker compose ainda é uma solução mais simples. Com certeza ela te obriga a ter algum conhecimento a mais sobre docker, mas particularmente não vejo isso como algo negativo. Mas levantar o ambiente é só uma das coisas que podem garantir performance através da qualidade do seu código. A próxima é:
Para codar mais rápido, automatize os cenários de teste
Alguns cenários de testes são tão simples quanto “Dado que haja um registro no banco de dados, quando iniciar o processamento, então o registro é processado e apagado”. Contudo, conforme a aplicação cresce, esses cenários vão ficando cada vez mais raros. E você precisa lidar com atualizações de banco de dados, levantar/derrubar componentes, gravar itens por API, publicar mensagens na mensageria (real ou emulada). E todo esse setup repetitivo consume justamente aquele bem mais valioso: tempo.
Na medida do possível, busque automatizar a criação dos seus cenários de testes. E quando falo isso, não pense que estou sugerindo você abrir o Selenium e escrever os testes automatizados. Eu estou falando em ter um arquivo com SQLs que você roda no seu SQL Client e o cenário está pronto para testes; arquivos bash/batch que alteram o ambiente, chamam APIs, fazendo em milisegundos aquilo que você gastaria alguns minutinhos pra fazer. Um cenário de testes, que leva um minuto para ser configurado e executado, se executado 30 vezes (chutando baixo) durante o processo de desenvolvimento, se automatizado, pode economizar 30 minutos do seu tempo. E não apenas do seu.
Seu output pode ajudar e até mesmo ser reaproveitado pelo time de qualidade, enquanto responsáveis por criar os testes automatizados e fazer testes exploratórios. Dessa forma, o seu esforço acaba maximizando não apenas a sua entrega pontualmente, quanto também a de todo o time. Além, claro, de ajudar uma boa pessoa de QA a explorar os limites da sua implementação.
Para codar mais rápido, use melhor o seu intelecto
Como você pode ter percebido, todas as dicas podem ser resumidas em dois pontos principais: Colaboração e automatização. Sim, quando eu sigo padrões ou compartilho códigos/automações, eu também estou colaborando com o time. Mas você pode pensar: “Poxa, mas o tempo que eu vou gastar escrevendo essas automações vai ser tão grande que compensa nem fazê-las”. E sim, você estaria certo há alguns anos. Porém não posso concordar com você hoje.
Muitos times possuem contas com Github Copilot, Claude e outros agents de inteligência artificial, que servem de grande ajuda durante o processo de codificação. Já outros times não possuem essa “graça divina” e precisam usar uma conta gratuita do ChatGPT ou até mesmo do DeepSeek. Em ambos os casos, claro, se você tiver cuidado para não compartilhar segredos da empresa (nem mesmo aquela connection string do ambiente de dev, viu?), você pode usar a Inteligência Artificial para escrever os scripts que te ajudarão nas automações necessárias. Isso é usar melhor o intelecto.
As pessoas acabam gastando muito tempo com vibe coding ou esperando que a I.A. faça o desenvolvimento por elas. Na minha humilde opinião, esse é o pior uso da I.A. Como toda ferramenta, ela precisa ser utilizada para executar aquelas tarefas que são menos intelectuais e que exigem uma carga cognitiva menor. Precisa criar o esqueleto de um padrão de projeto? Usa a IA. Precisa automatizar o fechamento de features de acordo com o andamento das histórias? Pede pra IA te ajudar a escrever uma pipeline pra isso. Você é muito importante pra se preocupar com tarefas tão simples. Qualquer um pode apertar um parafuso com uma chave de fenda. Seja a pessoa que sabe qual parafuso apertar e qual o torque ideal.
Para codar mais rápido, tenha uma boa Developer ToolBox
Todo esse papo começou porque recentemente fui levado de volta às trincheiras da codificação. E a minha habitual neura por performance voltou. Sim, eu sou desses que prefere decorar teclas de atalho a utilizar o mouse. E para ganhar minutos, eu sempre escrevia uma ou outra aplicação que me ajudava com as partes chatas da codificação (formatar SQL, formatar código, enviar mensagens pra um tópico em massa, etc). E percebi que pouca gente da minha bolha local mantém uma prática parecida.
Eu entendo que, talvez, porque agora as coisas ficaram mais difíceis. Com o bom e velho Delphi, bastava que eu arrastasse um componente pra tela e estava tudo pronto (RAD: Ame e odeie). Hoje, é um baita trampo você criar uma aplicação, escolher um framework, alinhar as divs, e ainda escrever uma API. Foi pensando nessa dor de cabeça que eu acabei criando o Developer Toolbox.
O que o Developer Toolbox faz?
Eu não queria ficar apenas no artigo. Queria oferecer para a comunidade de desenvolvimento um toolset de ferramentas que pudessem ajudar no cotidiano. Essa primeira versão possui uma manipulador do Service Bus Emulator e um mantenador de “Segredos compartilhados”.
Se você está usando o Service Bus Emulator, sabe que a única forma de se integrar com ele é via aplicação, já que o Service Bus Explorer ainda não consegue acessá-lo (acho que falta implementar algumas APIs no emulador). Por isso escrevi um visualizador que lê as mensagens do tópico e também tem a capacidade de enviá-las. Imagino que isso pode facilitar o processo de testes locais quando a aplicação precisa se comunicar com o Service Bus da Azure.
A outra feature disponível é a de “Segredos Compartilhados”. Sempre que alguém precisa configurar um serviço novo, temos que compartilhar (e depois apagar) uma lista de parâmetros, que pode ou não ter as famigeradas “password=12345”. Esse compartilhamento, por mais inocente que seja, pode causar problemas de compliance e segurança. Sem contar que as pessoas podem não estar disponíveis no momento em que precisamos desses arquivos de configuração. Esses “segredos públicos” podem ficar armazenados nessa aplicação, facilitando até mesmo o processo de onboarding de novos membros no time.
Colabore!
Caso tenha se interessado pela Developer Toolbox, você pode baixar o docker compose, que tem tudo o que você precisa para rodar localmente. Para isso, acesse: blogdoft/developer-toolbox-compose. Esse docker compose apenas faz referência às imagens. Fiz dessa forma, porque algumas empresas podem ter problema com a clonagem de repositórios externos.
Mas caso você queira dar uma olhada no código, queria sugerir features ou relatar bugs, você pode acessar blogdoft/developer-toolbox: A performance toolbox improvement.
Eu agora estou ouvindo um bebê chorar e acho que hora de trocar fralda. Vou deixando vocês por aqui, mas volto para ler as suas opiniões sobre o artigo e a aplicação que construímos.
Até logo!