MDA vs XP

Доброго времени суток.

Продолжу разговор о современных технологиях программирования, ускоряющих разработку и облегчающих нам - программистам, жизнь. Эти технологии прямо противоположны по методике разработке.

Так MDA (Model Driven Architecture) - изначально предполагает, что вы, как архитектор, создадите уже готовую часть (или всю) системы в виде моделей и спецификаций, а остальное на себя возьмет уже среда моделирования. Программистам останется лишь добавить специфической функциональности, что на современный момент не является необходимым - большое количество библиотек классов и фреймворков решают все.

С другой стороны - XP (Extremal Programing), подразумевает упор на кодинге. Сама архитектура вторична, и хотя они ее называют "метафора", это понятие весьма расплывчато. И дизайн системы постоянно улучшается - рефакторится.

Что больше всего интересно, так это то, что оба лагеря обещают быструю и удобную разработку, удовлетворение клиента и своевременную реакцию на изменения.
Я попробовал оба подхода и могу сказать следующее: MDA - вещь хорошая, но есть один нюанс - вы должны быть профессиональным архитектором и знать UML/OCL как свои пять пальцев. Иначе вы запросто заблудитесь в этих спецификациях и функциях системы. Как правило они очень мощные и слишком универсальные. Поэтому надо знать, что творишь и двигаться строго по методологии RUP/UML.

Экстремальное программирование - более легко в освоении, и близко к духу настоящего программирования. Ориентировано на кодирование, тесты и рефакторинг. И все бы хорошо, но оно отличается тем, что без общего плана, лишь с "метафорой" и текущим списком задач далеко не уедешь. Часто происходит то, что говорят: "не зная куда идешь, ты придешь не туда". Из-за этого необходимо поддерживать тесную связь с заказчиком. Даже влить его в команду, как они и советуют. Но наши заказчики - занятые люди и сложно уговорить их работать с нами на равных.

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

Могу лишь сказать, что я изучал UML с 1996 года и старался стать архитектором ПО. Продукты выходили достойные, но происходило это очень медленно - от 3х до 9и месяцев уходило на рождение системы. Хорошо клиенты попадались понимающие. После чего я встретил экстремальное программирование, и дух творчества и азарт, который начал стихать заново загорелся. Сейчас я делаю небольшие программы за неделю, но оставляю возможность их улучшения. Самое трудное - перейти на автономное тестирование. Рефакторингом мы занимаемся по любому достаточно часто. А вот тестирование, причем, встроенное  в процесс разработки - увы не так удобно, как кажется.

Благодарю вас за ваше время.
В следующей статье обсудим разработку RAD, основываясь на средах Delphi, Visual Studio.
Буду рад встретиться с вами