Экстремальное программирование: Pair Programming
Парное программирование является одной из практик XP. Эта практика воплощает экстремальную (преувеличенную) идею Code Review. Если ревью позволяет улучшить качество кода, то давайте делать его постоянно, во время рефакторинга и написания нового кода.
Проблема проведения обычного Code Review заключается в том, что программисты дают очень поверхностную обратную связь, когда просто смотрят на ваш код. Но как только они начинаются с ним работать, вот тогда прилетает настоящая обратная связь по всем тонким местам и недочетам.
Как это делать?
При парном программировании два человека сидят плечом к плечу за одним компьютером. Один из них является «водителем», у него в руках клавиатура и мышка. Второй делает постоянный ревью кода первого, чтобы определить тактические и стратегические недостатки в коде, в том числе ошибки в синтаксисе, логике программы, опечатки и реализации, которые не подходят под существующий дизайн системы. После определенного времени программисты меняются ролями, либо меняют пары.
Исследования
Самый большой скепсис вызывает вопрос: Не будет ли разработка идти медленней, когда два программиста занимаются одной задачей?
Исследования показывают, что работа в паре делает либо с такой же скоростью, как и по одиночке, либо немного (15%) медленнее. Зато код получается намного качественней, содержит меньше ошибок (60%) и технических долгов.
Анти-паттерны
Парное программирование может быть гораздо более интересным и увлекательным, чем программирование в одиночку, если делается правильно. И наоборот, может быть ужасным и скучным по сравнению с работой в одиночку, если делается неправильно.
Как исправить?
Если вы заметили пару программистов, которые работают по этим анти-паттернам, то дайте им обратную связь и укажите на ошибку. Практика показывает, что работу в паре довольно просто может наладить сторонний наблюдатель.
Границы применимости
В реальной практике применять парное программирование получается около 20% времени, а не постоянно, как может показаться из-за духа XP. Конечно, этот процент примерный и зависит от проекта, но в целом до 100% не доходит. Все-таки иногда хочется просто откинутся на спинку кресла и помедитировать на код, подумать о прекрасном и родить идею, как бы этот код сделать еще лучше.
Надо понимать, что парное программирование дает выигрыш при марафоне и является почти убийственным, если мы делаем короткие проекты.
Правильно воспринимать парное программирование, как инструмент, а не панацею от всех проблем. Пробуйте эту практику, чтобы понимать в каких ситуациях она полезна, а в каких можно обойтись и без нее.
Экстремальное
программирование
(XP) не для слабонервных
Экстремальное программирование или XP, eXtreme Programming — гибкая методология разработки программного обеспечения. Как и у других agile-методологий, у нее есть особенные инструменты, процессы и роли. Хотя автор XP не придумал ничего нового, а взял лучшие практики гибкой разработки и усилил до максимума. Поэтому программирование и зовется экстремальным.
Автор методики — американский разработчик Кент Бек. В конце 90-х годов он руководил проектом Chrysler Comprehensive Compensation System и там впервые применил практики экстремального программирования. Свой опыт и созданную концепцию он описал в книге Extreme Programming Explained, опубликованной в 1999 году. За ней были выпущены другие книги, в которых подробно описывались практики XP. К становлению методологии причастны также Уорд Каннингем, Мартин Фаулер и другие.
XP отличается от других гибких методологий тем, что применимо только в области разработки программного обеспечения. Оно не может быть использовано в другом бизнесе или повседневной жизни, как scrum, kanban или lean.
Цель методики XP — справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки. Поэтому XP хорошо подходит для сложных и неопределенных проектов
Методология XP строится вокруг четырех процессов: кодирования, тестирования, дизайна и слушания. Кроме того, экстремальное программирование имеет ценности: простоту, коммуникацию, обратную связь, смелость и уважение.
13 практик экстремального программирования
1. Вся команда
Все участники проекта с применением XP работают как одна команда. В нее обязательно входит представитель заказчика, лучше, если это будет реальный конечный пользователь продукта, разбирающийся в бизнесе. Заказчик выдвигает требования к продукту и расставляет приоритеты в реализации функциональности. Ему могут помогать бизнес-аналитики. Со стороны исполнителей в команду входят разработчики и тестировщики, иногда коуч, направляющий команду, и менеджер, который обеспечивает команду ресурсами.
2. Игра в планирование
Планирование в XP проводят в два этапа — планирование релиза и планирование итераций.
На планировании релиза команда программистов встречается с заказчиком, чтобы выяснить, какую функциональность он хочет получить к следующему релизу, то есть через 2-6 месяцев. Так как требования заказчика часто размытые, разработчики конкретизируют их и дробят на части, реализация которых занимает не более одного дня. Важно, чтобы заказчик разбирался в операционной среде, в которой будет работать продукт.
Задачи записываются на карточки, а заказчик определяет их приоритет. Дальше разработчики оценивают, сколько времени уйдет на каждую задачу. Когда задачи описаны и оценены, заказчик просматривает документацию и дает добро на начало работы. Для успеха проекта критично, чтобы заказчик и команда программистов играли на одном поле: заказчик выбирает действительно необходимую функциональность в рамках бюджета, а программисты адекватно сопоставляют требования заказчика со своими возможностями.
В XP если команда не успевает выполнить все задачи к дате релиза, то релиз не отодвигается, а режется часть функционала, наименее важная для заказчика.
Планирование итераций проводится каждые две недели, иногда чаще или реже. Заказчик обязательно присутствует: он определяет функциональность на следующую итерацию и вносит изменения в требования к продукту.
3. Частые релизы версий
В XP версии выпускаются часто, но с небольшим функционалом. Во-первых, маленький объем функциональности легко тестировать и сохранять работоспособность всей системы. Во-вторых, каждую итерацию заказчик получает часть функционала, несущую бизнес-ценность.
4. Пользовательские тесты
Заказчик сам определяет автоматизированные приемочные тесты, чтобы проверить работоспособность очередной функции продукта. Команда пишет эти тесты и использует их для тестирования готового кода.
5. Коллективное владение кодом
В XP любой разработчик может править любой кусок кода, т.к. код не закреплен за своим автором. Кодом владеет вся команда.
6. Непрерывная интеграция кода
Это значит, что новые части кода сразу же встраиваются в систему — команды XP заливают новый билд каждые несколько часов и чаще. Во-первых, сразу видно, как последние изменения влияют на систему. Если новый кусок кода что-то сломал, то ошибку найти и исправить в разы проще, чем спустя неделю. Во-вторых, команда всегда работает с последней версией системы.
7. Стандарты кодирования
Когда кодом владеют все, важно принять единые стандарты оформления, чтобы код выглядел так, как будто он написан одним профессионалом. Можно выработать свои стандарты или принять готовые.
8. Метафора системы
Метафора системы — это ее сравнение с чем-то знакомым, чтобы сформировать у команды общее видение. Обычно метафору системы продумывает тот, кто разрабатывает архитектуру и представляет систему целиком.
9. Устойчивый темп
XP команды работают на максимуме продуктивности, сохраняя устойчивый темп. При этом экстремальное программирование негативно относится к переработкам и пропагандирует 40-часовую рабочую неделю.
10. Разработка, основанная на тестировании
Одна из самых трудных практик методологии. В XP тесты пишутся самими программистами, причем ДО написания кода, который нужно протестировать. При таком подходе каждый кусок функционала будет покрыт тестами на 100%. Когда пара программистов заливают код в репозиторий, сразу запускаются модульные тесты. И ВСЕ они должны сработать. Тогда разработчики будут уверены, что движутся в правильном направлении.
11. Парное программирование
Представьте двух разработчиков за одним компьютером, работающих над одним куском функциональности продукта. Это и есть парное программирование, самая спорная практика XP. Старая поговорка «одна голова хорошо, а две лучше» отлично иллюстрирует суть подхода. Из двух вариантов решения проблемы выбирается лучший, код оптимизируется сразу же, ошибки отлавливаются еще до их совершения. В итоге имеем чистый код, в котором хорошо разбираются сразу двое разработчиков.
12. Простой дизайн
Простой дизайн в XP означает делать только то, что нужно сейчас, не пытаясь угадать будущую функциональность. Простой дизайн и непрерывный рефакторинг дают синергетический эффект — когда код простой, его легко оптимизировать.
13. Рефакторинг
Рефакторинг — это процесс постоянного улучшения дизайна системы, чтобы привести его в соответствие новым требованиям. Рефакторинг включает удаление дублей кода, повышение связности и снижение сопряжения. XP предполагает постоянные рефакторинги, поэтому дизайн кода всегда остается простым.
Преимущества и недостатки XP
Методология XP вызывает много споров и критики со стороны тех, кто так и не смог ее внедрить в своей команде.
Преимущества экстремального программирования имеют смысл, когда команда полноценно использует хотя бы одну из практик XP. Итак, ради чего стоит стараться:
Несмотря на все плюсы, XP не всегда работает и имеет ряд слабых мест. Итак, экстремальное программирование — недостатки:
Принципы XP
В первой книге Кент Бек сформулировал такие принципы экстремального программирования: простота, коммуникация, обратная связь и смелость. В новом издании книги он добавил пятый принцип — уважение.
1. Простота
В XP разработка начинается с самого простого решения, которое удовлетворит текущую потребность в функциональности. Члены команды учитывают только то, что должно быть сделано сейчас, и не закладывают в код функциональность, которая понадобится завтра, через месяц или никогда.
2. Коммуникация
В XP коммуникация между разработчиками ведется не посредством документации, а вживую. Команда активно общается между собой и с заказчиком.
3. Обратная связь
Обратная связь в XP реализуется сразу в трех направлениях:
4. Смелость
Некоторые методики экстремального программирования настолько непривычны, что требует смелости и постоянного контроля над собой.
5. Уважение
В экстремальном программировании уважение рассматривается с точки зрения уважения к команде и самоуважения. Члены команды не должны заливать изменения, которые поломают компиляцию, модульные тесты, или замедлят работу коллег. Каждый стремится к высшему качеству кода и дизайна.
Алгоритм внедрения методологии XP и процесс работы
Бек Кент рекомендует внедрять XP для решения проблем в проекте. Команда выбирает самую насущную проблему и решает ее с помощью одной из практик экстремального программирования. Затем переходит к следующей проблеме, используя еще одну практику. При таком подходе проблемы выступают мотивацией к применению XP и команда постепенно осваивает все инструменты методологии.
Чтобы внедрить XP в существующий проект, нужно постепенно осваивать его методики в области:
Тестирование.
Команда создает тесты ПЕРЕД написанием нового кода и постепенно перерабатывает старый код. Для старого кода тесты пишутся по мере необходимости: когда нужно добавить новую функциональность, исправить ошибку или переработать часть старого кода.
Проектирование.
Команда постепенно рефакторит старый код, обычно перед добавлением новой функциональности. Как и в случае с тестированием, рефакторинг старого кода проводят только по необходимости. При этом команде стоит сформулировать долгосрочные цели переработки кода и постепенно достигать их.
Планирование.
Команда должна перейти на тесное взаимодействие с заказчиком. На этом этапе важно донести до него преимущества работы в одной команде с разработчиками и интегрировать его в команду.
Менеджмент.
Роль менеджеров при переходе на XP — контролировать, чтобы все члены команды работали по новым правилам. Менеджер проекта принимает решение, когда расстаться с членом команды, который не справляется с работой в новых условиях, или найти нового и правильно интегрировать его в работу.
Разработка.
Преобразования в разработке начинаются с организации рабочих мест для программирования парами. Следующая задача — программировать парами большую часть рабочего времени, как бы тяжело это не давалось разработчикам.
В проекте, который работает по методологии XP процесс построен таким образом:
Кто использует XP
По данным исследования Versionone за 2016 год всего 1% agile компаний используют экстремальное программирование в чистом виде. Еще 10% работают по гибридной методологии scrum и XP.
Соотношение agile методологий и практик в компаниях
Самые популярные практики разработки в agile компаниях в 2016 г.
Не так просто найти информацию о командах, которые применяют XP, но есть и те, кто афиширует, что именно эта методология — причина их успеха. Пример экстремального программирования — компания Pivotal Software, Inc.
Pivotal Software, Inc.
Американская софтверная компания, которая разрабатывает ПО для бизнес-анализа на основе big data и оказывает консультационные услуги. Продуктами Pivotal пользуются корпорации Ford, Mercedes, BMW, GAP, Humana, крупные банки, государственные учреждения, страховые компании и т.д.
Pivotal — адвокат agile методологий, как единственно возможных в современной разработке. Из всех вариантов гибких методологий компания выбрала XP как win-win подход для заказчиков и команд программистов. Каждый рабочий день начинается с собрания на ходу, и заканчивается ровно в 18:00 — никаких переработок. Pivotal использует игру в планирование, парное программирование, постоянное тестирование, непрерывную интеграцию и другие практики XP. Для многих практик у них есть собственное ПО.
Парное программирование в openspace компании Pivotal Software, Inc.
Что почитать, чтобы разобраться в XP
Экстремальное программирование,
Экстремальное программирование: планирование,
Экстремальное программирование: разработка через тестирование / Кент Бек
Книги по экстремальному программированию от создателя методологии Кента Бека. Начните с первой, в ней с примерами описывается концепция XP и обосновываются ее преимущества. Позднее автор выпустил еще несколько книг, где подробно описал отдельные практики XP.
Рефакторинг: улучшение существующего кода / Мартин Фаулер
Мартин Фаулер — программист и соавтор методологии экстремального программирования. В книге описаны основные принципы и приемы рефакторинга, а также 70 практических методов рефакторинга с примерами.
Экстремальное программирование: постановка процесса. С первых шагов и до победного конца / Кен Ауэр, Рой Миллер
Так как экстремальное программирование стремится к чистому и легко поддерживаемому коду, к списку книг можно отнести все издания, которые учат программировать лучше.
Приложения для внедрения XP в команде
Команды, работающие над проектами по методологии XP, применяют таск менеджеры и сервисы для agile проектов. На рынке много таких продуктов, мы рассмотрим несколько примеров.
Redmine
Бесплатный менеджер задач с открытым кодом. Основные функции: работа сразу над несколькими проектами, гибкая система управления задачами, диаграмма Ганта, контроль времени, работа с документацией, создание задач через почту и др.
Basecamp
Простой удобный сервис для совместной работы над проектами. Включает таск менеджер, доску сообщений, встроенный чат, файлохранилище, календарь
Мощный сервис, разработанный специально для разработчиков agile проектов. Объединяет баг-трекер и сервис для управления проектами. Много функций плюс синхронизация с другими сервисами. Решения для команд разных размеров.
Worksection
Безопасный сервис для работы над проектами. Позволяет ставить задачи и контролировать процесс выполнения, вести переписку по задаче, настраивать фильтры, учитывать расход времени и финансов, работать с файлами.
Вердикт
Экстремальное программирование — гибкая методология, в центре которой качественный работоспособный код с простой архитектурой. Ее предназначение — снизить уровень неопределенности в проектах и по-настоящему гибко реагировать на изменения требований к продукту.
Эта методология предназначена исключительно для сферы разработки программных продуктов и не может быть адаптирована под другой бизнес.
Это одна из самых трудных для внедрения методологий, поскольку она включает целых тринадцать практик!
Немногие компании рискуют работать по чистому XP, но его практики разработки — самые популярные в agile проектах. И это весомый довод в пользу их эффективности.
Авторы методологии советуют одну за другой осваивать практики XP, параллельно решая проблемы проекта. Если вы видите эффект, продолжайте в том же духе.
Что такое экстремальное программирование?
Экстремальное программирование — что это? Речь идет о новой методологии разработки программных продуктов в условиях ограниченного количества ресурсов, финансирования, кадров, других негативных моментах. Когда при этом требования к качеству, скорости создания ПО остаются неизменными или становятся выше, чем при благоприятных условиях.
Подход дает возможность эффективно работать при скоплении негативных факторов без ущерба конечному результату. Поэтому он и носит такое название. С другой стороны, экстремальным такое программирование именуют за счет мобилизации ресурсов команды, доведения их до предельной точки — экстремума.
Для чего нужно экстремальное программирование?
Популяризатором подхода Extreme Programming выступает Кент Бек, который выдвинул и оптимизировал его в середине 90-х годов прошлого века, пока работал над крупным приложением для компании Chrysler. Результатом наработок стало создание принципиально новой методологии XP. Подобный подход преследовал сразу 4 цели:
Технологии подобного плана используются при недостатке ресурсов или при желании оптимизировать работу команды, скорее добиться результата. Это не догма, не принципиальная замена старым парадигмам, а один из вариантов решения повседневных рабочих вопросов. Выгодная альтернатива.
Кому подойдет подобный подход?
Экстремальное программирование подойдет нескольким категориям разработчиков:
Теоретически, технология подойдет любым командам, группам создателей приложений. Однако специалисты выделяют ряд формальных критериев, которых нужно придерживаться, выбирая подходящую методологию.
Экстремальное программирование подойдет в следующих случаях:
В то же время, XP не подходит для решения вопросов проекта, если:
Основные приемы
Суть методологии можно описать 12-ю принципами:
Тестирование
Многоуровневая система тестирования программного кода. Требует выработки четких принципов проверки того или иного сегмента будущего продукта. Подобный вариант позволяет сократить итоговую продолжительность работы над проектом. Поскольку ошибки исправляются на ходу. С другой стороны, процесс тестирование требует, чтобы код содержал комментарии. Сам по себе протоколируется. Следовательно, если продолжить работу над проектом через неделю, месяц, потребуется минимум времени на понимание сути написанного.
Исправление багов, если они появятся уже после перерыва и продолжения разработки.
Четкое планирование
Процесс начинается с постановки задания и создания примерного плана разработки с указанием графика реализации каждой части. По мере того, как задача становится все более четкой, план меняется, дополняется. Программисты получают как общие сведения, так и конкретные указания, которым должны следовать. Подобный подход позволяет держать руку на пульсе и четко понимать, на какой стадии находится команда. Следовательно, любые заминки, организационные проблемы, путиница исключены.
Плотный контакт с заказчиком
Согласно философии extreme programming заказчиком выступает не тот, кто платит за работу, а конечный пользователь приложения, системы. Для эффективной работы требуется постоянный контакт с пользователями. Они участвуют в тестировании промежуточных версий. Тот же, кто оплачивает счета и ставит техническое задание, участвует в разработке как проверяющий конечного результата.
Парное участие
Особый способ организации рабочего коллектива. Над программированием системы работают пары специалистов за одним компьютером. Один занимается подготовкой самого кода, решением вопроса. Другой — следит за точностью выполнения, видит всю картину целиком. При необходимости пары меняются местами: один наблюдает и корректирует, другой занимается созданием, пишет код.
Продолжительность работ каждой команды жестко не регламентируется. В течение дня команды могут меняться. Ротация позволяет сделать так, чтобы каждый программист имел представление не только о своем сегменте системы, но и обо всем программном продукте в целом.
Повторяющиеся итерации
Обычный подход к созданию системы предполагает, что проект окажется запущен для выполнения только один раз, после того как будет написана последняя строчка кода. XP же требует, чтобы проверка работоспособности системы проводилась несколько раз, по мере выполнения каждого крупного шага. Это позволит быстрее выявить ошибки, ускорить отладку приложения.
Рефакторинг или переработка кода
После выполнения каждой задачи специалисты проводят ревизию написанного кода. А затем ищут варианты его оптимизации, чтобы повысить скорость работы программы и облегчить ее выполнение на компьютере или ином устройстве пользователя. Благодаря этому, системы, созданные по принципам XP, считаются более легковесными, а также надежными и безопасными.
Ранний релиз конечного продукта
Сторонники XP стараются всеми силами сократить продолжительность разработки и как можно скорее выпустить первую версию системы. Это позволяет удовлетворять потребности бизнеса. Заказчик получает первые результаты (прибыль, оптимизацию рабочих процессов) гораздо раньше, чем при прочих вариантах разработки.
В то же время, создатели также могут рассчитывать на раннюю обратную связь. Учитывать мнение пользователей и заказчика при проектировании новых версий приложения. Релизы выпускаются часто, с указанием новых функций или особенностей программного обеспечения. Что делает процесс более эффективным, а само ПО — дружественным потребителю и полезным заказчику.
Простое проектирование
Проектирование системы проводится в несколько этапов, с учетом меняющихся условий. Сторонники XP считают, что заблаговременно строить подробный план не имеет смысла.
Достаточно набросать его по основным направлениям, а затем дополнять и дорабатывать по мере того, как задача становится четче. Благодаря этому, есть возможность сэкономить время проектировании, а также увеличить его эффективность.
Разработка метафоры системы
Речь идет об архитектуре системы, описании ее формы и внутренней структуры. Экстремальное программирование требует более четкого, детального описания архитектуры и при необходимости — коррекции информации.
Жесткие стандарты оформления кода
Программисты, члены команды должны придерживаться одних и тех же стандартов оформления программного кода. Пользоваться одними и теми же принципами. Это позволит упростить понимание между разработчиками, особенно в условиях больших коллективов. Ускорить процессы разработки, а также исключить вероятность недопонимания и задержек при длительном перерыве в работе над тем или иным модулем.
Коллективная работа
Специалистам предоставляется значительная свобода. Каждый может вносить предложения поменять тот или иной фрагмент кода. Также несет ответственность за весь проект целиком.
Так удается повысить осведомленность специалистов, вовлеченность участников. С другой стороны, тут есть и свои подводные камни.
Еще один момент касается трудовых прав специалистов, касается жесткого графика работы, без неоплачиваемых сверхурочных.
Как внедрить?
Чтобы внедрить XP требуется соблюдение нескольких условий:
Преимущества и недостатки
Среди преимуществ XP:
Экстремальное программирование — удобный вариант, когда нужно решить задачу быстро, в сложных условиях и с минимальными расходами. Но этот подход не идеален, имеет свои условия использования. При его реализации нужно проявлять максимум осторожности.