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:
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
6 Comentários
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.
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!
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!
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!
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.
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!