Как найти вонючие части вашего кода [Часть XXIX]

Запахи кода — это классика.

Это пахнет, потому что, вероятно, есть много случаев, когда его можно отредактировать или улучшить.

n Большинство этих запахов являются лишь намеками на то, что что-то может быть не так. Следовательно, их не обязательно исправлять как таковые… (Тем не менее, вы должны изучить это.)

Пахнет предыдущим кодом

Вы можете найти все предыдущие запахи кода (Часть I – XXVIII) здесь.

Продолжим...

Code Smell 141 – IEngine, AVehicle, ImplCar

Вы когда-нибудь видели IEngine в дикой природе?

TL;DR: не добавляйте префиксы и суффиксы к классам

Проблемы

• Читаемость
• Биекция Ошибка
• Реализационные имена

Решения

1. Удалить префиксы и суффиксы
2. Называйте свои объекты в честь того, что они делают.

Контекст

Некоторые языки имеют культурные соглашения, связанные с типами данных, абстрактными классами или интерфейсами. Эти имена нагружают наши модели когнитивными переводами, которые трудно понять.

Мы должны целоваться.

Пример кода

Неверно

public interface IEngine
{
    void Start();
}

public class ACar 
{

}

public class ImplCar 
{

}

public class CarImpl
{

}

Правильно

public interface Engine
{
    void Start();
}

public class Vehicle 
{

}

public class Car 
{

}

Обнаружение

• [x] Автоматически

Если у нас есть тезаурус, мы можем указать на неудобные имена.

Исключения

В C# принято ставить букву "I" в имени интерфейса, потому что без нее нельзя сказать, интерфейс это или класс.

Это языковой запах.

Теги

• Именование

Заключение

Используйте настоящие имена для своих моделей.

Отношения

Code Smell 130 — AddressImpl

Подробнее

• Что в названии: Часть II Реабилитация

Кредиты

Фото Тима Моссхолдера на Unsplash

Некоторые люди, сталкиваясь с проблемой, думают: "Я знаю, я буду использовать регулярные выражения". Теперь у них две проблемы.

Джейми Завински

Великие цитаты о разработке программного обеспечения

Code Smell 142 — Запросы в конструкторах

Доступ к базе данных в объектах домена — это запах кода. Делать это в конструкторе — неприятный запах.

TL;DR: конструкторы должны создавать (и, возможно, инициализировать) объекты.

Проблемы

• Соединение
• Побочные эффекты

Решения

1. Отделите важную бизнес-логику от случайного сохранения.
2. В классах сохраняемости выполняйте запросы в функциях, отличных от конструкторов/деструкторов.

Контекст

В устаревшем коде база данных неправильно отделена от бизнес-объектов.

Конструкторы никогда не должны иметь побочных эффектов.

В соответствии с принципом единой ответственности они должны создавать только допустимые объекты

Пример кода

Неверно

public class Person {
  int childrenCount; 

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

Правильно

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
  }
}

Обнаружение

• [x] Полуавтоматический

Наши линтеры могут находить шаблоны SQL в конструкторах и предупреждать нас.

Теги

• Связь

Заключение

Разделение задач является ключевым, а объединение — наш главный враг при разработке надежного программного обеспечения.

Подробнее

• Соединение: единственная проблема программного обеспечения

Кредиты

Фото Каллума Хилла на Скрыть

Я по-прежнему считаю, что если правильно подобрать структуры данных и их инварианты, большая часть кода напишется сама собой.

Питер Дойч

Великие цитаты о разработке программного обеспечения

Code Smell 143 — Скопления данных

Некоторые объекты всегда вместе. Почему бы нам не разделить их?

TL;DR: заставьте сплоченные примитивные объекты путешествовать вместе

Проблемы

• Плохая согласованность
• Дублированный код
• Сложность проверки
• Читаемость
• Удобство обслуживания

Решения

1. Извлечь класс
2. Найти мелкие объекты

Контекст

Этот запах дружит с первобытной одержимостью.

Если два или более примитивных объекта склеены вместе, между ними повторяется бизнес-логика и правила, нам нужно найти существующую концепцию биекция.

Пример кода

Неверно

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;
}

Правильно

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;
}

Обнаружение

• [x] Полуавтоматический

Обнаружение на основе шаблонов сцепления доступно в нескольких линтерах.

Теги

• Сплоченность

Заключение

Групповое поведение в нужном месте и скрытие примитивных данных.

Отношения

Code Smell 122 – Примитивная одержимость< /p>

Code Smell 01 — Анемичные модели

Code Smell 27 — Ассоциативные массивы

Подробнее

• гуру рефакторинга
• Википедия

Кредиты

Фото Dynamic Wang на Unsplash

Основой программного обеспечения является его способность решать связанные с доменом проблемы пользователя. Все остальные функции, какими бы важными они ни были, поддерживают эту основную цель.

Эрик Эванс

Великие цитаты о разработке программного обеспечения

Code Smell 144 — Взаимозаменяемые объекты

Мы много слышали о NFT. Теперь мы осваиваем концепцию взаимозаменяемости.

TL;DR: уважайте MAPPER. Сделайте взаимозаменяемым то, что является взаимозаменяемым в реальном мире, и наоборот.

Проблемы

• Биекция Ошибка
• Над дизайном

Решения

1. Определите взаимозаменяемые элементы в своих доменах
2. Моделируйте их как взаимозаменяемые

Контекст

Согласно Википедии:

Взаимозаменяемость — это свойство товара или товара, отдельные единицы которого по существу взаимозаменяемы и каждая часть которого неотличима от другой части.

В программном обеспечении мы можем заменить взаимозаменяемые объекты другими.

При сопоставлении наших объектов с реальными мы иногда забываем о частичных моделировать и строить поверх проекта.

Пример кода

Неверно

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'));

Правильно

public class Person  { 
} 

shoppingQueueSystem.queue(new Person());
// The identity is irrelevant for queue simulation 

Обнаружение

• [x] Руководство

Это семантический запах.

Нам нужно понять модель, чтобы проверить, правильная она или нет.

Теги

• Над дизайном

Заключение

Сделайте взаимозаменяемым то, что является взаимозаменяемым, и наоборот.

Звучит просто, но требует дизайнерских навыков и избегания случайных сложностей.

Кредиты

Фото Андрей Метелев на Unsplash

Люди думают, что информатика — это искусство гениев, но на самом деле все обстоит наоборот: многие люди делают вещи, которые строятся друг на друге, как стена из мини-камешков.

Дональд Кнут

Code Smell 145 — Взлом короткого замыкания

Не используйте логическое вычисление для упрощения чтения.

TL;DR: не используйте логическое сравнение для функций побочных эффектов.

Проблемы

• Читаемость
• Побочные эффекты

Решения

1. Преобразовать короткие замыкания в IF

Контекст

Умные программисты любят писать хакерский и малопонятный код, даже если для этого нет веских доказательств.

Преждевременная оптимизация всегда ухудшает читабельность.

Пример кода

Неверно

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

Правильно

if (userIsValid()) {
    logUserIn();
}

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

Обнаружение

• [x] Полуавтоматический

Мы можем проверить, являются ли функции нечистыми, и изменить короткое замыкание на IF.

Некоторые актуальные линтеры предупреждают нас об этой проблеме

Теги

• Преждевременная оптимизация

Заключение

Не пытайтесь выглядеть умным.

Нам уже не за 50.

Быть командным разработчиком.

Отношения

Code Smell 140 — Оценка короткого замыкания

Code Smell 06 — Слишком умный программист

Code Smell 149 — Необязательное объединение

Кредиты

Фото Майкла Дзидзича на Unsplash

Компьютер — это глупая машина, способная делать невероятно умные вещи, а программисты — умные люди, способные делать невероятно глупые вещи. Короче говоря, они идеально подходят друг другу.

Билл Брайсон

Следующая статья: Еще 5 запахов кода.