Кент бек экстремальное программирование. Экстремальное программирование. О серии ХР

13.04.2020

Жанр: ,

Серия:
Возрастные ограничения: +
Язык:
Язык оригинала:
Переводчик(и):
Издательство:
Город издания: Санкт-Петербург
Год издания:
ISBN: 978-5-496-02570-6 Размер: 382 Кб

Правообладателям!

Представленный фрагмент произведения размещен по согласованию с распространителем легального контента ООО "ЛитРес" (не более 20% исходного текста). Если вы считаете, что размещение материала нарушает чьи-либо права, то .

Читателям!

Оплатили, но не знаете что делать дальше ?

Внимание! Вы скачиваете отрывок, разрешенный законодательством и правообладателем (не более 20% текста).
После ознакомления вам будет предложено перейти на сайт правообладателя и приобрести полную версию произведения.

Описание книги

Возвращение знаменитого бестселлера. Изящный, гибкий и понятный код, который легко модифицировать, который корректно работает и который не подкидывает своим создателям неприятных сюрпризов. Неужели подобное возможно? Чтобы достичь цели, попробуйте тестировать программу еще до того, как она написана. Именно такая парадоксальная идея положена в основу методики TDD (Test-Driven-Development – разработка, основанная на тестировании). Бессмыслица? Не спешите делать скороспелые выводы. Рассматривая применение TDD на примере разработки реального программного кода, автор демонстрирует простоту и мощь этой методики. В книге приведены два программных проекта, целиком и полностью реализованных с использованием TDD. За рассмотрением примеров следует обширный каталог приемов работы в стиле TDD, а также паттернов и рефакторингов, имеющих отношение к TDD. Книга будет полезна для любого программиста, желающего повысить производительность своей работы и получить удовольствие от программирования.

Последнее впечатление о книге

SharerSharpened:
16-12-2018, 02:17

До прочтения этой книги я пытался писать тесты по статьям которые читал, но только с ней у меня начало получаться хорошо.

Читал два раза. Первый раз просто читал.

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

Свернуть

⬇ Остальные комментарии

Экстремальное программирование

Посвящается моему отцу, а также благодарю Синди (Cindee Andres), мою жену и партнера, за то, что она требовала, чтобы я не обращал на нее внимания и писал. Спасибо Бетани (Bethany), Линкольну(Lincoln), Форресту (Forrest) и за то, что они не отвлекали меня и предоставили мне писать.

О серии ХР

Экстремальное программирование (Extreme Programming), часто обозначаемое аббревиатурой ХР, – это дисциплина разработки программного обеспечения и ведения бизнеса в области создания программных продуктов, которая фокусирует усилия обеих сторон (программистов и бизнесменов) на общих, вполне достижимых целях. Команды, использующие ХР, производят качественное программное обеспечение с весьма большой скоростью. Методики, которые входят в состав дисциплины ХР, описанной в данной книге, выбраны из-за того, что они основаны на человеческом творчестве и принятии того, что человек является существом неустойчивым и подверженным ошибкам.

ХР часто представляется как набор методик, однако сама по себе ХР не является финишной линией. Вам не надо все лучше и лучше практиковать и развивать ХР для того, чтобы в конце этого процесса получить долгожданную золотую звезду. Напротив, ХР – это линия старта. ХР ставит вопрос: «Насколько минимальными могут быть наши усилия для того, чтобы мы могли продолжать производить качественное программное обеспечение?»

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

Я сказал «начало ответа на» так как продолжения на самом деле не существует. Люди, создававшие и внедрявшие ХР, тоже думали над решением этого вопроса. Попробовав использовать ХР, они перешагнули порог и побывали в неизведанном. Вернувшись, они рассказали свою историю. Изложенные ими мысли – это указатели, расставленные вдоль дороги: «Здесь живут драконы», «Через 15 км открывается хороший вид», «Этот участок опасен во время дождя».

Прошу прощения, но мне пора идти программировать.

Кент Бек, консультант серии

Предисловие

Экстремальное программирование (eXtreme Programming , XP) определяет кодирование как ключевую и основополагающую деятельность при работе над программным проектом. Возможно, что это неправильно!

Думаю, что стоит вспомнить о моем собственном опыте разработки программного обеспечения. Я работаю в среде, где разрабатываемый продукт постоянно находится в работоспособном состоянии, и при этом в него постоянно вносятся изменения. Сроки выпуска очередной работоспособной версии чудовищно сжаты, и при этом над всем этим нависает огромный технический риск. В подобной среде способность поправить своего соратника – это искусство, без которого не выжить. Обмен информацией как внутри некоторой команды, так и между несколькими командами, которые часто разделены географически, выполняется при помощи кода. Мы читаем код для того, чтобы понять устройство новых или модифицированных программных интерфейсов системы. Жизненный цикл и поведение сложных объектов определяются с использованием тестовых случаев, то есть снова при помощи кода. Сообщения о возникающих проблемах сопровождаются тестовыми случаями, демонстрирующими проблему, для этого опять используется код. Наконец, мы постоянно заняты улучшением существующего кода, делая его более производительным, более гибким, более понятным. Очевидно, что в подобных условиях разработка программного продукта почти целиком основана на кодировании, однако при этом нам удается с успехом завершать проекты к сроку, таким образом, данный подход вполне жизнеспособен.

Не следует делать вывод, что все, что вам потребуется для успешной реализации программного проекта, – это безоглядное ожесточенное программирование. Разрабатывать программное обеспечение очень непросто, а разрабатывать качественное программное обеспечение и при этом завершать работу в срок – еще сложнее. Чтобы описанный мною подход сработал, необходимо последовательное применение важных дополнительных правил и методик. Именно с этого Кент Бек (Kent Beck) начинает свою побуждающую к размышлениям книгу об ХР.

Кент был среди тех руководителей компании Tektronix, которые осознали огромный потенциал, заложенный в методике программирования в связанных парах при разработке сложных инженерных приложений в среде Smalltalk. Вместе с Бардом Каннингхемом (Ward Cunningham) Кент стал вдохновителем развития методики программирования по образцам (ее еще называют программированием с использованием паттернов – patterns programming , которая в значительной степени повлияла на мою собственную карьеру. В рамках ХР описывается подход к разработке программного обеспечения, который сочетает в себе методики, используемые многочисленными успешно работающими разработчиками, которые изучили множество литературы, посвященной организации труда программистов, и опробовали на практике множество методов и процедур разработки программного продукта. Как и программирование по образцам, ХР формирует набор наиболее эффективных методик, таких как тестирование программных модулей, программирование парами и переработка кода. В рамках ХР эти методики скомбинированы таким образом, чтобы дополнять и часто контролировать друг друга. Основная цель данной книги – рассказать о взаимодействии и совместном использовании различных методик. У всех методик программирования одна цель – создание программного продукта с заданной функциональностью к заданному сроку. Предлагаемый OTI весьма успешный процесс Just In Time Software не является ХР в чистом виде, однако между этими двумя подходами очень много общего.

Я сотрудничал с Кентом и использовал описанные в рамках ХР эпизоды при работе над небольшим, но небезызвестным проектом под названием JUnit . Его взгляды и подходы к разработке программ всегда за ставляли меня задумываться над тем, как лично я привык работать над программным проектом. Без сомнения, ХР ставит под вопрос многие традиционные подходы, используемые в индустрии программирования. Прочитав данную книгу, вы сможете самостоятельно решить, надо ли вам применять ХР в своей работе или нет.

Эрих Гамма (Erich Gamma)

Введение

Эта книга об экстремальном программировании (eXtreme Programming , XP). Экстремальное программирование – это упрощенная методика организации производства для небольших и средних по размеру команд специалистов, занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся требований. Данная книга предназначена для того, чтобы помочь определить, оправдано ли применение ХР в вашей ситуации.

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

Если пересмотр кода – это хорошо, значит, мы будем пересматривать код постоянно (программирование парами);

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

Eсли проектирование – это хорошо, значит, проектирование надо сделать составной частью повседневной работы каждого из участников проекта (переработка кода);

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

Eсли интеграционное тестирование важно, значит, необходимо собирать и тестировать разрабатываемую систему несколько раз на дню (продолжающаяся интеграция);

Eсли небольшие итерации – это хорошо, необходимо сделать итерации очень, очень маленькими – секунды, минуты, может быть часы, но не недели и месяцы, и ни в коем случае не годы (игра в планирование).

Когда я впервые решил сформулировать для себя суть ХР, я представил себе набор рукояток на пульте управления. Каждая рукоятка соответствовала некоторой методике, о которой из своего личного опыта я знал, что она вполне эффективна. Каждая рукоятка позволяла использовать ту или иную методику в определенной степени: от 1 до 10. Я попробовал установить все рукоятки в максимально возможное положение (10) и с удивлением обнаружил, что полный набор рассматриваемых мной методик остается стабильным, предсказуемым и гибким.

ХР формирует два набора обещаний:

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

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

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

Данная книга

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

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

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

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

Что такое ХР?

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

Благодаря использованию чрезвычайно коротких циклов разработки ХР предлагает быструю, реальную и постоянно функционирующую обратную связь.

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

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

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

ХР основана на оральном обмене информацией, тестах и исходном коде. Три этих инструмента используются для обмена сведениями о структуре системы и ее поведении.

ХР базируется на процессе эволюционирующего дизайна, который продолжается столь же долго, сколько существует сама система.

ХР базируется на тесном взаимодействии программистов, обладающих самыми обычными навыками и возможностями.

ХР основывается на методиках, которые удовлетворяют как краткосрочным инстинктам отдельных программистов, так и долгосрочным интересам всего проекта в целом.

ХР – это дисциплина разработки программного обеспечения. Это дисциплина потому, что в рамках ХР существуют определенные вещи, которые вы обязаны делать, если вы намерены использовать ХР. Вы не должны выбирать, надо или не надо писать тесты, потому что если вы этого не делаете, программирование, которым вы занимаетесь, нельзя назвать экстремальным: конец дискуссии.

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

ХР пугает или раздражает некоторых людей, которые сталкиваются с этой методикой впервые. Вместе с тем ни одна идея, лежащая в основе ХР, не является новой. В некотором смысле методика ХР консервативна – все используемые в ее рамках приемы проверены десятилетиями (что касается стратегии реализации) и даже столетиями (что касается стратегии менеджмента) практики.

Нововведениями в ХР являются следующие особенности:

Все эти давно известные приемы собраны под одной крышей;

Интенсивность, с которой эти приемы внедряются в повседневную работу, доведена до крайности;

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

Достаточность

В своих работах The Forest People(Лесные народы) и The Mountain (People Горные народы) антрополог Колин Тернбулл (Colin Turnbull) описывает два совершенно отличающихся друг от друга общества. В горах необходимых для жизни ресурсов не хватает, и люди всегда находятся на грани голода. Культура, которая возникла в подобных условиях, выглядит ужасающе. Матери бросают своих детей ради того, чтобы выжить самим. Пропитание может стать причиной смертоубийства. Жестокость, зверство и предательство являются обыденными и повседневными.

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

ХР – это попытка ответить на вопрос: Как лично вы программировали бы, если бы у вас было достаточно времени? Вообще-то у вас нет лишнего времени, так как в конце концов программирование – это бизнес. В любом бизнесе побеждает тот, кто делает работу быстрее. Однако если бы у вас было время, вы наверняка уделяли бы внимание разработке тестов; вы наверняка заново переделали бы архитектуру системы в случае, если пришли бы к выводу, что это необходимо; вы наверняка больше бы общались со своими соратниками-программистами, а также с заказчиком.

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

План книги

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

Книга разделена на три части.

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

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

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

Благодарности

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

Вард Каннингхэм (Ward Cunningham) – это мой основной источник, из которого я черпал излагаемый в книге материал. Так или иначе я потратил последние пятнадцать лет, просто пытаясь объяснить другим людям то, чем Вард уже давно занимается практически. Спасибо также Рону Джеффрису (Ron Jeffries) за то, что он тоже это попробовал, а затем существенно улучшил. Спасибо Мартину Фолеру (Martin Fowler) за то, что он объясняет все это простым мягким языком и без нервных срывов. Спасибо Эриху Гамма (Erich Gamma) за длительные беседы, совмещенные с созерцанием лебедей в Лимме, а также за то, что он не позволил мне покинуть его с плохими мыслями в голове. И конечно же, ничего этого не произошло бы в моей жизни, если бы у меня не было такого примера для подражания, как мой отец, Дуг Бек (Doug Beck), который оттачивал свое мастерство программирования в течение многих лет.

Спасибо команде С3 в компании Chrysler за то, что они сопровождали меня в моих изысканиях. А также особое спасибо нашим менеджерам Сью Ангер (Sue Unger) и Рону Сэведжу (Ron Savage) за то, что у них хватило храбрости дать нам попробовать.

Спасибо компании Daedalos Consulting за помощь в написании данной книги.

Чемпионская награда за просмотр материала переходит в руки Пола Чишолма (Paul Chisholm) за его обильные, емкие, скрупулезные, а зачастую откровенно раздражающие комментарии. Без его помощи данная книга не стала бы и наполовину столь же популярной.

Я действительно получал огромное удовольствие от общения со всеми теми, кто осуществлял предварительный просмотр того, что я написал.

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

Спасибо (перечисление в случайном порядке, в котором я получал от них комментарии) Грегу Хатчинсону (Greg Hutchinson), Массимо Арнольди (Massimo Arnoldi), Дэйву Клилу (Dave Cleal), Сэмесу Шустеру (Sames Schuster), Дону Уелсу (Don Wells), Джошу Киревски (Joshua Kerievsky), Торстену Диттмару (Thorsten Dittmar), Морицу Бекеру (Moritz Becker), Дэниэлу Габлеру (Daniel Gubler), Кристофу Хенирики (Christoph Henrici), Томасу Зангу (Thomas Zang), Дирку Коэнигу (Dierk Koenig), Мирославу Новаку (Miroslav Novak), Роднёю Райану (Rodney Rayan), Френку Вестфалу (Frank Westphal), Полу Трунцу (Paul Trunz), Стиву Хайесу (Steve Hayes), Кевину Бредтке (Kevin Bradtke), Джанни Де Гузман (Jeanine De Guzman), Тому Кабиту (Tom Kubit), Фалку Бругманну (Falk Bruegmann), Хаско Хейнеке (Hasko Heinecke), Петеру Мерелу (Peter Merel), Робу Ми (Rob Мее), Пете Макбрину (Pete McBreen), Томасу Эрнсту (Thomas Ernst), Гуидо Хечлеру (Guido Haechler), Дитеру Холцу (Dieter Holz), Мартину Кнехту (Martin Knecht), Дирку Крампе (Dierk Krampe), Патрику Лиссеру (Patrick Lisser), Элизабет Майер (Elisabeth Maier), Томасу Мансини (Thomas Mancini), Алексио Морено (Alexio Moreno), Рольфу Пфеннингеру (Rolf Pfenninger) и Мэтиасу Ресселу (Matthias Ressel).

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу электронной почты [email protected] (издательство Питер, компьютерная редакция).

Мы будем рады узнать ваше мнение!

Все исходные тексты, приведенные в книге, вы можете найти по адресу http://www.piter.com/download .

На web-сайте издательства http://www.piter.com вы найдете подробную информацию о наших книгах.

Проблема

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

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

Риск: основная проблема

Существующие дисциплины разработки программного обеспечения не срабатывают и не дают желаемого экономического эффекта. Эта проблема обладает огромным экономическим и гуманитарным значением. Мы нуждаемся в новом способе разработки программного обеспечения.

Основная проблема разработки программного обеспечения – это риск .

Вот несколько примеров риска.

Смещение графиков – наступает день сдачи работы, и вы вынуждены сообщить заказчику, что разрабатываемая система не будет готова еще в течение шести месяцев.

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

Система теряет полезность – разработанное программное обеспечение успешно устанавливается в реальной производственной рабочей среде, однако после пары лет использования стоимость внесения в нее изменений и/или количество дефектов увеличиваются настолько, что становится дешевле заменить систему новой разработкой.

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

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

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

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

Текучка кадров – в течение двух лет работы все хорошие программисты, работавшие над проектом, один за другим возненавидели разрабатываемую программную систему и ушли на другую работу.

На страницах данной книги вы прочитаете об экстремальном программировании (eXtreme Programming , XP) – дисциплине разработки программного обеспечения, которая ориентирована на снижение степени риска на всех уровнях процесса разработки. ХР способствует существенному увеличению производительности и улучшению качества разрабатываемых программ, кроме того, это весьма занятная практика, доставляющая всем ее участникам массу удовольствия.

Каким образом ХР снижает перечисленные ранее риски?

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

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

Система теряет полезность – в рамках ХР создается и поддерживается огромное количество тестов, которые запускаются и перезапускаются после внесения в систему любого изменения (несколько раз на дню), благодаря этому удается тщательно следить за качеством разрабатываемой программы. ХР постоянно поддерживает систему в превосходном состоянии. Дефектам просто не дают накапливаться.

Количество дефектов и недочетов – в рамках ХР разрабатываемая система тестируется как программистами, создающими тесты для каждой отдельной разрабатываемой функции, так и заказчиками, которые создают тесты для каждой отдельной реализованной возможности системы.

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

Экстремальное программирование: разработка через тестирование

Посвящается Синди: крыльям моей души

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

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

ISBN 978-0321146533 англ.

ISBN 978-5-496-02570-6

Предисловие

Чистый код, который работает (clean code that works), – в этой короткой, но содержательной фразе, придуманной Роном Джеффризом (Ron Jeffries), кроется весь смысл методики разработки через тестирование (Test-Driven Development, TDD). Чистый код, который работает, – это цель, к которой стоит стремиться потому, что

Это предсказуемый способ разработки программ. Вы знаете, когда работу можно считать законченной и не беспокоиться о длинной череде ошибок;

Дает шанс усвоить уроки, которые преподносит код. Если вы воспользуетесь первой же идеей, которая пришла в голову, у вас не будет шанса реализовать вторую, лучшую идею;

Улучшает жизнь пользователей ваших программ;

Позволяет вашим коллегам рассчитывать на вас, а вам – рассчитывать на них;

Писать такой код приятнее.

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

Новый код пишется только после того, как будет написан автоматический тест, завершающийся неудачей;

Любое дублирование устраняется.

Два простых правила, не правда ли? Однако они генерируют сложное индивидуальное и групповое поведение со множеством технических последствий:

В процессе проектирования мы постоянно запускаем код и получаем представление о его работе, это помогает принимать правильные решения;

Мы сами пишем тесты, так как не можем ждать, что кто-то другой напишет тесты для нас;

Наша среда разработки должна быстро реагировать на небольшие модификации кода;

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

Два упомянутых правила TDD определяют порядок этапов программирования.

1. Красный – напишите небольшой тест, который не работает, а возможно, даже не компилируется.

2. Зеленый – заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.

3. Рефакторинг – устраните из написанного кода любое дублирование.

Красный – зеленый – рефакторинг – это мантра TDD.

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

При достаточно низкой плотности дефектов команда контроля качества (Quality Assurance, QA) сможет перейти от реагирования на ошибки к их предупреждению;

С уменьшением количества неприятных сюрпризов менеджеры проекта смогут точнее оценить трудозатраты и вовлечь заказчиков в процесс разработки;

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

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

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

Храбрость

TDD – это способ управления страхом в процессе программирования. Я не имею в виду страх падения со стула или страх перед начальником. Я имею в виду страх перед задачей, «настолько сложной, что я пока понятия не имею, как ее решить». Боль – это когда природа говорит нам: «Стоп!», а страх – это когда природа говорит нам: «Будь осторожен!» Осторожность – это совсем не плохо, однако помимо пользы страх оказывает на нас некоторое негативное влияние:

Страх заставляет нас заблаговременно и тщательно обдумывать, к чему может привести то или иное действие;

Страх заставляет нас меньше общаться;

Страх заставляет нас пугаться отзывов о нашей работе;

Страх делает нас раздражительными.

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

Не пытаться предсказать будущее, а немедленно приступить к практическому изучению проблемы;

Не отгораживаться от остального мира, а повысить уровень коммуникации;

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

(с раздражением вы должны справиться самостоятельно).

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

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

Читатели книги Extreme Programming Explaine , должно быть, обратили внимание на разницу в тоне между экстремальным программированием (Extreme Programming, XP) и разработкой через тестирование (Test-Driven Development, TDD). В отличие от XP методика TDD не является абсолютной. XP говорит: «чтобы двигаться дальше, вы обязаны освоить это и это». TDD – менее конкретная методика. TDD предполагает наличие интервала между принятием решения и получением результатов, и предлагает инструменты управления продолжительностью этого интервала. «Что, если в течение недели я буду проектировать алгоритм на бумаге, а затем напишу код, использовав подход “сначала тесты”? Будет ли это соответствовать TDD?» Конечно, будет. Вы знаете величину интервала между принятием решения и оценкой результатов и осознанно контролируете этот интервал.

Большинство людей, освоивших TDD, утверждают, что их практика программирования изменилась к лучшему. Инфицированные тестами (test infected) – такое определение придумал Эрих Гамма (Erich Gamma), чтобы описать данное изменение. Освоив TDD, вы обнаруживаете, что пишете значительно больше тестов, чем раньше, и двигаетесь вперед малюсенькими шагами, которые раньше показались бы вам бессмысленными. С другой стороны, некоторые программисты, познакомившись с TDD, решают вернуться к использованию прежних практик, зарезервировав TDD для особых случаев, когда обычное программирование не приводит к желаемому прогрессу.

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

09.09.2007

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

Книга одного из основателей методологии и главного ее пропагандиста Кента Бека "Extreme Programming: Embrace Change" (в русском переводе из названия чудесным образом исчезла вторая половина названия, ну да это мелочи) представляет собой довольно полное изложение основных принципов этой методологии, написанное весело, бодро и сердито. Книга предназначена тем, кто собрался познакомиться с ХР и хочет решить, насколько эта методология ему подходит. Прекрасный язык изложения, иллюстративная, по-бековски напористая подача материала.

Закономерное, что эта книга стала первым (за исключением пары-тройки статей) русскоязычным источником по одной из самых популярных гибких методологий. Выбор издательства радует, не радует лишь неизбежный для "первого блина" ком. В данном случае, это перевод. Уж сколько раз твердили миру, что любой текст (за исключением телефонных справочников) нуждается в литературной правке. Как обидно видеть слабую переводческую работу, которую второпях даже не вычитали: нелепые терминологические ошибки, местами - подстрочник вместо нормального русского языка, исковерканные имена и фамилии (рекорд - 2 ошибки на 4-буквенное слово!). В оригинале книга читается легко, русский вариант намного тяжелее, "топорнее". То и дело спотыкаешься об ошибки, опечатки и явное недопонимание оригинала.

Так вот и борешься с противоположными чувствами: то ли радоваться - "Ура! Бек заговорил по-русски", то ли искать тухлый помидор, чтобы запустить в редактора-переводчика. Будем же оптимистами. По слухам, "Питер" собирается продолжать "методологическую" серию. Пожелаем же им не торопиться с выпуском очередного бестселлера, напичканного смысловыми и языковыми ошибками. Не надо спешить. Методологии живут дольше, чем версии "Photoshop 7.0" или "Microsoft Office 2000". Можно вполне успеть перевести книгу, выверить, отредактировать и уже тогда выпускать ее на радость и пользу всем, интересующимся повышением эффективности процесса разработки ПО.

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

О серии ХР

Прошу прощения, но мне пора идти программировать.

Предисловие

Экстремальное программирование (

eXtreme Programming

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

Я сотрудничал с Кентом и использовал описанные в рамках ХР эпизоды при работе над небольшим, но небезызвестным проектом под названием JUnit

Введение

Эта книга об экстремальном программировании (

eXtreme Programming

XP). Экстремальное программирование – это упрощенная методика организации производства для небольших и средних по размеру команд специалистов, занимающихся разработкой программного продукта в условиях неясных или быстро меняющихся требований. Данная книга предназначена для того, чтобы помочь определить, оправдано ли применение ХР в вашей ситуации.

Если пересмотр кода – это хорошо, значит, мы будем пересматривать код постоянно (программирование парами);