Проектирование жизни

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

Звучит эта сентенция красиво. Более того, она, вроде бы, совершенно верна. Есть только одна маленькая, незначительная проблема. На данном этапе развития цивилизации люди не в состоянии построить мета-метамодель. А законы Ньютона, Кеплера и даже, кажется, Шредингера — работают.

К чему это я?

Полнота и целесообразность.

Да, все к тому же.

Перед каждым человеком, достигшим совершеннолетия, стояло, стоит и будет стоять множество задач, требующих решения. Где купить зубную щетку, как сдать экзамен по прикладной парапсихологии, зачем делать предложение руки и сердца; «быть, иль не быть», наконец. На решение каждой из этих задач провидением, в тесном сотрудничестве со злыми духами времени и места, отведено какое-то время. Зубную щетку нужно купить обязательно сегодня, экзамен состоится через три дня, а с принятием решения по остальным пунктам можно подождать до конца месяца.

Ничего не напоминает? Ага, любой IT-проект. С единственным, но весьма существенным отличием. Постановкой задач в софтверном бизнесе занимается не мудрая природа, а м-м-м... не всегда успевающие достаточно педантично изложить суть проблемы — заказчики. Тривиальная задачка «купить зубную щетку» превращается, подчас, в устах этих, наверняка, аккуратных и компетентных во всем остальном людей, в шараду «пойди куда-нибудь, принеси что-нибудь, чтобы чисто выше шеи ниже носа в глубине».  «Вы же профессионал?» — с детской непосредственностью спрашивают они, выдают аванс, способный примирить кого-угодно с действительностью, и, сверкая запонками и булавкой для галстука, уходят. Твердо убежденные, что четче изложить требования — не смог бы и сам Господь Бог.

И вот тут необходимо (разумеется, после того, как треть аванса была конвертирована в пиво и употреблена по назначению) — поставить перед собой задачу. Выкристаллизовать из словесного, да простят меня господа заказчики, потока — четкие требования к будущему продукту. Техническое задание, по сути, должно удовлетворять всего трем характеристикам:

• Быть полным (необходимым и достаточным). Ничего лишнего, ничего в спешке позабытого.
• Четко описывать все выходные документы. А не базу данных и внешний вид формочек для ввода.
• Иметь решение. С учетом сроков, мощностей и прочей малозначимой лабуды.

Хотелось бы поподробнее остановиться на полноте постановки задачи. Приведу пример из совсем иной области. В русском биллиарде наиболее распространены два типа партий, играющихся одним шаром (битком).
В сибирской партии можно забивать как чужих шаров, так и своего. Удар выполняется без заказа. Каждый забитый шар стоит одно очко, и игра ведется до восьми.
В русской пирамиде забивать биток нельзя, а забитые шары оцениваются по их номиналу, от одного до пятнадцати. Перед каждым ударом необходимо сделать заказ — то есть объявить, какого шара каким образом планируется забить в какую лузу. Выигравшим признается тот, кто первым достиг рубежа в 71 очко.
А теперь представим себе, что перед нами стоит задача объединить эти два типа партий с целью создать еще одну разновидность. Шары должны оцениваться по номиналу, как в пирамиде; в то же время, ради увеличения зрелищности, игрокам должна быть предоставлена возможность забивать биток. Требуется определить остальные правила, а именно — сколько очков давать за забитый биток и какой результат засчитывать как победу в партии.

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

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

Еще немного занудства насчет отчетов, требуемых клиентом. Внутренняя структура базы данных, внешний вид форм для ввода данных, размер шрифта и язык реализации — это детали. Единственное, что нужно клиенту — получить возможность распечатать отчеты. Под отчетом я подразумеваю любой выходной сигнал с черного ящика, именуемого в народе вашим продуктом. Все кнопочки, менюшки, шорткатикии скрепочки в MS Word — ни что иное, как короткие тропинки к достижению единственной стоящей перед вами цели — напечатать чёртово письмо в чёртовую налоговую инспекцию. (Это не стилистический огрех, это авторизованный перевод с английского, поэтому тут два раза подряд встречается одно и то же слово.) Кнопки и пункты меню, позволяющие сделать главное окно приложения круглым, а также сама эта умопомрачительная возможность — останутся неоцененными. Да что там говорить, они останутся непонятыми. Сиречь, совершенно бесполезными.

Ну и, наконец, задача должна иметь решение. Свежая мысль, не так ли? К сожалению, очень многие известные мне проекты умирали, так и не превратившись в альфа-релиз только потому, что были грандиозны. И если бы их кто-то мог сделать, они принесли бы создателю славу, деньги и прочие блага. Только вот вместо создания пилота, умеющего обрабатывать один протокол и один тип файлов —эти монстры проектировались многопрофильными гигантами, способными распознавать неизвестные науке протоколы и сохранять данные во все, что шевелится (включая парадоксальные датабазы). И на третьем году написания поддержки двести пятого протокола кончались финансирование, энтузиазм и вера в светлое будущее.

Потому что — все гениальное — просто. Если оно масштабируемои достаточно абстрактно.

Принятие решений

Вообще говоря, идеальное техническое задание в чем-то сродни миниатюрам Микеланджело. Отсекая все лишнее, ты помогаешь обществу. Заказчика необходимо терзать вопросами: «Вы уверены, что Вам это необходимо?». Упрятать подальше собственную гордость, и любой приходящий в голову вопрос типа: «А вот хотите, мы здесь еще вот такую мулечку прикрутим?» — безжалостно инвертировать в: «А, может, еще и это убрать — чтобы операционистка не запуталась?». И настанет мир во всем мире.

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

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

Я, по крайней мере, в это верю.

Следствие: мета-мета-метамодель являет собой множество меры нуль.