Os 3 níveis de um desenvolvedor sênior

Não quero entrar na discussão a respeito de como se define precisamente um “sênior”, mas acredito que há algumas características de design de código cuja presença é imprescindível para qualquer programador profissional que assume essa designação.

Primeiro nível: não há nada para tirar

Pode parecer contra-intuitivo, mas é mil vezes melhor um projeto que não apresenta absolutamente nenhum excesso do que um projeto que “tem tudo o que precisa” mas traz até a pia da cozinha. Especialmente porque ter coisa sobrando é um terrível mau-cheiro, um sinal que a mentalidade que levou a desenvolver o projeto dessa forma é problemática.

É comum no meu trabalho eu cair meio que de paraquedas em um projeto tocado por juniors e até plenos e o que acontece invariavelmente é uma fase inicial de cortes: passo as primeiras horas tentando entender o projeto e, ao mesmo tempo, removendo sobras e coisas desnecessárias. Mas quando caio num projeto e reparo que não existe nada para ser removido, que absolutamente tudo ali é necessário e faz sentido, logo me dou conta que estou lidando com código feito por alguém experiente o bastante para desenvolver essa linda preguiça típica de nós, os velhos.

E não estou falando de detalhes bobos, como usar ipython no ambiente de desenvolvimento local: isso é absolutamente okay. Estou falando sobre “ requirements” de dev sendo levados para prod, dead code, documentação velha, Makefile com comandos que ninguém mais usa e nem funcionam mais, stale entrypoints em Dockerfiles, scripts obsoletos, implementação tupiniquim de coisa que deveria ser feita com biblioteca ou outro serviço e coisas similares. Isso é coisa que deve ser removida, é ruído, é abuso de capacidade cognitiva que já está provavelmente em falta. Num projeto saudável, a maior parte da carga cognitiva deve ser gasta com sinal, não com ruído.

Segundo nível: é fácil encontrar a primeira linha

Ao se integrar em um projeto novo, é comum tentarmos raciocinar sobre como o programa será executado e ajuda muito saber onde está a linha zero, a primeira linha de código custom a ser executada.

Pode ser o script que chama os outros scripts, pode ser o carregamento das configs para em seguida subir o serviço: em algum lugar existe a primeira linha e quão fácil ou quão difícil é encontrá-la diz muito sobre o quão experiente o desenvolvedor é.

Cada repositório tem lá sua geografia própria e o desenvolvedor mais atento sabe bem que programar, afinal, é dizer para outra pessoa o que se quer que o computador faça. Portanto, haverá de aplicar esforço tentando tornar o mapa da coisa toda o mais simples e intuitivo possível, seja com a organização dos módulos, seja com a forma de dar nome aos arquivos.

Nós velhos somos preguiçosos e queremos evitar a fadiga de ter que explicar para o próximo desenvolvedor onde cada coisa está. É muito mais fácil deixar o repositório organizado de maneira tal que as perguntas vão se auto-respondendo, bastando olhar para a hierarquia dos arquivos e então para seu conteúdo.

Terceiro nível: não há muito o que perguntar

Repare que o tema geral aqui é a clareza: quanto mais tempo de carreira o desenvolvedor tem, é de se esperar que aprenda cada vez mais o valor da clareza do código, que influencia diretamente na capacidade da empresa de integrar novos desenvolvedores e na capacidade desses novos desenvolvedores conseguirem entregar valor em tempo hábil e com pouco atrito e pouco sofrimento (todos queremos ter uma vida confortável, afinal).

O projeto já não tem o que tirar e já estou rastreando seu funcionamento a partir da primeira linha de código, que foi fácil de encontrar. Mas agora, na barriga do monstro, percebe-se se o autor conseguiu ser claro o bastante em suas intenções ou se, dado que o problema em si seja suficientemente complexo, teve a sensibilidade de pelo menos indicar o caminho das pedras por meio de comentários estrategicamente posicionados.

Quero expandir um pouco essa parte sobre comentários, porque também sou da opinião que deve-se evitá-los ao máximo. Todavia, há algumas situações em que é interessante enviar uma mensagem diretamente para as próximas gerações.

Recentemente vi um código que transformava coordenadas em graus (epsg:4326) para coordenadas métricas (UTM). Curiosamente, o código limitava o resultado a -80 e 84 graus de latitude. Nessas horas, usar constantes como “UPPER_LATITUDE_LIMIT” não é o bastante para explicar por que, afinal, existe algum limite de latitude: a razão é que as zonas UTM não cobrem os polos, que é justamente o que fica “abaixo e acima” desses limites.

O autor da biblioteca em questão, muito prestativo, colocou em um comentário um link de uma página excelente, simples e curta mostrando de onde vinham aqueles valores e explicando essa questão das zonas UTM: excelente. Tá aí a sensibilidade que comentei.

O desenvolvedor experiente já sabe quais partes do código são realmente complicadas e fará questão de guiar o leitor para as respostas corretas porque, afinal, somos velhos preguiçosos. Também é muito mais satisfatório para o próximo desenvolvedor conseguir entender as coisas por conta própria, sem a eventual frustração de, estando o autor original indisponível, por exemplo, ficar simplesmente “boiando” ou tendo dificuldades de encontrar respostas.

Originally published at https://www.linkedin.com.