UML и XP
Мне задают довольно много вопросов относительно моей приверженности методологии ХР, причем чаще всего люди интересуются - как я могу сочетать ее с верностью UML. Разве они не исключают друг друга?
Да, в ХР и UML есть несколько взаимоисключающих аспектов. Так, в ХР существенно снижается значение диаграмм. Не смотря на то, что официальная позиция ХР по этому поводу гласит: "используйте их, если это помогает вам в работе", но существует и неофициальный подтекст: "настоящий ХР-шник не рисует диаграмм". Это подчеркивается еще и тем фактом, что таким людям, как Кент, неудобно использовать диаграммы. Я, например, никогда не видел, чтобы Кент по своей воле рисовал диаграмму программного продукта, неважно даже на языке UML, или каком другом.
Я думаю, что такая ситуация возникает по другим причинам. Во-первых, одни люди считают, что диаграммы полезны, а другие придерживаются противоположного мнения. Фокус в том, что те, которые так считают, полагают, что те, которые так не считают, должны изменить свое мнение, и наоборот. Вместо этого, мы должны просто принять тот факт, что одни люди будут использовать в работе диаграммы, а другие не будут.
Во-вторых, диаграммы программных продуктов обычно ассоциируются с тяжелыми процессами разработки. В таких процессах большая часть времени уходит на построение диаграмм, что не очень помогает в работе, а иногда даже вредит. Именно поэтому я считаю, что людей нужно учить, как использовать диаграммы правильно и избегать различных ловушек, а не просто говорить "рисуй диаграмму, если тебе без нее совсем не обойтись, бедняга", как это обычно делают ярые ХР-шники.
Вот мои советы тем, кто хочет правильно использовать диаграммы:
Во-первых, пока рисуете диаграмму, не забывайте, для чего вы это делаете. Основное ее достоинство - коммуникация с людьми. Чтобы коммуникация была эффективной, нужно отображать на диаграмме только важные аспекты, не обращая внимания на все второстепенные. Такая избирательность - основа правильной работы с UML.
Не надо отображать на диаграмме каждый класс - только самые важные. У классов не нужно задавать каждый атрибут или операцию - только самые важные. Не надо рисовать диаграммы последовательности для всех вариантов использования и сценариев - ну, и так далее. Самая распространенная проблема с использованием диаграмм это то, что их пытаются сделать максимально всеобъемлющими. Однако самый лучший источник всеобъемлющей информации - это программный код, так как именно его легче всего синхронизировать с кодом. Для диаграммы же всеобъемлимость - враг удобопонятности.
Чаще всего диаграммы используются для того, чтобы проанализировать проектные решения еще до написания кода. Нередко при этом возникает чувство, что в ХР этого делать нельзя. Это совсем не так. Многие полагают, что перед разработкой сложной задачи стоит ненадолго собраться всей командой для ее предварительного проектирования. Тем не менее, когда проводите такие собрания, не забывайте, что:
- они должны быть действительно недолгими
- не нужно обсуждать все подробности (только самое важное)
- относитесь к полученному в результате проектному решению как к наброску, а не как к конечной версии, неподверженной изменениям
Изменения в дизайне вовсе необязательно подразумевает изменения в диаграммах. Абсолютно разумным будет просто-напросто выбросить диаграмму, после того, как она помогла вам найти нужное решение. Нарисовав диаграмму, вы решили стоявшую перед вами проблему, и этого совершенно достаточно. Диаграмма и не должна существовать как некий постоянный артефакт. Надо сказать, что лучшие UML-диаграммы такими артефактами как раз не являются.
Многие ХР-шники используют CRC-карточки. Это не противоречит UML. Лично я все время задействую некую смесь из CRC и UML, и вообще, пользуюсь любыми техниками, которые облегчают мне выполнение текущей задачи.
Кроме того, UML-диаграммы используются в качестве документации по проекту. Как правило, в своей обычной форме это модель, редактируемая при помощи некоторого CASE-инструмента. Идея здесь состоит в том, что ведение такой документации облегчает работу. На самом деле, чаще всего она вообще не нужна, поскольку:
- нужно постоянно тратить массу времени, чтобы не дать диаграммам устареть, в противном случае, они не будут соответствовать программному коду
- диаграммы находятся внутри сложного CASE-средства либо в толстенной папке, и никто туда не заглядывает
- Используйте только те диаграммы, которые вы можете поддерживать без особых усилий
- Помещайте диаграммы туда, где их все видят. Я предпочитаю пришпиливать их на стену. Пусть остальные рисуют на ней ручкой все простые изменения, которые были внесены в изначальный вариант.
- Посмотрите, обращают ли ваши разработчики на диаграммы хоть какое-то внимание, и если нет, выбросите их.
