Princípios para produzir um código bonito

Olá, leitores, tudo bem?

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.

Lembram-se do artigo sobre Code Ownership, quando mencionei que desenvolvedores “fogem” do código-fonte de algumas funcionalidades? Bom, eu não acho que eles estejam errados. Todos conhecem o stress e a dificuldade ao trabalhar em um código FEIO, sem contar a expressão que fazemos quando o abrimos:

mr-bean-meme

Concorda comigo ou não? 🙂

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?

Volto na semana que vem! Abraço!

Publicado originalmente em Blog André Celestino

André Celestino

Mais artigos deste autor »

Desenvolvedor de software há 7 anos e autor do blog AndreCelestino.com. Graduado em Sistemas de Informação e pós-graduado em Engenharia e Arquitetura de Software com ênfase em Desenvolvimento Ágil. Atualmente trabalha como Engenheiro de Software.


6 Comentários

Kleitom Antonio Machado de Souza
1

Sua matéria ficou muito legal, concordei plenamente quando sugeriu o uso dos padrões de projeto. Sou grande defensor do MVC, o código fica super limpo, de fácil entendimento e manutenção. Recomendo. Abraços.

André Luis Celestino
2

Opa, legal, Kleitom!
Também sou um grande adepto de padrões de arquitetura, como o MVC e MVP. Acredito que estes padrões contribuem – e muito – para a sofisticação da arquitetura de um projeto.
Obrigado pelo comentário!

Rodolfo Albuquerque
3

Desenvolvimento orientado ao ódio kkkkkkkkkkkkkkkkkkk
Quantas vezes já fiz e já peguei códigos assim?! Me lembra bastante meus tempos de faculdade, deixam saudades.
Parabéns pelo post, brother. Muito instrutivo!

André Luis Celestino
4

Olá, Rodolfo!
Tem razão! Nossos códigos da época acadêmica costumam ser um pouco “feios” mesmo, rsrs. Mas se conseguimos identificar isso, significa que hoje já temos uma senso mais crítico ao ler/escrever o código! 🙂
Obrigado pelo comentário!

Odirlei Borgert
5

Parabéns pelo artigo André!
Realmente as vezes corremos de códigos feios, mal escritos. O que devemos fazer é colocar a refatoração do código como um desafio para resolver o problema.

André Luis Celestino
6

Olá, Ordilei!
Concordo com você! Inclusive existe uma citação do Uncle Bob que gosto de compartilhar:
“Leave the campground cleaner than you found it.”
Se praticarmos a refatoração, principalmente em códigos legados, sempre estaremos contribuindo para a “beleza” do código.
Obrigado pelo comentário! Abraço!

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!