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

pic

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

Любой проект — это вложение средств с целью получения прибыли. Неважно, что конкретно производится — цель остается неизменной: получить качественный результат за меньшее время и с большей отдачей. В этом постулате кроется большая головная боль программиста — постановка задачи вынуждает его рисковать. Факторов риска много — сжатые сроки разработки, постоянно меняющиеся желания клиента, потеря актуальности разрабатываемого продукта на рынке, множество недочетов в системе, вызванное необходимостью завершить ее в срок. Способов борьбы с рисками также немало, и экстремальное программирование является одним из них.
Экстремальное программирование (eXtreme Programming, XP) — это дисциплина разработки программного обеспечения, ориентированная на небольшие команды разработчиков и позволяющая им эффективно работать над проектом в условиях характерных рисков, перечисленных выше. Название, безусловно, настораживает — мы привыкли ассоциировать экстремальное с чем-то беспредельным, непонятным для большинства. Однако ни сноуборд, ни горный велосипед для внедрения XP в коллектив программистов не потребуются (хотя, конечно, ситуации бывают разные). Скорее потребуется желание изменить ход вещей, неудовлетворенность традиционными методиками организации труда программистов.
Программистам XP дает возможность сосредоточиться на написании кода, а заказчикам и менеджерам — уверенность в том, что производственные силы не простаивают, а в любой момент времени заняты проработкой и кодированием наиболее приоритетной задачи. Безусловно, для создания подобной атмосферы необходимо проанализировать, какие факторы влияют на рабочий процесс более всего, выделить среди них самые приоритетные, и спросить самого себя: а что же необходимо изменить, чтобы работать эффективнее?
Один из основоположников экстремального программирования Кент Бек, автор книги «Extreme Programming Explained» — настоящего манифеста XP сравнивает этот стиль с неким абстрактным пультом управления, где каждая рукоятка позволяет использовать ту или иную методику программирования в определенной степени — от 1 до 10. Тогда, казалось бы, сумасшедшее решение вывернуть все рукоятки на положение 10 приводит не к дестабилизации всей системы, а напротив — к улучшению ее функционирования. Попробуем же рассмотреть различные методики (подписи под этими рукоятками).
№1. Разработка через тестирование. Итак, мы знаем, что на отладку программы зачастую уходит больше времени, чем на ее написание. Однако допустим, что у нас есть набор тестов, который охватывает все случаи использования некоторого программного кода, которые только могут прийти нам в голову. Тогда логично будет предположить, что если программа удачно выполняется на всех этих наборах, значит, она верна и дополнительной отладки уже не потребуется. Но в этом случае время, которое при других обстоятельствах было бы затрачено на отладку, придется потратить на составление тестов. Да, составить по готовому коду набор тестов непросто, так как придется учитывать особенности реализации. Но что если набор тестов есть у вас еще перед началом реализации кода? Тогда мы убиваем сразу двух зайцев: во-первых, нам уже заранее известно, как будет выглядеть система (то есть интерфейс класса, схема взаимодействия с пользователем, реагирование на различные типы входных данных), а во-вторых, отладка сведется к применению уже готовых тестов. Упростилось ли программирование? Однозначно сказать невозможно, зависит от специфики проекта, но время экономится ощутимо. Отсюда следует один из важнейших принципов экстремального программирования — разработка через тестирование. Причем тестирование должно быть постоянным, добавление любого мало-мальски важного участка кода в системы должно сопровождаться полным ее тестированием как на предыдущих наборах тестов, так и на новых, учитывающих специфику добавленной функциональности.
№2. Работа в паре. «Одна голова хорошо, а две — лучше». Несмотря на распространенное среди многих людей мнение, что программист — человек, чуждый обществу и предпочитающий работать в одиночестве, это далеко не так. Если в дело вступает постоянное тестирование и пересмотр кода, наличие двоих программистов за одним компьютером оказывается как нельзя кстати. Даже если их уровень поначалу разный, то менее опытный намного быстрее освоится, если постоянно будет наблюдать за работой своего более опытного коллеги, чем в одиночку с грудой зачастую непонятной документации. Равные же по уровню программисты будут постоянно поправлять друг друга, перехватывать инициативу, не давать друг другу отвлечься в сторону оптимизации или наращивания функциональности (если это не входит в их текущие планы). Они просто сделают то, что необходимо, протестируют, отдохнут и примутся за дальнейшую работу.
№3. Будьте проще. Сложность никогда не бывает к месту там, где существует простое решение. Если функциональность, требуемая заказчиком, может быть очень просто реализована с помощью имеющегося набора средств, не нужно изобретать что-то новое, писать собственные классы, тестировать их — просто используйте готовое. Процесс повторного применения готового кода называется рефакторингом, ему посвящены целые научные труды и исследования. Однако среди разработчиков бытует мнение, что переработка кода приводит к появлению менее оптимизированного кода, чем написание «с чистого листа». С этим утверждением можно поспорить — возможный выигрыш в оптимизации компенсируется временем, потраченным на написание кода. Кроме того, хорошо написанные и отлаженные суперклассы скорее помогают оптимизировать код, чем усложняют его структуру.
Итак, основные три методики XP мы рассмотрели. Они хороши и обоснованны, однако второй, не менее важный, аспект экстремального программирования — планирование. Планирование по XP — это процесс предположения, как будет выглядеть процесс разработки программного продукта для заказчика. Во время планирования определяется объем работ и приоритеты, оцениваюся затраты и график работ, определяются исходные данные для обратной связи. В XP ключевой акцент делается на абстрагировании процессов планирования для менеджеров (Business Planning) и разработчиков (Development Planning). При этом разработчики и менеджеры не должны конфликтовать в классическом представлении — то есть исключаются ситуации, когда на общем обсуждении проекта менеджеры требуют от программистов переключить приоритеты или изменить в корне ход работы. Если процесс планирования разработки был заранее продуман по методикам XP, такой вопрос не поднимется в принципе.
Основным инструментом разработчика в планировании по XP является карточка истории. В ходе работ по проекту каждая задача разбивается на минимальные кванты, для каждого кванта заполняется карточка истории, с указанием приоритета. Затем карточки сортируются, выбирается наиболее приоритетная, уточняется постановка задачи, пишутся все необходимые тесты, и начинается фаза кодирования. После этого все написанные тесты запускаются на готовом коде, и если тестирование прошло успешно, выбирается следующая карточка, и процесс повторяется. Такой подход гарантирует, что разработчик всегда занимается самой приоритетной задачей по проекту, что облегчает быстрое завершение каждой итерации.
Итерацией в XP называется фаза разработки, в результате которой создается рабочая версия проекта, но с минимально возможной функциональностью. Чем короче итерации, тем чаще заказчик может оценить текущее состояние продукта, опробовать его в рабочих условиях, протестировать готовую функциональность. Таким образом, заказчик не находится в отрыве от разработчиков, они постоянно доводят до его сведения, что на данный момент сделано и как это работает. Даже если сроки сдачи проекта затягиваются, у заказчика не возникает ощущения провала проекта, так как он уже видел рабочую систему, пускай даже с функциональными ограничениями. В условиях современного бизнеса это огромное преимущество.
Итак, подытожив все вышесказанное, нужно отметить, что экстремальное программирование для команды разработчиков — прежде всего способ выжить в условиях современного бизнеса со всеми его рисками и проблемами. К сожалению, в рамках одной статьи невозможно осветить все «за» и «против» данной дисциплины, отметить все тоноксти XP и поделиться какими-либо советами. Но если во всем вышеописанном вы увидели рациональное зерно, если вы программист и заняты в проекте, при выполнении которого сталкиваетесь с похожими проблемами — значит, XP для вас. Независимо от того, будете ли вы использовать XP, строго следуя его правилам, или ограничитесь лишь понравившимися вам методиками, ваша эффективность, скорее всего, повысится. Ведь именно эту цель преследует XP — работать эффективнее.

Orphus system