Em grande estilo neste mês de novembro, a #DevParaná contou com a ilustre participação de Uncle Bob, autor de diversos livros que são é (ou deveria) ser de conhecimento de 10 a cada 10 desenvolvedores de código.
São regras bem claras e diretas ditas por alguém que vê códigos desde 1960 e conhece como poucos os desafios enfrentados bem como a evolução da tecnologia.
São mais de 15, então separamos neste post as 5 primeiras de sua palestra.
As expectativas de um CTO como Uncle Bob
1. Não me entregue porcaria / “we should not ship shit”
Esta primeira regra apesar de óbvia e a minha tradução ter pegado um pouco leve em “porcarias” quer dizer que é fundamental que não seja entregue código ruim na iterações. Se você sabe que produziu algo que ficou ruim, nem deveria perder tempo fazendo Pull Request e fazer os outros membros do time revisar código ruim.
Mais do que isso, o primeiro revisor do PR deveria ser você e ninguém melhor que você mesmo para se dar ao respeito e não considerar código porcaria como entregue (eu diria até para estágios de aguardando revisão que seria equivalente à “aguardando para ser entregue”) pois partimos do pressuposto que apesar de não estar entregue, você desenvolvedor considera “pronto para entregar”.
É simples e deveria ser um princípio entre pares de trabalho.
2. Estaremos sempre prontos / “we will always be ready”
Código homologado mas não produtivo!
Está revisado, está homologado mas… não pode ir pra produção. Esse é um dos exemplos.
Do ponto de vista da área de negócios, está tudo bem “não estar pronto para ir pra produção” mas do ponto de vista técnico isso não seria negociável para Uncle Bob como CTO.
Aliás, Uncle Bob é extremamente enfático ao dizer que não é aceitável do ponto de vista dele regredirmos para coisas como “versão Beta” onde um cliente estaria disposto a usar uma versão com defeitos ainda em fase de testes.
Aqui, a equipe está segura e confiante com o que foi entregue até então e não há tanto receio com relação a implantação do código em produção.
3. Produtividade Estável / “stable productivity”
Não iremos demorar mais tempo para fazer uma mesma atividade hoje do que ano passado.
Faz sentido mas sabemos que não é a realidade de alguns códigos que vão se tornando tão complicados que tornam tarefas simples mais complexas de serem executadas do que anteriormente. Deveria ser mais difícil no começo, no desenvolvimento. Depois, deveria ser mais suave.
Produziremos mais rápido, não o contrário. Nossa bagunça não deve nos atrapalhar.
4. Adaptabilidade econômica / “inexpensive adaptability”
A adaptabilidade está diretamente relacionada com a produtividade mas a diferença fundamental é que aqui estamos falando das adaptações, ou seja, as mudanças e as evoluções.
Não deveria ser mais caro, demandar mais recursos, mais tempo, apenas NÃO DEVERIA.
Mudanças sempre haverão e adaptar não deveria ser um problema nem custar mais caro, apenas NÃO DEVERIA.
Manutenção (adaptação) não deveria dar tanto trabalho quanto pensamos. Apenas NÃO DEVERIA.
5. Melhoria Contínua / “continuous improvement”
E pra encerrar esta primeira lista de 5 expectativas, aquela regra de do escoteiro:
Se assim não pensar, terás a curto prazo um código cada vez pior.
