Como encontrar as partes fedorentas do seu código [Parte XXIX]

Cheiros de código são um clássico.

Cheira porque provavelmente há muitos casos em que poderia ser editado ou melhorado.

A maioria desses cheiros são apenas indícios de algo que pode estar errado. Portanto, eles não precisam ser consertados per se... (Você deve dar uma olhada nisso, no entanto.)

Código anterior cheira

Você pode encontrar todos os cheiros de código anteriores (Parte i - XXVIII) aqui.

Vamos continuar...

Code Smell 141 - IEngine, AVehicle, ImplCar

Você já viu um IEngine em estado selvagem?

TL;DR: Não prefixe ou sufixe suas classes

problemas

• Legibilidade
• Falha de bijeção
• Nomes de Implementação

Soluções

1. Remover prefixos e sufixos
2. Nomeie seus objetos de acordo com o que eles fazem

Contexto

Algumas linguagens têm convenções culturais relacionadas a tipos de dados, classes abstratas ou interfaces. Esses nomes carregam nossos modelos com traduções cognitivas difíceis de seguir.

Devemos BEIJAR .

Código de amostra

Errado

 public interface IEngine { void Start(); } public class ACar { } public class ImplCar { } public class CarImpl { }

Direita

 public interface Engine { void Start(); } public class Vehicle { } public class Car { }

Detecção

• [x] Automático

Se tivermos um dicionário de sinônimos, podemos apontar nomes estranhos.

Exceções

Em C#, é comum colocar "I" no nome de uma interface porque, sem ele, não dá para saber se é uma interface ou uma classe.

Este é um cheiro de linguagem.

Tag

• Nomenclatura

Conclusão

Use nomes reais para seus modelos.

Relações

Code Smell 130 - AddressImpl

Mais informações

• O que há em um nome: Parte II Reabilitação

Créditos

Foto de Tim Mossholder no Unsplash

Algumas pessoas, quando confrontadas com um problema, pensam “eu sei, vou usar expressões regulares”. Agora eles tem dois problemas.

Jamie Zawinski

Grandes Citações de Engenharia de Software

Code Smell 142 - Consultas em construtores

Acessar um banco de dados em objetos de domínio é um cheiro de código. Fazer isso em um construtor é um cheiro duplo.

TL;DR: Construtores devem construir (e provavelmente inicializar) objetos.

problemas

• Acoplamento
• Efeitos colaterais

Soluções

1. Separe a lógica de negócios essencial da persistência acidental.
2. Em classes de persistência, execute consultas em funções diferentes de construtores/destruidores.

Contexto

No código legado, o banco de dados não está separado corretamente dos objetos de negócios.

Construtores nunca devem ter efeitos colaterais.

De acordo com o princípio da responsabilidade única, eles só devem construir objetos válidos

Código de amostra

Errado

 public class Person { int childrenCount; public Person(int id) { childrenCount = database.sqlCall("SELECT COUNT(CHILDREN) FROM PERSON WHERE ID = " . id); } }

Direita

 public class Person { int childrenCount; // Create a class constructor for the Main class public Person(int id, int childrenCount) { childrenCount = childrenCount; // We can assign the number in the constructor // Accidental Database is decoupled // We can test the object } }

Detecção

• [x] Semiautomático

Nossos linters podem encontrar padrões SQL em construtores e nos avisar.

Tag

• Acoplamento

Conclusão

A separação de preocupações é fundamental e o acoplamento é nosso principal inimigo ao projetar um software robusto.

Mais informações

• Acoplamento: o primeiro e único problema de software

Créditos

<span>Foto de Callum Hill no Unsplash </span>

Minha crença ainda é que, se você acertar as estruturas de dados e suas invariantes, a maior parte do código se escreverá sozinho.

Peter Deustch

Grandes Citações de Engenharia de Software

Cheiro de Código 143 - Aglomerados de Dados

Alguns objetos estão sempre juntos. Por que não os separamos?

TL;DR: Faz com que objetos primitivos coesos viajem juntos

problemas

• Coesão Ruim
• Código duplicado
• Complexidade de validação
• Legibilidade
• Manutenibilidade

Soluções

1. Extrair classe
2. Encontrar objetos pequenos

Contexto

Esse cheiro é amigo da obsessão primitiva.

Se dois ou mais objetos primitivos estiverem colados, com lógica de negócios repetida e regras entre eles, precisamos encontrar o conceito existente de bijeção .

Código de amostra

Errado

 public class DinnerTable { public DinnerTable(Person guest, DateTime from, DateTime to) { Guest = guest; From = from; To = to; } private Person Guest; private DateTime From; private DateTime To; }

Direita

 public class TimeInterval { public TimeInterval(DateTime from, DateTime to) { // We should validate From < To From = from; To = to; } } public DinnerTable(Person guest, DateTime from, DateTime to) { Guest = guest; Interval = new TimeInterval(from, to); } // Even Better... public DinnerTable(Person guest, Interval reservationTime) { Guest = guest; Interval = reservationTime; }

Detecção

• [x] Semiautomático

A detecção baseada em padrões de coesão está disponível em alguns linters.

Tag

• Coesão

Conclusão

Agrupe o comportamento no lugar certo e oculte os dados primitivos.

Relações

Code Smell 122 - Obsessão Primitiva

Cheiro de Código 01 - Modelos Anêmicos

Cheiro de Código 27 - Arrays Associativos

Mais informações

• Guru de refatoração
• Wikipédia

Créditos

Foto de Dynamic Wang no Unsplash

O coração do software é sua capacidade de resolver problemas relacionados ao domínio para seu usuário. Todos os outros recursos, por mais vitais que sejam, suportam esse propósito básico.

Eric Evans

Grandes Citações de Engenharia de Software

Code Smell 144 - Objetos fungíveis

Ouvimos muito sobre NFTs. Agora, dominamos o conceito Fungível.

TL;DR: Respeite o MAPPER . Tornar fungível o que é fungível no mundo real e vice-versa.

problemas

• Falha de bijeção
• Overdesign

Soluções

1. Identifique elementos fungíveis em seus domínios
2. Modele-os como intercambiáveis

Contexto

De acordo com a Wikipédia :

Fungibilidade é a propriedade de um bem ou mercadoria cujas unidades individuais são essencialmente intercambiáveis e cada uma de cujas partes é indistinguível de outra parte.

Em software, podemos substituir objetos fungíveis por outros.

Ao mapear nossos objetos com os reais, às vezes nos esquecemos do modelo parcial e construímos sobre o design.

Código de amostra

Errado

 public class Person implements Serializable { private final String firstName; private final String lastName; public Person(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; } } shoppingQueueSystem.queue(new Person('John', 'Doe'));

Direita

 public class Person { } shoppingQueueSystem.queue(new Person()); // The identity is irrelevant for queue simulation

Detecção

• [x] manual

Este é um cheiro semântico.

Precisamos entender o modelo para verificar se está certo ou não.

Tag

• Overdesign

Conclusão

Tornar fungível o que é fungível e vice-versa.

Parece fácil, mas requer habilidades de design e evitar a complexidade acidental.

Créditos

Foto de Andrey Metelev no Unsplash

As pessoas pensam que a ciência da computação é a arte dos gênios, mas a realidade é o oposto, apenas muitas pessoas fazendo coisas que constroem umas sobre as outras, como uma parede de minipedras.

Donald Knuth

Code Smell 145 - Hack de curto-circuito

Não use a avaliação booleana como um atalho de legibilidade.

TL;DR: Não use comparação booleana para funções de efeito colateral.

problemas

• Legibilidade
• Efeitos colaterais

Soluções

1. Converter curtos-circuitos em IFs

Contexto

Programadores inteligentes gostam de escrever códigos obscuros e obscuros, mesmo quando não há evidências fortes para essa melhoria.

A otimização prematura sempre prejudica a legibilidade.

Código de amostra

Errado

 userIsValid() && logUserIn(); // this expression is short circuit // Does not value second statement // Unless the first one is true functionDefinedOrNot && functionDefinedOrNot(); // in some languages undefined works as a false // If functionDefinedOrNot is not defined does // not raise an error and neither runs

Direita

 if (userIsValid()) { logUserIn(); } if(typeof functionDefinedOrNot == 'function') { functionDefinedOrNot(); } // Checking for a type is another code smell

Detecção

• [x] Semiautomático

Podemos verificar se as funções são impuras e mudar o curto-circuito para um IF.

Alguns linters atuais nos alertam sobre esse problema

Tag

• Otimização prematura

Conclusão

Não tente parecer inteligente.

Não estamos mais na década de 50.

Seja um desenvolvedor de equipe.

Relações

Code Smell 140 - Avaliação de Curto Circuito

Code Smell 06 - Programador Muito Inteligente

Code Smell 149 - Encadeamento opcional

Créditos

Foto de Michael Dziedzic no Unsplash

Um computador é uma máquina estúpida com a capacidade de fazer coisas incrivelmente inteligentes, enquanto os programadores de computador são pessoas inteligentes com a capacidade de fazer coisas incrivelmente estúpidas. Eles são, em suma, uma combinação perfeita.

Bill Bryson

Próximo artigo: 5 mais cheiros de código.