Кент Бек: «На мой взгляд, отличительной особенностью XP является его всеобъемлющий подход»Кент Бек, которого считают основоположником «экстремального программирования» (eXtremal Programming, XP) и соавтором манифеста Agile Manifesto, — известный сторонник методик так называемого «скорого» (agile) программирования и использования его для сокращения сроков разработки программного обеспечения. Глава компании Three Rivers Institute, предлагающей консалтинговые услуги разработчикам программных систем, Бек ответил на вопросы редактора еженедельника InfoWorld Пола Крила.

Не могли бы вы изложить основные идеи Agile Manifesto и экстремального программирования?

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

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

Да, скорое программирование освоили немногие разработчики, но их число растет, причем неплохими темпами. Не могу привести данных независимых исследований в подтверждение своей точки зрения, но вы можете убедиться в моей правоте — достаточно посмотреть, насколько выросло число конференций и тому подобных мероприятий. Думаю, движущим мотивом к внедрению быстрой разработки стало то, что подход, при котором «отчетные» периоды короче, позволяет сделать разработку честнее и прозрачнее. Более того — в программировании такого уровня прозрачности не было очень-очень давно.

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

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

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

Позволит ли скорая разработка уменьшить число неудачных проектов? Думаю, многие программные проекты обречены на неудачу, но мы не знаем, какие именно, пока не зайдем достаточно далеко. Так может ли в данном случае помочь скорая разработка? Нет. Я думаю, что проекты по-прежнему будут заканчиваться неудачей, поскольку по-прежнему будут рождаться «грандиозные» идеи, которые на практике не работают. Скорая разработка может лишь гарантировать, что такой проект придет к своему краху быстрее и потребует меньших затрат, поэтому вы скорее сможете заняться чем-то другим.

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

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

Как подход XP соотносится с другими методиками скорой разработки, такими как Scrum?

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

Мне приходилось слышать выражение «ковбойское кодирование». В чем разница между ковбойским кодированием и скорой разработкой?

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

Вы говорите об скорой разработке вообще?

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

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

Да. Именно так я и работаю, поскольку живу в южной части Орегона (штат на северо-западе США. — Прим. ред.). Поэтому мне все время приходится заниматься географически распределенной разработкой. Часовые пояса создают определенные сложности. Самое сложное — поддерживать личные отношения, когда не видишь людей. Это действительно очень трудно. Но, если складываются хорошие отношения, тогда можно работать над техническими деталями: кто и когда делает рефакторинг, кто и какой код проверяет и так далее.

Что вы думаете о противостоянии Java и .Net? Оно как-то отражается на скорой разработке и на XP вообще или это не важно?

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

И как это можно отнести к противостоянию Java и .Net? Или это не имеет значения?

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

Вы можете использовать методологии скорой разработки с Java и .Net или предпочитаете какой-то другой язык?

Безусловно, это можно делать с Java и .Net.

А что вы скажете по поводу языков скриптов, таких как AJAX, Ruby и PHP? Они соответствуют парадигме скорого программирования?

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

С Ruby?

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

Насколько хорошо подходит скорая разработка для создания Web-приложений?

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

Говорят, Agile Manifesto подписало 17 человек...

Именно так. Мое имя стояло первым в списке по алфавиту, но из-за этого теперь говорят, что его подготовили Бек и другие.

Почему вы его подписали?

Мы пытались выработать общую позицию. Кое в чем мы были согласны друг с другом, но во взглядах тех, кто подписал Agile Manifesto, были очень серьезные различия. И сейчас, с моей точки зрения, термин «скорое» (agile) просто размывается. Чем чаще стали этот термин употреблять, тем больше первоначальный смысл его забывается, к сожалению. Сейчас оно уже не значит так много, как раньше.

И что это значит?

Я слышал от представителей Microsoft утверждение о том, что корпорация хочет стать более «скорой». Что это означает на деле? Мне кажется, что быть оперативной — значит воспринимать посыл, который дает окружающий мир, и реагировать на него.

Поделитесь материалом с коллегами и друзьями