Olar, provavelmente você já tenha estudado muito sobre o que são boas práticas de programação, nesta série de artigos irei explicar de forma mais detalhada o que NÃO FAZER no desenvolvimento de software, explicando o que são alguns Code Smells que talvez grande parte das pessoas desenvolvedoras já tenha feito alguma vez na vida.
Primeiramente, o que são Code Smells?
São sintomas de erros superficiais de um problema mais profundo no seu código, você pode ver uma definição mais completa neste artigo do Martin Fowler: https://martinfowler.com/bliki/CodeSmell.html
Esta série de artigos irá demonstrar alguns Code Smells que podem ocorrer em diversas linguagens de programação e dar umas dicas de como resolvê-los.
Neste primeiro artigo vou falar do tipo Bloaters do Code Smell:
Bloaters são códigos,métodos e classes que com o decorrer do tempo tomaram proporções gigantescas que dificultam o sistema de ser manutenível e escalável. Geralmente só percebemos esse tipo de smells quando o sistema cresce e fazer uma alteração ou adicionar uma nova feature. São aqueles códigos que são escritos “da forma errada”, e viram um débito técnico que, com o decorrer do tempo só aumenta.
O primeiro exemplo de Code Smell do tipo Bloater é o Data Clumps (Agrupamento de todos):
Muitas vezes partes diferentes de código contém grupos idênticos de variáveis (parâmetros de configurações, rotas de acesso, etc), o ideal é que esses grupos sejam transformados classes para serem acessados sem a repetição desses mesmos parâmetros em várias partes do código.
Geralmente ocorre pela falta de uma estrutura modularizada e frequentes “copy and paste” ao longo do desenvolvimento.
Como corrigir esse problema?
Aqui algumas sugestões do que fazer nesses casos:
Realizar Preserve Whole Object (quando temos vários valores de um objeto e o passamos como parâmetro para um método, podemos passá-lo como um objeto contendo esses dados, mais detalhes sobre essa técnica em: https://refactoring.guru/preserve-whole-object).
Aplicar Introduce Parameter Object (quando seus métodos contêm um grupo de parâmetros repetidos,podemos substituir ele por um objeto, um pouco semelhante ao anterior, mais detalhes em: https://refactoring.guru/introduce-parameter-object).
Se a repetição desses campos fazer sentido estar em uma classe separada para acesso a esses dados através de Extract Class (quando uma classe está fazendo o trabalho de duas, não está seguindo o princípio da responsabilidade única (SRP),podemos extrair esses métodos para uma nova classe e inserir todos os métodos e campos referentes a sua funcionalidade, mais detalhes em: https://refactoring.guru/extract-class).
Esse foi um tipo de Code Smell, nos próximos artigos irei abordar outros, segue algumas referências que utilizei e dicas de estudo sobre o assunto:
https://martinfowler.com/bliki/CodeSmell.html
https://refactoring.guru/refactoring/smells/bloaters
https://refactoring.guru/smells/data-clumps
https://martinfowler.com/bliki/DataClump.html
https://refactoring.guru/preserve-whole-object
https://refactoring.com/catalog/preserveWholeObject.html
https://refactoring.guru/introduce-parameter-object
https://refactoring.com/catalog/introduceParameterObject.html
https://refactoring.guru/extract-class
https://scrutinizer-ci.com/docs/refactorings/extract-class
https://refactoring.com/catalog/extractClass.html
https://www.infoq.com/br/presentations/principios-solid/
https://engineering.contaazul.com/princ%C3%ADpios-solid-srp-e-sopa-de-letrinhas-d569fd0f80d9
Top comments (6)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.