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