97 этюдов для программистов. Опыт ведущих экспертов

При использовании метрик нужно помнить, что это всего лишь эмпирические правила. Исходя из чистой математики мы увидим, что увеличивая fi, не изменяя при этом fo, мы приближаем I к нулю. Однако слишком большая величина fan-in имеет и обратную сторону: такие классы труднее изменить, не нарушая работу классов, зависимых от них. Кроме того, не решая проблемы fan-out, вы на самом деле не снижаете свои риски, поэтому нужно соблюдать некоторое равновесие.

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

Простота достигается сокращением Пол У. Гомер

«Делай заново…», — сказал мне начальник, твердо удерживая пальцем клавишу Delete. С привычной тоской я смотрел на экран, где безвозвратно исчезал мой код — строка за строкой.

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

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

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

Слишком много времени впустую тратится на попытки спасти плохую работу. Если что-то начинает высасывать ресурсы, от этого следует избавиться. И побыстрее.

Не хочу сказать, что так уж легко расстаться с набранным текстом, выбранными именами, форматированием. Реакция моего начальника была излишне жесткой, однако она заставляла меня переосмысливать свой код во время второй (а иногда и третьей) попытки. Тем не менее лучший способ исправить плохой код — приготовиться безжалостно его перерабатывать, переносить туда-сюда или удалять.

Код должен быть простым. Количество переменных, функций, объявлений и прочих синтаксических элементов языка должно быть минимальным. Лишние строки, лишние переменные… все лишнее должно немедленно уничтожаться. А того, что осталось, должно быть минимально достаточно, чтобы выполнить задание, реализовать алгоритм или осуществить вычисления. Все прочее — бесполезный, ненужный шум, появившийся по ошибке. Он запутывает алгоритм работы и скрывает действительно важные вещи в коде.

Конечно, если этого окажется недостаточно, удалите вообще все и начните сначала. Такое «рисование по памяти» часто позволяет избавиться от ненужного хлама.

Принцип единственной ответственности Роберт Мартин (Дядюшка Боб)

Вот один из наиболее фундаментальных принципов качественного проектирования:

Собрать вместе те вещи, которые изменяются по одной и той же причине, и разделить те, которые изменяются по разным причинам.

Этот принцип иначе известен как принцип единственной ответственности, или SRP (single responsibility principle). Если коротко, он гласит, что причина изменения любой подсистемы, класса и даже функции должна быть ровно одна. Классический пример — класс с методами для работы с бизнес-правилами, отчетами и базами данных:

public class Employee {

public Money calculatePay()…

public String reportHours()…

public void save()…

}