Книги
чёрным по белому
Главное меню
Главная О нас Добавить материал Поиск по сайту Карта книг Карта сайта
Книги
Археология Архитектура Бизнес Биология Ветеринария Военная промышленность География Геология Гороскоп Дизайн Журналы Инженерия Информационные ресурсы Искусство История Компьютерная литература Криптология Кулинария Культура Лингвистика Математика Медицина Менеджмент Металлургия Минералогия Музыка Научная литература Нумизматика Образование Охота Педагогика Политика Промышленные производства Психология Путеводители Религия Рыбалка Садоводство Саморазвитие Семиотика Социология Спорт Столярное дело Строительство Техника Туризм Фантастика Физика Футурология Химия Художественная литература Экология Экономика Электроника Энергетика Этика Юриспруденция
Новые книги
Цуканов Б.И. "Время в психике человека" (Медицина)

Суворов С. "Танк Т-64. Первенец танков 2-го поколения " (Военная промышленность)

Нестеров В.А. "Основы проэктирования ракет класса воздух- воздух и авиационных катапульных установок для них" (Военная промышленность)

Фогль Б. "101 вопрос, который задала бы ваша кошка своему ветеринару если бы умела говорить" (Ветеринария)

Яблоков Н.П. "Криминалистика" (Юриспруденция)
Реклама

Совершенный код. Мастер-класс - Макконнелл С.

Макконнелл С. Совершенный код. Мастер-класс — М.: Русская редакция, 2005. — 896 c.
ISBN: 5-469-00822-3
Скачать (прямая ссылка): soversheniykodmasterklass2005.djvu
Предыдущая << 1 .. 226 227 228 229 230 231 < 232 > 233 234 235 236 237 238 .. 426 >> Следующая

программиста группы.
¦ Оно ускоряет разработку системы. Как правило, пары пишут код
быстрее, допуская при этом меньше ошибок. Соответственно в
конце проекта группе приходится тратить меньше времени на
исправление дефектов.
¦ Оно обеспечивает все остальные общие преимущества
совместного конструирования, такие как распространение
корпоративной культуры, обучение неопытных программистов и
содействие совместному владению результатами работы.
ГЛАВА 21 Совместное конструирование 477
Контрольный список: эффективное
парное программирование мршг&сйтж
? Утвердили ли вы стандарт кодирования, позволяющий
парам сосредоточиться на программировании и не тратить время
на философские диспуты о стиле кодирования?
? Оба ли члена пары принимают активное участие в
программировании?
? Не используете ли вы парное программирование для реализации
всех аспектов системы? Определяете ли вы задачи, которые
действительно целесообразно решать в парах?
? Не забываете ли вы регулярно менять состав пар и назначаемые
им задачи?
? Соответствуют ли члены пар друг другу по темпу работы и
характеру?
? Назначили ли вы лидера группы, координирующего действия
участников проекта и отвечающего за связь с людьми, не
участвующими в проекте?
21.3. Формальные инспекции
Инспекцией называют специфический вид обзора, обеспе-
ДоволнмтепЬйые атж Пер. чивающий очень высокую эффективность
обнаружения де- вой ра6отой< лосинной ин-
фектов и требующий меньших затрат, чем тестирование, сяйщшм,
является статья "0е~ Инспекции были разработаны Майклом
Фаганом (Michael sign and Code Inspections to Ra-
Faean) и уже использовались в IBM за несколько лет до того,
Errors in Program Develop-
?? с? roent" (f&^an, 1976).
как Фаган опубликовал свою работу, которая сделала их ' *
'
доступными широким массам. Хотя любой обзор предполагает
изучение проектов или кода, инспекция отличается от
обыкновенного обзора несколькими важными аспектами:
¦ используемые при инспекциях контрольные списки концентрируют
внимание инспекторов на областях, с которыми ранее были
связаны проблемы;
¦ главной целью инспекции является обнаружение, а не
исправление дефектов;
¦ люди, выполняющие инспекцию, готовятся к инспекционному
собранию заблаговременно и прибывают на него со списком
обнаруженных ими проблем;
¦ всем участникам инспекции назначаются конкретные роли;
¦ координатор инспекции не является автором продукта,
подвергающегося инспекции;
¦ координатор прошел специальное обучение координированию
инспекций;
¦ инспекционное собрание проводится, только если все участники
адекватно к нему подготовились;
¦ данные, полученные при каждой инспекции, используются для
улучшения будущих инспекций;
¦ руководители не посещают инспекционных собраний, если только
вы не инспектируете план проекта или другие организационные
материалы; участие технических лидеров в инспекционных
собраниях допускается.
478
ЧАСТЬ V Усовершенствование кода
Каких результатов можно ожидать от инспекций?
Отдельные инспекции обычно приводят к обнаружению около 60%
дефектов, что превышает эффективность других методик за
исключением прототипирования и крупномасштабного бета-
тестирования. Эти результаты многократно подтверждены в таких
организациях, как Harris BCSD, National Software Quality
Experiment, Software Engineering Institute, Hewlett Packard и
многих других (Shull et al., 2002).
Комбинация инспекций проекта и кода обычно позволяет устранить
из продукта 70-85 или более процентов дефектов (Jones, 1996).
Инспекции способствуют раннему определению подверженных
ошибкам классов, и Кейперс Джонс сообщает, что при
использовании инспекций число дефектов в расчете на 1000 строк
кода оказывается на 20-30% более низким, чем при использовании
менее формальных методик обзора. Участвуя в инспекциях,
разработчики, занимающиеся проектированием и кодированием,
учатся улучшать свою работу и достигают повышения
производительности труда примерно на 20% (Fagan, 1976;
Humphrey, 1989; Gilb and Graham, 1993; Wiegers, 2002).
Инспекции проектов и кода системы требуют около 10-15% бюджета
проекта и обычно снижают общую сумму расходов на реализацию
системы.
Инспекции позволяют также оценить прогресс, но только
технический. Как правило, для этого нужно узнать, выполняются
ли технические аспекты работы и хорошо ли они выполняются.
Ответы на оба этих вопроса являются побочными продуктами
формальных инспекций.
Роли участников инспекции
Один из важнейших аспектов инспекции состоит в том, что каждый
ее участник играет свою особую роль.
Координатор Координатор должен поддерживать темп инспекции
достаточно высоким, чтобы она была продуктивной, и в то же
время достаточно низким, чтобы участники инспекции могли найти
максимум ошибок. Координатор должен обладать адекватной
технической компетентностью: он может не быть экспертом в
конкретном фрагменте инспектируемого проекта или кода, но
обязан понимать соответствующие детали. Координатор также
Предыдущая << 1 .. 226 227 228 229 230 231 < 232 > 233 234 235 236 237 238 .. 426 >> Следующая