Бек Кент. Экстремальное программирование

   Качество (quality) – эта переменная контролируется хуже всего. Если вам необходимо достигнуть каких-либо краткосрочных целей (для достижения которых требуется несколько дней или недель), вы можете намеренно пожертвовать качеством, однако связанные с этим затраты – человеческие, деловые и технические – могут оказаться чрезмерными.
   Объем работ (scope) – сократив объем работ, вы можете повысить качество (при условии, конечно, что поставленная заказчиком задача решена). Сокращение объема работ позволяет также сократить время проекта и связанные с проектом затраты.
   Между рассмотренными четырьмя переменными не существует простой зависимости. Например, вы не сможете увеличить скорость работы программы, просто затратив на ее разработку больше денег. Как говорит народная мудрость, девять женщин не могут родить ребенка за один месяц. (И в противоположность тому, что я слышал от некоторых менеджеров, даже восемнадцать женщин не смогут родить ребенка за один месяц.)
   В определенном смысле затраты являются наиболее ограничивающей переменной. Вы не можете напрямую менять деньги на качество, объем работ или скорость, с которой выпускаются промежуточные версии продукта. На самом деле в начале проекта вообще не существует возможности потратить сразу много денег. В начале работ инвестирование необходимо выполнять понемногу и затем, с течением времени, увеличивать объемы вложений. В процессе того, как проект будет развиваться, вы сможете эффективно тратить все большее и большее количество денег.
   У меня был один клиент, который сказал мне: Необходимо обеспечить всю заданную функциональность. Для этого предполагается использовать 40 программистов.
   Я ответил: В самый первый день работы над проектом вы не сможете задействовать сразу всех 40 программистов. Для начала необходимо задействовать небольшую команду. Затем к проекту необходимо подключить еще одну команду. После этого вы сможете использовать четыре программистских рабочих группы. В течение двух лет у вас появится возможность подключить к работе всех 40 программистов, однако в самом начале сделать этого нельзя.
   Он настаивал: Вы не понимаете. Мы обязаны задействовать в проекте 40 программистов.
   Я ответил: Вы не сможете сделать этого.
   Однако он не унимался: Но мы обязаны.
   Они не смогли. Я имею в виду, что они попытались сделать это. Они наняли 40 программистов, однако дела пошли не самым лучшим образом. Все эти программисты поувольнялись. Они наняли еще 40 программистов. Через четыре года они только-только приступили к рабочим испытаниям результатов своей работы. В рабочих условиях начал функционировать небольшой подпроект, однако перед этим они чуть было не закрылись.
   Любые связанные с затратами ограничения могут привести менеджеров в бешенство. В особенности это справедливо, когда они занимаются планированием бюджета на год. В подобных ситуациях они настолько привыкли выводить все из предполагаемого объема затрат, что зачастую приходится сталкиваться с очень серьезными ошибками. На самом деле, управляя объемом затрат, нельзя контролировать все и вся, и это обстоятельство ни в коем случае нельзя упускать из виду.
   Существует еще одна связанная с затратами проблема. Рост затрат может быть вызван желанием привлечь к себе внимание или повысить свой престиж. Ну да, под моим началом проект, в котором задействовано 150 человек (важное сопение). В результате проект может умереть по той простой причине, что его руководитель просто захотел выглядеть внушительно. Почему-то ему показалось, что если он сумеет разработать ту же самую систему, наняв для этой цели всего 10 программистов и закончив работу за половину выделенного для этой цели времени, он не сможет произвести на окружающих должного впечатления.
   С другой стороны, затраты тесно связаны с другими переменными. Если, действуя в допустимых пределах, вы увеличите объем инвестиций, вы можете расширить объем работ, или вы можете действовать с большей свободой и улучшить качество, или вы можете (до определенной степени) уменьшить время, необходимое для завершения работы.
   Затратив дополнительные деньги, вы также снижаете трение – вы получаете более быстрые компьютеры, большее количество технических специалистов, более просторные и удобные офисы.
   Ограничения, связанные с временем реализации проекта, как правило появляются извне – в качестве наиболее свежего примера можно вспомнить проекты, связанные с решением проблемы 2000 года. В качестве примеров внешних временных ограничений можно привести также конец года, начало следующего квартала, дата планируемого завершения работы старой системы, крупная торговая выставка. Зачастую время не поддается контролю со стороны менеджеров проекта – его контролируют заказчики.
   Качество – это еще одна весьма странная переменная. Зачастую, настаивая на улучшении качества, мы можете завершить проект быстрее, чем запланировано. Или вы можете успеть сделать больше за заданный интервал времени. Именно это случилось со мной, когда я приступил к разработке тестов для программного модуля, работа над которым описывалась в главе 2. Как только я закончил работу над всеми тестами, я был настолько уверен в своем коде, что смог разработать код модуля существенно быстрее, без каких-либо лиших сомнений и размышлений. Я смог подчистить мою систему с меньшим количеством усилий, в результате я существенно упростил дальнейшую разработку. Мне часто приходится наблюдать, как подобное происходит с целыми командами разработчиков. Как только они приступают к тестированию или как только они разрабатывают общие для всех стандарты кодирования, работа начинает идти существенно быстрее.
   Существует весьма странная зависимость между внутренним и внешним качеством. Внешнее качество – это качество, измерением которого занимается заказчик. Внутреннее качество оценивается программистами. Если вы намерены временно пожертвовать внутренним качеством для того, чтобы сократить время разработки, и при этом надеетесь на то, что внешнее качество не пострадает слишком сильно, имейте в виду, что вы стремитесь к достижению краткосрочной цели. Возможно, закрыв глаза на качество внутренней отделки, вам удастся сэкономить пару недель или даже месяц, однако с течением времени количество внутренних проблем может увеличиться настолько, что разрабатываемую вами систему будет чрезвычайно сложно сопровождать и развивать, кроме того, возможно, вам не удастся достичь приемлемого уровня внешнего качества.
   С другой стороны, время от времени вы попадаете в ситуацию, в которой вы можете завершить работу быстрее, ослабив ограничения, связанные с качеством. Однажды я разрабатывал систему, которая предназначалась для замены устаревшей системы, написанной на COBOL. Поставленный перед нами критерий качества подразумевал, что в рамках новой системы мы обязаны были в точности воспроизвести все ответы старой системы. По мере того как дата сдачи работы становилась все ближе и ближе, мы начали понимать, что можем воспроизвести в нашем новом программном продукте не только полную функциональность старой системы, но также и все заложенные в ней ошибки, однако для этого придется перенести сроки сдачи. Мы обратились к заказчикам и продемонстрировали им, что предлагаемые нами ответы являются более корректными. Мы также сообщили, что если в этом отношении они нам поверят, мы сможем сдать работу в срок.
   С качеством связан значительный человеческий фактор. Каждый желает делать свою работу хорошо и каждый работает существенно лучше, если чувствует, что он делает свою работу хорошо. Если же вы намеренно жертвуете качеством, возможно, в первое время ваша команда действительно будет работать быстрее, однако в скором времени вступит в действие деморализация. На людей начнет давить ощущение, что они заняты производством бракованного продукта. Если вы откажетесь от тестирования или от пересмотра кода или от соответствия стандартам, возможно, на некоторое время вы добьетесь некоторого преимущества, однако в дальнейшем вы можете потерять его за счет человеческого фактора.

Фокус на объеме работ

   Множество людей хорошо знает, что такое затраты, качество и время, и как с их помощью контролируется процесс производства программного обеспечения, однако при этом многие из них не признают четвертую переменную – объем работ. Объем работ, связанный с производством программного продукта, – это наиболее важная переменная, с которой приходится иметь дело в производстве программного продукта. В большинстве случаев как программисты, так и бизнесмены обладают весьма туманными представлениями о том, что является наиболее ценным в разрабатываемом программном продукте. Однако если вы активно управляете показателем объема работ, вы можете предоставить менеджерам и заказчикам контроль над затратами, качеством и временем.
   Отличительной чертой этого показателя является то, что объем работ – сильно изменяющаяся переменная. В течение десятилетий программисты привыкли жаловаться: Заказчики не могут сказать нам, чего они хотят. Когда мы даем им то, о чем они нас просили, они говорят, что им это не нравится. И это абсолютная горькая правда всей индустрии производства программного обеспечения. В самом начале работы над проектом требования заказчика никогда не бывают четкими и ясными. Заказчики никогда не могут сказать вам, что именно они хотят.
   После разработки некоторого фрагмента программного продукта требования к нему изменяются. Как только заказчики видят первую версию продукта, они понимают, что они хотят увидеть во второй версии... или что они на самом деле хотели увидеть в первой версии. И это достаточно важный процесс познания, так как во многих случаях заказчики просто не могут сформулировать требования к продукту, которого в реальности пока что не существует. Зачастую не возможно четко и полностью сформулировать техническое задание на основе только лишь беспочвенных абстрактных размышлений и предположений. Многие важные умозаключения и выводы делаются заказчиками на основе опыта. Однако заказчики не имеют возможности получить свой опыт в одиночку. Они нуждаются в людах, которые умеют программировать. И эти люди должны быть не просто советчиками, они должны быть компаньонами.
   Что, если посмотреть на нечеткость требований не как на проблему, а как на удобную возможность? В этом случае мы можем обнаружить, что показатель объема работ является наиболее удобной в управлении переменной из тех четырех переменных, о которых я говорил ранее. Так как этот показатель наименее четко очерчен, мы можем формировать его в соответствии с нашими собственными предпочтениями и предпочтениями заказчика – немного в эту сторону, немного в ту сторону. Если время поджимает и надо выпускать очередную версию продукта, у нас всегда будет что-то, что мы можем отложить до следующей версии. Однако если мы будем стараться не втискивать в рамки одной версии слишком много работы, то сохраним возможность выпустить продукт требуемого качества в указанные сроки.
   Если мы создадим дисциплину разработки программного обеспечения на основе описанной модели, то получим возможность контролировать дату выпуска, качество и стоимость любого фрагмента программного продукта. Вначале мы можем рассматривать объем работ как функцию от первых трех переменных, однако в дальнейшем мы получаем возможность постоянно корректировать объем работ с учетом складывающихся условий.
   Разрабатываемая нами дисциплина должна подразумевать низкую стоимость внесения изменений в проект, так как предполагается, что направление развития проекта будет меняться достаточно часто. Не стоит тратить деньги на разработку программного продукта, который в дальнейшем не будет использоваться. Не стоит тратить деньги на асфальтирование дороги, по которой вы все равно не будете ездить, так как вам придется свернуть на ближайшем повороте. Чтобы в подобной ситуации добиться желаемых результатов, вы должны использовать методику, в рамках которой стоимость внесения в проект изменений будет приемлемой в течение всего времени жизни системы.
   Если вы будете отказываться от реализации важной функциональности в конце каждого очередного периода работы над очередной версией продукта, заказчик в скором времени разочаруется в вашей работе. Чтобы избежать этого, ХР использует две стратегии.
   1. В процессе работы, приступая к реализации очередной части проекта, вы постоянно делаете предположение относительно того, сколько времени и усилий вам потребуется для того, чтобы реализовать эту часть проекта. В дальнейшем вы сравниваете реально затраченное время с вашими предварительными оценками. Таким образом вы тренируете свою способность правильно оценивать свои силы и снижаете вероятность отказа от реализации ранее запланированной функциональности.
   2. В первую очередь вы реализуете те требования заказчика, которые являются наиболее важными для него. Таким образом, если на завершающем этапе работы над очередной версией системы приходится отказываться от реализации какой-либо функциональности, эта функциональность оказывается менее важной, чем та функциональность, которая уже присутствует в системе.

Глава 5
Стоимость внесения изменений

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

   Рис. 1. С течением времени стоимость внесения изменений в программный продукт возрастает экспоненциально
   Затраты, связанные с исправлением проблемы, обнаруженной внутри программного продукта, растут экспоненциально с течением времени, – говорил профессор. – Проблема, для решения которой в процессе анализа требований потребовался бы доллар, может стоить вам нескольких тысяч долларов, если вы обнаружите ее в момент, когда система уже будет в производстве.
   Тогда, в той аудитории я раз и навсегда решил для себя, что я никогда не позволю проблемам оставаться в разрабатываемых мною программах до самого производства. Ни за что! Я обязательно буду устранять проблемы так быстро, как только это возможно. Я буду бороться с проблемами, которые даже еще не возникли, а только могут возникнуть. Я буду постоянно и беспрерывно пересматривать и проверять мой код. Ни под каким видом я не позволю себе допустить ошибку, которая в будущем будет стоить моему нанимателю сотни тысяч долларов.
   Однако проблема состоит в том, что на самом деле кривая, изображенная на рис. 1, больше не соответствует действительности. Говоря точнее, благодаря использованию новых технологий и специальных методик программирования можно добиться того, что кривая стоимости внесения изменений в программный продукт будет выглядеть прямо противоположно. Теперь становятся возможными истории, подобные следующей, которая случилась со мной относительно недавно, во время работы над системой управления контрактами страхования жизни:
   17.00 – я обнаруживаю, что некоторая встроенная в нашу систему возможность – способность в рамках одной трансакции хранить несколько дебетов с нескольких учетных записей и несколько кредитов для нескольких учетных записей – в процессе функционирования системы, по сути дела, не используется. Каждая трансакция извлекает средства только с одной учетной записи и переносит их только на одну учетную запись. У меня в голове возникает вопрос: можно ли упростить систему, как показано на рис. 2?

   Рис. 2. Можем ли мы использовать только один компонент для каждой пары дебет/кредит?
   17.02 – я обращаюсь к Массимо и прошу его, чтобы он подошел ко мне и сел рядом для того, чтобы помочь мне разобраться в ситуации. Мы пишем запрос. Выясняется, что из всех 300 000 трансакций в системе ни одна не использует более одной учетной записи для снятия денег и более одной учетной записи для переноса денег. Каждой из трансакций соответствует только одна дебетная учетная запись и только одна кредитная учетная запись.
   17.05 – если мы хотим исправить систему, как мы можем этого достичь? Мы можем изменить интерфейс компонента Transaction, а также изменить реализацию. Мы переписываем четыре требуемых метода и приступаем к тестированию.
   17.15 – все тесты (более чем 1000 модульных и функциональных тестов) по-прежнему выполняются на 100% отлично. Мы не можем придумать ситуацию, в которой внесенные нами изменения могут стать причиной неработоспособности системы. Мы приступаем к работе над кодом миграции базы данных.
   17.20 – мы завершаем программирование процедур миграции, которая должна быть выполнена в течение ночи. Также мы выполняем резервное копирование базы данных. После этого мы устанавливаем новую версию кода и инициируем процесс миграции.
   17.30 – мы запускам несколько проверочных тестов. Все, что мы могли предусмотреть, работает великолепно. Не в состоянии придумать чтолибо важное, о чем мы могли позабыть, мы уходим домой.
   Следующий день – журнал ошибок пуст. Никаких жалоб от пользователей не поступает. По всей видимости, внесенные нами изменения отлично работают.
   В течение нескольких следующих недель мы обнаружили, что в связи с использованием новой структуры разрабатываемую нами систему можно упростить еще больше. При этом мы получаем возможность внести в бухгалтерский раздел нашей программы совершенно новую удобную функциональность. Таким образом мы делаем систему проще, чище и менее избыточной.
   В течение последних нескольких десятилетий сообщество людей, работающих в области разработки программного обеспечения, приложило огромные усилия для того, чтобы снизить стоимость внесения изменений. Для этой цели были разработаны более совершенные языки программирования, более совершенные технологии баз данных, более эффективные методики кодирования, улучшенные среды и инструменты разработки, новые правила.
   Что, если все эти инвестиции не пропали даром? Что, если вся эта суета с новыми языками программирования и новыми базами данных не была напрасной? Что, если теперь стоимость внесения изменений не растет экспоненциально, как раньше, а увеличивается более медленно, со временем приближаясь к асимптоте? Что, если завтра профессор, преподающий студентам основы разработки программного обеспечения, нарисует на доске линию, изображенную на рис. 3?

   Рис. 3. Стоимость изменений со временем может увеличиваться существенно медленнее, чем экспонента
   Именно это является одним из основных предположений ХР. Это техническое предположение ХР. Если стоимость внесения в систему изменений со временем растет достаточно медленно, стратегия разработки программы должна быть совершенно другой, отличной от той, которая используется в случае, если стоимость внесения в систему изменений современем растет экспоненциально. В подобной ситуации вы можете откладывать решение важных задач на более поздние сроки. Вы получаете возможность принимать важные решения настолько поздно, насколько это возможно. Это делается для того, чтобы осуществлять связанные с этим затраты как можно позже. Кроме того, если вы откладываете решение важных вопросов на более поздний срок, тем самым вы повышаете вероятность того, что выбранное вами решение окажется правильным. Другими словами, сегодня вы должны реализовать только то, без чего сегодня не обойтись, при этом вы можете рассчитывать на то, что проблемы, решение которых вы отложили до завтра, развеются сами собой, то есть перестанут быть актуальными. Вы можете добавлять в дизайн новые элементы только в случае, если эти новые элементы упрощают код или делают написание следующего фрагмента кода более простым.
   Если пологая кривая роста затрат делает ХР возможным, то экспоненциальная кривая роста затрат делает ХР невозможным. Если изменение обойдется вам в кругленькую сумму, вы сойдете с ума, пытаясь предугадать, каким образом это изменение повлияет на работу системы. Если же изменение обходится вам дешево, вы всегда можете рискнуть и проверить, что будет, если вы тем или иным образом измените код, – позже вы всегда можете изменить систему так, как это будет лучше. В подобной ситуации, внеся изменения в систему, вы через короткое время получаете ответную информацию о том, насколько полезны данные изменения для системы.
   Но как поддерживать невысокую стоимость изменений на протяжении всего времени работы над проектом? Сохранение низкой стоимости изменений – это не какой-то магический трюк, оно достигается не просто так, а в результате применения технологий и методик, которые позволяют сделать программный продукт податливым и легко модернизируемым.
   С технологической точки зрения ключевой технологией, позволяющей добиться этого, являются объекты. Обмен сообщениями между объектами позволяет существенно расширить спектр возможностей по изменению разрабатываемой системы. Каждое сообщение становится потенциальной точкой для внесения в систему грядущих модификаций, модификаций, которые могут вносится в систему, не затрагивая при этом существующий код.
   Объектные базы данных переносят эту гибкость в пространство постоянной памяти. Благодаря использованию объектной базы данных вы получаете возможность с легкостью переносить информацию об объектах из одного формата в другой, так как в объектных базах данных код соединен с данными, а не отделен от них, как это было в более ранних базах данных. Даже если вы не можете найти способ выполнить миграцию объектов, вы можете обеспечить в рамках одной системы сосуществование двух разных реализаций.
   Я вовсе не хочу сказать, что вы обязаны использовать объекты для того, чтобы получить гибкость. Лично я познакомился с основами ХР, когда наблюдал, как мой отец пишет на ассемблере управляющий код процесса реального времени. Он разработал стиль, который позволил ему постоянно обновлять дизайн его программ. Все же мой опыт подсказывает мне, что стоимость изменений увеличивается в большей степени в случае, если вы не используете объекты, чем в случае, если вы основываете свой проект на объектно-ориентированном подходе.
   Я также не хочу сказать, что объекты – это все, что вам потребуется для снижения стоимости затрат. Я видел (и даже, по правде сказать, сам написал) немало кодов, заниматься изменением которых я не пожелал бы и врагу.
   Чтобы упростить модификацию вашего кода даже спустя несколько лет после начала работы над проектом, вы должны учитывать следующие факторы:
   • простой дизайн, в котором отсутствуют лишние элементы, – никаких идей, которые на текущий момент не используются, однако предположительно могут использоваться в будущем;
   • автоматические тесты – благодаря им всегда с легкостью можно узнать о том, что в результате внесения в систему изменений ее поведение изменилось;
   • постоянная практика в деле модификации дизайна системы – когда приходит время менять систему, вы не почувствуете страха перед этим.
   Если мы заложим в основу нашей работы три перечисленных элемента – простой дизайн, автоматические тесты и опыт постоянного видоизменения системы, мы увидим, что кривая расходов, связанных с внесением в систему изменений, станет пологой, как на рис. 3. Изменение, для осуществления которого до начала кодирования потребовалось бы несколько минут, через два года работы над системой потребует от вас не более 30 минут. Однако я сталкивался с проектами, в которых на принятие и предварительное обдумывание подобных решений тратятся дни и даже недели, хотя вместо этого проблему можно решить уже сейчас, а завтра, если это потребуется, можно будет с легкостью все переделать на новый лад.
   Теперь, когда мы кардинально пересмотрели наши изначальные предположения относительно стоимости внесения в систему изменений, у нас появляется возможность применить совершенно иной подход к разработке программного обеспечения. Как и любые другие подходы, разрабатываемый нами подход строг, он не терпит нарушения определяемых в его рамках правил, однако его строгость лежит в несколько иных измерениях. Вместо того чтобы заботиться о принятии важных решений как можно раньше и менее значительных решений – позже, мы с вами планируем разработать подход, в рамках которого каждое решение принимается быстро, при этом оно надежно защищается с использованием автоматических тестов. Помимо этого, в рамках нового подхода вы должны быть готовыми к изменению дизайна системы в случае, если вы понимаете, что существует более удачный дизайн, чем тот, который реализован вами на текущий момент.