Не рисуйте такие слайды!

YouTube решил порекомендовать мне сегодня посмотреть ролик High level architecture design

http://www.youtube.com/watch?v=bClMoThLiwM

Ролик популярный, на момент описываемых событий он собрал более 50 тысяч просмотров. Чем же он так приглянулся зрителям? Кроме того, что автор Rob Pettit имеет великолепное резюме и достаточное количество научных работ, на мой взгляд, эта презентация содержит всё то, за что люди не любят слушать ИТ-архитекторов и ненавидят смотреть их слайды. Сразу отмечу, что содержание рассказа мне не понравилось, но цепляться сегодня я буду за форму. Итак, поехали

Слайд №2 (отметка времени 0:43) «Software Architecture» – ага, наверное, определение. Нет, не определение. Эйфелева башня. Не самая оригинальная метафора архитектуры, конечно, но всё равно красиво. Фото красивое: фронтальный вид снизу-вверх, кадр обрезан(наверное) по золотому сечению. Где расположена на слайде эта замечательная фотография? Непонятно где: прижата к нижней рамке, но сдвинута от правой границы слайда. По размеру немного не доходит до середины. Сверху обтекается текстом. Существует множество способов разместить это фото на слайде: выровнять по верхней границе текста, растянуть по высоте на весь слайд и прижать к левому краю – красиво будет, но ведь нет. Ладно, читаем текст. Не переживай дорогой зритель, через пару слайдов шрифт с засечками поменяется на шрифт без таковых, а картинки буллетов(маркеров списка)  станут более-менее одинаковыми. Да и написана, в общем-то, ерунда. Так что переходим к следующему слайду

Слайд №3 (2:19) Полтора десятка строк текста, который так и напрашивается на отображение в виде картинки: компоненты, соединения, стереотипы, пакеты, подсистемы – всё это просится быть визуализированным. А если текст всё же важен, то он легко добавляется в такую картинку в виде комментариев. Всё это было сделано еще в самой первой книжке «UML. Руководство пользователя». Двигаемся дальше. Пропускаем четвертый слайд и переходим к

Слайд № 5 (8:47) Шрифт стал без засечек и номер слайда пропал. Зато картинка, по традиции, болтается в непонятном месте.

Слайд №6 (9:21) Всё хорошо. Нумерация слайдов вернулась, маркеры списков одинаковые, можно обратить внимание на содержание, читаем: «структурирование на подсистемы основано на расположении и функционале…» Смотрим на картинку и сразу же это замечаем, нет? Диаграмма выполнена в стиле: «мы сделаем такие маленькие фигуры, чтоб текст в них наверняка не читался и такие длинные стрелки, чтоб текст рядом с ними… – всё равно не читался». Парой слайдов раньше было четко написано, что подсистемы отображаются в виде UML компонент и стереотипизируются надписью «subsystem». Увеличиваем рисунок и видим, что на каждом квадратики указан стереотип «component». Да что же такое здесь нарисовано? Два сервера, два клиента, пять интерфейсов. Вот если просто четыре из пяти интерфейсов расположить в линию, то картинка станет читаемой. Впрочем, похоже у меня появилось новое упражнение для учебного курса: сделать из этой картинки что-то понятное. Следующий слайд

Слайд №7 (11:17) Структурное представление – 2. Номер слайда опять пропал, ну ничего, привыкли уже. Зато появились новые фигурки: «packages». Красиво! Наверное, потому, что все пакеты разные по длине и ширине. И выравнены по-разному. И компоненты тоже раскачивает туда-сюда. Наверное, на интерфейсах подвешены как на нитках. Вникаем в содержание. Ух ты! Так это же компоненты с предыдущего слайда: Agent Client, Customer Client, Billing, Reservation Server. Только вот в топологии что-то поменялось. Интерфейс IViewBill подвис. Ладно, зато новые компоненты появились Customer Database и Car Database. Вот только почему слово “Database” не убрано в стереотип, ведь стереотипы примерно для того и придумали, чтоб не рисовать лишних контейнеров (здесь в виде пакетов). Но идем дальше

Слайд №8 (12:28) Deployment View. Этот слайд красноречиво показывает, что автор умеет писать комментарии, серверные компоненты развертываются на одном узле, а Customer Client взаимодействует с сервером через интернет. Уже не знаю по какому волшебному протоколу он вызывает метод IMakeReservation, но видимо 9,10 слайды как раз об этом. Смотрите какие красивые ассоциации появились на 10-м слайде (он, правда, без номера, но следует за 9-м). На некоторых даже стереотипы «use» приведены. Но настоящее потрясение ожидает нас на следующем слайде

Слайд №11 (18:19) Architecture View In Practice. Наконец-то первая нормальная диаграмма и однозначно считываемое сообщение: всё что было раньше – не нужно, для неформальных коммуникаций используются понятные картинки, такие как на этом слайде. Правда докладчик его немного пожурит и в завершении предложит еще один «привычный» слайд в качестве бонуса

Слайд 12 (19:58). Если кто не понял, это улучшенная, но неполная версия предыдущего слайда. Зачем людям разбираться в незнакомых словах, типа OSGi, Context graphs или Reasoning Engine. Зато на нашей картинке интерфейсы нарисованы и компоненты с пакетами по традиции раскачиваются на интерфейсах.

Конечно я понимаю, что подобное комментирование творчества коллег занятие не сильно почитаемое. Порой даже испытываю легкое чувство неловкости: люди старались, прикладывали усилия… Но друзья, возможно кто-то из вас в ходе подготовки очередной презентации вспомнит мои невинные комментарии. Делайте красивые слайды и выразительные диаграммы, ведь архитектура, в конечном счете, появилась как техника и мастерство выражения замыслов.

Один комментарий к “Не рисуйте такие слайды!”

  1. Здоровая критика. Особенно порадовало последнее предложение. Это надо всем помнить

Добавить комментарий для Павел Отменить ответ

Ваш адрес email не будет опубликован.