Спасибо, что скачали книгу в бесплатной электронной библиотеке TheLib. Ru icon

Спасибо, что скачали книгу в бесплатной электронной библиотеке TheLib. Ru



Смотрите также:
1   2   3   4   5   6   7   8   9   10
Глава 16.

^ Стратегия разработки


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

В ХР метафора программирования используется для всех видов деятельности, благодаря чему все, чем вы занимаетесь, выглядит как программирование: программирование в ХР выглядит как программирование с некоторыми небольшими добавлениями, например, автоматическим тестированием. Однако разработка, как и все остальное в ХР, может показаться простой только на первый взгляд. Все составные части достаточно просты, чтобы их объяснить, однако использовать их совместно достаточно сложно. Как только вы начинаете практиковать ХР, у вас появляется страх. Как только появляется давление, возвращаются старые привычки.

Стратегия разработки начинается с планирования итерации. Постоянно выполняемая интеграция уменьшает количество конфликтов и является естественным завершением эпизода разработки. Коллективное владение стимулирует всю команду делать всю систему все лучше и лучше. Наконец, программирование парами связывает весь процесс в единое целое.


^ Постоянная интеграция


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

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

Интеграция через каждые несколько часов (не чаще чем через день) предоставляет множество преимуществ для обоих стилей – единственный программист и немедленная интеграция. Когда вы разрабатываете код, вы можете действовать так, как будто вы и ваш партнер – это единственная пара, работающая над проектом. Вы можете вносить в проект изменения тогда, когда вы этого хотите. После этого роли меняются. Когда вы приступаете к интеграции, вы узнаете (специальные средства сообщают вам об этом) о том, в каких именно определениях классов и методов возникли конфликты. Запустив тесты, вы узнаете о семантических конфликтах.

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

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

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

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

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


^ Коллективное владение


Коллективное владение – это на первый взгляд бредовая идея, предполагающая, что кто угодно имеет право изменять любой кусок кода в каком угодно месте системы в любое удобное для этого время. Если вы не практикуете автоматическое тестирование, применять коллективное владение на практике – это верный способ самоубийства. Однако с использованием тестирования и благодаря тому, что качество ваших тестов спустя месяцы практики в этом направлении будет достаточно высоким, вы можете смело использовать коллективное владение. Для того чтобы без опаски применять коллективное владение, необходимо также осуществлять интеграцию каждые несколько часов работы над проектом. Именно всем этим, конечно же, вы и будете заниматься в рамках ХР.

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

Коллективное владение в первую очередь препятствует проникновению сложного кода в систему. Если вы знаете, что кто-то еще кроме вас в самом ближайшем времени (буквально через несколько часов) будет просматривать код, который вы сейчас пишете, вы дважды подумаете, прежде чем добавите в систему сложный код, которому вы не можете довериться прямо сейчас.

Коллективное владение усиливает ощущение вашей личной власти над проектом. В рамках ХР-проекта вы никогда не проклинаете в бессилии чужую тупость, мало того, чужая тупость никогда не становится непреодолимой преградой на вашем пути. Если вы видите на своем пути препятствие, вы просто избавляетесь от него. Если вы предпочитаете сохранить что-либо, потому что это вам подходит, – это ваше личное дело. Но при этом вы никогда не попадаете в тупик. У вас никогда не возникает ощущения, что: Я мог бы отлично справится с моей работой, если бы только не все эти идиоты вокруг меня . А это значит, что у вас исчезает еще одна причина для огорчения. Вы еще на один шаг ближе к чистому мышлению.

Коллективное владение также способствует распространению знаний о системе среди членов команды. Очень маловероятно, что в системе найдется какая-либо часть, о строении которой будут знать только два человека (это должна быть по крайней мере пара, что уже лучше, чем распространенная ситуация, когда один очень умный программист держит всех остальных в заложниках). А это еще в большей степени снижает риск проекта.


^ Программирование парами


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

Для начала скажу, чем парное программирование не является. Парное программирование – это не значит, что один человек программирует, а другой смотрит. Смотреть на то, как кто-то программирует, и ничего при этом не делать – это также интересно, как смотреть на то, как зеленая трава умирает посреди иссушенной пустыни. Программирование в паре – это диалог между двумя людьми, пытающимися разрабатывать одновременно один и тот же код (и при этом анализировать, проектировать и тестировать), а также возможность совместно понять, как этот код можно запрограммировать лучше. Программирование в паре – это обмен информацией на нескольких уровнях, осуществляемый при помощи компьютера и сфокусированный на компьютере.

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

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

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

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

Что если кто-то отказывается работать в парах? Такие люди либо должны научиться работать так, как работает вся остальная команда, либо должны работать вне команды. ХР подходит далеко не каждому, и далеко не каждый подходит для ХР. Однако вовсе необязательно с самого первого дня внедрения ХР все свое рабочее время программировать в паре и только в паре. Как и ко всему остальному в ХР, вы должны привыкать к программированию в парах постепенно. Попробуйте работать в паре в течение часа. Если у вас плохо получится, попытайтесь понять, что именно вы делаете не так, затем попробуйте поработать в паре еще один час.

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

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

Даже если вы не получили роста продуктивности, вы все равно не должны сбрасывать со счетов программирование в парах, потому что получаемый в результате этого код обладает существенно более высоким качеством. Пока один из партнеров занят набиванием кода на клавиатуре, другой партнер размышляет на более высоком стратегическом уровне. Куда ведет избранный путь кодирования? Не попадем ли мы в тупик? Существует ли более эффективная стратегия организации этого кода? Какие есть возможности для переработки кода?

Еще одной важной особенностью программирования парами является то обстоятельство, что некоторые из методик ХР без него не работают. В состоянии стресса люди забывают о правилах хорошего тона. Они перестают писать тесты. Они отказываются от выполнения переработки. Они откладывают на потом интеграцию. Однако если за вами следит ваш партнер и при этом вы собираетесь нарушить одну из методик, у вас возникает чувство вины. Вам неудобно перед вашим партнером, так как вам кажется, что он никогда бы так не поступил. Сказанное не означает, что пары никогда не нарушают нормальный ход процесса разработки. Конечно же иногда это происходит, в противном случае вам не понадобился бы инструктор (coach). Однако если вы работаете в паре, вероятность того, что вы проигнорируете некоторые общепринятые правила, ниже, чем если бы вы работали в одиночку.

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


Глава 17.

Стратегия проектирования


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

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

Рассмотрим подробнее, что такое простота и что такое наборы тестов.


^ Самая простая вещь, которая, возможно, сработает


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

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

Простота – мы собираемся сформировать стратегию, которая помогала бы нам создавать простые дизайны, однако при этом, и сама стратегия должна быть простой. Это не означает, что она должна просто воплощаться в жизнь. Хороший дизайн – это всегда не так уж просто. Однако объяснить стратегию должно быть просто.

^ Обратная связь – одна из проблем, с которой мне приходилось сталкиваться в процессе проектирования, прежде чем я начал практиковать ХР, состояла в том, что я никогда не мог сказать точно, прав я или нет. Чем дольше я проектировал, тем значительней становилась эта проблема. Простой дизайн решает проблему благодаря тому, что он формируется быстро. Далее следует закодировать его и посмотреть, как выглядит и ведет себя код.

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

Следуя этим ценностям, мы должны:

• сформировать стратегию проектирования, в результате использования которой формируется простой дизайн;

• найти быстрый способ убедиться в том, что дизайн качественный;

• организовать обратную связь для того, чтобы быстро воплощать наши новые открытия и выводы в дизайне системы;

• сжать цикл времени, в течение которого выполняется весь этот процесс, и сделать его как можно короче.

Принятые нами ранее принципы также хорошо воплощаются в стратегии дизайна.

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

^ Приемлемая простота – мы должны быть уверенными в предположении, что самый простой дизайн, решающий проблему, который мы только можем себе представить, скорее всего, будет работать. Благодаря этому мы получим дополнительное время на решение возникших проблем в случае, если сформированный нами простой дизайн не срабатывает. Кроме того, благодаря такому подходу нам не придется тратить дополнительные ресурсы на обеспечение дополнительной гибкости.

^ Постепенное изменение – стратегия дизайна будет работать благодаря постепенному изменению. Мы будем проектировать постепенно и понемногу. Никогда не наступит момент времени, когда можно будет сказать, что система полностью спроектирована. Дизайн системы будет постоянно меняться, однако при этом некоторые части системы, возможно, будут оставаться неизменными в течение некоторого времени.

^ Путешествие налегке – стратегия проектирования не должна формировать какого-либо лишнего дизайна. Дизайн должен быть достаточным для того, чтобы решать наши текущие задачи (необходимость делать качественную работу), но не более того. Если нам придется постоянно все менять, мы должны иметь возможность начать с самого простого и постоянно пересматривать то, что у нас имеется на текущий момент.

ХР работает против многих программистских инстинктов. Мы, программисты, привыкли ожидать появления проблем. Если проблемы откладываются на более позднее время, мы счастливы. Если проблемы не появляются, мы не обращаем на это внимания. Поэтому наша стратегия проектирования должна увести нас в сторону от этих размышлений о будущем. К счастью, большинство разработчиков способно отучится от этой привычки брать неприятности взаймы (как про это говорила моя бабушка). К сожалению, чем вы умнее, тем сложнее вам отучиться от этого.

Еще один способ взглянуть на это предлагает заданный себе вопрос: ^ Когда следует добавить еще дизайна? Общепринято отвечать на него, что вы должны думать о том, какие проблемы встанут перед вами завтра, и исходя из этого вы должны проектировать программу с расчетом на завтра (рис. 8).


^ Рис. 8. Если стоимость затрат стремительно растет с течением времени

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

Проблема, связанная с этой стратегией, – это неопределенность.

На практике:

• иногда завтра не наступает никогда (то есть возможность, которую вы спроектировали заранее, больше не интересует заказчика);

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

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

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


^ Рис. 9. Если с течением времени стоимость изменений остается невысокой

Это ведет нас к созданию следующей стратегии проектирования:

1. Вначале разрабатывается тест, благодаря чему у нас появляется возможность определить момент завершения работы. Для того чтобы просто написать тест, мы опять же должны выполнить некоторый объем проектирования: мы должны определить набор объектов, с которыми мы работаем, а также набор видимых методов для этих объектов.

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

3. Повторяем.

4. Если мы видим возможность упростить наш дизайн, мы немедленно делаем это. Основные принципы, позволяющие нам определить степень простоты дизайна, рассматриваются в разделе: Что является самым простым?

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

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


^ Как работает проектирование при помощи переработки?


Если попробовать реализовать эту стратегию на практике, поначалу она покажется вам странной. Мы берем первый тестовый случай. Мы говорим: Если нам надо только лишь обеспечить срабатывание этого теста, тогда нам потребуется всего один объект с двумя методами . Мы создаем объект, добавляем в него два необходимых метода и считаем дело сделанным: весь наш дизайн – это один объект. Но только на минуту.

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

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

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

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

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

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


^ Рис. 10. Проект и продукт обладают паралельными подклассами

Этот дизайн нарушает правило Once And Only Once (OAOO) объектно-ориентированного дизайна (код должен присутствовать в системе один раз и только один раз). Чтобы исправить ситуацию, мы начали работать над формированием дизайна, показанного на рис. 11.


^ Рис. 11. Контракт ссылается на класс Function (функция), но не имеет подклассов

В течение года, пока мы работали над этой системой, мы сделали множество небольших шажков в направлении желаемого дизайна. Мы перекладывали обязанности подклассов класса Contract (контракт) либо на подклассы Function (функция), либо на подклассы Product (продукт), В самом конце работы над заказом мы не смогли полностью избавиться от подклассов Contract, однако они стали существенно менее содержательными, чем в начале, и было очевидно, что мы держим курс на отказ от их использования. Все это время мы продолжали добавлять в систему новую функциональность.

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


^ Что является самым простым?


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

Может быть, самый простой дизайн – это дизайн с наименьшим количеством классов? Но если в системе мало классов, значит используемые объекты становятся настолько большими, что их неудобно использовать.

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

Когда я говорю самый простой дизайн, я имею ввиду следующие четыре ограничения в порядке приоритета.

1. Система (как ее код, так и соответствующие тесты) должна выражать собой все, что вы хотите сообщить о ней всем остальным участникам проекта.

2. Система не должна содержать дублирующегося кода (1 и 2 пункты вместе составляют собой правило Once and Only Once).

3. Система должна состоять из наименьшего возможного количества классов.

4. Система должна содержать в себе наименьшее возможное количество методов.

Цель проектирования системы – это, во-первых, выразить намерения программистов и, во-вторых, обеспечить место для размещения логики работы системы. Представленные здесь ограничения обеспечивают обрамление, в рамках которого необходимо удовлетворить двум этим условиям.

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

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

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

Еще один способ взглянуть на этот процесс – это провести аналогию со стиранием. У вас есть система, для которой срабатывают все тестовые случаи. Вы удаляете из нее все, что не имеет определенной цели – либо коммуникационной цели, либо вычислительной цели. То, что остается, – это самый простой дизайн, который, скорее всего, сработает.


^ Как это может работать?


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

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

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

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

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

Если стоимость сегодняшнего решения высока, вероятность того, что оно окажется правильным, низка, вероятность того, что завтра вы найдете лучший способ решить проблему, высока, а стоимость внесения изменений в дизайн завтра низка, то мы можем прийти к выводу, что если сегодня мы можем обойтись без решения, значит, мы ни в коем случае не должны принимать это решение сегодня. Именно такой подход используется в рамках ХР. Количество сложностей ровно на один день и не более того.

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


^ Роль рисунков в дизайне


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

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

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

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

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

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

Давайте взглянем:

^ Небольшие начальные инвестиции – предполагает, что мы должны рисовать небольшое количество картинок за один раз.

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

^ Быстрая обратная связь – предполагает, что мы должны быстро определить, приближают ли нас картинки к цели или нет.

Работать в соответствии с человеческими инстинктами – предполагает, что мы ожидаем рисование картинок от тех, кому удобнее работать с картинками.

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

В рамках ХР используется следующая стратегия: кто угодно может проектировать при помощи картинок что угодно, однако как только встает вопрос, ответ на который можно найти только при помощи кода, чтобы найти ответ, разработчики должны приступить к кодированию. Картинки не сохраняются. Например, графическую схему можно нарисовать на пластиковой доске фломастером. Если у вас возникает желание сохранить схему, это значит, что дизайн не был объяснен команде или не был отражен в системе.

Если вы имеете дело с разновидностью исходного кода, который лучше выражается при помощи картинок, тогда определенно вы должны выражать его, редактировать его и поддерживать его в виде картинок. Хорошим примером являются средства из категории CASE, которые позволяют вам целиком и полностью определять поведение всей системы при помощи графических изображений. Часто эту методику называют генерацией кода (code generation), или автоматической генерацией кода, однако для меня это – язык программирования. В этом случае я возражаю не против картинок, а против попыток хранения одной и той же информации о системе в двух разных синхронизированных между собой представлениях.

Если вы используете текстовый язык программирования, следуя этому совету, вы не должны тратить более чем 10-15 минут на рисование картинок. После этого вы поймете, какой вопрос вы хотите задать системе. После того как вы получите ответ, вы можете нарисовать еще несколько картинок до тех пор, пока вы не сформулируете еще один вопрос, который требует конкретного ответа.

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


^ Системная архитектура


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

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

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

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






страница7/10
Дата конвертации19.11.2013
Размер2.33 Mb.
ТипДокументы
1   2   3   4   5   6   7   8   9   10
Разместите кнопку на своём сайте или блоге:
rud.exdat.com


База данных защищена авторским правом ©exdat 2000-2012
При копировании материала укажите ссылку
обратиться к администрации
Документы