Сценарии или свойства?
Кейсы и сценарии не единственный подход проектирования. И точно не панацея. Можно иначе. Есть инструменты, для которых кейсы не важны, а важно другое.
Так получилось, что последние 20 лет народ массово увлекается в проектировании сценариями. Кейсы, акторы, вот такой вот чувак от жизни хочет вот этого — а мы ему даем инструментину, которая ровно это делает.
Не безнадежно, потенциал есть. Чего таить, я сам 15+ лет топил за сценарии, «пишите кейсы, твари ленивые» и всё такое прочее. Потому что если рукожопие и кризис, кейсы это то, с чего вы начнёте. Возможно, ими же и закончите.
Методика проблему решает, решение даёт — чего еще тебе надо, собака.
Но штука не единственная. Есть другие, и вот конкретно другая. Поехали пример.
У вас задача бизнесовая стоит: механизм, чтобы (на)писать вот такие бизнесовые документы. Приходите вы как инженер-проектировщик, начинаете курить кейсы. Вот такие документы — вот такие акторы — вот такие данные — вот такие цепочки и бизнес-процессы — и в общем-то дальше понятно. Так множество систем рождаются. Документо-ориентированных. Успешных, я подчеркиваю; упаси боже сказать, что плохо — нет, это не так. Задача решается, и решается красиво. Оговорок и сарказма нет, всё честно.
А вот другой подход: вместо кейсов вы даете инструмент. Ручку шариковую. Можно ею написать документ? Очевидно да, бери пиши. Будет работать? Куда оно денется, веками так происходило. Чтобы совсем не скатываться в идиотизм примера, выдумаем к этому формочки, правила, цепочки — и мы получили решение задачи, тоже. Минусы у него есть. Но… что с плюсами?
Нас во втором случае не настолько волновали кейсы.
Инструмент — шариковая ручка. У нее есть свойства, они жестко заданы ее устройством.
А вот сценарии как раз жестко не заданы. К нашим обозначенным задачам инструментик подходит, этого достаточно.
Свойств у инструментика есть, в количестве. Может писать, может не писать. Может писать что-то умное, может глупое. Может показывать статус владельца и на столе стоять. Может пиво открывать, если жесткость позволит. Можно в глаз недругу воткнуть. Можно топливные шланги прочищать. Можно коллекционировать. Можно перепродать, туземцам за бусы. Можно в носу ковырять, себе, соседу. Можно вместе с матом и изолентой починить космический корабль. Где пригодится — там и пригодится.
И выше перечисленное явно покрывает (может покрывать) какой-то ненормально широкий набор кейсов, если вы рискнете заморочиться их описывать.
То есть, применимость инструмента описывается его свойствами, как физического предмета в данном случае. Набор кейсов вторичен.
Поменяется задача, поменяются кейсы — вы все еще сможете написать шариковой ручкой любой документ. Даже тот, который вы пока не придумали. Поведение инструмента не изменится.
С чисто инженерной точки зрения, широта свойств и потенциальная применимость — плюс. Жирный плюс. Если экстраполировать, под неизвестную заранее задачу лучше иметь неидеальный, но все-таки мульти-тул в кармане, чем узкозаточенную крутую систему, которая становится моментально бесполезна для всего остального, для чего она не проектировалась.
Об этом явлении и феномене рекомендую задуматься, минут на пять. Шариковую ручку никто не проектировал, чтобы намеренно прочищать ей сортир, отбиваться от врагов или (о, ужас) писать шекспировские сонеты. Она просто всё это может, в силу каких-то своих свойств. Не нравится чистить сортир паркером, ну возьми что-то поудобнее. Или не возьми, если под рукой только это — в моменте, дорога ложка к обеду. Или ручка к сортиру.
Так вот: подход построения универсальных инструментов — он тоже есть, он не безнадежен, и тоже в чем-то неплох. В первую очередь как показывает нам пример — когда мы не знаем конкретные задачи, а можем только предположить их общий класс.
Корректно вспомнить unix way в этой связи: вот тебе ворох весьма разнообразных инструментов, каждый из которых имеет какие-то свойства, и что-то своё может. Понятное заранее, и даже описанное. Собирай из этого балагана и винегрета всё, что заблагорассудится. Не получится — допиши недостающее, мелкое и конкретное. Если куда-то еще пригодится, окей, все порадуются.
Достаточно наивно было бы пытаться описать «все кейсы» использования Экселя, гугло-таблиц. Они просто могут то, что могут; делают то, что делают. Хочешь, считай мировую экономику, хочешь — конфеты в банке, хочешь Doom в браузере рисуй. Таблицам пофиг. Авторам тоже.
И я отмечу, что делают они свои задачи хорошо. Как минимум, предсказуемо. Это всё, что в данном моменте от них требуется. Походящесть экселя под расчет мировой экономики, и под соответствующий набор сценариев, никто заведомо не проектировал и не гарантировал: эта возможность органически следует из их заявленных (и проверяемых) свойств: считать арифметику.
Страницы блокнота пусты; ты волен писать там шедевр, но волен также писать там чепуху или ложь, или даже вырвать их.
Что в универсальном инструментарии потенциально хорошо: знание о нем, и навыки работы — также универсальны. Этим можно пользоваться; на этом, например, выехал Apple с тотальной жесточайшей стандартизацией UX на мобиле. Пока не наплодили бардака с 2015. Мне не нужно знать, что там накодили в конкретном случае очередные укуренные индусы; я точно знаю, как у них внутри экосистемы будет выполнена работа с текстом, контекст задач (приложуха), тапы-скроллы и прочая мишура.
Если в линуксе «всё файл», мне достаточно инструментов работы с файлами. Если под виндой есть папки-каталоги-окошки, я справедливо жду что меня этих инструментов не лишат без жестокой необходимости — а если такое произойдет, я справедливо спрошу «а какого хрена?» мне и миллионам юзеров повышают порог входа -всяким говно-креативом там, где без этого можно обойтись. К всеобщей пользе.
Да, одно решение придется вписывать в ограничения, и оно может пострадать. Вся масса инструментов (и их пользователей) заведомо выигрывает.
Сюда попадают наборы инструментов (toolkit) — раз. Если ты можешь вот этим ключом открутить вот этот болт, значит ты можешь так сделать применительно к любому болту, который удовлетворяет _свойствам — не сценариям, сценарии любые, даже пока не существующие.
Сюда же попадают разнообразные песочницы — два. Есть правила и ограничения среды, «физика» взаимодействия и правила игры. Пока правила соблюдаются, реализуй там потенциально любые фантазии. Очевидно, любая бизнес-область, в смысле business domain, точно также песочница со своим DSL и правилами — аналогию дальше сами.
Где-то между примерами лежит еще набор подходов и методов типа behaviour design, aspect-driven, DDD (который про другое ащет) и аналогичные скрещивания идей.
Если вы где-то внутри себя и своих мета-задач замахиваетесь на инструментарий, для которого не до конца формализованы задачи (или даже вообще никогда не будут формализованы) — присмотритесь к проектированию на свойствах.
Сюда попадают, например, многие классы задач где звучат слова «инфраструктура» или «экосистема».
Вам надо, чтобы в меняющемся мире то, что вы собираете (проектируете) сегодня, не стало фундаментально бесполезным завтра.
Идеальность не получится, но за полезность можно побороться.
Всё еще занудно подушню, что писать «универсальные конструкторы» под конкретную конечную задачу — обычно, плохо. Дорого энд глупо.
Это не отменяет факта, что не все задачи заранее понятны и конечны; вот там надо покурить вопрос.