O escritor e o desenvolvedor

by George Y. Kussumoto

TL;DR: leia mais código

Seria o desenvolvedor, também um escritor ? Afinal escrevemos texto/código, temos nossos "movimentos" que demonstram características não apenas de comunicação, mas também estético e quase filosófico.

Um trecho clássico do parnasiano, mais famoso por cair no vestibular do que por conhecimento popular:

Tu artista, com zelo,

Esmerilha e investiga!

Níssia, o melhor modelo

Vivo, oferece, da beleza antiga.

(Raimundo Correia)

Com certo "glamour" é claro, evidenciam o apreço pelo trabalho, não é só escrever por escrever, mas o que está por trás do ato (vish!).

De modo geral, é assim com o desenvolvedor também. Não é só uma questão de elegância no código, mas da solução, do cuidado, das escolhas entre os "trade-offs" de cada implementação.

Porém, existe uma diferença tão importante entre os dois, escritor e desenvolvedor, que tentarei (com sorte) ressaltar neste texto.

O escritor é primariamente um leitor, torna-se escritor por motivos diversos, porém é impossível de existir sem um enorme legado e bagagem de leitura passada.

Nós, desenvolvedores, não temos essa cultura (de certa forma) como pré-requisito. Muitos vão ler código ao se tornarem profissionais da área, por obrigação do trabalho, não por hábito.

Há um quê de dificuldade ao ler código de outra pessoa. Alguns casos por falta de compreensão do problema, outros por ficarmos constantemente nos perguntando o porquê de uma escolha X ou Y. Um certo preciosismo também ao pensar na nossa qualidade técnica contrapondo o que outra pessoa fez, enfim, uma série de barreiras mentais que não existe ao lermos uma obra literária.

Diferentemente de um leitor usual, pode ser difícil para um desenvolvedor médio citar, por exemplo, outro desenvolvedor ou um trecho de código terceiro. Exceto talvez por alguns que já são "clássicos", difícil alguém demonstrar o mesmo tipo de admiração que um Drummond ou Machado de Assis possuem (eu sei que existe, mas é tão raro).

"aqueles que não podem lembrar o passado, estão condenados a repeti-lo"

Tive a sorte de iniciar minha carreira em uma empresa que obrigava o "code-review". Independentemente de qualquer coisa, sem casos especiais, review e ponto.

Até aquele momento, tive pouco feedback sobre o código que eu produzia. Já tinha lido código, tanto em livros acadêmicos quanto nos "zines" que existiam antigamente, mas eu estava longe, e muito, de estar preparado.

Não era porque eu me achava melhor programador do que de fato era, algo excelente de quase todo mundo da área é o fato de reconhecermos que sempre existe espaço para mais conhecimento. Assim como eu não estava preparado, muitas pessoas ainda sentem uma dificuldade grande em conversar sobre código, quase como se fosse um tabu.

O primeiro aprendizado e talvez o mais difícil (principalmente para nós, brasileiros) é o distanciamento entre autor e obra. É complicado receber críticas, a maioria de nós reage muito mal quando isso acontece, se colocando em uma posição defensiva e poucas vezes se perguntando a razão de um argumento ou idéia, como se alguém necessariamente precisasse estar errado.

Entender que o julgamento é sobre o código e não sobre o desenvolvedor pode demorar um pouco. E código infelizmente não carrega contexto junto, aquele "workaround" pode ter sido uma solução feita 3am de um sábado sob pressão, revisado "por cima" porque o problema era crítico (sempre é) e toda empresa olhava pra equipe de TI com olhos assassinos.

Esse programador é ruim ? Não! Diria até que foi altamente competente e profissional. Mas o código pode ser. Novamente, "O código pode ser".

Até hoje eu ainda cometo esse equívoco ao me expressar, mas ao revisar código é importante deixar claro que as questões são sobre o código e não sobre quem escreveu. É sutil e crucial a diferença entre um comentário - "porque você não usa X pra evitar Y" e "porque não usar X pra evitar Y".

Para complementar, existem questões subjetivas como estilo e qualidade que no geral é pontual, mas pode gerar um pouco de atrito na equipe, o uso de uma diretriz tende a dar um alinhamento nessas questões.

Lembro que um dos problemas que resolvi no meu primeiro emprego (em alguns pontos) foi sobre performance. Não era uma questão de otimização prematura, mas os primeiros ORM's (hello SQLObject) não tinham quase nada de "lazy evaluation/cache", então era preciso ter bastante cuidado ao acessar alguns campos ou relações para não gerar um número absurdo de consultas no banco de dados.

Meu revisor sempre questionava sobre o número de consultas e o resultado final geralmente era um código menos claro/expressivo que o original, porém um código totalmente otimizado era quase ilegível. Com o tempo começa a ficar mais evidente como balancear "trade-offs" ou evitar certos problemas e complexidades desnecessárias.

O fator de "convencimento" é o tempo. Um desenvolvedor que nunca passou tempo suficiente dentro de um projeto pode ter dificuldade em aceitar a importância de ter testes por exemplo. Hoje em dia algumas boas práticas parecem muito óbvias, mas nem sempre foi assim, experiência nunca é de graça e geralmente também não é indolor.

Eis que chega um dia em que:

mind blown

Você finalmente tem a experiência necessária para compreender na prática o que outras pessoas estão falando (e junto, alguns cabelos brancos). E aí que quando você for revisar código, um sinal de alerta vai ecoar na sua mente diante de alguns padrões. Se você tiver oportunidade de olhar um código próprio mais antigo, pode ser que encontre algumas pérolas.

(side quest: A primeira vez em que olhei um código antigo, achei engraçado por um lado, mas também senti uma certa vergonha. Fiz o favor de me convencer que vergonha mesmo era continuar escrevendo código ruim. Ainda que continue ruim, que seja por motivos diferentes ;) )

Compreender o valor de uma boa prática tem o efeito imediato de ser propagado porque você, como revisor, não vai mais deixar de notar um gorila e vai explicar a razão para aqueles que ainda não passaram pelo problema. A revisão de código não só dissemina conhecimento sobre a base de código que um time trabalha, mas também sobre boas práticas descobertas por cada integrante da equipe.

Embora seja quase senso comum, tente racionalizar porque qualquer desenvolvedor vai ser absolutamente contra duplicação de código.

Eventualmente, nunca mais se tem problemas oriundos de duplicação de código, enterramos no passado.

(mas alguns problemas possuem a audácia de ressuscitar...)

Ainda estamos falando de escritor e desenvolvedor ?

Tenho alguns vícios de código, digamos assim, que repito constantemente. Embora eu compreenda o porquê, posso nunca ter deparado com o problema na vida. Exagerando num exemplo, nunca desenvolvi num modelo cascata para ser favorável ao modelo ágil (com ressalvas).

Mas eu tive que estudar, ler e entender. Com código, a mesma coisa, muito do que escrevo veio de outras pessoas, li, entendi e adotei. Evidentemente que é bastante saudável questionar o que é dado como verdade, e nada como boas leituras para levantar bons questionamentos.

Algumas experiências são traumáticas na vida de um programador, mas nem todas precisam ser (evitar dores pode ser um tremendo incentivo pra se estudar mais).

Em um texto com verso livre e cheio de metalinguagem, pode ser inevitável não referenciar Fernando Pessoa mesmo que implicitamente. De forma semelhante, cada linguagem de programação tem práticas que são mais ou menos aceitas por sua comunidade, já reparou como é simples reconhecer um código java ou C# (além da sintaxe) ?

Dito isso, é importante ter em mente que revisar código não é ser uma espécie de revisor ortográfico humano (embora seja parte do processo). Assim como quando fazemos "pair-programming", outros olhos no mesmo código possuem a oportunidade de ter uma visão mais ampla da implementação e como ela se encaixa dentro de um contexto maior, não só em detalhes de estilos e conformidades de alguma diretriz.

É preciso mais do que um português correto e a estrutura de soneto para "soar" como Camões, certo ? Um bom código possui conformidade além das diretrizes e boas práticas conhecidas, está alinhado também com os fundamentos da linguagem usada.

Quando Kenneth Reitz lançou a biblioteca requests, não demorou muito pra ser adotada quase que de forma viral em todos projetos python que precisasse fazer requisições HTTP, sua implementação é absolutamente simples, flexível e enxuta.

Embora, boa parte de programadores python conheçam a biblioteca requests e seu autor, acredito que poucos notaram instantaneamente a mentira que eu disse.

Como um mantra, memento mori - numa tradução livre - lembre-se de ler código. ;P

Para terminar com um mais do mesmo, esse texto representa apenas algumas opiniões pessoais, desconfie.

(side quest 2: já que chegou até aqui, se ainda não viu, assista Raymond Hettinger - Beyond PEP 8 - palestra obrigatória, imho, sobre o assunto)

Be nice o/