Categorias
Communication Software Development

Como escrever um código limpo e fácil de entender

Nós escrevemos código para pessoas, não para máquinas. Entenda que escrever código é um exercício de comunicação, e comunique-se melhor!

O pessoal costuma dizer que eu tenho uma boa didática. E realmente: eu sempre dou um jeito de explicar qualquer coisa que eu conheça bem pra qualquer um, independente do nível de complexidade.

Pra alcançar esse resultado, eu sempre penso que ensinar algo não é nada mais que fazer uma conexão com algo que a pessoa já conheça.

Isso torna aqueles desafios do tipo “explique um banco de dados pra uma criança” fáceis de responder! A criança conhece brinquedos, então eu só preciso fazer uma analogia com os brinquedos (registros) sendo guardados em caixas (tabelas). Cada caixa guarda apenas um tipo de registro (consistência)… e pronto!

Pra qualquer coisa que você queira ensinar, tenha certeza que a pessoa já conhece algo similar em outro contexto. Você só precisa descobrir o quê é e fazer a ligação.

A base da boa comunicação

Eu levanto a bandeira de que “comunicação não é o que se fala, mas sim o que se entende.”

Nosso objetivo ao comunicar qualquer é coisa é que a outra pessoa nos entenda. Não adianta falar um monte de coisas e não ser entendido. Quem já fez gestão de projetos aí sabe do quê eu estou falando:

Para se fazer entendido, você deve começar entendendo bem quem é sua audiência, o que ela conhece e o que não conhece. Assim, você consegue selecionar exemplos e escolher caminhos que sua audiência já conhece. Veja este:

E aí, tem outra situação. Sabe quando você está se esforçando pra entender algo que alguém está te falando, e você pergunta: “Deixe ver se eu entendi: você quer dizer isso e aquilo?” Aí a pessoa ignora o que você disse e responde: “Pense assim: bla bla bla”… Essa pessoa não entendeu nada sobre comunicação! 🙈🙉

Fale na linguagem de quem você quer atingir. Quem tem que fazer o esforço de comunicação é você! Assim como uma UX bem desenhada, sua comunicação deve induzir o interlocutor ao sucesso.

O que isso tem a ver com meu código?

Existe uma pesquisa, não me lembro agora qual é, que mostra que a parte do cérebro que fica mais ativa enquanto um desenvolvedor trabalha é a parte da linguagem. Não é a parte do raciocínio lógico, como a pesquisa esperava confirmar.

Nós escrevemos código para pessoas. As linguagens de alto nível que usamos são criadas dessa forma para que pessoas entendam. As linguagens modernas são cada vez mais expressivas e semânticas, para que a pessoa possa ler seu código como se lesse um livro.

Eric Evans, brilhante criador do DDD, reconhece isso. Tanto que Domain-Driven Design não é um livro sobre técnicas de programação, e sim uma abordagem que visa mapear a linguagem usada pelos sponsors do projeto, para então entender bem o negócio, para então traduzir processos em código.

Veja essa paletra do Eric Evans sobre Bounded Contexts. É tudo sobre linguagem e clareza de pensamento. É sobre comunicação:

Como colocar tudo isso em prática?

Melhorar a comunicação leva anos de prática e muita persistência. Várias tentativas concientes (e vários erros), com análises subsequentes do quê você poderia ter feito melhor, além do quê você acertou e precisa manter.

Mas vamos a algumas dicas simples:

  • Tente pensar como um(a) designer: ao criar uma tela, uma API, uma classe, um método, pense na sua audiência, em quem vai utilizar o resultado do seu trabalho;
  • Pense sobre o que sua audiência já conhece, e também sobre o que não conhece. Quais são suas habilidades e suas limitações;
  • Na sua empresa, quem são as outras pessoas da equipe? Qual é o nível técnico de quem vai dar manutenção no seu código amanhã ou depois?
  • Os nomes de variáveis e métodos que você está escolhendo são 100% claros? Ou estão ambíguos?
  • Você precisa escrever comentário pra conseguir explicar o que seu código está fazendo? É hora de rever os nomes que você escolhe…

Além disso, estude. Consuma o conteúdo desse site e tenha todo ele na cabeça: Refactoring Guru. Eu não ganho nada para divulgar este site, mas ele é realmente muito bom, com ilustrações excelentes!

Conclusão

Para ser melhor como Software Engineer, você precisa se interessar mais por comunicação. Precisa buscar outros assuntos além do técnico, para se tornar um(a) profissional mais completo(a).

Se não fizer isso, você fica tipo o Johnny Bravo, que só malha peito e braço. Você precisa ser um(a) atleta completo(a), e não apenas um bíceps bombadão. (Olha só como as analogias ajudam!)

Leia sobre boas interfaces de usuário, porque uma boa UI é essencialmente uma boa comunicação, também. Olha só as dicas desse site: Good UI – dicas para aumentar a conversão.

Faça um curso de teatro! (Eu fiz um de Palhaço 🤡, e sou muito feliz por isso!)

Estude muito. Pratique mais ainda. Seja um “eterno insatisfeito.”

Seja 1% melhor a cada dia 🚀


Photo by Jamie Templeton on Unsplash

Por Phillippe Santana

Apaixonado por escrever código que as pessoas possam entender. Sou um desenvolvedor de software, gerente de projetos, empreendedor e entusiasta de pessoas/cultura. Me adicione no [Linkedin](https://www.linkedin.com/in/phillippesantana/) e no [Medium](https://medium.com/@phillippesantana).