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

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

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

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

Путь к повышению эффективности программ заминирован грязным кодом

Кирк Пеппердин

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

Допустим, вы обнаружили место, где теряется производительность. В этом случае обычно пытаются снизить сложность алгоритма, создающего недопустимую нагрузку. Вы сообщаете своему менеджеру, что исправление займет у вас, скажем, три-четыре часа. Работая над исправлениями, вы обнаруживаете, что перестал работать зависимый участок кода. Родственные фрагменты кода часто связаны друг с другом, что вызвано объективной необходимостью, и такое нарушение работы, скорее всего, предполагалось и учитывалось в оценке времени. Но что если исправление этой зависимости приведет к нарушению работы и других зависимых частей? Более того, чем дальше эти зависимости находятся от исходной точки, тем менее вероятно, что вы их обнаружите и учтете в своей оценке. Внезапно начальная оценка раздувается от трех-четырех часов до трех-четырех недель. Часто одна подобная неожиданность увеличивает сроки сразу на 1–2 дня. Не столь уж редко «небольшой» рефакторинг затягивается на несколько месяцев. В таких ситуациях ущерб, нанесенный доверию к действующей команде и ее «политическому капиталу», может быть тяжелым и даже смертельным. Вот если бы у нас был инструмент, позволяющий обнаружить и оценить такой риск…

На самом деле, существует много способов измерить и проконтролировать степень и глубину связанности и сложности нашего кода. С помощью программных метрик можно посчитать встречаемость в коде определенных характеристик. Эти количественные показатели коррелируют с качеством кода. Отметим две метрики из тех, которые оценивают связанность кода: число входов (fan-in) и число выходов (fan-out). Например, для классов fan-out определяется как количество классов, к которым прямо или косвенно обращается оцениваемый класс. Это можно представить себе как количество всех классов, которые нужно скомпилировать, прежде чем можно начать компилировать ваш класс. С другой стороны, fan-in — это количество классов, которые зависят от данного класса. Зная fan-out и fan-in, можно по формуле I = fo / (fi + fo) рассчитать коэффициент нестабильности. Чем ближе I  к нулю для конкретного класса или модуля, тем он стабильнее. Когда значение I близко к 1, модуль становится нестабильным. Изменение кода стабильных модулей сопряжено с меньшим риском, тогда как в нестабильных модулях более вероятно наличие бомб грязного кода. Задача рефакторинга — приблизить I  к нулю.

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

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

Простота достигается сокращением

Пол У. Гомер

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

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

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

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

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

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

Код должен быть простым. Количество переменных, функций, объявлений и прочих синтаксических элементов языка должно быть минимальным.