Princípios para produzir um código bonito

Fonte: Pixabay

Já parou para pensar que programação é uma arte? Sim, somos artistas, e devemos nos preocupar com a “beleza” do nosso trabalho, já que será contemplado por outras pessoas. No nosso caso, ainda há uma diferença: além da beleza, codificamos funcionalidades para atender expectativas. Isso nos torna mais do que artistas!

O artigo de hoje é baseado em um ótimo texto do autor Hartmut Schlosser.

Desenvolvedores “fogem” do código-fonte de algumas funcionalidades. Todos conhecem o stress e a dificuldade ao trabalhar em um código FEIO, sem contar a expressão que fazemos quando o abrimos.

No entanto, temos que aceitar. A funcionalidade deve ser desenvolvida e, sim, infelizmente é necessário trabalhar no código feio. Segue um conselho, pessoal: elevem suas estimativas, pois um bom tempo será consumido para interpretar o código, compreendê-lo e descobrir o local que receberá a codificação. É complicado.
Todo esse contexto nos leva a um termo conhecido como “HDD”.

Hard Disk Drive?

Não, o significado é Hate Driven Development, ou “Desenvolvimento Orientado a Ódio”. De tanta raiva que o desenvolvedor sente com o código, acaba encontrando uma forma de solucionar o problema (mesmo que paliativa), justamente para fugir do código o mais cedo possível. Sendo assim, por incrível que pareça, o HDD promove a produtividade, haha!
Mas, claro, não é assim que gostamos de codificar. O nosso trabalho deve ser agradável e gratificante, nos motivando a desenvolver a melhor solução com as melhores técnicas. Para que isso aconteça, devemos escrever código BONITO! Não digo só pela facilidade de interpretação e manutenção, mas também porque faremos de tudo para não estragá-lo, ou melhor, não deixá-lo “feio”. Como efeito, seremos contribuintes do Desenvolvimento Sustentável!

Como descobrimos se o código está bonito?

Tecnicamente, não é possível. Não existe um checklist ou um documento com normas para quantificar e qualificar um código bonito, dado que existem diferentes linguagens, segmentos e abordagens. Porém, existem princípios que, quando adotados, nos transformam em melhores “artistas”:

• Usabilidade: um software implementado com código bonito se torna amigo do usuário. É capaz de estender a mão para um usuário novato e conduzi-lo até o objetivo, ou antecipar as necessidades e fornecer orientações conforme necessário. Nada de ambiguidades, confusões ou complicações. Pense em tratamentos de exceções, mensagens informativas e cubra o maior número possível de cenários. Além disso, facilite a interface gráfica para não confundir o usuário com tantas opções.
• Integridade: um código bonito apresenta uma solução plausível para o problema e não traz “surpresas” para outros desenvolvedores (lembre-se do POLA). Quanto mais íntegro, menores serão as manutenções no código, salvo quando houver mudanças na regra de negócio. Um fato importante sobre integridade do código é a equivalência ao baixo acoplamento. Mesmo quando classes ou módulos acoplados forem alterados, o impacto no código íntegro será mínimo.
• Inovação: conceitos da Engenharia de Software são sempre bem-vindos em um código bonito, como, por exemplo, Design Patterns. A iniciativa de encontrar práticas consolidadas no mercado para codificar soluções é uma forma de inovação e pode abrir várias oportunidades para sofisticar a arquitetura. Nesse item, também vale ressaltar as ações para aprimorar a produtividade dos usuários, como atalhos, novos relatórios ou novas formas de utilização das funcionalidades.
• Simplicidade: por fim, um código bonito é simples e não faz mais do que deve fazer, como também não assume responsabilidades alheias. Como diz o Roupa Nova: “As coisas mais simples e as mais sofisticadas se confundem. A sofisticação, às vezes, é encontrada na pura simplicidade”.

Para fechar, pessoal, deixo uma reflexão: o que impede a existência de códigos bonitos?
Ao meu ver, é só uma questão de profissionalismo.
Você é profissional?