Сегодня в голову пришла "крамольная" мысль. Даже жену спросил об этом.
Вот скажем как "всякие" сантехники или водопроводчики. Или токари чертежи читают.
Как?
Где их этому учат? В ПТУ вестимо.
И ничего. Читают и делают своё дело.
С разрезами, проекциями, фасками и прочими допусками.
Нам когда-то надо было сделать клапан для скороварки. Для походов. Ну пошли мы к токарю - объясняем. Он нам говорит - "чего вы на пальцах объясняете. Несите чертёж - сделаю". Так и получилось. Нарисовали чертёж. Принесли токарю. Он нам сделал, то, что нам было надо.
И ничего.
Помните, как Лев Кассиль писал про "магию людей своими руками создающими вещи"? Там правда не очень оптимистичная кульминация сюжета была. Но это - не важно....
Так как же так получается, что люди с ВЫСШИМ образованием, в основной своей массе - НЕ ГОТОВЫ читать диаграммы UML. Ведь они не СЛОЖНЕЕ, чем чертежи. Которым кстати в школе учили. Азам. А уж в ВУЗах - и подавно. По себе знаю. У меня было много подобных дисциплин. И ничего. Никто не умер.
Сколько должно времени пройти, чтобы научились? Лет 50-т?
Начинать надо со школы? ВУЗов?
Ведь UML - явно - НЕ СЛОЖНЕЕ, чем чертежи.
Или "сантехники" умнее, чем "креативный класс"?
И ведь главное - ведь УМНЫЕ люди говорят - "не хотим читать ваш UML, мы в нём ничего не понимаем".
Проблема в UML? Или в "молодости технологии"? Или в менталитете?
Не понимаю.
У меня у жены кстати заказчики - читают UML. Откуда они "такие умные" взялись - не понимаю. Много вопросов по этому поводу задавал. Ответов - пока не получил.
Или я что-то не так трактую?
P.S. Меня тут "на просторах интернета" дружно "тыкали носом". Мол "прочитайте книжки про UML". Прочитал. И перечитал. Много всяких разных. Умных и не очень. "Отбашлял" денег авторам.
Того же Лармана перечитал. И много других. В количестве 6-ти штук.
Ну что могу сказать. Да ничего.
Кроме "рекламных лозунгов" типа "UML это круто" и "UML позволяет упрощать общение с заказчиками". А также обсуждений типа "какая стрелочка кошернее" - ничего не почерпнул оттуда. :-(
Может быть я такой дурак и не понимаю "гениальности замысла"?
И не умею "читать между строк"?
Я ИСКАЛ - МОТИВАЦИЮ. Что? Почему? Зачем?
ПОЧЕМУ - UML это - ЗДОРОВО. Не нашёл... :-(
Ни в одной из книжек.
Плохо искал?
P.P.S. У меня кстати родилась ещё одна "крамольная" мысль, что и RUP и XP и Agile -направлены на "сантехников" и "кодеров". Потому что предполагают "открытый формат", "незамороченность" и "нестатусность".
Может быть "у них там на Западе" - по-другому всё устроено?
P.P.P.S. Да! Никого не хочу "поругать" или задеть. Просто "со стороны наблюдаю". И не только на СВОЁМ опыте. Было бы это ТОЛЬКО на МОЁМ опыте. "В рамках отдельно взятого предприятия" - я бы и писать бы об этом не стал бы.
Вот скажем как "всякие" сантехники или водопроводчики. Или токари чертежи читают.
Как?
Где их этому учат? В ПТУ вестимо.
И ничего. Читают и делают своё дело.
С разрезами, проекциями, фасками и прочими допусками.
Нам когда-то надо было сделать клапан для скороварки. Для походов. Ну пошли мы к токарю - объясняем. Он нам говорит - "чего вы на пальцах объясняете. Несите чертёж - сделаю". Так и получилось. Нарисовали чертёж. Принесли токарю. Он нам сделал, то, что нам было надо.
И ничего.
Помните, как Лев Кассиль писал про "магию людей своими руками создающими вещи"? Там правда не очень оптимистичная кульминация сюжета была. Но это - не важно....
Так как же так получается, что люди с ВЫСШИМ образованием, в основной своей массе - НЕ ГОТОВЫ читать диаграммы UML. Ведь они не СЛОЖНЕЕ, чем чертежи. Которым кстати в школе учили. Азам. А уж в ВУЗах - и подавно. По себе знаю. У меня было много подобных дисциплин. И ничего. Никто не умер.
Сколько должно времени пройти, чтобы научились? Лет 50-т?
Начинать надо со школы? ВУЗов?
Ведь UML - явно - НЕ СЛОЖНЕЕ, чем чертежи.
Или "сантехники" умнее, чем "креативный класс"?
И ведь главное - ведь УМНЫЕ люди говорят - "не хотим читать ваш UML, мы в нём ничего не понимаем".
Проблема в UML? Или в "молодости технологии"? Или в менталитете?
Не понимаю.
У меня у жены кстати заказчики - читают UML. Откуда они "такие умные" взялись - не понимаю. Много вопросов по этому поводу задавал. Ответов - пока не получил.
Или я что-то не так трактую?
P.S. Меня тут "на просторах интернета" дружно "тыкали носом". Мол "прочитайте книжки про UML". Прочитал. И перечитал. Много всяких разных. Умных и не очень. "Отбашлял" денег авторам.
Того же Лармана перечитал. И много других. В количестве 6-ти штук.
Ну что могу сказать. Да ничего.
Кроме "рекламных лозунгов" типа "UML это круто" и "UML позволяет упрощать общение с заказчиками". А также обсуждений типа "какая стрелочка кошернее" - ничего не почерпнул оттуда. :-(
Может быть я такой дурак и не понимаю "гениальности замысла"?
И не умею "читать между строк"?
Я ИСКАЛ - МОТИВАЦИЮ. Что? Почему? Зачем?
ПОЧЕМУ - UML это - ЗДОРОВО. Не нашёл... :-(
Ни в одной из книжек.
Плохо искал?
P.P.S. У меня кстати родилась ещё одна "крамольная" мысль, что и RUP и XP и Agile -направлены на "сантехников" и "кодеров". Потому что предполагают "открытый формат", "незамороченность" и "нестатусность".
Может быть "у них там на Западе" - по-другому всё устроено?
P.P.P.S. Да! Никого не хочу "поругать" или задеть. Просто "со стороны наблюдаю". И не только на СВОЁМ опыте. Было бы это ТОЛЬКО на МОЁМ опыте. "В рамках отдельно взятого предприятия" - я бы и писать бы об этом не стал бы.
С трудом себе представляю выпускника профильного ВУЗа, который имея доступ в Интернет не разберётся с UML-диаграммой.
ОтветитьУдалитьДругое дело, что рисовать означенные диаграммы он по своей воле не станет, поскольку чаще всего имеет дело с задачами, для решения которых они не необходимы.
С другой стороны, проектировщики и архитекоторы в небольших компания (да и в больших тоже) со скепсисом относятся к применению UML, поскольку:
1. Довести детали технического решения до исполнителя они чаще всего могут с использованием более простых средств.
2. Большие UML-диаграммы воспринимаются чуть ли не хуже, чем текст на русском, а затраты на их производство/сопровождение несопоставимы.
3. Как правило, детализация до классов не нужна, поскольку для проектировщиков и архитекоторов это не операционный язык. Они работают с более высоким уровнем - компонент, в то время как за классы отвечают конкретные исполнители, для которых уровень архитекторов тоже не операционный, они на нём редко работают.
Таким образом получается, что применение UML ограничивается пояснительными картинками к техническим заданиям и постановкам.
Пртиворечие, Ваше честь!
ОтветитьУдалить>>который имея доступ в Интернет не разберётся с UML-диаграммой.
>>Большие UML-диаграммы воспринимаются чуть ли не хуже
... и еще, позволю себе некий трюк, взяв за основу текст комментария
Как правило, детализация до чертежей, поскольку для проектировщиков и архитекоторов это не операционный язык. Они работают с более высоким уровнем - детали, в то время как за сборку отвечают конкретные слесаря-сборщики, для которых уровень архитекторов тоже не операционный, они на нём редко работают.
Таким образом получается, что машиностроительного черчения ограничивается пояснительными картинками к техническим заданиям и постановкам в языковой форме.
«Пртиворечие, Ваше честь!
ОтветитьУдалить>> который имея доступ в Интернет не разберётся с UML-диаграммой.
>> Большие UML-диаграммы воспринимаются чуть ли не хуже»
-- В чём же Вы видите противоречие? ;-)
Ну и разобраться - это одно, а использовать UML в роли такого же инструмента, как программный код - совсем другое.
«... и еще, позволю себе некий трюк, взяв за основу текст комментария»
-- 1. Для проектировщиков и архитекторов, о которых Вы говорите, чертежи как раз операционный язык. Более того, часто единственными артефактами их деятельности и являются означенные чертежи, в соответствии с которыми далее точат, куют и строят. В программировании же и артефакты другие и методы. Не удивительно, что на UML смотрят со скепсисом, поскольку вполне успешно обходятся без него.
2. Далее, чертежи в Вашем случае являются формализованным языком, на котором инструкции передаются от проектировщика конкретному исполнителю. В программировании же UML на эту роль претендовать не может, поскольку формализовать позволяет далеко не всё и не с той степенью подробности, что в означенном Вами примере.
3. В программировании совершенно иначе построено разделение труда. Кто по-Вашему должен рисовать диаграммы? Аналитик? - У него часто просто недостаточно квалификации для этого. Архитектор? - У него своих проблем полно. Программист? - Для него эти диаграммы - не более, чем пояснительные картинки. Ввести специалиста по созданию UML-диаграмм? - А зачем, если система успешно работает и без этого специалиста?
>>Кто по-Вашему должен рисовать диаграммы?
ОтветитьУдалитьВсе.
Чертежи должны читать все. Рисовать - да, не все. А читать - да.
>>А зачем, если система успешно работает и без этого специалиста?
Бригада шабашников, строящих забор, тоже обходятся без чертежей.
«Кто по-Вашему должен рисовать диаграммы?
ОтветитьУдалитьВсе.
Чертежи должны читать все. Рисовать - да, не все. А читать - да.»
-- Читать все и могут. Тут не виду вообще никакой проблемы.
«А зачем, если система успешно работает и без этого специалиста?
Бригада шабашников, строящих забор, тоже обходятся без чертежей.»
-- Врачи, учителя и учёные также зачастую без них обходятся.
Не нужно спекулировать Всеволод, поднимая UML для программистов до уровня чертежей для токарей и строителей. Программисты не детали вытачивают и не бетон месят. Более тонкая работа требует более тонких инструментов.
Простите.. Но у меня иногда создаётся ощущение, что ВСЕ МЫ (программисты) зорко охраняем свой "ореол таинственности".. Что мол "программирование - это творчество"... И вообще - закрытая сфера...
УдалитьПо-моему - НЕТ ничего там ни "таинственного", ни "творческого" (я писал уже об этом).. По-моему - программирование на 80% состоит из "умения выполнять те или иные УСТОЯВШИЕСЯ правила"... не более того.. ну и 10% на творчество... ну и 10 - на всё остальное...
"умения выполнять те или иные УСТОЯВШИЕСЯ правила"
Удалить-- шаблоны проектирования, UML, RUP, стандартные алгоритмы, Agile, "best-practice".. далее - "добавить - по-вкусу"...
"*поднимая* UML для программистов до уровня чертежей для токарей и строителей"
Удалить"и не бетон месят. Более тонкая работа требует более тонких инструментов"
-- по-моему - тут явное противоречие.. могу ошибаться...
«Простите.. Но у меня иногда создаётся ощущение, что ВСЕ МЫ (программисты) зорко охраняем свой "ореол таинственности".. Что мол "программирование - это творчество"... И вообще - закрытая сфера...»
Удалить-- Не знаю. Не замечал. Не понимаю, о каком "ореоле" идёт речь. Я такового не наблюдаю.
И рассуждаю, по-моему, достаточно прозрачно. Есть понятие описательного языка (Pascal или UML, или вообще - русский). Есть предметы, с описанием которых он справляется хорошо, есть предметы, с описанием которых - плохо. Универсальных языков, одинаково хорошо годящихся для любых целей, пока, насколько мне известно, не создано. Не стоит ждать такой универсальности и от UML и от графической нотации вообще.
«По-моему - программирование на 80% состоит из "умения выполнять те или иные УСТОЯВШИЕСЯ правила"... не более того.. ну и 10% на творчество... ну и 10 - на всё остальное...»
-- Не знаю. Думаю, у каждого своё деление, зависящее от отношения к делу.
«"умения выполнять те или иные УСТОЯВШИЕСЯ правила"
-- шаблоны проектирования, UML, RUP, стандартные алгоритмы, Agile, "best-practice".. далее - "добавить - по-вкусу"...»
-- Это всё - разновидности языков. Где-то они хороши, где-то - неадекватны.
«"*поднимая* UML для программистов до уровня чертежей для токарей и строителей"
"и не бетон месят. Более тонкая работа требует более тонких инструментов"
-- по-моему - тут явное противоречие.. могу ошибаться...»
-- Я не вижу противоречия. Я говорил ранее, что не виду причин, по которым UML должен быть универсальным языком для программистов. Это один из языков, у которого есть своя ниша. Она пересекается с программированием, но не может выступать в качестве полноценной замены специализированным языкам.
Что же до "бетона" и его "замеса" - мне казалось очевидно. Есть низкоквалифицированная работа, есть высококвалифицированная. Чем сложнее область, тем выше порог входа и требования к навыкам. Восприятие программирования как ремесла имеет право на жизнь, если удаётся свести какую-то область к ремеслу, там можно широко распространить более простые подходы. Это вполне в духе мэйнстрима, но для такого мэйнстрима UML оказывается слишком сложным.
С другой стороны, иные походы требуют более тонких инструментов, чем UML. Для таких подходов UML является громоздким, недостаточно гибким и детализированным. Мой первый пост в данной теме был посвящён этому.
Что смущает и где Вы видите противоречие?
"Не стоит ждать такой универсальности и от UML и от графической нотации вообще"
Удалить-- я не говорю про "UML сейчас", я пытаюсь говорить про "чертежи в программировании в будущем".
"Что смущает и где Вы видите противоречие?"
Удалить-- "поднимать до уровня" и "месить бетон" - я тут вижу противоречие. Возможно - я как-то не так мыслю.