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

• Предыдущая
• 37/50
• Следующая

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

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

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

• Параллельный тест (parallel test) – этот тест предназначен для того, чтобы доказать, что новая система работает в точности, как старая система. На самом деле тест демонстрирует, насколько новая система отличается от старой. При этом заказчик может принять решение о том, насколько удовлетворительным для него является различие и допустима ли эксплуатация новой системы в промышленных условиях.

• Стресс-тест (stress test) – этот тест разрабатывается для того, чтобы сымитировать наиболее высокую нагрузку на систему. Стресс-тесты применяются для тестирования сложных систем, для которых сложно делать предположения о характеристиках, связанных с производительностью.

• Тест обезьяны (monkey test) – этот тест предназначен для того, чтобы продемонстрировать, что система корректно реагирует на бессмысленный, неподдерживаемый или запрещенный ввод. 

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

За простой и, очевидно, корректный ответ на вопрос о том, как следует внедрять ХР, я хочу поблагодарить Дона Уэллса (Don Wells):

1. Выберите самую неприятную для вас проблему.

2. Решите ее, применяя способ ХР.

3. Когда эта проблема перестает быть самой неприятной для вас, повторите эту последовательность действий с самого начала.

Две очевидные составляющие, с которых можно начать процесс внедрения, – это тестирование и игра в планирование. Очень многие проекты страдают от проблем, связанных с низким качеством кода, а также от дисбаланса полномочий между бизнесом и разработчиками. Вторая книга из серии книг, посвященных ХР, под названием Extreme Programming Applied: Playing to Win (Применение экстремального программирования: игра чтобы победить) будет посвящена именно этим темам, так как с освоения именно этих компонентов ХР удобнее всего приступать к внедрению этой дисциплины.

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

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

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

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

0. Купите какую-нибудь закуску, например шоколадки, сухарики или крекеры.

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

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

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

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

Я разговаривал со многими командами, которые говорили: О, да! Мы уже работаем в рамках ХР. У нас все, как в ХР. Все, за исключением тестирования. Тестирование мы делаем по старинке. Да, и еще у нас есть 200 страничный документ, в котором изложены точные требования заказчика. Но все остальное мы делаем в точности как в ХР. Именно поэтому данная глава состоит из нескольких разделов, каждый из которых соответствует одной из методик. Если вы уже внедрили у себя одну из методик, которая используется в рамках ХР, вы можете игнорировать соответствующий раздел. Если вы намерены внедрить у себя какую-то новую методику, обратитесь к соответствующему разделу.

• Предыдущая
• 37/50
• Следующая