vit_r (vit_r) wrote,
vit_r
vit_r

  • Mood:

Про ёжика в тумане, зазнайство, языки программирования и вериги

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

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

Про то, как победила дружба, а люди стали рабами машин





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

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

- Если бы Ява не победила Смолток.
- Если бы Ява не украла веб у Оберона 2.
- Если бы не впал в немилость Лисп.
- Если бы GNU (в котором выбор и направление развития определяются силой крика) не победил BSD
- Если бы Sun вовремя открыл исходные коды Solaris
- Если бы в своё время Unix не выжил VMS
...

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

- День, когда представители ИБМ пошли покупать операционную систему у автора CP/M, который в это время летал на собственном самолёте и не смогли с ними встретиться, в результате чего тем пришлось обращаться к Билли Гейтсу.
- Приказ центрального офиса ИБМ немецкому отделению придержать продажи OS/2 и пропустить вперёд Windows 95.
- Решение заменить технократов в руководстве Псиона на эффективных менеджеров.

День, когда объектно-ориентированной парадигме был нанесён сокрушающий удар можно привязать к календарю. 25 сентября 1997 года OA&D Task Force в результате голосования рекомендовала OMG принять UML в качестве стандарта. Над рождающимся новым перспективным подходом к программированию разлилась тьма.

Что мы видим сейчас, через 15 лет после «унификации»?

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

Я не буду писать, что я думаю по поводу многоуровневой метамодели, поддержки разными тулами, замечательного XML языка для переноса и новомодной Model Driven Architecture. Как указано выше, у меня есть что сказать, но я воздержусь. Этот пост о вещах более банальных, так что ограничусь вопросом «нафига это вообще нужно?»

Первая и главная задача любой модели - объяснять. Объяснять сложные и запутанные вещи для людей не знающих и не причастных.

Что предлагает Унифицированный Язык? Правильно, сертификацию.

Для того, чтобы понять (я уже не говорю о рисовании или нащёлкивании в каком-нибудь туле) рекомендуется прочитать толстые книжки и сдать экзамен. Ещё раз: для того, чтобы инженеры-механики, продавцы, финансисты и менеджеры могли общаться с ИТ отделом, им предлагается выучить нечто, для них по полезности и логичности равное египетским иероглифам. Есть у них на это время, я уже не говорю про желание? Вот то-то и оно.

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

С другой стороны, когда менеджеры и продавцы разговаривают между собой, им нужны какие-то картинки. И они их делают. В меру своих сил и понимания. В PowerPoint и Viso. Получается на порядок понятнее и нагляднее, чем у программистов, благо эстетическое чутьё и желание быть понятыми развито у них на порядок лучше. Обычно это не совсем соответствует реальности и реализуемости, но чаще всего хорошо видно, что люди хотят и что им нужно.

Программисты, не осчастливленные сертификатом и не имеющие доступа к супер-тулам, тоже делают что-то более-менее понятное. По крайней мере, у меня ещё ни разу не было проблем с их рисунками, насколько бы оригинальны и нестандартны одни не были.

Короче, всё хорошо, пока картинки не попадают в руки сертефицированных.

О! Что тут начинается... И стрелочки не того типа, и прямоугольнички не однотонные, а раскрашены, и стереотип типа не указан... Короче, картинка, попав к ним в лапы, избавляется от пары мелких ляпов и приобретает прописанное по стандарту уродство. А софтверный архитект тыкается часами в менюшках супер-унифицированно-модельного тула, решая важный вопрос, сделать ли переменную для номера текущего месяца int или long?

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

Но это ещё не самое весёлое.

SysML overmodelling Когда сертифицированные захватывают власть и получают бюджет для... Ладно, официально это называется Дизайн Системы. Сначала хотел сказать про самоудовлетворение посредством общения с UML-тулами, но это уже тема психологическая, проблемная и достаточно опасная для тонкой душевной организации сертифицированных. Хотя, результаты практически всегда соответствуют... да, совсем не тому названию, что официально.

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

Я прекрасно знаю, что нажатием кнопочки крутой тул извлекает из своих недр информацию и генерирует «документацию», которую можно даже вывести в привычный менеджерскому взгляду Ворд. Но, первым делом, это настолько замусорено совершенно ненужными подробностями и испахаблено форматированием, что становится практически не читаемо. А во-вторых, сертифицированные при генерации банально не удосуживаются щёлкнуть на паре малоприметных чекбоксов. (Не забываем, у кого граната.) В результате умные тексты, запрятанные в недрах тула, просто не выводятся. Страниц много, слов до дури, таблица на таблицу налезает, а смысл фиг найдёшь.

Вторая задача модели - помочь думать. В идеальном случае - помочь думать коллективно.

Что в этом плане предлагает унифицированный язык?

О! Он предлагает много: long или int? private или protected? стереотип или нет, а если да, то какой из ста? Короче, с думаньем прекрасно. Только в этом случае думать не помогают, а заставляют. Причём, совсем не о том, о чём нужно.

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

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

Человек достаточно слабая система. Память ограничена. Зона внимания ограничена. Цели и задачи могут смещаться в процессе выполнения... В принципе, сертифицированные не виноваты в том, что у них получается. Просто человеческое несовершенство умножается на запутанность процесса. Они не идиоты, просто их так научили.

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

Тут даже говорить ничего не хочется. Всё, что есть, создано не благодаря, а вопреки.

В результате процесс использования Унифицированного проходит в три стадии.

На первой все сертифицированные активно... Ну да, это самое с тулами. Диалоги в тулах активно заполняются, создаётся масса диаграммок, собираются митинги, проводятся ревью... Так как людей, могущих делать что-то реальное, всегда не хватает, на этот процесс бросаются практиканты, доктора компьютерных наук и прочий сброд, не имеющий ни практического опыта, ни практической пользы.

На менеджерском языке это называется Фазой Дизайна. Отчитываются по ней по объёмам произведённого бреда и практически не бывает случаев, когда ляпы, ошибки и недоработки во всех этих картинках и генерируемых многословных текстах задержали бы общий процесс.

На втором этапе уже более-менее полезные люди начинают переводить результат Фазы Дизайна в код, после чего выясняется, что разрисованные на диаграмках идейки немного не работают. (То «немного», что от слова «нихера».) По науке всё должно возвращаться обратно Архитекторам и Дизайнерам, чтобы они исправили и довели до ума. Естественно, этого никто не делает. Даже не потому, что смысла нет, просто по плану этап завершён, а сроки поджимают. Так что, все просто плюют на высокие материи и начинают делать то, что считают нужным. Или реализуют нарисованное без изменений, если они индусы и им абсолютно наплевать, будет ли работать результат. Правда, потом из отдела тестирования на головы разработчикам бурным потоком начинают литься сообщения об ошибках, так что переход к реальности всё равно совершается, но это в менеджеркских отчётах уже называется Тестирование и Доработка, на что бюджет выделяется в размере текущих расходов. То есть, практически бесконечно.

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

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

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

Кстати, agile - это совершенно не противопоставление стандартным процессам. Просто обезьянки прекращают изображать профессоров математики в водопаде, спирали или фау-модели и начинают делать то, что делать в состоянии, называя это хоть и забавными именами, но всё-таки более близкими к реальности.

Ладно. Пора подвести черту. На балансе у нас жопа. Причём, в приказном порядке прописанная для всех более-менее существенных проектов.

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

А между тем, к финишу рядом с поделкой трёх амиго шли очень интересные методологии: Shlaer-Mellor и OML.

Если бы победил Shlaer-Mellor...

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

Конечно, это если мозги есть. Без них - жестокий отсев. Потому что вопрос «Как называется эта стрелочка?» - это совсем не то, что безжалостное «Как сделать это?»

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

Зато...

Зато описание мира в конечных автоматах - это очень мощная техника. Сделать декомпозицию и построить модель - сложно. Но потом любой технический специалист без проблем поймёт, о чём речь, и что происходит. А таблицы переходов можно обсуждать даже с отделом маркетинга. И, как я уже писал, именно таблицы переходов позволяют получить полное описание системы, что просто не даёт возможности производить дырявый софт.

Кстати, производители многих тулов сразу после внедрения Унифицированного, эти самые таблицы убрали. Потому что все варианты лежат на ладони и нельзя смухлевать, забыв половину условий.

Ещё, помнится, в ньюсгруппу по объектам пришёл некий гуру Б. и спросил, что такое архитектура? А то гении из Рационаля делают Унифицированный Процесс и не смогли сойтись по этому вопросу. Было много ответов, заумных, резонных и не очень. И только один человек написал коротко и банально, что архитектура - это просто декомпозиция системы на домены верхнего уровня по Шлейер-Меллору.

Самое печальное, что это абсолютная правда. То, что у сертифицированных идёт в разделе высокой философии, для Шлейер-Меллора является просто чёткой последовательностью технических решений.

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

Да, там были проблемы, были вопросы насчёт стыковки с реальным миром, много что было не оптимально... Однако, если бы сотая часть тех сил, что ушли на оживление Универсального, была бы пущена на то, чтобы модернизировать Шлейер-Меллора и распространить его из встроенных систем на бизнес-приложения, мы бы сейчас жили совсем в другом мире.

Но не судьба. Исковерканные потомки под именами xUML и xtUML ещё мелькают на задворках индустрии, но молодые постдоки, опять изобретающие велосипед с квадратными колёсами, уже не знают о том, что всё уже давно делалось проще, лучше и надёжнее. Даже название мало кто из них слышал.

Если бы выжил OML...

Ха. Думаю, никто и не помнит, что это такое.

OML - это OPEN Modeling Language. В свою очередь, OPEN - это Object-oriented Process, Environment and Notation.

Да. Это именно то, что написано. Если я что-то понимаю в объектно-ориентированной парадигме, это кроме Шлейер и Меллора благодаря Brian Henderson-Sellers и немного Donald Firesmith.

У них есть дикий, совершенно ужасный недостаток - они не проповедники, а учёные. Читать, что они писали, было сложно. Нужно было понимать и думать. OPEN - это не компромиссы и уловки, а попытка создать цельную логичную систему. OPEN Process Framevork - это конструктор, позволяющий строить процесс под задачу. Именно тот и с теми характеристиками, которые нужны. Хочешь - лёгкий и быстрый, хочешь - полновесный со всеми отчётами, танцами и поклонами. Но в отличии от того, что мы видим сегодня, это всё могло работать. Потому что не втискивалось в шаблон, а строилось на здоровом фундаменте.

OML тоже был сыроват. Конечно, не настолько, как поделка трёх амиго, но для внедрения в массы его следовало ещё отполировать, немного упростить и объяснить человеческим языком. Что можно было бы достаточно легко и быстро сделать, если бы это пятнадцать лет назад не потеряло бы смысл.

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

Если Шлейер-Меллор был техническим языком моделирования, то OML с полным правом можно считать гуманистическим. В нём больше теории, нельзя протестировать функциональность на модели или скомпилировать из неё полноценный код. Зато были все задатки для того, чтобы создать язык общения, лёгкий, понятный и выразительный. Настоящий язык для анализа и моделирования, который помогает и поддерживает, а не путается под ногами.

Но... Но к финишной черте три амиго пришли не с пустыми руками.

- Посмотрите, - сказали они. - Нам не нужны всякие графические извращения. Никаких сложных фигур. Никаких стрелочек с украшениями. Никакой головоломки со сквозной интеграцией и проекциями модели в разные виды представления. Никакого тестирования. Никакой компиляции. Просто рисуем прямоугльнички и линии со стрелочками. Все особенности - через текст. Все логические связи и зависимости - не обязательны. Не надо, чтобы пользователь с первого взгляда понимал характер отношений. Просто нарисуем звёздочку, цифру или букву, а он пусть сам разбирается. И не надо задавать правила. Как пользователь хочет, пусть так рисует. Кстати, тул, что это может, у нас уже есть. И за ним стоит фирма Рейшенал. А за ней - Майкрософт. Так что откиньте все заумные теории и берите то, что проще будет продавать.

Если знать, кто входит в OMG, совершенно понятно, почему пятнадцать лет назад истрия пошла по такому пути.

А потом ещё долго люди спрашивали, зачем нужны диаграммы Y, если есть тип X, тоже входящий, или аналогичный Z из структурного подхода, позволяющие всё то же самое показать нагляднее и проще? Остепенённые преподаватели и проповедники несли чушь. И только редкие практики, немного знающие внутреннюю кухню, тихо и не для прессы объясняли: когда призвали третьего амиго, его вклад получался довольно бледным на фоне первых двух. Чтоб не обижать и равноправно вписать его имя на обложку, в результат был добавлен Y, который остаётся там по сию пору, но практической пользы почти не имеет.
Tags: agile, it, management, motivation, psychology, quality, ru, trends
Subscribe
  • 99 comments
  • 99 comments

Comments for this post were locked by the author