Código para produção
Inscreva-se na newsletter
Receba os novos tutoriais e faça parte da comunidade iafluente!
O impulso para criar certamente é uma das características mais humanas. O processo de dar vida a algo que outrora existia apenas na imaginação é prazeroso e o mundo está repleto de meios que nos possibilitam exercer esse impulso tão primitivo.
Um desses meios é o código.
O código é um meio extremamente maleável e uma sensação comum que se tem ao programar é a de que é possível construir qualquer coisa imaginável, livre das muitas limitações impostas pelo mundo físico. Porém, assim como para outros meios, existem construções e construções.
No mundo físico, uma coisa é construir um puxadinho; outra, é construir a ponte Golden Gate.
Por mais óbvio que pareça, no software, não é diferente. Todavia, é comum encontrar pessoas que estão claramente construindo puxadinho atrás de puxadinho, mas que acham que estão no processo de construir arranha-céus. Dentre os resultados dessa dissonância estão desde projetos lentos e que falham a estresses evitáveis.
O campo de gestão de projetos e desenvolvimento de software é vasto e existem centenas de livros inteiros dedicados ao assunto. Neste tutorial, vamos explorar apenas um pequeno primeiro passo na direção da construção de bom software: uma mudança de perspectiva, do código experimental para o código para produção.
Código experimental
O código que chamo de experimental é o análogo, em software, ao puxadinho, na construção civil.
O código experimental resolve problema que ele se propõe a solucionar. Porém, há pouca ou nenhuma preocupação com o código em si. Toda a atenção está voltada para as informações que ele é capaz de produzir.
Como exemplo de código experimental, cito praticamente todo o código que escrevi durante a minha formação acadêmica. Nesse contexto, programava para gerar gráficos e tabelas para artigos científicos; para gerar artefatos que utilizaria nos trabalhos.
Contanto que fossem evitadas bizarrices, pouco importava se o código estava bem estruturado, se haviam funções mal escritas, código duplicado ou algum teste. O objetivo do programa estava sendo cumprido: gerar os resultados.
Acredito que esse modo de programar predomine no meio acadêmico. É também a forma que se acaba programando quando se aprende a programar sozinho. Isso acontece porque, nesses contextos, o código já costuma nascer com uma data de expiração: a entrega do trabalho ou o fim do projeto pessoal. Passada essa data, o código é praticamente descartado e não há grande preocupação em reutilizá-lo.
Por inércia, o código experimental é também o predominante quando se entra no mercado de trabalho e várias consequências negativas — incluindo o famoso débito técnico — aparecem quando se aplica a mentalidade do código experimental com o intuito de construir algo sólido.
Código para produção
Para construir algo sólido, é necessário o que chamo de código para produção.
No início de seu livro “The Software Craftsman”, Sandro Mancuso narra um ponto de inflexão que aconteceu no início da sua carreira. Assim que recebeu sua primeira tarefa fazendo parte de um time que admirava, trabalhou duro para completá-la no menor tempo possível a fim de impressionar o seu chefe. No processo, também fez questão de escrever trechos de código difíceis de decifrar — para mostrar quão proficiente ele era como desenvolvedor.
Porém, para sua surpresa, quando mostrou seu código para o chefe, em vez de elogios, foi recebido com várias perguntas diretas como1:
- "Está vendo este bloco de código? Se você pensasse um pouco mais, conseguiria reduzi-lo de 8 para 2 linhas."
- "Você pensou que os seus colegas de trabalho, quando forem modificar essa parte do código, talvez não tenham o mesmo tanto de contexto que você tem agora? Como você se sentiria se não soubesse nada sobre essa parte, mas tivesse que mantê-la?"
- "Por que você repetiu este bloco em vários lugares?"
- "Você sabe quão desrespeitoso é isso? (…) Imagina como seria difícil entender o código todo se todo mundo decidisse mostrar o quão inteligente ele(a) é? Imagine milhares ou até milhões de linhas escritas assim."
e a lista continua.
Como lição final, o chefe fala uma frase marcante:
Como é feito é tão importante quanto fazer.
Esse é o espírito do código para produção.
Quando o objetivo é realmente construir com código, a forma com que se alcançam os resultados é tão importante quanto os resultados em si. Isso acontece porque, diferente do código experimental, o código para produção não nasce com uma data de validade: ele está em constante evolução, é mantido por muitas pessoas, e é esperado que seja executado um número indeterminado de vezes, servindo uma quantidade grande de usuários.
Se você quer construir algo sólido com software, você precisa se esforçar para produzir esse tipo de código. Isso envolve uma preocupação com o ambiente de execução do programa para reprodutibilidade, um esforço contínuo para escrever código de forma clara — lembrando que se está trabalhando em equipe e que o código deve evoluir no futuro — testes, documentação, dentre várias outras atividades. Em suma, como o próprio livro de Sandro sugere: tornar-se um artesão de software, que se importa com a sua obra.
Citei que costumava escrever majoritariamente código experimental e, hoje, considero estar em um ponto bem melhor do que o que comecei. Além dos conselhos óbvios como estudar constantemente, aprender com os comentários de pessoas mais experientes, e tentar replicar padrões que observo em bons códigos (de bibliotecas open-source ou da empresa em que trabalho), acredito que a atividade que mais me ajudou a melhorar a qualidade do código que escrevo foi frequentemente refatorar blocos de código que escrevi. Assim como o primeiro rascunho de um texto dificilmente vai ser bom, a primeira versão do código que você escrever dificilmente vai ser clara. Reler algumas vezes e se esforçar para melhorar uma parcela de código já funcional faz maravilhas.
O que é refatoração?
De acordo com Martin Fowler, no livro “Refatoração: aperfeiçoando o design de códigos existentes”, a “refatoração é uma modificação feita na estrutura interna do software para deixá-lo mais fácil de compreender e menos custoso para alterar, sem que seu comportamento observável seja alterado”. Além disso, o autor cita que, quando se está programando, frequentemente alternamos entre duas atividades distintas: a de acrescentar funcionalidades e a de refatorar. Quando se refatora, o objetivo não é acrescentar funcionalidades: é apenas reestruturar o código. Pessoalmente, gosto dessa imagem de alternância e tento mantê-la em mente no dia-a-dia.
Momento certo
Por fim, é importante lembrar que existem situações que clamam pelo código experimental e outras pelo código para produção. Em alguns contextos, é natural que se escreva algo sem a intenção de reutilização, para produzir alguns resultados rápidos. Em outros, deve-se trabalhar em equipe para construir algo para longo prazo. Use os dois modos com responsabilidade, ciente dos trade-offs inerentes a cada um.
-
Tradução livre. ↩