Современные интегрированные среды разработки быстры и удобны как никогда ранее. Но и этого мало. Разработка программ ведется слишком долго. Многие компании разрабатывающие программное обеспечение совершенствуют существующие и классические методологии программирования, к примеру есть и такое направление, называемое экстремальным программированием(Extreme Programming (XP)). Методология XP предназначена для большей эффективности управления процессом создания программ, уменьшить время разработки и предоставить конечный продукт отвечающий ожиданиям пользователей. Многие компании кроме методологий делают ставку и на мощные интегрированные среды разработки (Integrated Development Environments (IDEs)), например, на IBM VisualAge for Java. Выбор мощных сред разработки не случает, при их помощи они надеются быстро разрабатывать сложные приложения.

К сожалению не всегда удается совместить какую-то конкретную среду разработки с какой-то конкретной методологией разработки. Эта статья содержит несколько наилучших способов использования сегодняшней методологии экстремального программирования в совокупности с VisualAge for Java.

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

Основные принципы XP:

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

Поскольку принципы XP сильно зависят друг от друга, то в проектах где используется экстремальное программирование все они должны быть реализованы в полном объеме. Тем не менее, некоторые из этих принципов (общий код к примеру), требуют осмотрительности когда они реализуются на IDE таких как VisualAge. Поскольку в таком случае XP зависит от нестандартного применения и настроек IDE.

VisualAge for Java является IDE для профессиональных программистов Java. VisualAge бывает трех разновидностей: Entry, Professional и Enterprise. В этой статье рассматривается Enterprise версия VAJ-а, поскольку только она поддерживает групповую разработку, которая в свою очередь необходима для XP.

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

Но к сожалению, эта иерархическая модель индивидуальных привилегий работает не очень хорошо в экстремальном программировании, кода весь код общий. К примеру, в предыдущем примере, все три разработчика, если они будут использовать XP, должны получить права на создание нового класса, на создание открытой редакции, на изменение кода и на публикацию. А вот хорошая новость состоит в том, что VisualAge for Java была разработана для строго разграничения права, но она может быть и адаптирована для целей экстремального программирования.

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

XP подразумевает, что все разработчики должны владеть всем кодом. Но поскольку VisualAge for Java четко разделяет командные роли и схемы для владением кода, как же можно это сделать? Установите один идентификатор пользователя для всех разработчиков, после этого каждый из разработчиков будет владеть всем кодом полностью.

После инсталляции VisualAge for Java и создания проекта VisualAge, используйте окно User Administration (Window --> Repository Explorer --> Admin --> Users...) для установки идентификатора (userid) для всех ваших разработчиков. Все разработчики в последующем будут подключаться к системе с этим общим идентификатором и ассоциированным с ним паролем. Обычно, идентификатор разработчиков указывает на права владельца проекта. В качестве владельца проекта они получат соответственно все права на создание, модификацию, слияние, удаление и публикацию кода проекта.

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

Обычно, программистская пара, заменяет свое редакцию проекта на своем рабочем пространстве последней редакцией доступной в командном репозитарии. Затем они создают открытые редакции проекта и всех пакетов, в которых они собираются работать. Если первоначально не создается открытая редакция пакета, то версия этого пакета может в последствии отличаться от версии проекта. В результате чего другой разработчик не получит самую последнюю версию кода при обновлении его рабочего пространства из репозитария. Поэтому следует быть осторожными.

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

Иногда может так произойти, что многие пары программистов могут работать над одним и тем же кусочком кода. Когда такое происходит, то VAJ начинает присваивать разветвленные номера версий. К примеру, если пакет com.ibm.myPackage был версии 1.1 до того, как пара начала программировать, то после версиализации она должна стать версией 1.2. Но, если в этот же момент времени другая пара программистов начнет работать с этим же пакетом, то после версиализации версия начнет ветвиться, и она будет соответственно 1.1.1 для первой пары и 1.1.2 для второй. При этом следует замечать такое поведение как модно раньше и не допускать его. Проще всего договариваться перед началом работы о том, какая пара программистов будет работать на каким конкретным участком кода.

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

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

В дополнении к общему коду, очень полезно использовать преимущество VisualAge позволяющее придерживаться некоего стандарта кодирования. Жесткие стандарты оформления исходного кода это еще одна особенность использования XP. Она помогает в кооперативной работе нескольких программистов, особенно над одним и тем же кусочком исходного кода. Строго стандартизированный код легче понять и можно сделать гораздо меньше ошибок, а читаемость чужого исходного кода при этом значительно возрастает. VAJ предоставляет функцию форматирования кода приводящую весь код к одному и тому же формату. Вы можете изменить формат в окне свойств Visual Age, но убедитесь, что у всех разработчиков установлены именно такие установки. Воспользоваться утилитой форматирования можно прямо из окна ввода исходного текста, по нажатию правой кнопки мыши нужно выбрать пункт Format Code.

Как Вы уже узнали, существуют некоторые хитрости благодаря которым можно осуществлять экстремальное программирование на VisualAge for Java. Лучшие методы это установка одного идентификатора на всех пользователей, целостное познание о механизмах контроля версий и исходного кода, а также преимущества форматирования кода. Вот с этими простейшими шагами VAJ вполне может подойти для разработок программного обеспечения по методологии экстремального программирования.