Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Кодирование. В основе экстремального программирования лежит ряд практик

Дизайн

Планирование

Практики XP

В основе экстремального программирования лежит ряд практик. Условно их можно разделить на 4 группы:

  • Планирование
  • Дизайн
  • Кодирование
  • Тестирование

 

Каждая группа включает в себя несколько практик.

 

  • Пользовательские истории (User stories) – пользовательские истории играют похожую роль что и варианты использования (Use-case). Они используются для сбора требований пользователей и планирования итераций. Пользовательские истории записываются пользователями (или разработчиками под диктовку пользователей) и описывают то что система должна делать с точки зрения пользователя получающего результат. Обычно они занимают три предложения обычного текста без использования технических терминов. Кроме того, пользовательские истории используются для создания приёмочных тестов (acceptance test). Один план итерации включает как правило около 80 пользовательских историй, котрые требуется реализовать в рамках данной итерации.
  • Планирование релиза. – этот (совместный пользователи и разработчики) процесс решает какие пользовательские истории или требования должны быть реализованы и какие итерации предстоят в рамках релиза. (Т.е. релиз состоит из нескольких итераций)
  • Необходимо выпускать частые маленькие релизы. Одной из задач планирования релизов является выявление обособленной группы функциональности которая имеет какое либо существенное бизнес-значение.
  • Релиз делится на итерации, каждая длится 1 – 3 недели. Недопускается менять сроки итерации, и если становиться ясно, что какая то функциональность не может быть реализована до конца итерации, не следует откладывать окончание итерации, а функциональность перенести на следующую итерацию.
  • Планирование итерации – каждая итерация планируется заново, пользователи выбирают истории из тех которые вошли в план релиза, которые должны войти в следующую итерацию. Кроме того отводится время на исправление автоматических тестов и рефакторинг.
  • Ротация людей – необходимо менять пары программистов, с тем что бы знания распространялись как можно быстрее и не возникало ситуаций при которых лишь один или два человека знают какую то конкретную часть системы.
  • Стоячие совещания (stand-up meeting) – их следует проводить каждый день в назначенное время (желательно сутра) для того чтобы убеждаться что все чётко понимают свои ближайшие задачи, а кроме того чтобы повысить общение в проекте.

 

  • Простота – необходимо делать самое простое решение которое удовлетворяет пользовательские истории. Заказчик платит за реализацию пользовательских историй а не за создание технологичных каркасов (frameworks).
  • Метафора – я специально опускаю её определение – так как это нечто такое, что должно вести весь процесс в нужном направлении. Некоторые понимают под этим упрощённую версию языка предметной области. Хотя, на мой взгляд, это более глубокое понятие.
  • Используйте CRC карточки (Class Responsibility Collaboration Card) для выработки дизайна классов. Каждая карточки может представлять объект. На ней удобно писать то что должен делать этот объект и за что он отвечает.
  • Делайте технологические прототипы или быстрые решения на скорую руку (spike solution) – их суть заключается не в том чтобы реализовать функциональность пользовательской истории в полном объёме, а в том что бы лишь исследовать возможность её реализации тем или иным способом и далее чтобы дать адекватную оценку трудозатрат для её реализации.
  • Пытайтесь делать систему как можно меньше загруженную функциональностью и механизмами, которые вам МОГУТ понадобится в дальнейшем.
  • Проводите рефакторинг (Refactoring) всегда когда и где это возможно.

 

  • Заказчик должен быть доступен всегда всем участникам проектной команды. Идеальной является ситуация, когда заказчик сидит в одной комнате с разработчиками.
  • Используйте соглашения по кодированию (Coding Standards)
  • Сначала пишется тест, потом код его реализующий.
  • Весь код, который является частью системы (production code) – должен быть написан программистами в парах.
  • Постоянная интеграция – существуют продукты, которые позволяют организовать среду разработки так, что система будет автоматически собираться из version manager’а (репозитория исходного кода) и проходить автоматическое тестирование. Постоянная интеграция позволяет выявлять ошибки как можно раньше, а следовательно стоимость их исправления остаётся невысокой (программисту гораздо проще вспомнить то что он делал пару часов назад, чем то что написал другой человек год назад).
  • Коллективное владение кодом – в идеале в системе не должно быть частей или модулей закреплённых за одним каким либо программистом (или парой). Любой участник проектной команды имеет право вносить изменения, добавлять или рефакторить любой код системы.
  • Не прибегайте к сверхурочной работе (overtime).

 

<== предыдущая лекция | следующая лекция ==>
Введение. Экстремальное Программирование (Extreme Programming) | Конфигурационное управление (Software Configuration Management)
Поделиться с друзьями:


Дата добавления: 2014-01-05; Просмотров: 415; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.012 сек.