— Извините, а чатлане и пацаки — это национальность?
— Нет.
— Биологический фактор?
— Нет.
— Лица с других планет?
— Нет.
— А в чем они друг от друга отличаются?
— Ты что, дальтоник, Скрипач — зеленый цвет от оранжевого отличить не можешь?
Турист…
К/ф "Кин-дза-дза"
Не будем откладывать в долгий ящик кроющуюся за многоточием в названии неопределенность. Речь пойдет об очередной "серебряной пуле", обещающей… в общем, много чего обещающей. Экстремальное программирование (eXtreme Programming, XP) — как будто новая методология программирования, как будто приобретающая все большую популярность. Эти "как будто" неспроста (сказано голосом Винни-Пуха — Уэфа — Леонова) — в отношении любой методологии непременно упоминаются в той или иной сравнительной степени "новизна" и "популярность". В XP подкупает простота (по крайней мере — простота изложения основных принципов на вербальном уровне), многозначительные обещания эффективности и подтвержденность растущими как грибы после дождя проектами из мира Open Source. Последнее немаловажно — действительно, XP, по большому счету, является "проекцией" принципов сугубо демократичного и крайне недетерминированного в формах движения Open Source на строго детерминированную поверхность (в идеале — абсолютно ровную и гладкую) коммерческой разработки. Впрочем, как раз это во многом очевидное соображение мы обсуждать не будем в силу его очевидности. Итак, введение у нас получилось кратким — пора переходить к сути.
Основы основ
Естественно, в любой методологии основа основ — терминология. Тем более в XP (как в некоторой научной базе процесса проектирования), где терминологии отведена исключительно важная роль. Здесь, к сожалению, мы вновь сталкиваемся с проблемой всех методологий, открытой и идеально сформулированной А. Зиновьевым: "Трудно назвать хотя бы один методологический термин, который благодаря усилиям специалистов не превратился бы в бессмысленный путем приобретения неконтролируемой многосмысленности. Попробуйте узнать, что такое причина (уж кажется привычнее и банальнее термина нет), и вы получите десятки несовместимых ответов" ("Зияющие высоты").
User Story, иначе говоря, нечто, рассказанное пользователем о каком-то аспекте функционирования системы. Повествование должно быть кратким и завершенным — таким, чтобы оно могло поместиться на небольшой карточке. Собственно, эти самые карточки и являются важнейшим элементом методологии — настолько важным, что авторы "Практического руководства по экстремальному программированию" Д. Астелс, Г. Миллер и М. Новак рекомендуют переходить от User Stories к понятию более высокого уровня путем объединения User Stories, описывающих фрагмент системы, подчиненный достижению одной общей цели, исключительно с помощью… перевязывания карточек резинкой. Никаких скрепок, липких листочков и прочего оппортунизма, видимо, допускать нельзя. Для перевязанных резинкой User Stories придуман весьма оригинальный и подходящий по многозначительности термин — стек. Как уже говорилось, он определяет ряд функциональных аспектов, объединенных одной общей целью. Более высокий уровень модели отражает многокритериальный и многоцелевой характер сложных систем — это набор стеков User Stories, именуемый deck (в данном случае автор предпочел даже не пытаться выбрать из обилия значений данного слова предпочтительное для перевода).
Пока вроде бы все было подозрительно просто, за исключением одного важного "но". Иерархия "карточка User Story — стек из перевязанных резинкой карточек — deck как набор стеков" в определении самого нижнего уровня содержало одно крайне подозрительное слово. А именно, "пользователь". Даже в начале обсуждения вопросов терминологии уже понятно, что приведенные выше термины относятся к самому ответственному проектному этапу — выработке требований к системе. Поэтому "пользователь" здесь — понятие, ведущее в тупик (хотя бы потому, что пользователь еще несуществующего невозможен). Конечно, автор мог сразу найти более подходящий эквивалент, но из песни слов не выкинешь, и дотошный читатель непременно столкнется с подобной несуразицей в литературе по XP. Так что "пользователь" в данном случае — это "эксперт со стороны заказчика". Причем эксперт вовсе не в программировании, а в предметной области, для которой разрабатывается программная система. По крайней мере, такое определение полностью подтверждается всеми доступными источниками и… дает нам право первый раз сказать "Ага!". Просто "ковыряясь" в самых базовых понятиях XP, у нас неожиданно возникло подозрение — возможно, эта методология далеко не универсальна. Она ориентирована больше на заказное программирование, то есть на разработку для конкретного конечного заказчика. Скорее всего инновационные TBD-проекты (для которых заказчик "To Be Determined" — "будет определен") для XP — твердый орешек. И сразу найдем маленькое подтверждение этому подозрению — в упомянутой выше книге есть скромная сноска: "Что делать, если в проекте нет заказчика" (здесь и далее орфография и синтаксис перевода сохранены). Она написана с использованием столь мощных логических построений (фактически дословно эта цепочка выглядит так: заказчик — важнейший элемент XP, тем не менее некоторые TBD-проекты можно выполнять на основе XP, хотя проблема заказчика может быть легко решена), что только усиливает подозрение.
К богатому перечню трудных терминов XP также относятся понятия коммуникации (оно определяет взаимодействия людей в коллективе), сложности (о, это действительно сложное понятие), качества и спектра качества (как бы там ни было, для них лучшего определения, чем "степень соответствия требованиям", пока еще никто не придумал), ролей, версий (релизов) и т. д. — в общем, все атрибуты зрелой методологии, которые благодаря усилиям специалистов… (далее согласно последней цитате А. Зиновьева). Для краткой журнальной статьи достаточно этого более-менее детального описания терминологического аппарата самого главного уровня, где ошибки не просто непростительны, а зачастую даже грозят мучительным летальным исходом для разработчика. Но так может случиться при классической организации проектного процесса — и именно здесь, на данном уровне, в XP действительно заключается некоторое рациональное зерно, отличающее эту методологию от множества других, как зеленый цвет от оранжевого.
Суть (опять термины)
Методология XP определяет некий стиль (или, если кому больше нравится, — дисциплину) проектного процесса (ПП). Согласно XP-стилю ПП представляется множеством итераций цепочки "планирование—дизайн—кодирование—тестирование" или различных вариаций цепочки, в которые непременно входит "планирование". Если учесть, что именно на этапе "планирования" согласно XP-стилю осуществляется построение концептуальной модели разрабатываемой системы и что одним из главных требований XP является непосредственное участие заказчика во всем ПП, то, по идее, влияние ошибок на этой "смертельно опасной" стадии устраняется. Несмотря на то что реалии жизни слишком далеки от идей, итеративное изменение проектируемой системы "от и до" — действительно нечто новое. По классике проектирования то, что определено на начальных этапах, "замораживается" из-за очевидной дороговизны как проектных действий на этих стадиях, так и последующих неизбежных "глубоких" (или "откатных") модификаций. Но раз есть дороговизна неких процессов, то никакая методология дешевыми их не сделает — реально они существуют вне методологии. Значит, ПП на основе XP-методологии может быть весьма дорогим. Что, по сути, налагает ограничение на масштабы — повышение стоимости проектного процесса с 10 до 20 тыс. условных единиц, мягко говоря, не эквивалентно такому же двукратному удорожанию ПП с начальной стоимостью 100 млн. тех же единиц. Вот и еще одно подозрение относительно XP.
Слава Богу, что здравомыслящие сторонники XP все это хорошо понимают — теперь
мы с уверенностью подтверждаем логично обоснованные предположения об ограничениях
XP, полученные далеким от тщательности анализом только трех (!) базовых терминов
и сути принципа проектирования, мнением специалистов, к которому можно и нужно
прислушаться: "XP создавалась как решение проблем [разработки ПО для] прикладных
областей, характеризующихся частой сменой требований [особенно во время ПП]…
XP ориентирована на небольшие коллективы разработчиков — от 2 до 12 человек,
хотя в отдельных случаях достигнуты успехи и командами из 30 разработчиков…"
(www.extremeprogramming.org/when.html,
уточнения в квадратных скобках принадлежат автору статьи). Как видите, все совпадает
даже без детального анализа.
И тут бы возрадоваться и заставить читателя двигаться дальше, но и здесь не обошлось без маленького неприятного нюанса. А что это, собственно, за прикладные области, в которых ну никак нельзя зафиксировать требования хотя бы на время, необходимое для их выявления и формализации? Ничего конкретного, к сожалению, о таких областях неизвестно, зато из цитируемого последним источника можно почерпнуть нечто весьма забавное, предположительно дающее ответ на "нехороший" вопрос: "Ваш заказчик может не иметь устоявшегося представления о том, что должна делать проектируемая система". Неужели наступило время для очередного "Ага!"? Давайте для начала просто попытаемся восстановить из следствия "заказчик не знает, что заказать" причину. Здравый смысл подсказывает только один возможный вариант — заказчику в действительности не нужно то, что он заказывает. В любом ином случае заказчик непременно будет знать, что именно ему нужно. Пусть даже с некоторой степенью неопределенности в деталях (особенно в деталях реализации), но конечное назначение заказываемого "нечто" станет известным, и тогда его можно зафиксировать, что фактически равноценно фиксации архитектуры системы (которая строится профессиональным архитектором с должной степенью гибкости, обеспечивающей модификации по ходу устранения неопределенности в деталях). Давайте не упустим из вида и поразительное противоречие, возникающее теперь между уточненным понятием заказчика и того самого "пользователя" (а он и есть заказчик в терминах XP), который должен быть экспертом в своей прикладной области, но, учитывая уточнения, — неспособным определить свои потребности в своей же области. Возглас "Ага!" уже напрашивается, однако спешить нам некуда…
Как и всякая методология, XP очень много внимания уделяет организационным вопросам. И некоторые, предлагаемые XP-методологами подходы, действительно революционны. Так, например, системный архитектор фактически поставлен в иерархии на один уровень с кодировщиками, более того, в перечне его обязанностей наряду с характерной для этой специальности рутиной (разные проектные мелочи, как то — принятие стратегических решений по организации структуры проекта в целом, декомпозиции и пр.) значится и вещь совсем уж нестандартная — выявление "некрасивого" кода. В идеале архитектор должен найти "гадкий код" до того, как это сделают другие участники ПП. И все это он обязан выполнять итеративно.
Над архитектором и прочей командой "парит" гуру-инструктор (coach). Все решения об изменениях в ходе ПП принимаются им, он же в команде играет роль идеологического центра: "на своем примере показывает другим правильный путь" ("Практическое руководство по экстремальному программированию", Д. Астелс и др.). Кодировщики также не обойдены вниманием — XP предполагает так называемый парный непараллельный стиль разработки, когда над одним фрагментом программы трудятся одновременно два программиста, но за общим монитором, по принципу "первый делает, второй смотрит, затем они меняются местами". То, что парный стиль приводит к улучшению кода, особенно в случае "сработанных" пар, мы даже не будем подвергать сомнению — это очевидно. Но вспомним о ценовом факторе собственно ПП (он ведь тоже стоит денег, и немалых), доверимся статистике и примем за доказанные факты то, что "парные программисты" пишут на 15% быстрее и делают на 15% меньше ошибок. Правда, естественно, их стоимость в ПП в два раза выше, чем одного программиста. Если речь идет о высококлассных кодировщиках, годовая оплата труда которых составляет в развитых странах порядка 50 тыс. долл. и более, окупит ли их "спаривание" удвоение стоимости кодирования — вопрос серьезный, и ответа на него в общем случае дать нельзя. Что касается кодировщиков среднего класса, работающих в компаниях третьего мира на локального заказчика, — ситуация аналогична. Выгодность подобного стиля для контрактных разработчиков из таких стран, работающих на состоятельного зарубежного заказчика, — также отдельная тема для разговора. Ни в одном случае, к сожалению, готовых ответов нет. Зато теперь понятно, что и "спаривание" кодировщиков, и необычные требования к обязанностям системного архитектора, и наличие в команде многоопытного гуру — все это, с одной стороны, красиво выглядит на бумаге, а с другой — может являться источником серьезных проблем и ограничений. Если добавить к получившемуся коктейлю и очевидно заимствованный из практики Open Source принцип не просто доступности исходных текстов всего проекта всем разработчикам, а, более того, благоприятствования модификациям чужого кода (как бы это ни называлось в литературе, смысл не меняется) с целью его улучшения. Эти модификации, по-умному называемые рефакторингом, могут (и, по идее, даже должны) скорее изменять "некрасивые приемы" (дизайн программы) на "красивые", чем преследовать цели оптимизации производительности. Теперь понятна важность роли архитектора — если он упустит из виду нечто "некрасивое" в программе, или, что хуже, если его представления о "красоте" не совпадают с представлениями кодировщиков, последние (опять, по идее) могут стать участниками броуновского движения "за тотальный рефакторинг!". И даже мощная система тестирования, требуемая в рамках XP-методологии, в этом случае не гарантирует помощи — тесты, как известно, только доказывают или свою работоспособность, или работоспособность тестируемых задач на тестовых данных.
Пожалуй, наиболее интересным аспектом XP является ужесточение требований к… заказчику. Его непосредственное участие необходимо во всем цикле ПП, то есть во всех итерациях. Всегда и постоянно. Это требование насколько, без сомнения, замечательно, настолько же очевидна проблематичность подчинения ему заказчика в реальной жизни. Тем более заказчика, который сам не знает, чего хочет.
Ага!
Наступила пора уточнить ограничения, свойственные XP, и происходящие от выявленных совершенно поверхностных несуразностей. Давайте называть вещи своими именами: заказчик, который не знает, чего хочет, — это с 99%-ной вероятностью стремящийся вывести в Сеть свою компанию (обычно не относящуюся к IT) бизнесмен. Оно как бы ему и не надо сегодня (элементарная логика — раз у предпринимателя есть свободные средства на попытку "интернетизации" бизнеса, значит, бизнес достаточно успешен и без этой "интернетизации"), но как бы прогресс требует жертв. А прогрессивность всегда в моде — ну согласитесь, что это за производитель пусть даже очень вкусных пончиков, у которого СЕГОДНЯ нет сайта www.best_ponchiks.ua (или, что лучше — www.best_ponchiks.com)? Оно, конечно, неважно, что на качество пончиков наличие сайта никак не повлияет, да и Internet-торговля горячими пончиками — нечто вообще трудно представимое… Это предположение неплохо подтверждается временем появления и становления популярности XP, которое фактически совпадает с возникновением массовой заинтересованности бизнесом в Web. Больше того, вспоминая особенности ролевой специфики разработчиков, невольно задумываешься над тем, какого масштаба и какой специфики должен быть проект, чтобы, например, один архитектор мог успевать в обозримые сроки и решать свои вопросы, и "просматривать" постоянно меняющийся код. Возможно, есть в природе гении, способные "на глаз" выявить в сотне модулей, в каждом из которых десятки классов или процедур, "некрасивости", возможно… Возможно, существуют безмерно талантливые программисты, способные охватывать детализированную картину кода всего проекта в целом (подумаешь, каких-то пара миллионов строк) и "по ходу дела", развлекаясь, улучшать то там, то тут. И при этом все они в общем случае должны быть прикладными математиками, знающими "на отлично" все разделы как минимум всех университетских курсов математики и физики (а вдруг, не приведи Бог, придется XP-методологически разрабатывать управляющее ПО или какую-нибудь систему автоматизации проектирования). Но на ставке на гениев коммерция не делается. Значит, в общем случае все это совершенно нереально. В случае же с бизнес-ориентированным Web-программированием картина получается весьма привлекательной — ограниченный набор инструментальных и технологических средств и приемов, небольшие (сравнительно небольшие) объемы кода, отсутствие потребности в сложной математике.
Вот мы и пришли к последнему "Ага!". XP — весьма привлекательная… (ну не поворачивается язык назвать это методологией) организационная идея, позволяющая неплохо работать небольшим компаниям, специализирующимся на заказном Web-программировании. Что здесь значит "неплохо", насколько оно "неплохо"… ну уж, извините, время покажет.