Вы также должны серьезно подумать о том, что кто-то из членов команды должен выполнять роли наставника (coach) и наблюдателя (tracker).

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

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

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

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

Из удивительно сложных вещей появляются удивительно простые вещи.
Уинстон Черчилль (Winston Churchill)

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

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

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

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

Определение простоты

Какой дизайн является самым простым из возможных? Кент определяет такой дизайн следующим образом:

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

Хорошо сделанный дизайн

Том Кубит (Tom Kubit)

Когда мы с Доном Уэллсом (Don Wells) работали над одним XP-проектом в компании Ford, он однажды сказал мне: «Иногда найти самый простой способ из всех возможных — это самая сложная задача, с которой ты когда-либо сталкивался». Тогда я ответил ему: «Однако когда ты обнаруживаешь этот способ, дизайн кажется настолько простым, что каждый, который смотрит на него, удивляется, почему для этого понадобилось столько времени?» Именно так зачастую и происходит. Длительное время вы пытаетесь придумать идеальный дизайн, а потом, когда вы его все-таки создаете, кто-нибудь говорит вам, что столь простую штуку можно было бы сделать и быстрее. Если вам говорят такую фразу, не огорчайтесь, воспринимайте это как большой комплемент. Подобное случалось с нами много раз. Все дело в том, что самые простые идеи далеко не всегда приходят в голову самыми первыми. Однако когда вы обнаруживаете их, вы смотрите на плод своего труда и говорите: «Хорошо сделано!» Copyright © 2001 by Tom Kubit. All rights reserved.

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

Стив Хайес (Steve Hayes) сообщил нам:
Я думаю, что выражение «четко и ясно выражать намерения программиста» на текущий момент является одним из наиболее глубоких выражений, содержащихся в книгах, посвященных XP. Вначале я не достаточно хорошо понимал, насколько глубоким является это выражение. Если не принимать его во внимание, самым простым решением будет единственный класс с методами, устраняющими дублирование кода. Все остальное было бы закодировано в виде процедур. Когда я начал делать XP-презентации, я узнал, что именно так большинство людей трактует выражение «самый простой дизайн». Многие люди говорили мне, что XP противоречит проверенным принципам ООП, таким как инкапсуляция. Для меня было очевидным, что эти люди ошибаются. Однако, по всей видимости, именно такое впечатление складывалось на основе имеющейся литературы об XP. Мы должны объяснить людям, что выражение «делать понятными намерения программиста» означает создавать объекты, каждый из которых отвечает за решение только одной задачи (потому что в этом случае намерения программиста становятся яснее); это означает использовать паттерны проектирования; это означает отделять модель от представления и от контроллера. Это означает пользоваться всеми проверенными принципами ООП и еще многое другое.1

Почему люди не используют простой дизайн

Как правило, приступая к работе, никто не ставит перед собой задачу создать самый сложный дизайн из всех возможных. Ну почти никто. Джим Хайсмит (Jim Highsmith) сообщил нам:

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

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

Разработчики программ предпочитают сложные технические решения по привычке. В школе их учили тому, что для сложных проблем необходимо использовать сложные решения. У них отсутствует привычка сначала подумать о проблеме, а затем попытаться найти самое простое решение. Усложнение дизайна происходит естественно: со временем дизайн деградирует. Вот что говорит об этом Мартин Фаулер (Martin Fowler) в своей книге о рефакторинге:

Чем сложнее увидеть дизайн в коде, тем сложнее сохранить его и тем быстрее он разрушается.3

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

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

Чтобы сохранять простоту дизайна, вам потребуется следующее:

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

Зачем необходимо сохранять вещи простыми?

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

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

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

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

Как начать использовать простой дизайн

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

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

Вспомните правила из главы 8. Когда вы начинаете думать о сохранении простоты дизайна, ваши мысли должны быть простыми. Вспомните о первом рабочем дне Роя в компании RoleModel. На решение поставленной перед ним задачи Рой потратил около четырех часов, причем полученное решение было ужасающе сложным. Кен решил ему помочь, за 30 минут он написал в три раза менее объемный код, который решал поставленную задачу. В чем разница? Рой услышал, как другой член команды спросил, насколько успешно Рой справился с заданием. «Ему необходимо научиться думать просто», — ответил Кен.

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

Как я заставлял себя думать просто

Джефф Маккена (Jeff McKenna)

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

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

Приведенный мною пример с коллекциями весьма показателен. Я описал его, когда рассказывал об этой дилемме на семинаре, посвященном экстремальному программированию, который проходил в рамках конференции OOPSLA 2000. Позже оказалось, что требование реализовать поддержку работы с несколькими пользователями перенесли на более позднее время. Мы не занимались этим вопросом в течение шести месяцев! Иными словами, реализованный мною «более совершенный» дизайн оказался излишним. Мало того, он стал причиной снижения производительности. Хуже того, когда мы приступили наконец к реализации многопользовательской поддержки, мы пришли к выводу, что в сложившихся условиях будет лучше отказаться от синхронизируемых коллекций. Эта история превосходно иллюстрирует принцип YAGNI.

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

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

Каждый класс должен отвечать за решение только одной задачи. Простой класс не может использоваться для решения нескольких разных задач.

Необходимо придерживаться закона Деметры (Law of Demeter)1. При этом функциональность будет заключаться в «правильном» классе. Если при этом класс будет отвечать за слишком многое (у него будет больше чем одна ответственность), его можно разделить. Если появляются классы, которые не отвечают ни за что, их необходимо удалить.

Необходимо использовать концепцию стереотипов. Ребекка Вёфс-Брок (Rebecca Wirfs-Brock) придумала концепцию часто встречающихся типов классов. Каждый такой тип основан на предназначении класса. Ребекка назвала их стереотипами2. Примерами стереотипов могут быть контроллер (Controller), хранилище данных (Data Store), интерфейс (Interface) или диспетчер (Dispatcher). Идентифицируйте используемые в рамках вашего дизайна стереотипы и сделайте так, чтобы каждый из объектов принадлежал только к одному из них.

Используйте CRC-карты для исследований. Вы сможете лучше понять дизайн, если вы сможете в него «сыграть». Зачастую, когда вы «играете» в дизайн, вы получаете самый простой дизайн из всех возможных. Copyright © 2001 by Jeff McKenna. All rights reserved.

Почему не следует использовать простой дизайн с самого начала?

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

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

Лучший в этом отношении совет я услышал от дяди Боба (Robert Martin). Он советует не особенно мучиться над тем, чтобы ваш дизайн был самым простым из всех возможных. В конце концов вы не только можете, но и обязаны в дальнейшем выполнить рефакторинг. Желание выполнить рефакторинг имеет значительно большее значение, чем желание с самого начала получить самый простой дизайн.1

Другие естественные силы, действующие в рамках XP, также способствуют формированию простого дизайна. Мы зачастую обнаруживаем, что если должным образом представить проблему заказчику, он также может стимулировать формирование простого дизайна.

Кен отлично помнит время, когда в магазинах появилась книга GoF2. Многие люди были настолько очарованы паттернами, что они пытались использовать тот или иной паттерн для решения каждой из проблем вне зависимости от того, была ли эта проблема достаточно сложной или смехотворно простой. Иногда Кен даже жалел о том, что познакомил того или иного человека с книгой о паттернах. Однажды он обнаружил, что один из программистов воспользовался паттерном State (состояние) там, где вполне можно было использовать простой условный оператор. В этом случае следует вспомнить о YAGNI. Используйте условный оператор. Если одно и то же условие проверяется во множестве методов одного и того же класса, подумайте о применении паттерна State. Опытные дизайнеры, как правило, хорошо знают об этом, однако новички легко могут упустить это из виду.

С другой стороны, используя правила XP, новичок может упустить из виду то, что опытный дизайнер чувствует за версту. Опытный дизайнер предлагает реализовать нечто похожее на машину состояний в задаче, для которой необходимость подобного подхода не очевидна. Менее опытный проектировщик говорит: «YAGNI». Возможно, опытный дизайнер ошибается. Он может попробовать объяснить свою правоту, однако иногда полезно обратиться за советом к заказчику (в смысле к бизнесменам, которым предстоит использовать разрабатываемый продукт). Возможно, именно заказчик сможет точно определить, какой подход будет более правильным в дальней перспективе. Вместо того чтобы спорить между собой, расскажите о проблеме заказчику. Ясно опишите ему преимущества и недостатки спорного подхода, пусть заказчик выскажет свое мнение.

Простой дизайн может быть бизнес-решением

Кен Ауэр (Ken Auer)

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

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

Наставник: О’кей, теперь давайте разобьем это пожелание на несколько задач. Что необходимо сделать?

Фрэнк: Необходимо вместо поля X вставить комбобокс и…

Наставник (прерывая): Фрэнк, давай спросим об этом у заказчика. Заказчик расскажет нам, чего он хочет, а мы зададим ему вопросы в случае, если либо он, либо мы чего-то не понимаем.

Заказчик: Вообще-то мне бы хотелось заменить поле X на комбобокс, обеспечить интернационализацию текстовых меток и сделать недоступными некоторые кнопки.

Фрэнк: Отлично. Мы вполне можем сделать это.

Джо: Можно мне сказать?

Наставник: Говори.

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

Заказчик: Мне все равно, как вы это сделаете.

Джо: Но я думаю, что это повлияет на трудозатраты.

Заказчик: Используйте способ, при котором трудозатраты будут наименьшими.

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

Заказчик: Вы уверены?

Джо: Давайте, я объясню вам мою мысль простыми словами, так, чтобы вам было понятно. Чтобы отключить некоторые из элементов интерфейса, иногда используют достаточно хрупкий код, который производит поиск всех необходимых кнопок и пунктов меню. Иногда этот код приходится дублировать, в подобной ситуации очень сложно обеспечить четкость внутренней логики (при этих словах некоторые разработчики согласно закачали головами). Однако существует второй вариант: вы создаете внутри системы набор условий и связываете их с объектами, которые называются «активаторы» (enablers). Активатор — это объект, который связан с некоторым набором элементов управления. Активатор следит за состоянием условий и в зависимости от этого активирует или деактивирует все связанные с ним элементы интерфейса. Таким образом, код, включающий или отключающий элементы интерфейса, содержится в одном месте системы и не дублируется. Если один из элементов системы переключает некоторое условие, ассоциированный с этим условием активатор (enabler) автоматически активирует (или деактивирует) все связанные с ним элементы управления. Например, в приложении может использоваться условие «режим тестирования включен». Это условие может быть связано с несколькими активаторами (enabler), которые в свою очередь связаны с различными элементами интерфейса. Связи между активаторами и условиями определяются в одном месте, за счет этого существенно упрощается модификация пользовательского интерфейса. Если вы хотите добавить новое условие (например, уровень привилегий пользователя), вы легко добавляете его в эту систему и связываете с элементами интерфейса. Это происходит в одном месте — остальной код никоим образом не меняется. Иными словами, благодаря использованию подобного подхода мы сможем существенно сократить трудозатраты в будущем, однако в рамках текущей итерации для создания подобного механизма нам потребуется дополнительное время. Думаю, мы уложимся в несколько дней. Когда я программировал на Smalltalk, как правило, мне хватало одного дня. Я думаю, что на Java реализовать подобное будет сложнее, однако ненамного.

Заказчик: Сколько дней?

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

В этот момент разговор мог продолжиться в рамках одного из двух сценариев:

Сценарий 1

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

Сценарий 2

Заказчик: Я уверен, что в будущем нам придется постоянно менять правила, по которым кнопки становятся доступными и недоступными. Как вы считаете, сколько времени нам удастся сэкономить, когда мы перейдем к экрану навигации?

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

Заказчик: Мне необходимо знать, успеете ли вы в рамках текущей итерации реализовать эту систему настолько, чтобы кнопка Remove была заблокирована? Дело в том, что в конце итерации я планировал продемонстрировать экран завершения заказа сотрудникам службы технического обслуживания в целях обучения.

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

Заказчик: Отлично. Так и сделаем. Однако вы обязательно должны завершить работу над экраном завершения заказа к концу этой итерации.

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

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

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

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

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

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

Очень важный инструмент проектирования

CRC-карты — это неплохая штука. Нам они нравятся. Однако самый лучший инструмент проектирования показан на рис. 18.1.

Рис. 18.1. Доска для временных заметок

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

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

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

Начало
Cодержание
Отрывок
[Заказать книгу в магазине "Мистраль"]