Принципы, паттерны и методики гибкой разработки на языке C#

Принципы, паттерны и методики гибкой разработки на языке C#
Автор: Роберт Мартин, Мика Мартин
Год: 2011
ISBN: 978-5-93286-197-4
Страниц: 768
Язык: Русский
Формат: PDF
Размер: 17 Мб

Download

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

+

1 Гибкие методики

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

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

Организация Agile Alliance

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

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

Плодотворное сотрудничество с заказчиком больше,
чем формальные договоренности по контракту.
Оперативное реагирование на изменения больше,
чем следование плану.
Иначе говоря, не отрицая значимость факторов, перечисленных
в правой части предложений, мы больше ценим те, что слева.
Кент Бек Джеймс Греннинг Роберт К. Мартин
Майк Бидл Джим Хайсмит Стив Меллор
Ари ван Беннекум Эндрю Хант Кен Швабер
Алистер Кокбэрн Рон Джеффрис Джефф Сазерленд
Уорд Каннингэм Йон Керн Дэйв Томас
Мартин Фаулер Брайан Мэрик

Люди и их взаимоотношения важнее процессов и инструментов

Люди – важнейшая составная часть успеха. Самый лучший процесс не спасет проект от провала, если в команде нет сильных игроков. Однако плохой процесс может сделать даже сильнейших игроков неэффективными. И даже коллектив, состоящий сплошь из сильных игроков, может потерпеть фиаско, если его члены не будут работать как единая команда.
Сильный игрок – не обязательно ас программирования. Сильным игроком может быть средний программист, умеющий хорошо работать вместе с другими. Умение работать с коллегами – общаться и взаимодействовать – важнее, чем талант к программированию сам по себе. Команда средних программистов, умеющих работать совместно, скорее добьется успеха, чем группа суперзвезд, не способных быть командой.
Для успеха может оказаться чрезвычайно важен выбор подходящих инструментов. Компиляторы, интерактивные среды разработки (IDE), системы управления версиями исходного кода и пр. – все это существенно для функционирования команды разработчиков. Но значимость инструментов не стоит переоценивать. Чрезмерное изобилие больших и громоздких инструментов столь же плохо, как и их нехватка.
Наш совет – начинать с малого. Не считайте, что вы переросли инструмент, пока не опробовали его и не поняли, что он вам не подходит. Вместо того чтобы покупать новейшую супердорогую систему управления версиями, найдите бесплатную и работайте с ней, пока не станет ясно, что имеющихся в ней функций уже не хватает. Прежде чем приобретать групповую лицензию на самую лучшую систему автоматизированной разработки программ (CASE), попробуйте поработать с доской и миллиметровкой, пока не убедитесь, что вам нужно нечто большее. Прежде чем прибегать к самой новой монструозной СУБД, попробуйте
плоские файлы. Не думайте, что стоит заиметь большой и хороший инструмент, как ваша работа автоматически улучшится. Зачастую такие инструменты больше мешают, чем помогают. Помните, что создание команды важнее, чем создание среды разработки. Многие команды и менеджеры впадают в одну и ту же ошибку: первым делом готовят среду и думают, что команда спаяется сама собой. А следовало бы сначала собрать команду, а потом позволить ей сконфигурировать среду так, как она сочтет нужным.

Работающая программа важнее исчерпывающей документации

Программа без документации – это ужас. Код – не самое подходящее место для описания назначения и структуры системы. Команда обязана подготовить понятные человеку документы, в которых описывалась бы система и обосновывались принятые проектные решения.
Однако слишком много документации хуже, чем слишком мало. На создание огромных томов документации уходит много времени и еще больше – на синхронизацию их с кодом. Если же документация не соответствует коду, то становится большой и запутанной ложью и источником дезинформации.
Очень неплохо, когда команда составляет и поддерживает в актуальном состоянии короткий документ, содержащий обоснования решений и описание структуры. Но он должен быть кратким и существенным. Под «кратким»я понимаю десяток-другой страниц, не более. Говоря «существенный», я имею в виду, что в документе рассматриваются только общие особенности проекта и системные структуры самого верхнего уровня.
Но если у нас есть только краткий документ с обоснованием и описанием структуры, то как ввести новых членов команды в курс дела? Просто надо тесно сотрудничать с ними. Передавать знания, сидя рядом и оказывая необходимую помощь. Новые люди становятся членами команды в результате персонального обучения и личного общения.
Два документа, лучше всего приспособленных для передачи информации новым членам команды, – это код и сама команда. Код не лжет относительно того, что делает. Извлечь обоснование и назначение из кода не всегда легко, но только код может служить точным источником информации. Постоянно изменяющееся устройство системы находится в головах членов команды. Самый быстрый и эффективный способ перенести это устройство на бумагу и передать другим – общение между людьми.
Многие команды застревали на полпути, стремясь создать документацию вместо программы. Зачастую эта ошибка бывает фатальной. Вот
простое правило, позволяющее избежать ее:

Первый закон документирования Мартина
Не создавайте документ, пока необходимость в нем не станет очевидной и срочной.

Плодотворное сотрудничество с заказчиком важнее формальных договоренностей по контракту

Программу нельзя заказать, как предмет потребления. Невозможно составить описание желаемой программы и надеяться, что кто-то разработает ее в оговоренные сроки по оговоренной цене. Сколько раз попытки трактовать программные проекты подобным образом терпели крах. Иногда неудачи оказывались весьма зрелищными.
У руководителей компаний возникает большое искушение сообщить разработчикам, что нужно сделать, и считать, что спустя некоторое время они явятся с готовой системой, удовлетворяющей всем требованиям. Но такой подход чреват низким качеством и срывом проекта.
Чтобы проект оказался успешным, необходимо регулярное и частое общение с заказчиком. Заказчик программы должен не полагаться на контракт или техническое задание, а плотно контактировать с командой разработчиков, регулярно высказывая свое мнение о том, что они сделали.
Контракт, в котором оговорены требования, сроки и стоимость проекта, – это фундаментальная ошибка. В большинстве случаев сформулированные в нем условия теряют смысл задолго до завершения проекта, а иногда даже задолго до подписания контракта! Самые лучшие контракты – те, что оговаривают способы взаимодействия заказчика с разработчиками.
Примером успешного контракта может служить тот, что я заключил в 1994 году на разработку большого, многолетнего проекта стоимостью в полмиллиона долларов. Нам, команде разработчиков, платили ежемесячно по сравнительно низкой ставке. Крупные платежи поступали, когда мы передавали в эксплуатацию большие функциональные блоки. Эти блоки не были детально специфицированы в контракте. Вместо этого в контракте оговаривалось, что блок будет оплачен после прохождения приемо-сдаточного испытания. Детали таких испытаний также не были оговорены в контракте.
По ходу работы над проектом мы тесно сотрудничали с заказчиком. Версии ПО выпускались чуть ли не каждую пятницу. К понедельнику или вторнику следующей недели мы получали список изменений, который следовало внести в программу. Мы совместно расставляли приоритеты и составляли график реализации изменений на следующие недели. Заказчик так плотно контактировал с нами, что приемо-сдаточные испытания никогда не вызывали никаких проблем. Он знал о готовности функционального блока, потому что еженедельно наблюдал за его разработкой.
Требования к проекту менялись постоянно. Не редкостью были и принципиальные изменения. Бывало, что исключались целые функциональные блоки, а вместо них вставлялись новые. И тем не менее контракт и проект выжили и успешно завершились. Ключом к успеху было
тесное сотрудничество с заказчиком и контракт, в котором оговаривался именно порядок сотрудничества, а не детальные требования и сроки
при фиксированной цене.

Оперативное реагирование на изменения важнее следования плану

Способность реагировать на изменения часто определяет успех или провал программного проекта. Строя планы, необходимо следить за тем, чтобы они были гибкими и могли адаптироваться к изменениям в бизнесе и технологиях.
Ход работы над программным проектом нельзя планировать на длительный срок. Во-первых, условия функционирования бизнеса вполне могут измениться, и требования придется пересматривать. Во-вторых, заказчики, увидев, что система заработала, сразу начинают просить что-то изменить. Наконец, даже если мы заранее знаем требования и уверены, что они не изменятся, трудно оценить, сколько времени уйдет на их реализацию.
Для неискушенных менеджеров очень соблазнительно выглядит идея нарисовать и повесить на стену симпатичную PERT-диаграмму или график Гантта по проекту в целом. У них даже может возникнуть иллюзия, будто такая диаграмма позволяет им управлять проектом. Они могут отслеживать отдельные задачи и убирать их с диаграммы по мере завершения. Можно сравнивать фактические сроки с плановыми и реагировать на расхождения.
Но в действительностидиаграмма просто перестает быть актуальной. По мере того как команда больше узнает о системе, а заказчик – о потребностях команды, некоторые обозначенные на диаграмме задачи становятся ненужными. Но выявляются другие задачи, которые следует добавить. Короче говоря, изменяются не только даты, но и формаплана.
Более правильная стратегия планирования состоит в том, чтобы составлять подробные планы на следующую неделю, ориентировочные – на три месяца и совсем грубые – в более далекой перспективе. Необходимо знать, над какими задачами будут работать отдельные сотрудники в течение следующей недели. Нужно примерно представлять себе, какие требования будут реализовываться в течение следующих трех месяцев. И следует иметь общее представление о том, что сможет выполнять система через год.

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

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

  1. Высшим приоритетом считать удовлетворение пожеланий заказчика посредством поставки полезного программного обеспечения в сжатые сроки с последующим непрерывным обновлением.В журнале MIT Sloan Management Review был опубликован анализ методик разработки программ, которые помогают компаниям создавать высококачественные продукты. Авторы статьи выявили ряд факторов, оказывающих значительное влияние на качество конечной системы. Одним из них является корреляция между качеством и ранней поставкой частично работающей системы. В статье отмечается, что чем менее функциональна начальная версия, тем выше качество конечного продукта. Отмечается также наличие сильной корреляции между качеством конечного продукта и частыми выпусками новых версий с постепенно расширяющейся функциональностью. Чем чаще выпуски, тем выше качество конечного продукта. Гибкие методики подразумевают быструю поставку начальной вер-сии и частые обновления. Наша цель – поставить рудиментарную систему в течение нескольких недель с момента начала проекта. В дальнейшем системы с постепенно расширяющейся функциональ-ностью должны поставляться каждые несколько недель. Заказчик  может начать промышленную эксплуатацию системы, если сочтет, что она достаточно функциональна. А может просто ознакомиться с имеющейся функциональностью и сообщить о том, какие следует
    внести изменения.
  2. Не игнорировать изменение требований, пусть даже на поздних этапах  разработки.  Гибкие  процессы  позволяют  учитывать  изменения ради обеспечения конкурентных преимуществ заказчику. Это выражение нашей позиции. Люди, практикующие гибкие процессы, не боятся изменений. Они считают изменения требований благом, так как любое изменение улучшает понимание командой потребностей заказчика. Гибкая команда прилагает все силы к тому, чтобы сделать структуру программы подвижной и тем самым минимизировать влияние изменений на систему в целом. Ниже в этой книге мы будем обсуждать принципы, паттерны и методики объектно-ориентированного проектирования, позволяющие добиться такой гибкости.
  3. Поставлять новые работающие версии ПО часто, с интервалом от пары недель до пары месяцев, отдавая предпочтение меньшим срокам. Мы поставляем работающую программу и делаем это быстро и часто. Мы не довольствуемся поставкой кипы документов или планов. Мы вообще не считаем последние объектом поставки. Наша цель – поставить программу, удовлетворяющую потребности пользователя.
  4. Заказчики и разработчики должны работать совместно на протяжении всего проекта. Чтобы проект можно было назвать гибким, заказчики, разработчики и все заинтересованные стороны должны общаться часто и помногу. Программный проект – это не самонаводящийся снаряд. Программному проекту нужно постоянно уделять внимание.
  5. Проекты  должны  воплощать  в  жизнь целеустремленные люди. Создайте им условия, обеспечьте необходимую поддержку и  верьте, что  они доведут дело  до конца.Люди – важнейшее условие успеха. Все остальные факторы – процесс, среда разработки, управление и т. д. – вторичны и могут быть изменены, если негативно отражаются на людях.
  6.  Самый эффективный и продуктивный метод передачи информации команде разработчиков и обмена мнениями внутри нее – разговор лицом к лицу.В гибком проекте люди разговаривают друг с другом. Основной способ коммуникации – простое человеческое общение. Письменные документы создаются и обновляются постепенно по мере разработки ПО и только в случае необходимости.
  7. Работающая программа – основной показатель прогресса в проекте. О приближении гибкого проекта к завершению судят по тому, насколько имеющаяся в данный момент программа отвечает требованиям заказчика. Прогресс не оценивается в терминах текущего этапа, количества документации или объема написанного инфраструктурного кода. Проект закончен на 30%, если присутствует 30% необходимой функциональности.
  8. Гибкие процессы способствуют долгосрочной разработке. Заказчики, разработчики и пользователи должны быть в состоянии поддерживать неизменный темп сколько угодно долго.Гибкий проект – не забег на 50 ярдов, а, скорее, марафон. Команда не стартует на максимально возможной скорости, думая только о том, как бы дотянуть до конца дистанции. Нет, она бежит в высоком, но позволяющем долго продержаться темпе. Слишком быстрый бег приводит к изнеможению, поиску коротких путей и неудаче. Гибкие команды не устраивают гонки. Они не позволяют себе слишком быстро уставать. Они не занимают завтрашнюю энергию, чтобы побольше успеть сегодня. Они работают в том темпе, который обеспечивает соблюдение высочайших стандартов качества на протяжении всего проекта.
  9. Непрестанное  внимание  к  техническому  совершенству  и  качественному проектированию повышает отдачу от гибких технологий. Высокое качество – ключ к высокой скорости. Чтобы продвигаться быстро, нужно писать максимально чистый и надежный код. Поэтому все члены гибкой команды стремятся создавать только код самого высокого качества. Они не оставляют беспорядка, обещая себе прибраться, как только появится время. Порядок наводится незамедлительно.
  10. Простота – искусство достигать большего, делая меньше, – основа основ. Гибкие команды не пытаются возводить системы-небоскребы. Напротив, они всегда ищут простейший путь, ведущий к цели. Они не придают первостепенного значения предвидению завтрашних проблем и не пытаются решить их сегодня. Вместо этого они решают сегодняшние задачи максимально просто и качественно, будучи уверены в том, что если завтра возникнет какая-то проблема, то можно будет без труда внести изменения.
  11. Самые лучшие архитектуры, требования и проекты выдают само-организующиеся команды.Гибкая команда – самоорганизующийся коллектив. Задачи поручаются не отдельным членам команды из-вне, а команде в целом. Команда сама решает, как лучше всего справиться с порученными задачами.
    Члены гибких команд совместно работают над всеми аспектами проекта. Каждому участнику разрешено вносить свой вклад в общее дело. Нет такого члена команды, который единолично отвечал бы за архитектуру, требования или тесты. Ответственность лежит на команде в целом, и у каждого ее члена есть право голоса.
  12. Команда должна регулярно задумываться над тем, как стать еще более  эффективной,  а  затем  соответственно  корректировать и подстраивать  свое  поведение. Гибкая команда постоянно корректирует свою организацию, правила, соглашения, взаимоотношения и т. д. Она знает, что окружение непрестанно изменяется, и понимает, что должна изменяться вместе с ним, если хочет остаться гибкой.

Заключение
Профессиональная цель любого разработчика или команды разработчиков ПО – предложить заказчикам и работодателям продукт максимально высокого качества. И тем не менее количество неудачных проектов остается чересчур высоким. Раскручивающаяся спираль разбухания процессов, пусть даже с самыми благими намерениями, – одна из причин таких неудач. Шкала ценностей и принципы гибкой разработки составлены таким образом, чтобы разорвать порочный круг разбухания технологического процесса и сосредоточиться на простых методах достижения целей.
Во время работы над этой книгой можно было выбирать из нескольких гибких процессов: SCRUM, Crystal, разработка по свойствам (Feature-driven development – FDD), адаптивная разработка программ (Adaptive software development – ADP)и экстремальное программирование (Extreme programming – XP). Однако большинство успешных гибких команд взяли что-то полезное из каждого процесса, подстроив это под свое представление о гибкости. Такие адаптации концентрируются вокруг SCRUM и XP, причем методики SCRUM применяются для управления несколькими командами, практикующими XP.