Fala pessoal, este é mais um resumo de um vídeo de uma das referências em desenvolvimento de software, que é o Dave Farley. Mais uma vez, este resumo não substitui assistir ao vídeo e não recomendo fortemente acompanhar os vídeos do Dave lá no canal Continuous Delivery. E mais uma vez, além de um resumo, há algumas opiniões próprias aqui.
No texto de hoje, Dave compartilha algumas características que ele encontrou em algumas das pessoas que ele trabalhou lado a lado durante sua carreira, e tais características faziam delas grandes desenvolvedoras. Quais seriam então, essas características?
Code as communication (Código como forma de comunicação)
Há um vídeo da Alura na qual Paulo Silveira conversa com Fabio Akita sobre boas práticas de programação. Neste vídeo, Akita comenta algo bem interessante, que vou parafrasear: a maioria das boas práticas de programação decorrem de tornar o código legível e manutenível, pois não estamos programando para o computador mais, estamos programando para que outra pessoa possa ter a capacidade de entender o código que estamos escrevendo (e essa outra pessoa pode ser nós mesmos).
Dave Farley comenta a mesma coisa quando afirma que: "o alvo de nossa comunicação quando 'codamos' é outra pessoa, não o computador". Isso é uma verdade quando ele analisa as linguagem de programação modernas que são "focadas em como nós pessoas ao contrário de como o computador funciona". Logo, "nós devemos ter cuidado em se comunicar bem".
Farley vai ainda mais além ao afirmar que um código legível é um "investimento que salva tempo e dinheiro". Portanto, bons programadores investem tempo em deixar seu código claro.
Be cautions of frameworks (São cautelosos com frameworks)
Segundo Farley, frameworks não são o "core de nossas habilidades como desenvolvedores de software". Isso significa que há um risco em usá-los. Dave comenta que o ideal é deixar o core do seu sistema o mais abstraído possível do framework, para que uma mudança nele impacte o mínimo possível no sistema/produto. Por fim, ele dá uma distinção bem interessante entre library e framework: o "código usa uma library, um framework define um código (como estrutura)".
Code as design
Dave começa esse ponto afirmando que "parece que nós geralmente falamos muito mais sobre ferramentas e tecnologias do que sobre design". Ele ainda vai afirmar que "são as formas ('shapes') das soluções que nós criamos que realmente importam muito mais do que as tecnologias que escolhemos para implementar essas formas ('shapes')". Mas o que seria o design então? Ele afirma que o design é o código, pois design são "as escolhas que todos nós fazemos todos os dias quando escrevemos um bom código", e o bom aqui é importante.
Creio que Dave quis argumentar aqui é que bons desenvolvedores entendem que o bom design de uma solução sai da própria solução, do dia-a-dia construindo ela. Fábio Akita comenta isso em um outro vídeo no canal da Alura quando fala a respeito de design emergente ou arquitetura evolucionária. Tal conceito está intimamente ligado com o 11° princípio do Manifesto Ágil: "As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.".
Para finalizar, Dave afirma que: "pense primeiro nas formas que você irá precisar criar e as convenções e conversas que você precisará para fazer o trabalho, só então pense nas tecnologias". Assim, confio que podemos sair desse tópico com o seguinte pensamento: a solução não é a tecnologia, a solução é suportada pela tecnologia, e bons desenvolvedores sabem disso.
Quality over features
"Bons programadores orgulham-se do seu próprio trabalho". É sobre ser prático e pragmático. Eles são bons em entender que a maior parte do tempo que investimos quando trabalhamos com software é na sua manutenção.
Logo, eles vão investir tempo agora em construir código com qualidade, pois sabem que isso irá trazer benefícios na sua manutenção no futuro.
O que seria, portanto, código com qualidade? Aqui vem um assunto um tanto polêmico, mas confio que um código de qualidade é um código coeso e bem testado. Ao ouvir Dave comentando sobre essa característica lembrei de uma frase que encontrei no primeiro capítulo de Clean Code, de Bob Martin: Código limpo é um código que parece ter sido construído por alguém que se importa. Essa frase, no livro, é de autoria de Michael Feathers, conhecido pelo livro Working Effectively with Legacy Code (Trabalhando Efetivamente com Código Legado).
Código limpo é um código que parece ter sido construído por alguém que se importa - Michael Feathers no livro Clean Code
Assim, podemos sair desse tópico com o pensamento de que bons programadores se importam em construir código com qualidade é isso é mais valorizado do que apenas entregar features.
Software development is a social activity (Desenvolvimento de sotfware é uma atividade social)
Qual o primeiro valor do Manifesto Ágil?
Indivíduos e interações mais que processos e ferramentas
Não podemos esquecer que hoje, mais do que nunca, software é uma atividade social.
Dave afirma que "bons desenvolvedores que conheço também são bons comunicadores". Eles expressam ideias claramente e também descrevem ideias complexas a pessoas de maneira clara".
Essa característica se relaciona com a primeira a medida que, "se você achar difícil expressar sua ideia claramente em uma conversa ou em um diagrama, quais são as chances de que você irá conseguir escrever um bom código?"
Como trabalhar essa característica então? Dave cita alguns exemplo: seções de pair programming, palestrar, ensinar, manter um blog.
Por fim, Dave cita uma situação que já aconteceu comigo algumas vezes. Você se encontra preso em uma situação e não consegue encontrar uma solução. Neste momento você chama alguém para conversar pedindo ajuda. Enquanto você descreve o problema para aquela pessoa, descobre uma solução para o problema. Tenho um colega de trabalho, Anthony, que fala que isso se chama psicólogo de programador. Às vezes você só precisa de alguém para te ouvir.
Avoid code ownership
Podemos resumir esse tópico em uma frase:
They are not preicous about their code just because it is their code
Para muitos desenvolvedores, o código que eles desenvolvem é como a próxima figura:
Add alt text
Dave afirma que "A responsabilidade por uma parte do código ou uma área do sistema precisa ser compartilhada com o restante da equipe".
Quando fazemos isso, precisamos estar abertos a ter nosso código criticado e aprender com melhorias vindo de outras pessoas.
Seções de code review e pair programming são importantes nesse aspecto, porque ajudam a compartilhar o conhecimento do código com mais pessoas da equipe.
A última característica é:
Work in small steps
Como começamos uma maratona? Um passo de cada a vez. Assim deve ser o nosso dia-a-dia de trabalho. Conscientes do que estamos fazendo, sabemos que algo grande se constrói peça a peça. Dave afirma "faça progresso em pequenos passos", assim "se procedermos em pequenos passos, nós podemos aprender mais rapidamente".
É interessante como podemos ver isso no Manifesto Ágil quando, no terceiro principio afirma que:
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo
Bem pessoal, acabamos por aqui, mas podemos continuar essa conversa. Se possui mais dicas de como se tornar um programador melhor, compartilha nos comentários.
Até a próxima!