Заблуждения в XP II:
Ахиллес и Черепах рассуждают о Дизайне.

Ахиллес - известный специалист по архитектуре ПО; Черепах - известный XP-программист. Сегодня они говорят о дизайне в XP.

Ахиллес

Вообще-то г. Ч., я думал что Вы умнее - Нельзя писать программы без предварительного проектирования.

Черепах

Совершенно согласен.

Ахиллес

Что?

Черепах

Я говорю, что совершенно с Вами согласен. Глупо думать, что можно разработать нетривиальную систему без того, чтобы сначала ее не спроектировать.

Ахиллес

Но я слышал, что вы не проектируете.

Черепах

Полностью безосновательно.

Ахиллес

Но как же слухи?

Черепах

Не надо бы Вам слушать сплетни.

Ахиллес

Хорошо, докажите. Покажите мне UML диаграммы вашего проекта.

Черепах

Мы не используем UML в нашем проекте.

Ахиллес

Ладно, не все используют UML, тогда обьясните, в каком стандарте вы рисуете диаграммы, и где они?

Черепах

Мы почти не используем диаграмм а те, которые нарисовали мы вскоре выбросили.

Ахиллес

Чего?

Черепах

Ахиллес, мой друг, у Вас что-то со слухом сегодня, возможно Вам надо обратиться к лекарю.

Ахиллес

Похоже Вы правы. Мне просто послышалось что Вы сказали будто у Вас нет никакой документации дизайна вашего проекта!

Черепах

Хммм, ну тогда, похоже, Вам не нужно к лекарю. Ваш слух в порядке, потому что именно это я и сказал.

Ахиллес

Не могу поверить, что Вы можете быть таким тупым. Если у вас нет никакой документации, то и дизайна у вас никакого нет.

Черепах

Интересно... Так Вы думаете, что в результате дизайна получается документ?

Ахиллес

Конечно, документ.

Черепах

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

Ахиллес

Не пойду я ни к какому лекарю ни за какими пиявками, потому что Вы попросту издеваетесь. Ну, если Вы думаете, что в результате дизайна не получается документ, то что же тогда получается?

Черепах

П Р О Г Р А М М А

Ахиллес

<Закашлялся> Программа? Конечно, она получается, но <говорит медленно как с ребенком> без диаграмм как же разработчики узнают, что им кодировать?

Черепах

Не говорите со мной свысока, Ахиллес, Вы, может быть, и самый лучший атлет в Греции, но это не извиняет дурные манеры!

Ахиллес

Как же я могу не разговаривать с Вами свысока - Вы же всего один локоть в высоту!

Черепах

<Глядит мрачно, уперев лапы в панцирь>

Ахиллес

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

Черепах

Так-то лучше. Нехорошо грубить, когда хочешь что-то узнать. Я хотел бы ответить вопросом на вопрос.

Ахиллес

Я так и знал.

Черепах

Почему?

Ахиллес

Потому что Вы всегда так делаете.

Черепах

Хм. Да, так что же Ваши разработчики делают с проекной документацией?

Ахиллес

Они ее читают.

Черепах

А потом?

Ахиллес

Потом они создают софт согласно этому дизайну.

Черепах

Действительно? Если это так просто, то зачем нам программисты?

Ахиллес

Потому что для того, чтобы понять дизайн и воплотить его в коде, нужна голова.

Черепах

То есть, они должны понять дизайн перед тем, как начать кодировать.

Ахиллес

Ну конечно.

Черепах

Ну это и есть ответ на Ваш вопрос.

Ахиллес

Ваши разработчики понимают дизайн, и поэтому им не нужна документация?

Черепах

Точно. Теперь-то Вы поняли.

Ахиллес

Постойте-постойте, не все так просто. Как к ним приходит понимание дизайна? Кто , собственно, занимается проектированием?

Черепах

Разработчики понимают дизайн, потому что сами его придумывают.

Ахиллес

<Думает и отвечает медленно, но не педантично> Хорошо, если разработчики сами занимаются дизайном, то им не нужны никакие диаграммы для общения самим с собой.

Черепах

Точно.

Ахиллес

Но есть проблема.

Черепах

Неужели?

Ахиллес

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

Черепах

А как вы думаете, можно ли этого избежать?

Ахиллес

Ну, система должна быть достаточно простой, чтобы ее понимал один человек.

Черепах

И Вы опять правы! Мы делаем систему маленькой. Каждый раз мы добавляем в нее небольшие кусочки функциональности, так что наш дизайн остается простым.

Ахиллес

Но ведь вся система не простая, вы можете кодировать маленькими кусочками, но вам же все равно надо сначала иметь дизайн всей системы.

Черепах

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

Ахиллес

Но вы не можете проектировать систему после того, как она построена.

Черепах

Нет, но можно проектировать в процессе построения.

Ахиллес

Как же?

Черепах

Рабочие задачи очень маленькие, обычно не больше, чем на пару часов работы. Такими небольшими задачами легко управлять, особенно если над ними работают сразу два человека. Когда разработчики пишут код, они по ходу дела обдумывают и обсуждают как и что сделать.

Ахиллес

И это деятельность по дизайну - вы немного проектируете, немного кодируете? Это как итеративная разработка, но в гораздо меньшем масштабе.

Черепах

Да, помимо всего прочего.

Ахиллес

Чего прочего?

Черепах

Как только они придумывают, как реализовать фичу, они начинают писать тест для фичи и запускают его.

Ахиллес

Но ведь без этой наличия самой фичи тест не пройдет. Не глупо ли тестировать то, что точно не будет работать?

Черепах

Вовсе нет, просто мы так работаем. Мы не пишем никакого рабочего кода, пока у нас нет неработающего теста.

Ахиллес

То есть вы не пишете код - вы пишете тесты, а потом исправляете ошибки?

Черепах

Именно. Мы тестируем, фиксим по маленькому тесту за раз. Часто мы обнаруживаем, что тесты уводят нас не в том направлении, которое мы намечали в наших маленьких дизайн-сессиях, но это нормально, мы позволяем тестам и коду вести нас туда, куда нужно. Мы называем это Test First Design.

Ахиллес

Но ведь после этого весь ваш код превращается в полную кашу?

Черепах

Мог бы, если бы не финальная часть нашей стратегии.

Ахиллес

Финальная часть? Продолжайте, похоже, и тут я вас не уел.

Черепах

Мы начинаем писать тест, потом пишем код так, чтобы тест проходил. Как Вы очень правильно заметили, это может привести к полной неразберихе, так что мы идем к лекарю.

Ахиллес

Что-что вы делаете?

Черепах

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

Ахиллес

Если бы не вы, я никогда бы не догадался. Спасибо, мне нельзя терять вторую пятку.

Черепах

Всегда пожалуйста. Так на чем мы остановились?

Ахиллес

На лекаре для кода.

Черепах

Да, точно. Мы несем код к лекарю. Мы рефакторим его. Вы знаете, кто-то однажды назвал рефакторинг самой мощной концепцией, появившейся за последние две тысячи лет?

Ахиллес

И это так?

Черепах

Очень может быть.

Ахиллес

Тогда расскажите мне об этом поподробнее.

Черепах

Рефакторинг удаляет зловонные раны, которые оставляет в системе новый код. Следуя нескольким хорошо известным правилам, можно уменьшить дублирование кода в системе и улучшить модульность. Это очень желательные характеристики.

Ахиллес

Желательные характеристики - да, но это ли хороший дизайн?

Черепах

Ну если хороший дизайн - это тот, который приносит желательные характеристики - тогда то, что имеет желательные характеристики, и есть хороший дизайн, не так ли?

Ахиллес

Нет... То есть да, то есть я не знаю...

Черепах

Недавно группа лучших на свете инженеров-программистов устроила дебаты на тему "Что такое хороший дизайн", и знаете, какой был результат?

Ахиллес

Не знаю, но представляю себе какой глубокомысленный и технически обоснованный ответ они дали.

Черепах

На самом деле, лучшее, до чего они додумались - "Хороший дизайн это тот, который не отстойный".

Ахиллес

Что?

Черепах

Ну опять, эти выкрики становятся скучны. Я попрошу автора вложить более осмысленные слова в Ваши уста.

Ахиллес

Ну я хотел сказать "Это правда?". Неужели эти светила не могли придумать ничего лучше?

Черепах

Нет, проблема в том, что контекст был слишком обширный. Большинство этих людей понимало, что такое хороший дизайн, когда они его видят, но контекст был слишком большой, чтобы дать какой-нибудь подробный ответ.

Ахиллес

Ну а нам-то как это помогает. И помогает ли?

Черепах

Это помогает понять, что на вопрос "Хороший ли это дизайн?" нужно отвечать "Му!"

Ахиллес

А, дзэнский коан! Бессмысленный вопрос, на который нужно найти единственно правильный ответ.

Черепах

Вы делаете успехи.

Ахиллес

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

Черепах

Точно.

Ахиллес

Все, что мы можем сказать, это то, что в результате рефакторинга мы получаем дизайн с желаемыми характеристиками.

Черепах

Опять верно.

Ахиллес

Я тащусь!

Черепах

А мне всегда казалось, что Вы весьма скоры на ногу.

Ахиллес

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

Черепах

Элементарно. Они его не понимают.

Ахиллес

Но если они его не понимают, кто же управляет им?

Черепах

Код системы.

Ахиллес

Я ничего не понимаю.

Черепах

Рефакторинг направляется " вонючим кодом", то есть кодом который имеет элементы плохого дизайна. Помните, мы не знаем, какой дизайн плохой, а какой хороший, но мы всегда можем отличить их, когда видим. Когда мы видим ужасный код мы говорим что он "воняет", когда мы видим код, который не так ужасен, но все равно нехорош, мы говорим что он "плохо пахнет" (мы же не хотим смешать эти два понятия).

Ахиллес

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

Черепах

Элементарно. Они его не знают.

Ахиллес

Но как это работает?

Черепах

Каждый разработчик знает всю систему в общем. Кроме того, каждый разработчик хорошо знает ту часть, над которой он работает.

Ахиллес

Но что если Вам требуется работать над частью кода, о которой у Вас нет детального представления?

Черепах

А что Вы делаете, если у Вас нет документации и Вам приходится работать над незнакомым кодом?

Ахиллес

Не знаю. Возможно, попрошу помощи у других?

Черепах

Точно, именно это мы и делаем - просим помочь. Разработчик, который может помочь, подходит и помогает нам. Он работает с нами в паре, пока мы не накопим достаточно знаний, чтобы двигаться самим, или пока дело не будет сделано.

Ахиллес

Но ведь это будет мешать работе того разработчика - назовем его Б. Не будеть ли это мешать работе Б?

Черепах

Будет.

Ахиллес

Но ведь тогда они свою работу не сделают.

Черепах

Почему?

Ахиллес

Потому что они проведут все время с разработчиком, которому нужна помощь, назовем его А.

Черепах

Но если ему будут помогать, то А закончит работу быстрее, и время, которое потерял Б, будет в конце концов компенсировано.

Ахиллес

Я приму Ваши доводы, потому что я пока не хочу вдаваться в детали парного программирования.

Черепах

Хорошо, ибо вы бы сами стали защищать его в конце дискуссии.

Ахиллес

Итак, я вижу, что вы действительно занимаетесь дизайном, и что ваш софт хорошо спроектирован.

Черепах

Имеет желаемые характеристики.

Ахиллес

Да, все равно... Вы занимаетесь дизайном и ваши программы хорошо спроектированы.

Черепах

Да, и, похоже, Вы получили ответ на Ваш вопрос - предполагает ли XP дизайн? Предполагает и очень даже неплохой.

Ахиллес

Есть ли какие-нибудь достоинства у этого подхода?

Черепах

Целая куча, представьте себе шестимесячный проект который прервали после трех месяцев работы.

Ахиллес

Я видел несколько таких.

Черепах

Я тоже. Расскажите о самом последнем.

Ахиллес

Мы собрали требования и только что успели закончить дизайн. Мы сделали бОльшую часть инфраструктуры, но все пришлось выбросить.

Черепах

А бизнес (заказчик) получил от этого какую-нибудь пользу?

Ахиллес

Ну, мы все получили опыт, а когда стали жаловаться, то нам посоветовали воспринимать это как обучение и новый опыт.

Черепах

По определению, обучение - это опыт, в результате которого появляется постоянное изменение поведения. Что-нибудь изменилось в Вашем следующем проекте?

Ахиллес

Не хотите ли Вы сказать, что мы ничему не научились?

Черепах

Нет, я просто задал вопрос.

Ахиллес

Хорошо.

Черепах

Ну и?

Ахиллес

Ну и - что?

Черепах

Научились ли вы чему-нибудь?

Ахиллес

Научились!

Черепах

Стали ли Вы действовать по-иному?

Ахиллес

Нет.

Черепах

Научились ли вы чему-нибудь?

Ахиллес

Нет.

Черепах

Ну вот - это не так-то и сложно.

Ахиллес

Я полагаю при XP все было бы по-другому?

Черепах

А вы как думаете?

Ахиллес

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

Черепах

Может быть в первую же неделю.

Ахиллес

И поскольку вы кодировали бы бизнес-функциональность, а не инфраструктуру, то вы бы произвели продукт, который имел бы пользу для бизнеса. Как скоро вы бы могли сделать это?

Черепах

Не более чем через три недели, обычно через неделю или две, но начальные итерации идут медленнее, потому что надо вьезжать в новый проект.

Ахиллес

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

Черепах

Да.

Ахиллес

И благодаря революционной технологии эта система была бы хорошо спроектирована.

Черепах

Я бы убрал "Р".

Ахиллес

Не понял.

Черепах

Не Революционной а Эволюционной.

Ахиллес

Да какая разница...

Черепах

Дизайн развивается соответственно с потребностями бизнеса.

Ахиллес

Хорошо, Вы быстро выпускаете хорошо спроектированную систему и, полагаю, тесты делают ее достаточно качественной.

Черепах

Тесты помогают, но у нас есть другие средства, которые тоже помогают.

Ахиллес

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

Черепах

Именно.

Ахиллес

Звучит неплохо, что я могу еще почитать об XP?

Итак, наши персонажи медленно продолжают свое шествие по дороге истории, первые разработчики ПО, вкусившие ХР (а Кент Бек еще утверждает, что это он все придумал, хехе).

Обсудить

Публикуется с разрешения Рона Джеффриза и Брайана Доллери. Copyright © 1999-2002, Ronald E Jeffries