Роль рисунков в дизайне - раздел Программирование, Экстремальное программирование
Что Можно Сказать О Графическом Представлении Дизайна, А Такж...
Что можно сказать о графическом представлении дизайна, а также о визуальном проектировании и анализе? Некоторым людям действительно удобнее размышлять о структуре системы при помощи визуальных образов, а не строк кода. Как может визуально‑ориентированный человек осуществлять проектирование системы?
Прежде всего хочу отметить, что если вместо чисто ментального или текстового представления вы проектируете систему с использованием графических изображений, в этом нет абсолютно ничего плохого. О визуальном подходе к проектированию следует сказать особо. Проблемы, которые возникают при рисовании графических диаграмм, могут служить подсказками, указывающими вам на состояние здоровья вашего дизайна. Если вы не можете найти способ уменьшить количество графических элементов на диаграмме, если существует явная асимметрия, если количество линий значительно превышает количество прямоугольников, все это может указывать на то, что дизайн неудачен. Таким образом, качество дизайна можно оценить на основании его графического представления.
Еще одним преимуществом визуального проектирования является скорость. За время, которое требуется для того, чтобы закодировать один вариант дизайна, вы можете сравнить три визуальных представления различных вариантов дизайна.
Недостатком графического представления является отсутствие надежной обратной связи. Имея перед глазами графическую схему системы, вы быстро получаете представление о том, насколько хорошо она спроектирована, и это в определенном смысле можно назвать полезной разновидностью обратной связи. Однако при этом вы лишаетесь другой разновидности обратной связи. К сожалению, обратная связь именно этой разновидности позволяет вам узнать о дизайне самое главное – можно ли с его помощью обеспечить срабатывание тестовых случаев? Позволяет ли данный дизайн обеспечить наиболее простую реализацию системы? Подобную обратную связь можно обеспечить только при помощи кодирования.
С одной стороны, если мы проектируем с использованием графики, мы можем делать это быстро. С другой стороны, проектируя с использованием графики, мы увеличиваем риск. Нам необходима стратегия, которая позволила бы воспользоваться преимуществами визуального проектирования и при этом нейтрализовать его недостатки.
К счастью, у нас есть все необходимое для разработки этой стратегии. У нас есть набор принципов, руководствуясь которыми мы можем действовать.
Давайте взглянем:
• Небольшие начальные инвестиции – предполагает, что мы должны рисовать небольшое количество картинок за один раз.
• Игра для победы – предполагает, что мы должны использовать картинки не от собственного страха (например, для того, чтобы оправдать упущенный день, который мы тратим на решение проблем с дизайном).
• Быстрая обратная связь – предполагает, что мы должны быстро определить, приближают ли нас картинки к цели или нет.
• Работать в соответствии с человеческими инстинктами – предполагает, что мы ожидаем рисование картинок от тех, кому удобнее работать с картинками.
• Принятие изменений и путешествие налегке – предполагает, что мы не сохраняем картинки, которые уже оказали свое влияние на код, так как решения, которые иллюстрируются этими картинками, скорее всего, завтра потребуется изменить.
В рамках ХР используется следующая стратегия: кто угодно может проектировать при помощи картинок что угодно, однако как только встает вопрос, ответ на который можно найти только при помощи кода, чтобы найти ответ, разработчики должны приступить к кодированию. Картинки не сохраняются. Например, графическую схему можно нарисовать на пластиковой доске фломастером. Если у вас возникает желание сохранить схему, это значит, что дизайн не был объяснен команде или не был отражен в системе.
Если вы имеете дело с разновидностью исходного кода, который лучше выражается при помощи картинок, тогда определенно вы должны выражать его, редактировать его и поддерживать его в виде картинок. Хорошим примером являются средства из категории CASE, которые позволяют вам целиком и полностью определять поведение всей системы при помощи графических изображений. Часто эту методику называют генерацией кода (code generation), или автоматической генерацией кода, однако для меня это – язык программирования. В этом случае я возражаю не против картинок, а против попыток хранения одной и той же информации о системе в двух разных синхронизированных между собой представлениях.
Если вы используете текстовый язык программирования, следуя этому совету, вы не должны тратить более чем 10‑15 минут на рисование картинок. После этого вы поймете, какой вопрос вы хотите задать системе. После того как вы получите ответ, вы можете нарисовать еще несколько картинок до тех пор, пока вы не сформулируете еще один вопрос, который требует конкретного ответа.
Тот же совет имеет силу и в отношении других некодовых нотаций дизайна, таких как карты CRC. Занимайтесь этим в течение нескольких минут для того, чтобы сформулировать вопрос, затем обратитесь к системе, чтобы снизить риск того, что вы занимаетесь самообманом.
Все темы данного раздела:
О серии ХР
Экстремальное программирование (Extreme Programming), часто обозначаемое аббревиатурой ХР, – это дисциплина разработки программного обеспечения и ведения бизнеса в области создания
Данная книга
Данная книга рассказывает о вещах, связанных с методикой ХР, – ее корнях, философии, разного рода историях и мифах. Книга предназначена для того, чтобы помочь вам принять взвешенное
Что такое ХР?
Что такое ХР? ХР – это упрощенный, эффективный, гибкий, предсказуемый, научно обоснованный и весьма приятный способ разработки программного обеспечения, предусматривающий низкий уро
Достаточность
В своих работах The Forest People(Лесные народы) и The Mountain (People Горные народы) антрополог Колин Тернбулл (Colin Turnbull) описывает два совершенно отличающихся друг о
План книги
Книга написана так, как будто вы и я вместе занимаемся созданием новой дисциплины разработки программного обеспечения. Мы начинаем с изучения наших базовых представлений о разработк
Благодарности
Я обращаюсь к читателям от первого лица не потому, что в книге представлены мои собственные идеи, а потому, что я рассказываю вам о моем собственном восприятии этих идей. Большая ча
Проблема
В данной части книги подготавливается сцена, на которой должно в последующем появиться экстремальное программирование. Здесь описываются различные аспекты проблемы, которую предстои
Наша цель
Если мы признаем, что риск является основной проблемой, которую требуется решить, то в каком месте следует искать решение этой проблемы? Перед нами стоит задача сформировать стиль р
Экономика разработки программного обеспечения
Мы должны сделать разработку программного обеспечения экономически более выгодной, для этого мы должны тратить деньги медленнее, приносить прибыль быстрее, а также увеличива
Взаимосвязь между переменными
Затраты (cost) – чем больше денег, тем легче работать, однако слишком большое количество денег в самые кратчайшие сроки создаст больше проблем, чем требуется решить. С другой
Фокус на объеме работ
Множество людей хорошо знает, что такое затраты, качество и время, и как с их помощью контролируется процесс производства программного обеспечения, однако при этом многие из них не
Коммуникация
Первая ценность ХР – это коммуникация. Проблемы, которые возникают в процессе работы над проектом, почти всегда связаны с тем, что кто‑то не сказал кому‑то о чем‑т
Простота
Вторая ценность ХР – это простота. Инструктор ХР спрашивает команду: Какова самая простая вещь, которая скорее всего сработает? (эта фраза является часто употребляемым выражением, в
Обратная связь
Третья ценность в ХР – это обратная связь. Инструктор ХР часто произносит: Не спрашивай у меня, спроси у системы и Ты еще не написал для этого тестовый случай? Обратна
Храбрость
В контексте первых трех рассмотренных ранее ценностей – коммуникации, простоты и обратной связи – необходимо действовать с максимально возможной скоростью. Если вы работаете со скор
Ценности на практике
Я обратился к команде СЗ (именно эти люди работали над тем самым крупным ХР‑проектом, о котором я говорил чуть раньше) с просьбой рассказать мне о моменте в процессе работы на
Кодирование
В конце дня у нас должна быть готовая программа. Таким образом, я прихожу к выводу, что кодирование – это как раз та самая деятельность, без которой нам не обойтись. Рисуете ли вы д
Тестирование
Английские философы‑позитивисты Лок (Locke), Беркли (Berkeley) и Хьюм (Hume) утверждают, что все, чего нельзя измерить, на самом деле не существует. Если речь заходит о коде,
Слушание
Программисты ничего не знают. Говоря точнее, программисты не знают ничего такого, что является интересным для бизнесменов. Если бы бизнесмены могли обойтись без программистов, они б
Проектирование
Почему нельзя просто слушать, затем писать тестовый случай, затем заставить его работать, затем опять слушать, опять писать тестовый случай и опять заставить его работать, и так дал
Решение
Можно считать, что мы подготовили сцену, на которой должна появиться разрабатываемая нами дисциплина. Мы познакомились с проблемой, которую нам предстоит решить. Мы поняли, что для
Игра в планирование
Ни соображения бизнеса, ни технические соотношения не должны превалировать. Разработка программного обеспечения – это всегда эволюционирующий диалог между желаемым и возможным. Прир
Небольшие версии
Каждая версия должна быть настолько маленькой, насколько это возможно. В ней должны быть реализованы наиболее ценные для бизнеса требования. В целом версия должна быть логически зав
Метафора
Каждый программный проект ХР направляется при помощи единой всеобъемлющей метафоры. Иногда эта метафора выглядит наивной, как, например, система управления контрактами, о которой ра
Простой дизайн
В каждый момент времени правильным является дизайн системы, в рамках которого:
1. Выполняются все тесты.
2. Нет дублирующейся логики. (Опасайтесь скрытого дублиров
Тестирование
Любая возможность программы, для которой нет автоматических тестов, просто не существует. Программисты пишут тесты модулей, благодаря чему их уверенность в правильности функциониров
Переработка
Когда программисты приступают к реализации некоторой возможности программы, они всегда задаются вопросом, существует ли способ изменения имеющейся программы для того, чтобы упростит
Программирование парами
Весь код системы вплоть до ее внедрения в производство пишется парами программистов, каждая из которых работает на одном компьютере, оснащенном одной клавиатурой и одной мышью.
Коллективное владение
Любой член команды, который видит возможность добавить что‑либо в любой раздел кода системы, может сделать это в любой подходящий для этого момент времени.
Сравните э
Постоянно продолжающаяся интеграция
Код интегрируется и тестируется каждые несколько часов, минимум один раз в день. Для того чтобы обеспечить это, проще всего выделить для этой цели один специально предназначенный дл
Часовая рабочая неделя
Я хочу быть свежим и энергичным каждое утро, равно как и уставшим и удовлетворенным каждый вечер. Каждую пятницу я хочу быть уставшим и удовлетворенным настолько, чтобы в течение по
Заказчик на месте разработки
Для ответов на возникающие вопросы, решения споров и установки мелкомасштабных приоритетов рядом с командой разработчиков должен постоянно находиться реальный заказчик. Под термином
Стандарты кодирования
Если мы собираемся перебрасывать программистов с разработки одной части системы на разработку другой части системы, обеспечивать постоянную смену партнеров в парах по несколько раз
Методики поддерживают друг друга. Слабость одной из них покрывается за счет силы других.
Подождите‑ка минутку! Ни одна из перечисленных ранее методик не является уникальной или оригинальной. Все они используются уже давно, с самого начала эпохи программирования. От многих из этих
Игра в планирование
Вы не можете начать работу над проектом, имея на руках лишь грубый, нечеткий план предстоящей работы. Вы не можете постоянно обновлять ваш план – это потребовало бы слишком много
Небольшие версии
Вы не можете приступить к эксплуатации системы уже через несколько месяцев работы над проектом. Вы определенно не можете выпускать новые версии системы каждый день или каждые нес
Метафора
Вы не можете приступать к разработке, обладая лишь метафорой. В метафоре недостаточно детально отображено строение системы, кроме того, что, если, формируя метафору, вы сделаете
Простой дизайн
Вы не можете разрабатывать систему, дизайн которой достаточен лишь для того, чтобы решать только сегодняшние задачи. Вы не можете проектировать систему, не уделяя внимание тому,
Программирование в парах
Вы не можете программировать парами. Двум людям очень сложно писать один и тот же код. Это слишком медленно. Кроме того, вам кажется, что два человека по отдельности на двух разн
Коллективное владение
Вы не можете разрешить каждому члену команды вносить любые изменения в любое место системы в любое удобное для этого время. В результате этого программисты немедленно разбросают
Постоянно продолжающаяся интеграция
Вы не можете интегрировать всю систему каждые несколько часов работы. Интеграция – это очень серьезный и длительный процесс, в ходе которого, как правило, приходится устранять мн
Часовая рабочая неделя
Вы не можете работать только 40 часов в неделю. Вы не успеете выполнить весь необходимый объем работ.
Однако в ХР:
• игра в планирование за
Заказчик на месте разработки
Вы не можете получить реального представителя заказчика, который все свое рабочее время сидел бы в офисе, где осуществляется разработка. Такой человек более ценен на производстве
Стандарты кодирования
Вы не можете заставить команду кодировать в соответствии с общими для всех стандартами. Каждый программист – это индивидуальность, ему легче отказаться от общих стандартов, чем п
Метрики
Основным инструментом оценки в ХР является метрика. Например, отношение ожидаемого времени разработки к календарному времени является базовой мерой оценки в ходе игры в планирование
Инструктирование
То, что многие понимают под менеджментом, в ХР делится на две роли: инструктор (coach) и ревизор (tracker). Обе эти роли могут исполняться одним и тем же членом команд
Слежение
Слежение (tracking), или, точнее говоря, отслеживание , – это еще один важный компонент менеджмента в ХР. Вы можете делать любые предположения и оценки, но если вы не
Интервенция
Управление командой ХР – это не только хождение за едой и покупка игрушек. В некоторых ситуациях возникшие проблемы просто не могут быть решены за счет гениальности независимой и са
Разработчики
Можно подумать, что если большие полномочия предоставляются разработчикам, жизнь становится лучше. Но на самом деле это не так. В действительности результат получается такой же.
Что делать?
Решение состоит в том, чтобы определенным образом разделить полномочия и ответственность между бизнесом и разработчиками. Бизнесмены должны принимать решения в своей области компете
Выбор технологии
Поначалу может показаться, что выбор технологии – это чисто техническое решение, но на самом деле это бизнес‑решение, однако бизнесмены должны формировать его на основе сведен
Что если это сложно?
В большинстве случаев решения, которые формируются в рамках этого процесса, на удивление просто воплотить в жизнь. Программисты отлично видят чудовищ, которые притаились за каждой и
Игра в планирование
Планирование в ХР намеренно абстрагирует процесс планирования для двух участников – бизнес (Business) и разработчики (Development). Это способствует устранению некотор
Стратегия
Стратегия команды – инвестировать настолько мало, насколько это возможно для того, чтобы внедрить наиболее ценную функциональность в реальных производственных условиях так бы
Фаза исследования
Фаза исследования предназначена для того, чтобы предоставить обеим сторонам возможность уяснить, что должна делать вся система. Фаза исследования включает в себя три хода.
Фаза подтверждения
В фазе подтверждения бизнес должен определить объем работ и дату выхода следующей версии, а разработчики должны со всей уверенностью подтвердить, что они в состоянии выполнить намеч
Фаза управления
Фаза управления предназначена для обновления плана на основе новых данных, которые появляются у разработчиков и у бизнеса. Фаза управления включает в себя четыре хода.
•
Итерационное планирование
Описанная в предыдущем разделе игра в планирование (Planning Game) предоставляет заказчику возможность управлять процессом разработки каждые три недели. В рамках одной итерац
Фаза подтверждения
• Принятие задачи – программист принимает на себя ответственность за выполнение задачи.
• Оценка задачи – ответственный программист оценивает количество идеал
Фаза управления
• Реализация задачи – программист берет карточку задачи, находит партнера, пишет тестовые случаи для задачи, добивается их срабатывания, затем интегрирует новый код в систему
Планирование за неделю
Как планировать проект, если у вас в запасе всего неделя? Подобная ситуация часто возникает в случае, если команда должна сделать предложение с фиксированной ценой. Вы получаете тен
Постоянная интеграция
Никакой код не остается не интегрированным в систему в течение более чем двух часов. В завершение каждого эпизода разработки полученный код интегрируется в текущую версию системы, и
Коллективное владение
Коллективное владение – это на первый взгляд бредовая идея, предполагающая, что кто угодно имеет право изменять любой кусок кода в каком угодно месте системы в любое удобное для это
Программирование парами
Программирование парами действительно заслуживает того, чтобы о нем написали отдельную книгу. Это изящное искусство, на совершенствование которого вы можете потратить всю оставшуюся
Самая простая вещь, которая, возможно, сработает
Давайте сделаем шаг назад и подойдем к решению проблемы постепенно. В формировании этой стратегии участвуют все четыре ценности.
• Коммуникация – сложный дизайн слож
Как работает проектирование при помощи переработки?
Если попробовать реализовать эту стратегию на практике, поначалу она покажется вам странной. Мы берем первый тестовый случай. Мы говорим: Если нам надо только лишь обеспечить сра
Что является самым простым?
Таким образом, лучшим является самый простой дизайн, который обеспечивает срабатывание всех тестовых случаев. Чтобы сделать это определение эффективным, необходимо объяснить, что им
Как это может работать?
Традиционная стратегия сокращения с течением времени затрат на разработку программного обеспечения заключается в том, чтобы снизить вероятность переработки и затраты, связанные с пе
Системная архитектура
Я не использовал это слово ранее. На самом деле архитектура также важна для проектов ХР, как и для любых других программных проектов. Частично архитектура выражается в системной мет
Кто пишет тесты?
Как я уже говорил в самом начале главы, тесты возникают из двух источников:
• программисты
• заказчики
Программисты пишут тесты для каждого из методов. Те
Другие тесты
Функциональные тесты и тесты модулей являются сердцем используемой в рамках ХР стратегии тестирования, однако помимо них существуют также и другие тесты, использование которых может
Тестирование
Когда вы приступите к приведению существующего кода в соответствие с требованиями ХР, тестирование станет для вас, наверное, наиболее разочаровывающим процессом. Код, написанный до
Проектирование
Переход к проектированию в стиле ХР во многом напоминает переход к тестированию в стиле ХР. Вы обнаружите, что по сравнению со старым кодом, новый код выглядит совершенно по‑д
Планирование
Вы должны преобразовать существующую информацию о требованиях в набор карточек с историями. Вы должны обучить вашего заказчика правилам игры. Заказчик должен решить, что необходимо
Менеджмент
Освоение менеджмента ХР – один из наиболее сложных переходов в процессе адаптации к ХР. Менеджмент ХР – это игра в направление и влияние. Если вы менеджер, скорее всего, вы поймаете
Разработка
Первым делом, которое вы обязаны сделать, является проверка расположения столов. Я не шучу. Прочтите заново материал о программировании парами (см. главу 16). Передвиньте ваши столы
Проблемы?
Некоторые из читателей данной книги уже обладают готовыми сформированными командами, однако разрабатываемые ими программные системы еще не поступили в эксплуатацию. Возможно, ваш пр
Исследование
Предварительная подготовка к работе – это неестественное состояние системы, и этот этап должен быть завершен как можно быстрее. Какую фразу я услышал совсем недавно? Если программа
Планирование
В ходе фазы планирования заказчики и программисты должны прийти к обоюдоодобренному соглашению по поводу даты, к которой будет реализован наименьший возможный полезный для бизнеса н
Итерации в первой версии
График работы над первой версией разбит на несколько итераций длительностью от одной до четырех недель. В ходе каждой итерации разрабатывается набор функциональных тестовых случаев
Внедрение в эксплуатацию
На завершающих стадиях работы над очередной версией следует сократить цикл обратной связи. Вместо трехнедельных итераций необходимо перейти на итерации продолжительностью в одну нед
Обслуживание и поддержка
Обслуживание и поддержка в действительности – это нормальное состояние любого ХР‑проекта. Вы должны одновременно работать над реализацией новой функциональности, поддерживать
Программист
Программист является сердцем ХР. На самом деле если бы программисты могли всегда принимать решения, в которых тщательно балансировались краткосрочные и долгосрочные приоритеты, в ра
Заказчик
Заказчик – это вторая половина базовой двойственности экстремального программирования. Программист знает, как программировать. Заказчик знает, что программировать. Конечно, не с сам
Ревизор
Как ревизор вы должны быть совестью команды.
Для того чтобы делать правильные предварительные оценки, вам потребуется обратная связь и практика. Вы обязаны делать множество
Инструктор
Как инструктор вы отвечаете за весь процесс разработки. Вы должны обращать внимание на то, что люди отклоняются от заранее обусловленного порядка работы, и вы должны обращать на это
Консультант
В рамках проекта ХР, как правило, не возникает каких‑либо специализаций. Каждый член команды работает в паре с любым из других членов, партнеры в парах часто меняются, пары ме
Большой босс
Если вы – большой начальник, значит, команда больше всего желает видеть в вас храбрость, уверенность и время от времени возникающее желание убедиться в том, что команда делает именн
Фиксированная цена
Практика показывает, что наибольшие проблемы с использованием ХР возникают в случае, если работа идет над контрактом с фиксированной ценой. Можно ли играть в игру в планирование, ес
Разработка чужими силами
Когда разработка осуществляется руками сторонних исполнителей (outsourcing), в результате у заказчика оказывается кусок кода, который неизвестно как поддерживать и модифициро
Разработка своими силами
Наверное, вам показалось, что я не в восторге от выполнения разработки чужими руками. Дело в том, что если разработка выполняется на стороне, это, как правило, означает, что существ
Время и материалы
В контрактах категории время и материалы (Time and Materials, T&M) команда ХР получает почасовую оплату. Все остальное работает так, как описывалось ранее.
Пробл
Премия за завершение
Отличный способ уладить разногласия между заказчиком и исполнителем в рамках контракта с фиксированной ценой или Т&М – это учреждение премии за завершение проекта
Раннее закрытие проекта
Одним из преимуществ ХР является то, что заказчик получает возможность видеть, что именно выходит из рук исполнителя по мере работы над проектом. Что, если на полдороге заказчик при
Программные инфраструктуры
Программная инфраструктура (framework) – это некоторый универсальный исходный код, который может использоваться в качестве основы при разработке разнообразных приложений опре
Продукты широкого использования
ХР можно использовать также для разработки программных продуктов для широкого потребительского рынка. В этом случае роль бизнеса в игре в планирование играет отдел маркетинга. Его с
Ожидание
Один юноша пришел к мастеру фехтования. Когда они сидели на солнышке рядом с хижиной мастера, мастер преподнес молодому человеку свой первый урок: Вот твой деревянный меч для тренир
Словарь терминов
Там, где это возможно, ХР использует общеупотребительные, общепринятые и широко распространенные термины. Если некоторые используемые в рамках ХР концепции в значительной степени от
Новости и инфо для студентов