Введение.

eXtreme Programming

Не надо думать, что "Экстремальное программирование" - это ерш из пива, последней версии модного шутера и разноса у начальства по утрам за проваленный проект :-). XP - это реальная замена традиционной концепции "водопадного" программирования. Подробности на английском языке: www.xprogramming.org, на русском: www.xprogramming.ru.

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

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

Для достижения поставленной цели в XP существует две базовые практики: Рефакторинг и Тестирование. Они настолько базовые, что могут принести результат сами по себе, без применения остальных практик XP.
Рефакторинг - это внесение в программу изменений, которые направлены на то, чтобы программа стала более понятна для человека. При этом при Рефакторинге никаких функциональных изменений в программу не вносится. Именно Рефакторинг приводит к поставленной цели - снижению стоимости изменений, поскольку при постоянном Рефакторинге код и структура программы все время остаются простыми для внесения изменений. Однако Рефакторинг должен быть безопасным. Мы должны быть уверены в том, что при улучшении читаемости не ухудшился функционал.
В этом нам помогает Тестирование. С точки зрения XP Тестирование является лишь вспомогательной практикой, поскольку не приводит напрямую к поставленной цели (снижение стоимости для внесения изменений), а напротив, требует дополнительных расходов. Однако при внедрении методик XP начинать нужно именно с Тестирования, поскольку если программа не делает того, что должна - нам все равно, насколько ее просто сможет понять человек. Более подробное мое видение Тестирования можно посмотреть на специальной страничке.

Разумеется, возможности применения XP небезграничны. Например, для программ с заведомо коротким жизненным циклом, применение XP, очевидно, нецелесообразно. Так же нельзя применять XP для разработки таких программ, для которых накладные расходы, неизбежные при применении определенных практик XP, недопустимы. Например, такими программами являются всевозможные системы с realtime откликом. Наибольший эффект от применения XP можно получить для программ, которые во-первых, должны существовать и стабильно работать достаточно длительное время (например, больше одного года), а во-вторых, должны иметь возможность к быстрому изменению функционала. Я, как человек, занимающийся автоматизацией "хозяйствующих субъектов", сталкиваюсь в своей работе именно с такими программами.

1С и Объектно-Ориентированное Программирование.

XP выросло на таких Объектно-Ориентированных языках программирования, как SmallTalk и Java. И многие приемы XP очень активно используют именно возможности объектной модели.

Однако давно не секрет, что язык 1С является объектным только в пресс-релизах АОЗТ "1С". Однако, есть внешняя компонента 1C++, реализующая для 1С практически полностью объектную модель. Для меня эта компонента стала билетом в мир ООП и это знакомство полностью перевернуло мои представления о возможностях программирования. Если вы работаете с 1С - настоятельно рекомендую хотя бы ознакомиться с возможностями 1С++. Потраченное на ознакомление время окупится сторицей.

XP и 1С.

Как уже было сказано, базовой практикой XP является тестирование. Без тестов все остальное теряет всякий смысл. Тесты бывают функциональными и внутренними.

Функциональные тесты. A-Tests, Acceptance-Tests, Приемочные тесты. С их помощью проверяют работу всей программы в целом. С помощью функциональных тестов можно полностью описать ожидаемый функционал программы. Доводя мысль до конца - функциональные тесты можно рассматривать, как Техническое Задание для проекта. Инструмент создания функциональных тестов должен быть достаточно прост (понятен) для того, чтобы с ним смог работать конечный пользователь (ибо именно заказчик и ставит задание программисту).

У меня пока нет точного видения того, в каком виде могут существовать полноценные юниттесты для 1С. С функциональными тестами все немного проще. Функционал 1С может быть описан в первую очередь с помощью генерируемых документами проводок, движений по регистрам и записям в журналах расчетов. Это - подход программиста. С точки зрения пользователя, функционал 1С выражается в отчетах. Значит, если у нас будет инструмент, позволяющий задавать ожидания проведения документов, а так же отчетов - можно считать, что первый шаг к применению XP нами сделан.

FuncTest

FuncTest - это результат моей попытки создания инструмента функционального тестирования для 1С. Насколько я могу судить - попытка оказалась довольно удачной. Для моей конфигурации я создал за месяц более сотни тестов, и каждую неделю с его помощью удается предотвратить внесение двух-трех ошибок. При написании этого инструмента я пользовался возможностями 1С++ (надо же когда-то начинать программировать на Объектных языках :).