Метафора садоводства намного ближе к реальности разработки программного обеспечения. Возможно, некая программа переросла себя или пытается осуществить слишком много – ее необходимо разбить на две. Все, что не получается в соответствии с планом, подлежит прополке или обрезке.
   Переписывание, переработка и перепланирование текста программы описывается общим термином "реорганизация".

Когда осуществлять реорганизацию?

   Если вы встречаете на своем пути камень преткновения, поскольку текст программы никуда не годится, замечаете, что два объекта стали несовместимы друг с другом, или же нечто другое, что задевает вас своей «неправильностью», не стесняйтесь вносить изменения. Другого времени, кроме настоящего, не существует. Программу можно считать пригодной для реорганизации при наличии одного из указанных ниже условий:
   •  Дублирование.Вы обнаружили нарушение принципа DRY (см. "Пороки дублирования").
   •  Неортогональность конструкции.Вы обнаружили некий фрагмент программы или конструкцию, которой можно придать большую ортогональность (см. "Ортогональность").
   •  Устаревшие знания.Все изменяется, требования варьируются, и ваши знания о проблеме расширяются. Программа должна соответствовать новому уровню знаний.
   •  Рабочие характеристики.Для улучшения характеристик программы вам необходимо перенести функциональную возможность из одной части системы в другую.
   Реорганизация программы, т. е. перемещение функциональной возможности и изменение ранее принятых решений – это упражнение в обезболивании. Скажем сразу – изменение исходного текста программы может быть весьма болезненной процедурой: она уже почти работала, а теперь ее разрывают в клочья. Многие разработчики крайне неохотно соглашаются «вспарывать» программу лишь на том основании, что она работает не совсем правильно.
Осложнения в реальном мире
   Итак, вы идете к вашему шефу или заказчику и говорите: "Эта программа работает, но для ее реорганизации мне нужна еще неделя".
   Они скажут вам… впрочем, это непечатное выражение.
   На жесткие временные рамки часто ссылаются, оправдывая отсутствие реорганизации. Но это оправдание не должно становиться нормой: если вы не сможете провести реорганизацию сейчас, то позже (когда придется принимать во внимание большее число зависимостей) на устранение возникшей проблемы потребуется намного больше времени. А будет ли у вас это время? У нас – точно не будет.
   Попробуйте объяснить этот принцип вашему шефу, пользуясь аналогией с медициной: рассматривайте программу, нуждающуюся в реорганизации, как «опухоль». Чтобы удалить ее, требуется хирургическое вмешательство. Вы можете начать сразу и извлечь ее, пока она небольшая. Но если вы будете ждать, пока она вырастет и распространится, то ее удаление станет более дорогой и опасной процедурой. Подождите еще, и вы можете потерять пациента окончательно.
 
   Подсказка 47: Реорганизация должна проводиться часто и как можно раньше
 
   Следите за всем, что требует реорганизации. Если вы не можете провести реорганизацию чего-либо прямо сейчас, удостоверьтесь, что она стоит в вашем плане. Убедитесь, что пользователи программы, над которой производится реорганизация, знают о запланированной процедуре и о том, как она может повлиять на их работу.

Как производится реорганизация?

   Реорганизация появилась в среде программистов, работающих с языком Smalltalk, и начала, вкупе с другими модными поветриями (например, шаблоны конструкций), завоевывать все более широкую аудиторию. Но это еще малоизвестная тема, по ней опубликовано не так много работ. Первая большая монография о реорганизации ([FBB+99], а также [URL 47]) вышла одновременно с данной книгой.
   Суть реорганизации заключается в перепланировке. Все спроектированное вами или другими членами вашей команды может быть переделано в свете новых фактов, более глубокого понимания, изменения требований и т. д. Но если вы предадите забвению огромные фрагменты программы, то окажетесь в худшем положении, чем в начале работы по реорганизации.
   Ясно, что реорганизация представляет собой род деятельности, которая должна осуществляться медленно, преднамеренно и осторожно. Мартин Фаулер предлагает ряд простых подсказок – как провести реорганизацию, чтобы это не принесло больше вреда, чем пользы (см. врезку на стр. 30 в книге [FS97]):
   1. Не пытайтесь одновременно производить реорганизацию и добавлять функциональные возможности.
   2. Перед тем как начинать реорганизацию, убедитесь, что тестирование прошло успешно. Проводите тестирование как можно чаще. В этом случае вы сразу увидите нарушение, которое было вызвано внесенными изменениями.
Автоматическая реорганизация
   Исторически сложилось так, что пользователи Smalltalk всегда применяли средство просмотра классов как неотъемлемую часть интегрированной среды разработчика. В отличие от web-браузеров, средства просмотра классов позволяют пользователям перемещаться по иерархиям и методам класса и проверять их.
   Обычно средства просмотра классов позволяют редактировать текст программы, создавать новые методы, классы и т. д. Следующей вариацией на эту тему является браузер реорганизации.
   Этот браузер может в полуавтоматическом режиме проводить операции, обычные при реорганизации: разбивать длинную подпрограмму на несколько более коротких, автоматически перенося изменения на имена методов и переменных, а также осуществлять операцию "буксировки и перетаскивания", что помогает в перемещении текста программы и т. д.
   Во время написания данной книги этой технологии еще предстояло выйти за пределы мира Smalltalk, но скорее всего она начнет меняться с той же скоростью, что и язык Java, – быстро. В то же время исторический браузер реорганизации Smalltalk можно отыскать в Интернете [URL 20].
 
   3. Двигайтесь обдуманно и не спеша: переместите поле из одного класса в другой, объедините два подобных метода в суперкласс. Часто при реорганизации вносится много локальных изменений, которые приводят к серьезным сдвигам. Если вы двигаетесь без спешки и проводите тестирование после каждого шага, вы избежите длительной процедуры отладки.
   На данном уровне тестирование будет обсуждаться в разделе "Программа, которую легко тестировать", тестирование на более высоком уровне – в разделе "Безжалостное тестирование"), но мнение г-на Фаулера о тщательном регрессионном тестировании является ключом к надежной реорганизации.
   Также весьма полезно удостовериться в том, что серьезные изменения в некоем модуле, такие как изменения его интерфейса или его функциональной возможности неподобающим способом, приведут к нарушению процесса сборки. Это означает, что прежние клиенты этой программы не смогут пройти компиляцию. Тогда вы можете отыскать старых клиентов и внести необходимые изменения, чтобы осовременить их.
   Поэтому в следующий раз, когда вам попадется фрагмент программы, который не совсем такой, каким ему надлежит быть, исправьте и его, и все то, что от него зависит. Научитесь управлять этой головной болью: если она досаждает вам сейчас, то потом будет досаждать еще больше, у вас есть шанс устранить ее совсем. Помните уроки, полученные в разделе "Энтропия в программах": не живите с разбитыми окнами.
Другие разделы, относящиеся к данной теме:
   • Мой исходный текст съел кот Мурзик
   • Энтропия в программах
   • Суп из камней и сварившиеся лягушки
   • Пороки дублирования
   • Ортогональность
   • Программирование в расчете на стечение обстоятельств
   • Программа, которую легко тестировать
   • Безжалостное тестирование
Упражнения
   38. По всей вероятности, за последние годы представленная ниже программа переписывалась несколько раз, но эти изменения никак не способствовали улучшению ее структуры. Проведите ее реорганизацию. (Ответ см. в Приложении В.)
   if (state==TEXAS) {
   rate=TX.RATE;
   amt=base * TX_RATE;
   calc=2*basis(amt) + extra(amt)*1.05;
   }
   else if ((state==OHIO) || (state==MAINE)) {
   rate=(state==OHIO) ? OH_RATE : MN_RATE;
   amt=base*rate;
   calc=2*basis(amt) + extra(amt)*1.05;
   if (state==OHIO)
      points = 2;
   }
   else {
   rate=1;
   amt=base;
   calc=2*basis(amt) + extra(amt)*1.05;
   }
 
   39. Класс Java, представленный ниже, нуждается в поддержке дополнительных форм. Произведите реорганизацию этого класса, чтобы подготовить его к этим дополнениям. (Ответ см. в Приложении В.)
   public class Shape {
   public static final int SQUARE = 1;
   public static final int CIRCLE = 2;
   public static final int RIGHTTRIANGLE = 3;
   private int shapeType;
   private double size;
   public Shape(int shapeType, double size) {
      this.shapeType = shapeType;
      this.size = size;
   }
   //… другие методы…
   public double area() {
    switch (shapeType) {
     case SQUARE: return size*size;
     case CIRCLE: return Math.PI*size*size/4.0;
     case RIGHT TRIANGLE: return size*size/2.0;
   }
   return 0;
   }
   40. Данная программа на языке Java представляет собой часть некоего скелета, который будет использоваться во всем вашем проекте. Произведите реорганизацию этой программы, чтобы сделать ее более общей и упростить ее расширение в будущем. (Ответ см. в Приложении В.)
 
   public class Window {
     public Window(int width, int height) {…}
     public void setSize(int width, int height) {…}
     public boolean overiaps(Window w) {…}
     public int getArea() {…}

34
Программа, которую легко тестировать

   Термин "программная интегральная схема" является метафорой, брошенной в ходе дискуссии о многократном использовании и компонентно-ориентированной разработке [39]. Идея заключается в том, что программные компоненты должны объединяться так же, как это происходит с чипами интегральной схемы. Этот подход срабатывает только в том случае, если известно, что используемые компоненты надежны.
   Чипы предназначены душ тестирования не только на предприятии-изготовителе, не только при сборке, но и в сфере их применения. Более сложные чипы и системы могут снабжаться полномасштабными средствами самотестирования, которые осуществляют внутреннюю диагностику на базовом уровне, или тестовым стендом с комплектом измерительных кабелей инициирующим подачу тестовых входных сигналов и снимающим ответную информацию с чипа.
   То же самое можно осуществить и с программным обеспечением. Подобно нашим коллегам, работающим с «железом», нам приходится с самого начала встраивать средства тестирования в программы и тщательно тестировать каждый фрагмент, перед тем как предпринять попытку их объединения.

Модульное тестирование

   Тестирование аппаратных средств на уровне чипа отдаленно напоминает модульное тестирование программного обеспечения – тестируется каждый модуль по отдельности для проверки его поведения. Мы можем лучше представить себе, какова будет реакция модуля на внешний мир, если проведем его тщательное тестирование в контролируемых (и даже искусственных) условиях.
   Модульный программный тест – это программа, испытывающая работу модуля. Обычно модульный тест задает некую искусственную среду, затем осуществляется вызов подпрограмм из проверяемого модуля. Потом происходит проверка полученных результатов, они сравниваются с известными величинами или с результатами предыдущих прогонов той же самой программы тестирования (регрессионное тестирование).
   Когда мы объединим наши "программные интегральные схемы" в единую систему, мы будем уверены, что ее отдельные части работают предсказуемо, а затем можем применить те же средства модульного тестирования при проверке системы в целом. О подобном крупномасштабном тестировании речь идет в разделе "Безжалостное тестирование".
   Но прежде чем выйти на этот уровень, необходимо решить, а что же мы будем тестировать на уровне блоков. Обычно программисты задают несколько случайных массивов данных и считают, что они провели тестирование. Но это можно сделать намного лучше, если использовать идеи, связанные с "программированием по контракту".

Тестирование в рамках контракта

   Мы рассматриваем модульное тестирование, как тестирование исходя из контракта (см. "Проектирование по контракту"). Нам бы хотелось написать процедуры тестирования, гарантирующие, что данный модуль соблюдает соответствующий контракт. При этом выясняются два момента: отвечает ли программа условиям контракта, и означает ли контракт на самом деле то, что мы о нем думаем. Мы хотим проверить, обладает ли модуль функциональными характеристиками, которые в нем заложены, используя разнообразные тестовые процедуры и граничные условия.
   Что это означает на практике? Рассмотрим подпрограмму извлечения квадратного корня, с которой мы впервые встретились в разделе "ППК и аварийное завершение работы программы". Ее контракт довольно прост:
   require:
      argument >=0
   ensure:
     abs((result*result)–argument) < epsilon
   Он указывает на моменты, нуждающиеся в проверке:
   • Передать отрицательный аргумент и удостовериться в том, что он отклонен
   • Передать аргумент, равный нулю, и удостовериться в том, что он принят (это граничное значение)
   • Передать значение в интервале от нуля до максимально выражаемого параметра и проверить, что разность между квадратом результата и исходным аргументом меньше некоторой величины "epsilon"
   Вооружась этим контрактом и полагая, что наша программа осуществляет собственную проверку предусловий и постусловий, можно записать базовый тестовый сценарий для проверки функции извлечения квадратного корня.
   public void testValue(double num, double expected) {
   double result = 0.0;
   try {    // We may throw a
   result = mySqrt(num); // precondition exception
   }
   catch (Throwable e) {
   if (num<0.0) // If input is «0, then
      Return; // we're expecting the
   Else // exception, otherwise
      Assert(false); // force a test failure
   }
   assert(Math.abs(expected-result)<epsilon);
   }
   Затем мы можем вызвать эту подпрограмму, чтобы проверить нашу функцию излечения квадратного корня:
   TestValue(-4.0, 0.0);
   TestValue(0.0, 0.0);
   TestValue(2.0, 1.4142135624);
   TestValue(64.0, 8.0);
   TestValue(1.0e7, 3162.2776602);
   Это весьма простая процедура тестирования; в реальном мире любой нетривиальный модуль скорее всего будет зависеть от ряда других модулей, поэтому, может быть, есть смысл протестировать их сочетание?
   Предположим, есть модуль А, использующий модули LinkedList и Sort. Мы осуществляем тестирование в следующем порядке:
   1. Полностью тестируем контракт модуля LinkedList.
   2. Полностью тестируем контракт модуля Sort.
   3. Тестируем контракт модуля А, который полагается на другие контракты, но не раскрывает их напрямую.
   При этом способе тестирования вы вначале обязаны проводить тестирование подкомпонентов.
   Если модули LinkedList и Sort успешно прошли тестирование, а модуль А испытания не прошел, мы можем быть вполне уверены, что проблема заключается в модуле А или в том, как модуль А использует один из подкомпонентов. Эта методика способствует уменьшению трудоемкости процесса отладки: можно быстро сосредоточиться на вероятном источнике проблем в пределах модуля А и не тратить время на изучение его подкомпонентов.
   Зачем вся эта головная боль? Прежде всего, хотелось бы избежать создания "бомбы замедленного действия", той, что остается незамеченной и позже взрывается в самый неподходящий момент во время работы над проектом. Подчеркивая важность "тестирования в рамках контракта", мы пытаемся, насколько это возможно, избежать катастроф, возникающих в будущем.
 
   Подсказка 48: Проектируйте с учетом тестирования
 
   Когда вы проектируете модуль или даже целую программу, вы обязаны проектировать ее контракт и программу для проверки этого контракта. Проектируя программу, которая проходит тестирование и выполняет соответствующий контракт, вы можете учесть граничные условия и другие аспекты, на которые в иных случаях не обратили бы внимания. Лучше всего устранять ошибки, избежав их с самого начала. На самом деле, при создании процедуры тестирования до реализации программы вам приходится испытывать интерфейс перед тем как принять его.

Создание модульных тестов

   Модульные тесты не должны оказываться где-то на периферии исходной древовидной схемы. Они должны располагаться так, чтобы с ними было удобно обращаться. В случае небольших проектов можно внедрить модульный тест в сам модуль. Для более крупных проектов можно поместить каждую из процедур тестирования в отдельный подкаталог. В любом случае необходимо помнить, что если модуль сложно отыскать, то он не будет использован.
   Делая тестовую процедуру доступной, вы наделяете разработчиков, которые могут воспользоваться вашей программой, двумя бесценными ресурсами:
   1. Примерами того, как использовать все функциональные возможности вашего модуля
   2. Средствами построения процедур регрессионного тестирования для проверки правильности любых изменений, которые будут вноситься в программу впоследствии
   Если каждый класс или модуль содержит свой собственный модульный тест, это удобно, но не всегда практично. Например, в языке Java каждый класс содержит собственную подпрограмму main. За исключением файла основного класса приложения, подпрограмма main может использоваться для запуска модульных тестов; она будет игнорироваться во время работы самого приложения. Преимущество состоит в том, что программа, отправляемая заказчику, все еще содержит тесты, которые могут использоваться для диагностики проблем, возникающих "в боевой обстановке".
   При работе с языком С++ вы можете добиться того же эффекта (во время компиляции) используя конструкцию #ifdef для выборочной компиляции программы модульного теста. Ниже представлен очень простой модульный тест на языке С++, внедренный в наш модуль и проверяющий работу функции извлечения квадратного корня с помощью подпрограммы testValue, подобной программе на языке Java, реализованной ранее:
   #ifdef _TEST_
   int main(int argc, char **argv) {
   argc-; argv++; // пропускаем имя программы
    if (argc<2) {   // стандартные тесты, если аргументы не указаны
      TestValue(-4.0, 0.0);
      TestValue(0.0, 0.0);
      TestValue(2.0, 1.4142135624);
      TestValue(64.0, 8.0);
      TestValue(1.0e7, 3162.2776602);
   }
   else {   // в этом случае используем аргументы
     double num, expected;
     while (argc>= 2) {
     num = atof(argv[0]);
     expected = atof(argv[1]);
     testValue(num.expected);
     argc – = 2;
     argv += 2;
    }
   }
   return 0;
   }
   #endif
   Данный модульный тест запускает минимальный набор тестов или же (при наличии аргументов) позволяет использовать внешние данные. Эта возможность могла быть задействована в сценарии запуска более полного набора тестов.
   Как поступить, если корректным откликом на модульный тест является выход из программы или ее аварийное завершение? В этом случае вам необходимо выбирать запускаемый тест, указывая аргумент в командной строке. Вам также придется передать некие параметры, чтобы указать различные начальные условия для ваших тестов.
   Но разработки одних модульных тестов недостаточно. Вы обязаны выполнять их и выполнять часто. Это также полезно, если класс время от времени проходит процедуру тестирования.

Применение тестовых стендов

   Поскольку обычно мы пишем большое количество тестирующих программ и проводим большое количество процедур тестирования, есть смысл облегчить себе жизнь и разработать стандартный тестовый стенд для конкретного проекта. Программа main, представленная в предыдущем разделе, является весьма простым тестовым стендом, но обычно нам нужно больше функциональных возможностей.
   Тестовый стенд может осуществлять универсальные операции, такие как регистрация состояния системы, анализ выходных данных на наличие ожидаемых результатов, а также выбор и запуск конкретных процедур тестирования. Стенды могут управляться при помощи графического интерфейса, могут быть написаны на том же целевом языке, что и весь проект, или реализованы в виде сочетания сборочных файлов и сценариев на языке Perl. Простой тестовый стенд описан в ответе к упражнению 41 (см. Приложение В).
   При работе с объектно-ориентированными языками и средами можно создать базовый класс, содержащий универсальные операции. Отдельные тесты могут создать подкласс и добавить специфические процедуры тестирования. Можно использовать стандартное соглашение об именовании и отражение на языке Java для формирования списка процедур тестирования в автоматическом режиме. Эта методика является прекрасным способом соблюдать принцип DRY – вам не приходится следить за списком доступных тестов. Но перед тем как взлететь и начать писать свой собственный стенд, есть смысл изучить методику xUnit Кента Бека и Эриха Гаммы [URL 22]. Они уже проделали всю сложную подготовительную работу.
   Вне зависимости от выбранной вами технологии тестовый стенд обязан предоставлять следующие возможности:
   • Стандартный способ определения установочной процедуры и завершения работы
   • Метод выбора отдельных тестов или всех доступных тестов
   • Средства анализа выходных данных на наличие ожидаемых (или неожиданных) результатов
   • Стандартизированная форма отчета об обнаруженных неисправностях
   Процедуры тестирования должны быть составными; другими словами, процедура тестирования может состоять из различающихся степенью детализации субтестов, которые направлены на подкомпоненты. Мы можем воспользоваться этой особенностью для тестирования отдельных компонентов или системы в целом, используя те же самые инструменты.
Специальное тестирование
   Во время отладки можно прекратить создание определенных тестов "на лету". Это может быть таким же простым делом, как оператор print или ввод фрагмента программы в интерактивной оболочке отладчика или ИСР.
   В конце сеанса отладки необходимо формализовать процедуру специального тестирования. Если программа прервалась один раз, скорее всего она прервется снова. Не стоит просто отбрасывать в сторону созданную процедуру тестирования; добавьте ее к существующему модульному тесту.
 
   Например, при помощи JUnit (элемент Java из семейства xUnit) можно записать процедуру проверки извлечения квадратного корня следующим образом:
   public class JUnitExample extends TestCase {
   public JUnitExampleffinal String name) {
     super(name);
   }
   protected void setUpQ {
   // Load up test data…
   testData.addElement(new dblPair(-4.0,0.0));
   testData.addElement(new dblPair(0.0,0.0));
   testData.addElement(new dblPair(64.0,8.0));
   testData.addElement(new dblPair(Double.MAX_VALUE, 1.3407807929942597E154));
   }
   public void testMySqrt() {
   double num, expected, result = 0.0;
   Enumeration enum = testData.elements();
   while (enum.hasMoreElements()) {
   dblPair p = (dblPair)enum.nextElement();
   num = p.getNum();
   expected = p.getExpected();
   testValue(num, expected);
   }
   }
   public static Test suite() {
   TestSuite suite= new TestSuite();
   suite.addTest(new JUnitExample("testMySqrt"));
   return suite;
   }
   }
   Пакет JUnit разработан по модульному принципу: к нему можно добавлять сколько угодно тестов, и каждый из них может, в свою очередь, являться пакетом. В дополнение к этому для управления процедурой тестирования вы можете выбрать графический или текстовый интерфейс.

Построение тестового окна

   Даже самые лучшие наборы тестов скорее всего не смогут обнаружить всех «жучков»: во влажных и жарких условиях реальной эксплуатации возникает нечто, что заставляет их вылезать из деревянных изделий.
   Это означает, что зачастую приходится тестировать фрагмент программного обеспечения сразу после его развертывания – с реальными данными, текущими в его жилах. В отличие от печатной платы или чипа, в программном обеспечении нет тестовых контактов, но можно по-разному взглянуть на внутреннее состояние модуля, не прибегая к помощи отладчика (в производственных условиях его применение либо неудобно, либо просто невозможно).
   Одним из таких механизмов являются файлы журналов. Сообщения в журналах должны записываться в обычном последовательном формате; возможно, вы захотите провести их синтаксический анализ в автоматическом режиме дня определения времени обработки или логических путей, по которым двигалась программа. Диагностические процедуры, составленные небрежно или в несовместимом формате, вызывают тошноту – их трудно читать и непрактично анализировать.
   Другим механизмом, позволяющим заглянуть внутрь выполняющейся программы, является комбинация "горячих клавиш". При нажатии такой комбинации на экране появляется окно диагностики с сообщениями о состоянии и т. д. Совсем не обязательно сообщать о такой возможности конечным пользователям, но это может быть весьма полезно для службы технического сопровождения.
   Для более крупных программ, работающих на серверах, существует изящная технология, заключающаяся в том, что для слежения за ходом работы используется встроенный web-сервер. Можно привязать web-браузер к HTTP-порту приложения
   (который обычно имеет нестандартный номер типа 8080) и увидеть внутреннее состояние, журналы и даже нечто вроде панели управления отладкой. Реализация этого может показаться сложным делом, что не соответствует действительности это. Бесплатно внедряемые web-серверы с протоколом HTTP реализованы на различных современных языках программирования. Поиск можно начать с сайта [URL 58].

Культура тестирования

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