LibKing » Книги » Компьютеры и Интернет » Прочая околокомпьтерная литература » Кент Бек - Экстремальное программирование

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

Тут можно читать онлайн Кент Бек - Экстремальное программирование - бесплатно ознакомительный отрывок. Жанр: Прочая околокомпьтерная литература. Здесь Вы можете читать ознакомительный отрывок из книги онлайн без регистрации и SMS на сайте LibKing.Ru (ЛибКинг) или прочесть краткое содержание, предисловие (аннотацию), описание и ознакомиться с отзывами (комментариями) о произведении.
Кент Бек - Экстремальное программирование

Кент Бек - Экстремальное программирование краткое содержание

Экстремальное программирование - описание и краткое содержание, автор Кент Бек, читайте бесплатно онлайн на сайте электронной библиотеки LibKing.Ru

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

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

Экстремальное программирование - читать книгу онлайн бесплатно (ознакомительный отрывок), автор Кент Бек
Тёмная тема

Шрифт:

Сбросить

Интервал:

Закладка:

Сделать

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

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

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

Большой босс

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

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

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

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

Глава 23.

Правило 20 на 80

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

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

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

Вард Каннингхэм (Ward Cunningham) рассказывал мне о книге, посвященной освоению техники горнолыжного спуска. Эта книга называлась The Athletic Skier ( Лыжник-спортсмен). Половина книги была посвящена настройке и подгонке горнолыжных ботинок таким образом, чтобы вы уверенно стояли на лыжах, чувствовали склон и поддерживали равновесие во время спуска. После этого в книге говорилось: Однако после того, как вы выполните 80% всех этих упражнений, вы улучшите вашу ситуацию лишь на 20%. Далее объяснялось, что существует огромная разница между состоянием равновесия и состоянием потери равновесия. Если вы немножко не в равновесии, это может означать, что вы полностью потеряли равновесие. На это влияет огромное количество факторов, например качество настройки ваших горнолыжных ботинок. Если хотя бы один из них настроен неправильно, значит, вы потеряете баланс. По мере того как вы учитываете в своей подготовке все большее количество факторов, ситуация будет очень медленно улучшаться. Однако когда вы внесете в свою подготовку несколько самых последних изменений, вы получите существенные, кардинальные улучшения вашей техники спуска.

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

Читать дальше
Тёмная тема

Шрифт:

Сбросить

Интервал:

Закладка:

Сделать


Кент Бек читать все книги автора по порядку

Кент Бек - все книги автора в одном месте читать по порядку полные версии на сайте онлайн библиотеки LibKing.




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


Отзывы читателей о книге Экстремальное программирование, автор: Кент Бек. Читайте комментарии и мнения людей о произведении.


Понравилась книга? Поделитесь впечатлениями - оставьте Ваш отзыв или расскажите друзьям

Напишите свой комментарий
Большинство книг на сайте опубликовано легально на правах партнёрской программы ЛитРес. Если Ваша книга была опубликована с нарушениями авторских прав, пожалуйста, направьте Вашу жалобу на PGEgaHJlZj0ibWFpbHRvOmFidXNlQGxpYmtpbmcucnUiIHJlbD0ibm9mb2xsb3ciPmFidXNlQGxpYmtpbmcucnU8L2E+ или заполните форму обратной связи.
img img img img img