"Отзывчивый" - в данной ситуации означает "изменяющийся в зависимости от окружающих реалий".
Предлагаю вниманию свой взгляд с иллюстрациями на сущность «отзывчивого», развиваемого дизайна. Меня заинтересовал конспект лекции об «отзывчивом дизайне», поскольку текущая наша разработка идёт именно в таком ключе — функционал добавляется понемногу, в процессе уточнения и переосмысления задач, без революций, с хорошим пренебрежением к академической идеальности и законченности, которой в процессе развития просто не имеет права быть. Это по-своему замечательно — пренебрегать правилами валидности (они — для будущего), кроссбраузерности (функционал есть, но отображается в IE c долей снисхождения) и концептуальности до момента, пока функционал системы не определён. Она имеет только те куски «мяса», которые работают, отработавшие куски постепенно удаляются. Именно это описывает Кент Бек в своей лекции, поэтому так живы и богаты ассоциации с его классификацией о четырёх стратегиях.Для справки, Кент Бек — автор книги
«Экстремальное программирование. Разработка через тестирование»
и других из области ЭП. Описанная лекция
опукбликована в crazysage.diary.ru/p66324356.htm
и в crazysage.habrahabr.ru/blog/95906, а прочитана около года назад.
(Слова Бека (из конспекта лекции) далее выделены в цитаты, а свои примечания в цитатах — другим цветом.)
Исходный дизайн проекта.
Он представляет собой далеко не идеальную конструкцию, которая, тем не менее, исполняет требуемую заказчиком функцию и пользуется спросом, за неимением более совершенных на данный момент.
Изучение дизайна интроспективно (доступно для самоизучения), эмпирично (подпитывается опытом, строится на нём) и квантитативно (ещё одно умное слово автора, т.е. "способно быть измеренным").
Дизайн — так себе, но учтите, что до сих пор никто ничего подобного не видел, это же каменный век! Все отлично понимают, что итоговый дизайн будет другим. Просто работать оно должно уже сейчас, знаний, технологий и материалов было достаточно, устройство прошло все критические тесты — спуск с горы, падение в реку, перевоз статуи божества с шаманскими плясками с бубном. (Вспомним, что важная составляющая экстремального программирования — Test driven development.)
Дизайн - это набор полезных связанных (бревно, колесо) элементов или полезно связанных (верёвка, бронзовые гвозди) элементов.
Тем не менее, вырожденный случай, когда вместо одного проекта возникает другой — это рабочая стратегия, одна из четырёх, названная "Опорный камень" и имеет смысл поддержки, ускорения общей работы через построение для неё некоторой «опоры».
Применяется если:
* Не знаем, как это делать (никогда не работали в этом фреймворке);
* Знаем, что можно сделать, чтобы упростить решение задачи (научимся в нём работать - дело пойдёт быстрее).
Тогда:
* Строим дополнительный проект, с помощью которого будет проще достичь цели (научиться работать в фреймворке).
(плюс): Получение компонентов, которые потом можно использовать в других проектах (капроновая верёвка, титановые гвозди);
(минус): Большое количество лишней работы (для нас не лишняя, мы прокачиваем скиллы);
(минус): Отсутствие обратной связи на данном этапе (взлетит - не взлетит?).Исходные предпосылки
Дизайн программного обеспечения фрактален: проектирование связи двух объектов (связка частей одной верёвки) не сильно отличается от проектирования связи двух систем (связка двух смежных брёвен).
Продвигаться надо безопасными шагами — внесение одного изменения не должно приводить к поломкам в десяти местах.
Перед тем, как изменить что-либо, надо изолировать этот кусок и встроить обратно, если все будет успешно. Цель разработки — непрерывный поток функционала.Дизайн должен быть таким, чтобы новый функционал можно было добавлять прямым путем, а не хитро закрученным.Если решение проблемы полностью известно, то отзывчивость дизайна не столь обязательна. Требуется она в следующих случаях:
* Неизвестно, как что-то сделать (например, в новом фреймворке);
* Известно как, но не хватает ресурсов (другими словами, вытащить деньги у заказчика по частям, чтоб не так заметно было);
* Известно как, ресурсы есть, но остальная команда не понимает этого варианта (да, "под шумок" можно всем доказать, что "она вертится").
Делая безопасные шаги, надо балансировать следующими параметрами:
* Эффективность (показывать результаты в итерации);
* Риск (величина шага зависит от вероятности провала);
* Отзывы (пиар любых результатов (особенно, если их нет));
* Командная работа (вовремя перехватить идею изобретения правильного колеса).Стратегии
Прыжок
Суть — в объединении этапов проектирования в один, если путь очевиден. Метод хорош в строительстве проверенных объектов (ловчие ямы, пещеры), но рискован в разработках.
Применяется если:
* Знаем, как это делать;
* Уверены, что сможем безопасно сделать и встроить этот вариант.
Тогда:
* Выполняем несколько действий одним шагом.
(плюс): выше эффективность;
(минус): выше риск.
Параллельность
Осторожная стратегия. Различие между следующим пунктом: «Опорный камень» — там и тут — параллельная разработка, но здесь мы дублируем функционал и переносим его по частям, а там строится нечто типа «Большого Прыжка», а функционал запускается заново.
Применяется если:
* Знаем как это делать;
* Не уверены, что сможем безопасно сделать и встроить.
Тогда:
* Временно поддерживаем оба варианта дизайна, постепенно перенося функционал из старого в новый.
(плюс): Безопасность;
(минус): Очень много дополнительной побочной работы.
Теперь, когда убедимся, что квадратные колёса работают не хуже треугольных (это далеко не факт), аккуратно снимаем треугольные, оставляем их в качестве obsolete-функций в проекте, далее пользуемся квадратными.
Опорный камень
(Рассматривали пример выше — вертолёт. Надо добавить, что суть стратегии — в изготовлении в части проекта того самого «опорного камня» — инструмента (библиотека), опалубки (фреймворк), связующих материалов (интерфейс). Вертолёт, как упоминалось — вырожденный случай полной замены проекта на другой, когда речь стоит вести уже о другом проекте.)
Упрощение
Применяется если:
* Не знаем, как это делать (как построить телегу);
* Нет ресурсов на выполнение всей задачи (ни верёвки, ни гвоздей, каменный век на дворе);
Тогда:
* Выбрасываем требования, пока задача не будет решаться в один безопасный шаг (демонтируем мешающие простому решению конструкции, например, меняем когда-то придуманные устаревшие внутренние интерфейсы, или отказываемся от каркаса из брёвен, чтобы перейти на доски);
* Постепенно восстанавливаем требования к проекту (колесо, каркас, телега, вертолёт).
(плюс): можно применять почти всегда (почти всегда безопасно ставить отступ в начале строки);
(плюс): Развивает инициативу (и превращает робкость в осторожность);
(минус): Нелинейная стоимость в зависимости от порядка восстановления требований (точнее, различная стоимость в зависимости от продуманности нового построения).
Или современный пример: иногда проще перенести данные между компьютерами на флеш-носителе, чем устанавливать WiFi- или LAN-соединение. Или если говорить про дизайн проектов, то тут под упрощением понимается грамотное построение архитектуры проекта, которую иногда удобнее переделывать, разобрав некоторые прежние нагромождения решений.
Дополнительное замечание
Если не можешь добавить функционал прямым [архитектурно грамотным, простым] путем:
* Делай, как получится;
* Будь готов заплатить цену этого решения позже (демонтировать часть проекта, чтобы установить что-то новое тем же методом упрощения или устанавливать впоследствии на уже нагромождённое);
(скорее всего, это относится к функционалу, поставленному наспех, в нарушение норм проектирования. Т.е. под "прямым" путём подразумевается "правильный".)
Глобальную смену дизайна в любом случае оплачивают заказчики, наиболее выгодно растянуть ее на некоторое время, чтобы не сильно замедлить добавление нового функционала и не сделать каждое добавление безумно дорогим.