UML умер, а никто и не заметил?

Автор оригинала: Ernesto Garbarino
  • Перевод

UML, нам будет тебя не хватать

Unified Modelling Language (UML), разработанный Rational Software и принятый в качестве стандарта Object Management Group (OMG) в 1997 году, призван был стандартизировать множество различных типов графических нотаций, принятых в отрасли разработки ПО.

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

Откровением для меня стала формальная семантика, связанная с UML Activity Diagrams. Я не мог терпеть неформальные схемы Visio из-за множества неопределённостей в них. Например, что означают две стрелки, исходящие из прямоугольника: выбор или разделение потока на два параллельных пути? Аналогичный пример: две стрелки, указывающие на один прямоугольник, означают, что действие начинается сразу после достижения первым потоком прямоугольника? А может, это OR, XOR или AND? В общем, смысл вы поняли. UML решает эту проблему благодаря введению чёткой и недвусмысленной семантики.


Игра была нечестной изначально: правильного ответа нет

Я по-настоящему вкладывал душу в UML:

  • Я чертил схемы для собственных решений с 2004 по 2015 годы для семи разных работодателей и клиентов почти исключительно с помощью UML.
  • Я проводил буткемпы по UML (для бизнес-аналитиков) у двух крупных клиентов.
  • В качестве кандидатской диссертации я определил ключевое множество дискретной математики, являющееся фундаментом для большинства структурных и поведенческих моделей UML. Я даже написал на Haskell инструмент на основе GraphViz для визуализации этой математики в графическом UML.

Спустя несколько лет, примерно в 2015 году, я осознал, что практически перестал пользоваться UML, как и остальные мои коллеги, а также почти все клиенты из списка Fortune 500, которых я консультировал в последнее время. Что же произошло?

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

Но жертвой стал не UML сам по себе. Если откровенно, UML стал просто побочной потерей. Настоящая резня развернулась в сфере разработки требований, включающей в себя бизнес-аналитику и проектирование. Убийцей стал Agile, а его отравленными стрелами были user stories.

В модели, куда на входе засовывают user stories, а на выходе получают демо (или feature production release), больше нет места для содержательного структурного анализа задач.

В современном дивном новом мире понимание напрямую кристаллизуется в код, готовый к продакшену. Даже моделирование бизнес-структур, по сути, было убито родственной Agile дисциплиной: Domain Driven Design (DDD). Ограниченные контексты инкапсулируют (заметают под ковёр) сложность, чтобы энтерпрайз мог масштабироваться на «команды на две пиццы». Компании, использующие BDD и требующие от своих рабочих групп писать спецификации Cucumber, имеют здесь перевес, но этим занимаются очень немногие бизнесы.

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

Вы уже должны были понять: дело не в каких-то недостатках UML. Мы просто отказались от бизнес-анализа и формальных спецификаций, поэтому перед нами встаёт новый вопрос: чем пользоваться вместо UML?


Пример масала-диаграммы

Хотя некоторые используют легковесные техники моделирования наподобие C4, большинство применяемых сегодня диаграмм относятся к типу, который я несколько пренебрежительно называю «масала-диаграммами». В конце концов, почему бы не назвать так диаграммы, которые я и сам делаю? Почему «масала»? Потому что они неформальные; они одновременно покрывают несколько размерностей, они могут быть и структурными, и поведенческими, логическими и физическими. Часто они являются мешаниной визуализаций архитектурной модели 4+1.


Как готовить масала-диаграмму

Системы стоимостью в миллионы долларов, от которых зависят наши жизни и финансы, создаются, финансируются и реализуются полностью на основе этих масала-диаграмм, которые часто не содержат ничего лишнего, кроме нескольких эпиков и user stories.

«Автор, ну архитектура ипотечной системы моего банка уж точно не была спроектирована на основе этих ваших ужасных масала-моделей!»

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

Неужели мир сошёл с ума? Нет, мы просто отказались от инженерного проектирования ПО. Теперь это просто авантюра с кодом. Я не говорю, что те, кто пишет ПО, сами не являются инженерами; чаще всего, это не так. Смысл в том, что на организационном уровне ПО больше не проектируется, как это делается в других сферах, например, в машиностроении. Boeing никогда бы не заказал у Rolls Royce реактивный двигатель на основе подобной неформальной масала-диаграммы.

Однако у масала-диаграмм есть своё предназначение. Если использовать их там, где им место, то они прекрасны. Видите ли, это не спецификации. Их цель — вызывать эмоции. Масала-диаграммы ценны, когда нужно вызвать радость в сердце руководителя, для которого они предназначены.

Как бы я ни спорил с моими друзьями из лагеря Agile, я не могу остаться слепым к счастью людей. Мои клиенты и коллеги не только просят больше масала-диаграмм, но и настаивают, чтобы я делал их ещё более «масала» (чтобы я объединял в них больше архитектурных размерностей!). Зачем же этому противиться?

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



На правах рекламы


Эпичные серверы — это VDS для размещения сайтов от маленького интернет-магазина на Opencart до серьёзных проектов с огромной аудиторией. Создавайте собственные конфигурации серверов в пару кликов!

Присоединяйтесь к нашему чату в Telegram.

VDSina.ru
Серверы в Москве и Амстердаме

Комментарии 179

    –7

    Перевели всё-таки...

      +36
      Дело не в UML. Утратило популярность само планирование. Вместо того, чтобы продумывать процессы в системе, её набрасывают в общих чертах (так, нам нужна БД, резервная БД, бэк на ноде, потому что мы её умеем, и редиску не забыть) — и сразу бросаются делать MVP. А поскольку все компоненты из проекта в проект одинаковые, то это всё «само собой» соединяется.

      И только в высоконагруженных или нестандартных задачах этап планирования достаточно подробный, чтобы для него нужен был отдельный язык. И этот язык — Pytho UML.
        +14

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

          +28
          не спорю, это тоже нужно, возможно, большинству заказчиков только это и нужно — примитивное отображение его рабочих процессов в интерфейсе системы

          Вы так говорите, как будто взять и просто решить задачу, это плохо :)
            +16
            Зависит от масштаба. Если это сайтик магазина в подъезде — это прекрасно.
            Если это промышленная система, где надёжность, безотказность, много лет поддерживать и расширять не методом «напишем с нуля» — это отвратительно.
              +17
              Если это промышленная система, где надёжность, безотказность, много лет поддерживать и расширять не методом «напишем с нуля» — это отвратительно

              В каких-то частных случаях задач в частных случаях систем — да. В общем случае и там точно так же успешно действует подзабытый принцип KISS. Простое и быстрое решение в общем случае лучше сложного и обвешенного бюрократией. Потому что
              1. Простое и быстрое — не означает «ненадёжное» или «трудно поддерживаемое»
              2. Тщательное глубокое проектирование не означает получение надёжного и масштабируемого результата.
              3. С увеличением сложности решения надёжность снижается, количество точек отказа и потенциальных ошибок увеличивается.
              4. А ещё примитивное отображение рабочих процессов в системе (как бы ни иронизировали на тему «автоматизированного бардака») означает, что решение сразу и практически гарантированно будет функционировать. В то же время в случае перестройки рабочих процессов в формулу успеха добавляется изрядное количество человеческого фактора, который легко может похоронить проект.
                +4
                Изменились бизнес-требования. Новое направление, новый закон, новая страна… и 30% графиков больше не актуальны. А мансала — осталась актуальной. Что теперь, держать целый отдел ради графиков? Это же средство, а не цель.
                Это очень утрировано, но вроде мысль понятна. А вообще, низкий уровень работы и так описан кодом, а для понимания связности блоков мансала вполне удобно выглядит.
                  –1
                  «низкий уровень работы» — что это значит? извините, я не понимаю ваш русский…
                  +1

                  Если мы ведем речь о ПО для ядерных реакторов или самолетов, то тут вы правы бесспорно. Но если речь идёт о каком-то интернет-сервисе, то пока Вася планирует, проектирует, разрабатывает, Петя хренак-хренак на коленке, криво-косо выкидывает в продакшн MVP. Через год-два Петя уже обрастает клиентурой, и уже может нанимать людей. А Вася, сделав крутой, качественный, проект, внезапно осознаёт, что, во-первых, рынок занят, а во-вторых, изменились требования — и его наработки устарели, еще не взлетев. Поэтому Вася, понурив голову, идёт к Пете с резюме.

                  +7

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

                    +3
                    А песни Пугачёвой стали?
                      0

                      А то!
                      А-ха-ха-ха-ха, ха-ха-ха, ха. О-хо-хо-хо-хо, хо-хо-хо, хо!..

                    0
                    За «просто» никто платить не будет, и когда все знают что это просто, для сложных систем идет тот же подход и отношение.
                      0
                      А кто сказал что платить будут? IMHO тренд как раз опустить «простейших» до уровня их экосистемы. Ведь если человек и правда научится планировать и думать — он чего доброго захочет планировать и выбирать себе судьбу, а там и до государства недалеко… Нафига, ведь понятно что индивидуальностью сложно управлять. И дороже. И куда как проще с примитивной толпой с стиле «муравьиного социализма». Туда же как раз и оплата — если ты одинаковый «как все», то получай «как все» свою ложку баланды, макэйр, самокатик, ипотеку в Бирюлево и Дом-2 и Олю Бузову, Моргенштернов, Даню Милохина для умственных развлечений… Зачем тебе в принципе знать — что можно по другому жить, дурашка?
                        +1
                        Лихо вы от UML к Оле Бузовой махнули %)
                          +3
                          Казалось бы, какая связь между UML и Ольгой Бузовой? А вот, здешние эксперты все по полочкам разложили ).
                  +18
                  Утратило популярность само планирование.
                  Ситуация существенно хуже. Утрата планирования это следствие отсутствия адекватного целеполагания в разработке. И категорическое нежелание оценивать эффективность изначальной задуманной идеи. Т.е. необходимо демонстрировать деятельность, что-то разрабатывать, писать отчеты, в которые никто не вчитывается и которые мало кто понимает. Оценивать результаты деятельности категорически отказываются. Это засилье дилетантов и театрально-показательного подхода в руководстве. Платят не за результат, а за демонстрацию усталости, управленческие фантазии, гору кода и потраченное время жизни разработчиков. И Agile со всей его умопомрачительной театральностью и показательностью напряженной работы рабов тут как нельзя к месту.
                  Когда рисуется масала-диаграмма ее может до некоторой степени понять (или думать, что понял) любой дилетант. А вот UML хоть немного, но надо учить. Никто из руководителей и бизнес заказчиков этого делать не будет.
                  Zanak
                  Дело в падении образования
                  Дело не в падении образования, а в деградации подхода ко всему IT. Каждая дворняга считает себя специалистом в IT. У начальника есть сын-балбес, которого он считает светилом в IT и специалистом по нажиманию кнопок на всех компьютерах. А тут какие-то придурки, чтобы начальник понял что будут разрабатывать, требуют от него учить нотацию UML. Не будет он этого делать. Дело не в падении образования, а в торжестве невежества. При этом работу в среде полного невежества называют софт скилами.
                  И вы думаете, что такая деградация в разработке только в дефолтовой стране? Посмотрите на новый Skype. Новые разработчики сломали почти все что могли сломать в старом Skype. При этом нахерачили лайки, обратную связь, и продолжают добавлять и громогласно рекламировать странные фичи при кривой и не исправляемой основной работе мессенджера. За то деньга капает и гиря пилится.
                    +9

                    Можно называть это деградацией, но, как вы говорите, "деньга капает", а значит, это работает. Деньга же появляется не из ниоткуда. При этом мы живём в условиях рынка, т.е. если бы описанное вами было изначально неверным подходом, то оно, по идее, должен было бы вскоре затухнуть из-за безоговорочных побед конкурентов с более формализованными/бюрократизированными подходами. Но оно продолжает жить и внедряться, так что, возможно, это c'est la vie, с которым нужно просто смириться :)

                      –1

                      Ну очень часто деньга капает совсем из других источников, а сам продукт убыточный на постоянной основе

                        0

                        Если цель - просто проесть деньги инвесторов, то уже как бы всё равно, agile там или не agile, если результат заведомо известен.

                          +5
                          Может ИТ стало отражением реального мира, где имитация и освоение денег правит бал. Этакий аналог смены плитки и бордюров с летних на зимние, производство автомобилей, требующих доработки(патчей) сразу после покупки в салоне, строительство многоквартирных домов, окна и двери от застройщика сразу на замену и т.д.
                            0
                            все ради оборотов.
                        +1

                        Вот про Скайп в точку. С каждой версией всё тормознутей и глючнее :(

                        Хотя уже давно Teams появился...

                          +6

                          Имхо, Teams существенно хуже Skype.

                          • Лично у меня он сильнее тормозит. Переключение между чатами медленное.

                          • Отвратительный текстовый редактор.

                            • Иногда в нем тормозит ввод текста, это же просто немыслимо

                            • Непредсказуемый wysiwyg markdown ввод.

                            • Вставка форматированного текста может провести к тому, что к обычному тексту он не возвращается (например, вставил список)

                          • Жутко тормозит редактирование сообщений

                          • Нет цитирования/ответа

                          • Изображения регулярно не прогружаются

                            +2

                            Да, шило на мыло... Ещё что в тимсе очень бесит, так это кружок статуса на таскбаре. Статус показывает свой, а фамилию человека, с которым последний раз был открыт чат.

                            В общем что что, а мессенджеры микрософт так и "ниасилил" :(

                              0
                              Цитирование/ответ есть в приложении тимс.
                                0
                                wysiwyg и markdown это взаимоисключающие понятия
                                +2
                                Скайп еще ничего так. А вот Вайбер реально бесит. С компьютерной версии нельзя контакт добавить, только с телефона.
                                А недавно, так просто слов цензурных нет: решил отправить видеофайл, который спокойно открывается браузером и проигрывателем. Перетащил файл в вайбер и вайбер завис, причем завис так, что даже после перезагрузки компа продолжил висеть. Я уже думал удалять гада, но вспомнил про телефон, зашел с телефона и оттуда смог удалить отправленное видео, только после этого вайбер на компе стал работать.
                                  +4
                                  Псс… WhatsApp видели?
                                    +2

                                    это который без телефона не работает совсем?

                                    0
                                    Это ладно, когда свой файл — у меня вайбер с какого-то момента (возможно, после апгрейда убунты с 18.04 на 20.04) стал стабильно падать на присланных видео. И приходилось людей просить присланное удалить. Правда, потом не выдержал, запустил его под gdb, увидел что падает он в плагине libjpeg.so, взял и удалил плагин. Вайбер перестал показывать видео и картинки, но и падать тоже перестал :)
                                  +1

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


                                  Что касательно UML как такогово, то он сам себя и убил, как только стал стандартом. Стандарты/унификация — это замечательно, позволяет уменьшить сроки разработки и тп, но другая сторона этой палки — стагнация, а жизнь уходит вперед.

                                    +2
                                    Интересно. На С++, PCIe, метрические винты, тульские пряники, да хоть кошачьи шкурки тоже есть стандарты. Отчего они себя не убивают?
                                      +1
                                      Дело в цене ошибки, мощности связей между компонентами и длительности итерации разработки. Части систем становятся все менее и менее связанными и позволяют «горячую замену» — из-за этого подход «не будет работать — переделаем» превалирует над «лучше неделю тренироваться — а потом за час долететь».
                                    +1

                                    Это не деградация, это следствие огромного объема задач. И кажущиеся на первый взгляд нелепые решения, связаны с тем, что в данный момент программист просто не знал систему хорошо.

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

                                    По этому рефакторинг архитектуры, дизайна и кода - это важная вещь.

                                      0

                                      О, да!
                                      "Выйти из скайпа" в трее меня в лоб убило...

                                        0
                                        А что не так тут?
                                        +2
                                        Ага — и даже в год «самоизоляции» умудрились профукать передовые на старте Skype технологии телеконференций каким то выскочакам типа Zoom, Jitsi, Zoho и пр. А сами даже бренд не могут фокусировать. То у них Skype, то Skype for Business, то Link, то Teams маркетолухи постоянно креятивят…
                                          0

                                          Историческое наследие, которое сразу и резко ломать нельзя. Так-то они сейчас все постепенно в одну кучу стягивают

                                            +1

                                            но почему постепенно? Там надо было резко стартовать, когда все это начиналось. И захватывть долю.

                                          0
                                          А может это потому, что скайп стал дефолтным средством видеозвонка? Ватсапов, телеграмов, зумов у человека может не быть, а скайп стопудова есть. Может именно из-за огромного охвата юзеров можно издеваться как угодно над продуктом — всё равно схавают. Ой, возможно и в винде такие же дела)
                                            0
                                            Да не стал, а был, когда-то. Сейчас нет, довольно давно, причем.
                                          +8
                                          Вместо того, чтобы продумывать процессы в системе, её набрасывают в общих чертах (так, нам нужна БД, резервная БД, бэк на ноде, потому что мы её умеем, и редиску не забыть) — и сразу бросаются делать MVP. А поскольку все компоненты из проекта в проект одинаковые, то это всё «само собой» соединяется.

                                          Точно, раньше же круче было. Можно было два года рисовать диаграмки, только для того, чтобы понять, что требования давно изменились, да и сам продукт потерял актуальность.

                                            –2
                                            требования -> дизайн («диаграмки») -> реализация (код). Уберите промежуточный шаг и добро пожаловать в легаси ад.
                                              +6

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


                                              Пример про рисование диаграмок на протяжении нескольких лет без создания реального продукта — это не голые слова, а печальные реалии многочисленных проектов периода расцвета uml (~2000-ые). Все движение в аджайл возникло не на пустом месте. Людям нужен был продукт, а не набор артефактов в розе и тп продуктах

                                                +2
                                                Более того, с расцветом скриптовых языков и появлением у них репозиториев с готовыми пакетами для чего угодно — чаще проще написать сам код чем его UML-модель.
                                                А глядя на скорость работы и UI большинства UML-редакторов — современные программисты впадают в депрессию.
                                                  0

                                                  Это тоже, ну такое… дорогой в ад попахивает, в 2000-ые у нас уже были, например, perl и cpan, где были пакеты для чего угодно. Но это другой вопрос.
                                                  UML, когда он используется без фанатизма и излишней формализации, не плох как универсальный язык для общения, записи каких-то идей, но проектировать систему от и до — это явный перебор.

                                                    +1
                                                    В те же 2000-ые, с ростом сложности систем — стало понятно что последовательное выполнение наперед заданных последовательностей действий (даже если они раскиданы по разным «методам») — достигло предела масштабируемости, а ручное управление параллелизмом (мьютексы, семафоры и вот это все) — сильно превышает возможности среднего программиста. Вот и начали придумывать всякие DCOM, EJB, message loop, AMQ и прочие имплементации паттерна «песочница» — в которой код понятия не имеет, кто его вызывает и кого на самом деле вызывает он — а связыванием занимается тот или иной брокер. Соответственно — брокер и стал верхним уровнем системы, а сами компоненты-сервисы — практически самодокументированы. Еще и интерфейсы умерли, заменившись описанием обрабатываемых и порождаемых событий.
                                                    Опять же — это все было еще в Смоллтоке и других средах, просто сегодня стало намного доступнее.
                                          +5
                                          Автору благодарность за понимание, переводчику — за труд. «Масала» на русский, видимо, лучше переводить как «солянка» или «винегрет». Для тех, кто как и я пользовался «до UML-ными» SADT/IDEF, ситуация выглядит неважно.
                                          Подкину по теме "Несеребряные пули или кратко про методы софтостроения"
                                            –3
                                            >«Масала» на русский, видимо, лучше переводить как «солянка» или «винегрет»

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

                                            Меньше «локализации» — меньше перлов типа "написание программ на языке высокого уровня С++ для персональных ЭВМ".
                                              +3

                                              А я поддержу Мориарти. Масалу не надо переводить, это ещё и отсылка к индусам.

                                                +2
                                                Вопросы к 9 (на данный момент) минусаторам:
                                                1. Вы поставили минус статье за непереведенные картинки?
                                                2. Вы считаете что переводчик должен был «пересобрать» иллюстрацию и вставить фотографию солянки/винигрета?
                                                  +5

                                                  В гугле по запросу "masala diagram" на первом месте выводится именно оригинал этой статьи. То есть никакой это не узнаваемый термин, а авторская метафора. Поэтому для удобства читателей лучше её перевести (ну или хотя бы добавить "прим пер." с дополнительным контекстом).

                                                +22

                                                Я не соглашусь с автором и снова повторю свой любимый тезис по этому поводу. UML умер потому, что он графический. Что практически целиком убивает совместную работу и работу с Version Control. Т.е. упомянутый анализ и проектирование в результате завязывается на одного человека. Плюс рисовать эти картинки — довольно так долго и утомительно. Т.е. сам цикл анализа и исправления соответствующих результатов замедляется.


                                                Был бы этот UML нормально-текстовым, а картинки — генерировались бы из текста для удобства просмотра — может бы и использовали бы.


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

                                                  0

                                                  В статье упоминается graphviz - инструмент достаточно мощный чтобв в т.ч. описыватт uml текстом. Вот только вдобавок к знанию uml, аналитикам придётся учить еще и dot, учитывая то, что этот инстркмент не специализирован именно на uml. До популяризации git, были распространены и другие системы контроля версий (кое-где и до сих пор используются), в т.ч. те, в которых можно блокировать бинарники перед измением. С данной фичей, совместная работа с бинарниками вполне удобна.

                                                    +6
                                                    В статье упоминается graphviz — инструмент достаточно мощный чтобв в т.ч. описыватт uml текстом.

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

                                                      0
                                                      draw.io тоже штука крутая и хранит в тексте. Тут нужно что-то вроде openapi, который можно писать руками, а в итоге оно рендерится само во что-то красивое. Не факт правда, что это подъемно такой язык сделать. Особенно с учетом, что правильное отрисовка графа задача неформальная и текстом это не опишешь.
                                                        0
                                                        draw.io тоже штука крутая и хранит в тексте

                                                        То же возражение. Оно хранит картинку, а не ее смысл.


                                                        Особенно с учетом, что правильное отрисовка графа задача неформальная и текстом это не опишешь.

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

                                                          0
                                                          То же возражение. Оно хранит картинку, а не ее смысл.

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

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

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

                                                          Вот с openapi там все просто. Процесс трансформации кода в HTML страничку полностью формализован.
                                                            0
                                                            Речь о том, что человек банально хочет определенное расстояние между блоками, определенный их порядок, местоположение.

                                                            Ну, что graphviz, что yEd, который является демонстрацией работы соответствующей коммерческой библиотеки, как-то более-менее справляются. Не, диаграмму можно и руками поправить, но обычно оно бессмысленно.


                                                            Поэтому я не уверен, что получится сделать подобный язык описания диаграмм

                                                            Я не про язык диаграмм, а про язык описания того, что UML пытался описывать. Т.е. архитектуры и так далее.

                                                              0
                                                              Дык, все равно конечная цель получить на выходе картинку. Или вы хотите сместить приоритет на код, а картинку оставить чисто для красоты? Тут я тогда не уверен. От UML тогда еще меньше пользы останется. В чисто графическом виде он хотя бы как-то понятен людям.
                                                                0
                                                                Дык, все равно конечная цель получить на выходе картинку.

                                                                Нет. Конечная цель — понять описание системы. Картинка да, исключительно для иллюстрации для тех, кому почему-то так удобнее.


                                                                В чисто графическом виде он хотя бы как-то понятен людям.

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

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

                                                                  Но тут похоже всплывает недостаток UML как подхода, который пытается мир ИТ и бизнеса состыковать этими диаграммами. Если картинки оставить бизнесу, ИТ дать язык описания архитектур, и продумать какой-то мостик между этими мирами, то наверное получится.
                                                                    +1

                                                                    Не забываем, что бизнес вполне читает законы/договора/инструкции и прочие весьма немаленькие и сложные текстовые документы. Т.е. с текстами работать умеет.


                                                                    И я не очень понимаю, почему принято считать, что для него прямо таки необходимо увидеть все в простых неформальных картинках, а не, скажем, в дюжине столь же неформальных текстовых строк.

                                                                      0

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

                                                                      С другой стороны, на диаграмме часто иллюстрируют чтото нетривиальное с кучей объектов и связей, следовательно, вариантов того, как это изобразить, будет множество. И большинство - не удачные. Значит, любая тулза практически гарантированно не будет рендерить самое удачное представление. И тут мы приходим к двум вариантам:

                                                                      1. Довольствуемся тем, что получается (но, скорее всего, такой результат никому не нужен)

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

                                                                        0
                                                                        Я бы не стал приравнивать тексты и документы к программному коду. Это все такие совершенно разные вещи в плане восприятия. Бизнес умеет работать именно с текстами, а не с языками множеств и прочей лабудой, которая нам программистам порой ближе, чем обычный текст.

                                                                        И я не очень понимаю, почему принято считать, что для него прямо таки необходимо увидеть все в простых неформальных картинках, а не, скажем, в дюжине столь же неформальных текстовых строк.

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

                                                            Борланд сделал штуку, рисуешь UML, потом компилируешь в программу. Но она взлетела не сильно, а на фоне этого вектора развития Дельфи перешла другим владельцам. В итоге загнулся и Борланд.

                                                              +1
                                                              TogetherUML была куплена Borland, если мне не изменяет память. Тогда еще шутили что будет вместо быстрой Together IDE тормознутый Borland JBuilder.
                                                              До это был продукn Rational Rose Realtime, который умел тоже самое только не в Java, а в С++.

                                                              Насколько я знаю сейчас довольно много продуктов BPM которые используют нотацию UML:JBPM/Activity или WWF.

                                                              Кстати RUP проповедовал итерационный подход задолго до Agile.
                                                        +1
                                                        Блюпринты на Unreal Engine версионизируются: дифаются без особых проблем. С мерджем есть нюансы, но это в процессе решения сейчас.
                                                        При этом это в чистом виде графический код.
                                                        И рисовать блюпринты весьма удобно. Начинающим часто быстрее чем код писать, потому что есть контекстная помощь.

                                                        Почему этого всего не было в UML? Как видно дело не в графическом представлении. Просто никому не надо было.
                                                          +1
                                                          При этом это в чистом виде графический код

                                                          неужели прям как .jpg хранится? Нет же.
                                                          Так что выглядит, как будто дело именно в графическом представлении, потому что без нормальной IDE не работает. Unreal себе сделал — вот у них и работает. А если в условном пейнте рисовать...

                                                            0
                                                            blueprint hell — по этому запросу поисковик показывает прекрасные картинки.ю что в итоге получается
                                                              0
                                                              В итоге чего? Это из-за мерджа макароны разрастаются?
                                                              Я вашу мысль пока вообще не понял.
                                                                0
                                                                Я скорее про то, что у визуального программирования есть свои минусы. А если мержить визуальные схемы легко, то они, видимо, имеют еще большую тенденцию разростаться
                                                                  0
                                                                  На любом языке, независимо от его визуальности, можно делать говнокод.
                                                                  Если соблюдать правила написания кода, макарон не будет.
                                                            +1
                                                            mermaid в markdown похоже на то, что вы хотите видеть?
                                                            mermaid-js.github.io/mermaid/#
                                                              0
                                                              Был бы этот UML нормально-текстовым, а картинки — генерировались бы из текста для удобства просмотра — может бы и использовали бы.

                                                              Так ведь был же такой вариант языка! (Правда, только для интерфейсов, последовательности и прочее подобное не поддерживалось). Он назывался IDL, и помимо возможности версионного контроля (благодаря текстовости) обладал ещё кучей киллер-фич. (Например, все IDE того времени под самую популярную платформу того времени умели из IDL — через .tlb — генерировать кодо-заготовки). Картинки из него тоже можно было строить. Как результат, в нашей компании он полностью вытеснил UML через год-другой (с UML работа просто удваивалась и не было гарантий, что программист не напишет всё по-своему, сделав документацию нерелевантной). Ну а потом всякие дотнеты свели всё, что можно и нельзя (от разметки до документации), обратно к ЯП. Всемирная история, банк Империал ^^
                                                                0
                                                                Дотнеты еще WSDL пропихивали — причем вроде как стандартный, но специально сделанный «чуть-чуть» несовместимым. А IDL был еще в CORBA (не к ночи будь помянут) — включая рефлексию, динамические вызовы и даже авто-конверсию в Web-сервис для простых типов.
                                                                  0
                                                                  Дотнеты еще WSDL пропихивали — причем вроде как стандартный, но специально сделанный «чуть-чуть» несовместимым.

                                                                  Э-э-э, чуть-чуть несовместимый с чем?

                                                                    0
                                                                    Со стандартом. Я уже точно не помню — по-моему они включали в WSDL какие-то данные, в стандарте не предусмотренные — зато их собственный генератор stub-ов понимал и стандартные WSDL и такие «кастомные».
                                                                    А чтобы клиента на другой платформе сгенерировать — приходилось предварительно WSDL через XSLT прогонять. Но это лет 10 назад было — я уже подробностей не помню. Помню, что в ADFS то же самое было — их assertions «понимали» далеко не все системы, спокойно работавшие с identity providers других вендоров.
                                                                      0

                                                                      Только что проверил — WCF не вставляет никаких нестандартных дополнений в WSDL. Но даже если ASP.NET WebServices их вставляли — там в WSDL в RFC предусмотрены специальные места расширения, и тот факт что какая-то система не в состоянии их проигнорировать — не вина Microsoft.

                                                                        0
                                                                        Вполне возможно — с тех пор многое изменилось.
                                                                0
                                                                минус вам в карму за глупость «UML умер потому, что он графический» и «убивает совместную работу и работу с Version Control». Существующие инструменты предоставляют точно такие же эффективные методы командной работы над дизайном и управление изменениями как и при разработке.
                                                                  0
                                                                  UML умер потому, что он графический.

                                                                  Не надо путать визуализацию и хранение. *.uml — вполне себе XML, положите его в git или еще куда и радуйтесь.
                                                                    +2

                                                                    К сожалению, я видел такой XML, описывающий диаграмму, лежащий в git. Если формат изначально не затачивался на то, что его человек читать будет — этот xml ничуть не лучше бинарника. Ну показывает diff что какие-то строчки в рандомных местах изменились — а что это означает? А если у нас конфликты по мержу этой самой диаграммы — то вообще ничего сделать нельзя.

                                                                      +1

                                                                      Диаграммы в репо кладут для того, чтобы можно было контролировать и ревьювить их изменения. XML с этим не очень помогает. А graphviz — вполне читаемый на ревью PR.

                                                                      +3
                                                                      Он умер не потому, что он графический, а потому, что он никак не привязан к коду. Код изменился, диаграму забыли поменять. Ну и нафиг та диаграма теперь нужна? Случается такое в среднем дважды в день, поэтому каждый разработчик понимает бесполезность UML с первого раза. Каждый архитектор тоже с первого раза, но ему за рисование этих диаграмм иногда деньги платят, поэтому он их из своего резюме не вычеркивает.
                                                                        0
                                                                        Графичность UML — его огромное преимущество, потому что мозги наши затачивались эволюцией под разглядывание, а не чтение.
                                                                        Картинки в репу класть не надо, есть прекрасные человекочитаемые нотации, которые можно и в репу положить, и почитать, если уж картинки не нравятся — см. PlantUML, например.

                                                                        Эджайлу и прочим модным вещам UML как и проектирование системы заранее вообще не противоречит. А уж полезность графических нотаций обычно недооценивают, а потом берут на вооружение даже самые модники мира разработки. Оказывается, графическое изображение, например, взаимодействия 5 сущностей намного проще воспринимать и обсуждать, чем сбивчивое объяснение с маханием руками в зуме.

                                                                        Относится это, кстати, не только к UML, но и прочим графическим языкам. BPMN например )
                                                                        +25
                                                                        Помню в универе была непонятна надобность этого UML, его тучи диаграмм и строгости, а когда пришла практика и посмотрел, чего другие компании делают, то оказалось, что никто толком ими и не пользуется. По моим ощущения, UML просто тратит слишком много времени и сил, никто не понимает его формальный язык. Непонятна его итоговая ценность. Ну и вечная проблема синхронизации — софт очень быстро может меняться, именно на нем тестируются подходы и каждый раз за ним править диаграммы такое себе. Поэтому сейчас из UML, по сути, понабрали наиболее полезные и простые элементы (вроде sequence диаграмм, которыми пользуются повсеместно), а все остальное рисуется неформально или вообще не рисуется. Диаграммы больше дополняют исходный код, чем диктуют его структуру. Мы живем в век эдаково code-first подхода.

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

                                                                        Хотя с обратной стороной этого всего тоже постоянно сталкиваешься. Упомянутый openshift вот. Часто для таких систем нужно понять write-path, read-path. Четко понять, что какой компонент когда делает и зачем. А никто задачей описания этого даже не занимался. Только и остается по крупицам комментарии расшифровывать или копаться в исходниках, если они вообще доступны.
                                                                          +3
                                                                          Можно было сократить до «срок жизни продуктов стал меньше чем время затрачиваемое на их же проектирование» — это конечно утрировано, но по сути так и есть. То что в каждый делает в голове и на салфетке — это не проектирование, это решение текущей задачи про которую завтра никто знать не будет, как и ее решения.
                                                                            0

                                                                            Всмысле знать не будет? Это все ложится в схемы и описание системы. Да просто сам код, выбранные библиотеки, протоколы, базы и прочее, все продиктовано этими решениями.

                                                                              0
                                                                              В том смысле что если у людей нет времени на проектирование, то скорее всего не будет время и на ведение документации, зачем она если все в голове, да под рукой вот есть «сам код, выбранные библиотеки, протоколы, базы и прочее...»
                                                                                0
                                                                                А что есть проектирование по-вашему? Я выше написал, этап проектирования есть и его выход диаграммы и текст.
                                                                            0
                                                                            ну да, а потом приходит Антоненко Артем такой через год и спрашивает, а что сия картинко означает и как ее интерпретировать?
                                                                              0
                                                                              У вас какие-то странные представления о процессе, если такое возможно
                                                                            +33
                                                                            В комментах и без меня написали конкретные следствия использования UML (например, необходимость поддержки 2-х версий логики вместо одной), но мне кажется, что у автора фундаментальное непонимание, чем именно разработка ПО отличается от машиностроения, отсюда такое отношения аджайлу в стиле «ох, время нынче не то, деградирует все».
                                                                            Логическая ошибка заключается в том, что подразумевается следующая конструкция: «взрослые дяди годами моделируют и создают макулатуру при создании надежных вещей типа самолетов, следовательно это моделирование и макулатура и создает надежные вещи».
                                                                            Нет. Надежные вещи создает злой QA. А моделирование и написание макулатуры по моделям — это от бедности и является неизбежным злом. Прототипы в мире, отличном от разработки ПО, — штука крайне дорогая, а труд инженеров — нет. Приходится заменять реальные прототипы виртуальными моделями, и по ним делать выводы, максимально откладывая создание первого прототипа. Моделирование штука тоже дорогая, но дешевле прототипов. Неизбежное зло.
                                                                            Но подобный процесс не делает самолеты автоматически надежными. Наоборот, появляются точки расхождения между кучей моделей и реальным изделием. Но если собрать и испытать реактивный двигатель стоило бы 1 цент, конечно боинг бы просто его купил, обвесил датчиками и испытал — и это было бы более надежно и информативно.
                                                                            В случае программ, в подавляющем большинстве случаев нажал F5 — вот он твой прототип. Моделирование не просто не требуется, оно вредно. И целью должна быть понятность кода — через создание DSL, разного рода визуализаторы и прочую машинерию. А диаграммы нужно оставить там, где они и нужны — для эскизного проектирования и иллюстраций. А не для того, чтобы быть более плохой и плохо отлаженной версией кода.
                                                                              –1
                                                                              Согласен с основным тезисом acidhouse. Серъёзное проектирование в создании ПО менее востребовано, чем в машиностроении из-за черезвычайно низкой стоимости отдельных проб и прототипов.
                                                                              Но хотел бы добавить от себя ещё следующие аспекты:
                                                                              1. Широкой публике намного сложнее понять уродливость очередной инкарнации Skype по сравнению с уродливостью новой инкарнации автомобильной марки или уродливым новым зданием.
                                                                              2. По Марксу — мы переживаем финальную стадию консолидации производства, когда почти всё в конечном счёте принадлежит финансовым монстрам. Их финансовые возможности несопоставимы с возможностями независимых стартапов. Конкурентной борьбы в главных сферах программирования практически нет. Эффективность и качество востребованы существенно меньше, чем 50 или даже 20 лет назад.
                                                                              3. «Кровавый энтерпрайз» полностью анонимизировал труд разработчиков, превратил их в безымянных кочевников. В этих условиях атрофируются чувства стыда и гордости за сделанную работу.
                                                                              4. Немыслимое для других отраслей удешевление основного ресурса — hardware — часто сводит на нуль необходимость качественного проектирования. Зачем тратить сумму х с целью ускорить работу на у процентов, если можно на те же деньги арендовать z новых серверов и ускорить работу св к*у раз?

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

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

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

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

                                                                                    А это просто так не работает:
                                                                                    Кроме всего прочего, проектирование позволяет не только сберечь деньги, но еще и показать наиболее оптимальное решение из всех возможных.
                                                                                      +1
                                                                                      Метод полного перебора, комбинаторика, метод проб и ошибок, научные опыты — зачем все эти сложные действия, если можно просто:


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

                                                                                      А это просто так не работает:


                                                                                      Ну а кто сказал, что хорошее решение должно даваться легко?

                                                                                      Хотя с другой стороны, кто сказал, что кому-то вообще нужно хорошее решение?))))
                                                                                      +1
                                                                                      Только вот чтобы замоделировать паровоз, нужен чертеж паровоза.
                                                                                      Здесь же предлагается перед созданием чертежа паровоза сначала сделать UML-модель чертежа паровоза, в которой все нюансы вплоть до габаритных размеров отдельных деталей уже учтены, и, только построив эту модель, приступать, собственно, к черчению.
                                                                                    +2
                                                                                    Будете смеяться, но Space X как раз и применяют аджайл для создания ракет и спутников: построили прототип, взорвали, получили кучу информации, внесли изменения в следующий прототип… И вроде неплохо у них получается. Быстрее чем у Боинга с их SLS.
                                                                                      +1
                                                                                      Причем по тем же причинам, что и современный software development — появились инструменты (мощные CAD, обрабатывающие центры с ЧПУ и 3D-печать чем угодно), которые дают возможность переделывать быстро и дешево (как минимум, для соответствующей индустрии).
                                                                                    +2

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

                                                                                      +2

                                                                                      Я ещё UML использую, когда нужно заниматься реверс-инжинирингом легаси. Как раз недавно подкинули задачу - есть модуль, написанный пред-предыдущими исполнителями, как именно он работает не знает никто, точных требований не знает даже заказчик. И от меня требовалось понять и описать что там происходит. Выбрал как раз UML, так как он более наглядный. Не писать же юзер-сторис с нуля :)

                                                                                        0

                                                                                        Ну то есть не средство, но цель. "А что, так можно было?" ​

                                                                                          0

                                                                                          Не совсем понял, что вы имеете в виду.

                                                                                          Я выбрал UML только потому, что на мой взгляд он более наглядный, чем текст.

                                                                                          Но если бы текст был (например описанные юзер-сторис, или тест-кейсы, или просто подробный список требований, то вряд ли бы UML кто-то рисовал, так как диаграммы дублировали бы имеющуюся документацию.

                                                                                            0

                                                                                            Обычно с UML разработка только начиналась, были даже продвинутые варианты с кодогенерацией. А у вас UML - конечная цель. Почему бы и нет?

                                                                                      +3
                                                                                      UML мог бы найти себя в сфере накопления знаний о сформировавшемся продукте, инфраструктуре. Но никто этим не занимается, сужу по своему опыту. Дай боже, если будет хотя бы просто документация не для конечного пользователя, а для админа. Документации для разработчиков банально нет и за последние много лет складывается впечатление, что этот навык у людей просто постепенно уходит — писать документацию для себя, для тех кто пишет код с тобой и будет писать после тебя. Работал в проекте по защите данных и вот там была важна изначально высокая точность и надежность. Из UML диаграмм целый год не вылезали. Ушел работать в game-индустрию, в e-commerce и тут подходы уже другие, важны MVP и фичи. Это правильный подход судя по тому, что бизнес не умирают, а быстро развиваются. Такой подход наоборот дает возможность выйти к пользователю раньше и получить и отзывы, и баги и сделать редизайн всего от UI до всего что на серверах. Но в зрелых продуктах, которые уже устоялись, очень часто вижу отсутствие привычки документировать те решения, которые выработаны и будут существовать долго. И приходится бегать и собирать со слов, из комментариев в коде, и из старых переписок, делать реверс-инжинеринг. Накопление знаний как явление отсутствует много где. Вот это вот реально печально.
                                                                                        0

                                                                                        Но никто этим не занимается, сужу по своему опыту.

                                                                                        Если вы не пишете документацию, это не значит что её никто не пишет.

                                                                                        +5
                                                                                        Мне как-то в джуниорстве пытались озадачить рисованием UML-диаграм для существующего приложения. Знаете, в гробу я видел этот UML: на удивление не гибкое, неудобное, и просто медленное в работе решение. С тех пор все мои диаграммы были нарисованы от руки на бумаге, это тупо быстрее. Если нужна именно графическая версия — да, упомянутый в статье Visio.
                                                                                          +2
                                                                                          Думаю имеет место, «систематическая ошибка выжившего».
                                                                                          У среднестатистического программиста вероятность за карьеру наткнуться на проект, где будут использоваться инструменты проектирования снизилась, из-за непомерно возросшего количества потребительских программ разного толка, где такое серьезное проектирование совсем не нужно. Вот и создается впечатление что «и без UML обходимся, значит он не нужен».
                                                                                            0
                                                                                            Насколько я понимаю, все это предполагалось быть завязанным с ООП, чтобы по мере продвижения к детализации в конце концов можно было бы генерить классы на каком-то языке. И даже потом там в том же туле кодировать методы, отлаживать и т.д. И для этого нужна строгость в следовании спецификациям.

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

                                                                                            Если где-то проектируют и поддерживают софт строго по этой методологии — от UML диаграмм до реализации в коде — расскажите плз как у вас это организовано.
                                                                                              +1

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

                                                                                              Тестирование было тоже на основе диаграмм, так что разработчикам приходилось им следовать.

                                                                                                +1
                                                                                                Присоединяюсь. В моих лучших проектах было так. В остальных я с болью наблюдал, как этого не хватает.
                                                                                                Проблема состоит в том, что недостаточно провести для команды трехдневные курсы по UML. UML — это элемент технической культуры команды.
                                                                                              +3
                                                                                              Лично для меня UML был мертворожденным потому что чтобы написать диаграмму надо подробно освоить ещё и тулзу, которая позволяет эти диаграммы создавать. Я конечно и не искал особо, но на глаза не попадалось ни одной софтины, которая позволяла бы создавать диаграммы так же удобно и быстро, как, например, форматированный текст в markdown.

                                                                                              Нет времени создавать диаграмму → редко пользуешься софтиной для создания диаграмм → не успеваешь запоминать синтаксис и знаки форматирования (как в том же markdown) → т.к. не успеваешь запоминать способ работы, создание диаграммы занимает много времени → нет времени создавать диаграмму. Круг замкнулся.

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

                                                                                                Пробовали VS code + plantuml? Прирост в скорости разработки и изменения сиквенсов x10 по сравнению с Visio тем же.

                                                                                                Код прошлых диаграмм очень удобно использовать для новых.

                                                                                                  +1

                                                                                                  Согласен с вами. Добавлю, что еще проблема в отсутствии фиксированного формата внешнего представления. Вы взяли тулзу, нарисовали диаграмму, а как остальным участникам ее посмотреть? Им надо такую же тулзу, и можно с уверенностью утверждать, что у большинства ее не окажется. Поэтому вам приходится сохранять все в jpg. А когда кто-то захочет вашу диаграмму доработать, ему придется сначала исходник найти, затем инструмент, которым его можно открыть, и не факт, что получится.

                                                                                                    0

                                                                                                    Кстати, по поводу поиска исходника. Если png-диаграмма сделана в plantuml, то картинку можно конвертировать в исходный код. Встроенная функция в плагин plantuml для VS Code. Главное, чтобы там кириллицы только не было, а иначе придется руками надписи переписывать. Это еще один фактор, почему я полностью перешел на plantuml и других мотивирую.

                                                                                                  +5

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

                                                                                                  Считаю, что моделирование и проектирование крайне недооценено для успеха проекта. Ну и мало кто видел действительно качественное проектирование, вот и сформировалось мнение, что оно не нужно.

                                                                                                    +2
                                                                                                    Ну и мало кто видел действительно качественное проектирование

                                                                                                    Мало кто видел действительно качественную разработку в принципе :)
                                                                                                      0
                                                                                                      Какие средства использовали? Конкретно, интересует поддержка версионности возможность легко посмотреть внесенные изменения. Потому что если с текстовой информацией легко справляется diff, git и куча удобных тулов, то с диаграммами ревизия изменения зачастую превращается в игру «найди 10 отличий в картинках».
                                                                                                        0

                                                                                                        Plantuml + Visual studio code (с плагином plantuml) + git для исходников. Для визуализации схемы выгружались в формат svg. Просмотр и ссылки между схемами посредством sharepoint-а. Версионный контроль и сравнение через git.

                                                                                                        Если используется confluence и bitbucket, то можно генерировать диаграммы на странице confluence прямо из кода диаграммы в ветке master, например. Но плагин для этого платный и довольно дорогой.

                                                                                                        Если настроить PlantUML сервер, то можно заиспользовать препроцессинг. Он позволит выносить общие части диаграмм в отдельные библиотеки. Например, можно включить все ИС компании в такую библиотеку, добавить ее в диаграмму через !include, описать взаимодействия и активировать отображение только включенных во взаимодействие ИС. +100500 к унификации.

                                                                                                        Еще есть алгоритмы и инструменты автоматической генерации диаграмм, но до этого я даже не дошёл.

                                                                                                        В общем как инструмент plantuml очень мощный, изучать его можно долго.

                                                                                                      +2

                                                                                                      В современном Skype нет UML и внятного проектирования, а в Telegram очевидно есть. Сравнить нетрудно. И совершенно ясно, что грамотно спроектированная система заведомо лучше тупо нашлепанной по фидбекам. Причем фидбек в грамотно спроектированной системе даже не исключается.

                                                                                                      Но! Бизнес - это не инженерия. По крайней мере современный его этап. Суть не в UML, а в инженерном или маркетинговом подходе. Маркетологи почти всегда побеждают инженеров, пока продукт покупают люди. Сделать крутой продукт это 5 процентов работы. Раскрутить и продать - вот где реальные события разворачиваются.

                                                                                                      А значит - UML неизбежно мертв. Пока в строгих нотациях пилится архитектурно красивое решение у маркетологов (читай бизнеса) уже три раза концепция продукта поменялась. UML просто не успевает в этой дикой гонке. Даже не UML, а инженерия.

                                                                                                      Выход есть - фреймворки. Набор кубиков на все случаи жизни. Условный Spring на backend все больше и все страньше. Но он решает проблему скорости. Скорости разработки. На frontend та же история, тоже фреймворки. И все. UML мертв.

                                                                                                        0
                                                                                                        Вспоминается анекдот про Вольтера и Бога… Эти «одноклеточные» айджалисты и правда верят что могут снести все десятилетние наработки в computer science и software engineering? Пусть сначала рот от смузи вытирать научатся
                                                                                                          0
                                                                                                          Cнесут, и лет за 10 лет переизобретут всё это заново (только уже с JSON вместо XML).
                                                                                                          Вот, например, S-выражения изобрели jsonlogic.com :)
                                                                                                            0
                                                                                                            А начиналось всё с «в JSON никакие s-выражения не нужны»? :)
                                                                                                          0
                                                                                                          Вообще, то, что тут представлено в качестве т.н. «масала-диаграммы», это схема, рассчитаная как маркетинговый материал. Называется она — инфографика, и направлена на широкую аудиторию.

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

                                                                                                          Ощущение, что в статье описан мир человека который никогда не видел программного архитектора и плоды его работы. И не работал на проектах сложнее мобильного приложения.

                                                                                                          P.S.
                                                                                                          У меня складывается стойкое ощущение, что мы начинаем тут по кругу обьяснять малообразованым, неопытным «изобретателям-рационализаторам» какие-то прописные истины.
                                                                                                          Сегодня пиарить свою необразованность, создавая полезную для карьеры медийность, может любой. А инженеров хороших со временем больше не становится.
                                                                                                            +1
                                                                                                            Наоборот, чтобы описать коммуникационную стурктуру каждого компонента, там очень даже нужны диаграммы последовательности, диаграмма деятельности, блок-схемы и пр.
                                                                                                            Почему это просто не закодировать?
                                                                                                              0
                                                                                                              А чтобы снять блокбастер, почему бы просто не выйти актерам на съемочную площадку, оператор там просто все сцены отснимет, которые режиссер скажет. Потом там монтажер сцены в нужной последовательности просто склеит. Звукооператор там звук и звуковые эффекты просто где надо наложит, а цветокорректор там немного с фильтрами поиграет. Ну и там немного эффектов просто добавить, и компьютерной графики где надо. И в принципе готово. Недели за три-четыре управиться можно. А что костюмы и декорации? Не ну они конечно должны быть заранее подготовлены. Ну а так недели три-четыре. Ладно, ну пусть полтора месяца на крайний случай. Что? Сколько миллионов бюджет? Ну тыщ в двадцать уложимся, это если с непредвиденными расходами.

                                                                                                              Как комиксы рисовать? А что их рих рисовать взял и нарисовал. Художник нужен хороший. Сториборды? Раскадровка? Не ну можно сделать, но тогда дольше будет.

                                                                                                              Как компьютерные игры делать? Да вобщем все несложно. Персонажей и предметы смоделировал, анимации к ним прикрутил, там программист потом запрограммировал движения и реакции на события, коллизии например, физику. Окружение создал, карты, освещение и тени где надо проставил. Систему погоды можно прикрутить, ну это покруче если проект, но в принципе все это уже из коробки системами разработки поддерживается. Потом там собрал под разные платформы, выставил в аппстор, рекламную кампанию провел. Все впринципе вполне шаблонно.
                                                                                                              [sarcasm=off]
                                                                                                                0
                                                                                                                А для создания раскадровки нужна раскадровка раскадровки?
                                                                                                                  +1
                                                                                                                  Зря ёрничаете. Ни на съёмках блокбастера ни при рисовании комикса ни при разработке компьютерной игры никогда не бывает «хорошей» документации, как её понимают тут в комментах. Сториборды, раскадровки, даже сценарий — это нифига не UML, это как раз «masala», они дают очень приблизительное представление о том, что должно получиться в итоге, и нередко по 10 раз перерабатываются в процессе. Причём прямой связи между упорядоченностью и качеством результата нет никакой, на проекте может быть умело направляемый в нужную сторону хаос, из которого рождается шедевр, а может быть армейская дисциплина, а в итоге получится полная туфта. Поэтому в этих сферах такая огромная зависимость от личностей, которые могут этим всем как-то управлять.
                                                                                                                    0
                                                                                                                    UML — коммуникационный инструмент (язык, он так и называется) Язык для коммуникации разных стейкхолдеров между собой. Можно плохо описать в любом языке, хоть в естественном хоть в схематичном. Обычно человек не в состоянии держать в голове все механизмы устройства программы, где какие интерфейсы по каким протоколам общаются.

                                                                                                                    Я работал на проекте где были диаграммы состояний и переходов для описания поведения фронтенда, и диаграммы последовательностей для описания протокола коммуникации с железом через интерфейс абстракции. Чтобы связать морду и железо нужен четко очерченый протокол. Т.е. последовательность общения. Оповещения например могут приходить вне очереди, а какие-то данные приходят только по запросу. Или у тебя многоканальная коммуникация, где несколько событий могут влиять на состояние. Типа, пришел сигнал с интерфейса А, тогда данные с интерфейса X нужно представить таким образом, а если не пришл — то другим. А если это под японский рынок то там вообще два сигнала, и решает их комбинация, а под американский — нет функции такой вовсе. И это только касается показывать какой-то там значок в строке статуса или нет.

                                                                                                                    Эти диаграммы предоставлял заказчик, и в тех частях программы где диаграмм таких не было или они были сделаны плохо — разработчики тратили много лишних сил на согласование поведения. Железо и HAL делает один подрядчик, интерфейс к нему -другой, и железо еще и для разных рынков разное. На каждый компонент — свой подрядчик, соседние разделы приложения тоже делают другие подрядчики. На проекте задействовано более 500 человек. Серийное производство. 34 варианта продукта при каждой сборке, и это только основные варианты. Разработка идет внахлест, новый продукт основывается на старом с добавлениями и доработками и ты не можешь начать с чистого листа. Два-три поколения приложения одновременно в одной кодовой базе, до финального вычленения продуктов. И приходится следить чтобы не сломать старый протокол, реализуя новый. А от твоих функций зависят функции других подрядчиков, а работоспособность всей сборки необходима потому, что идет регулярная интеграция с железом и ПО в идеале всегда должно быть рабочим. Просто мало кто себе представляет такой масштаб.

                                                                                                                    И когда у тебя есть такие диаграммы спецификации, ты всегда можешь на них сослаться. Не на пестрые презентации которые «concept, not final», где каждый интерпретирует цвет рамочки по своему, a на жесткую спецификацию интерфейса и протокола коммуникации. На слайдах удобно смотреть новые функции чтобы понимать идею с т.з. пользователя. Моки там, вайрфреймы, все такое.

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

                                                                                                                    никогда не бывает «хорошей» документации
                                                                                                                    Безусловно не будет идеальной документации, но при таком масштабе важно уже не это, а что ту, которая есть, все понимают одинаково. В этом смысл универсального языка моделирования.
                                                                                                                      0
                                                                                                                      Чтобы связать морду и железо нужен четко очерченый протокол.
                                                                                                                      Как можно разработать четко очерченый протокол, не разработав его референсную имплементацию?
                                                                                                                      А если есть референсная имплементация — зачем нужно дублировать ее в виде UML?
                                                                                                                      По мне это просто уход от ответственности — когда архитектор вместо референса программирует в ворде и в случае косяков виноват кто угодно, но не он.
                                                                                                                      А далее вместо простейшего юнит-теста с обращением к референсу, приходится ломать глаза, вглядываясь в диаграмму и пытаясь понять, кто из вас троих мудак — ты, автор диаграммы, или автор программы на другом конце протокола.
                                                                                                                        0
                                                                                                                        Во многих случаях достаточно того же сваггера. Обновили апи — сваггер сам обновился, с доками и прочим. А тут что? Апи обнови, схему обнови, а если апи работает не по схеме то кто виноват? А если для разных веток будут разные схемы и лучше их хранить прямо в гите?
                                                                                                                          0
                                                                                                                          Апи обнови, схему обнови, а если апи работает не по схеме то кто виноват?

                                                                                                                          Тот, кто делал code/documentation review. Он, теоретически, должен был на сопроводительную документацию посмотреть и убедится, что она коду соответствует.


                                                                                                                          А если для разных веток будут разные схемы и лучше их хранить прямо в гите?

                                                                                                                          Да. Именно там и хранить.

                                                                                                                    0
                                                                                                                    Почему это просто не закодировать?
                                                                                                                    Например, потому что кроме «основной деятельности» программы, в коде будут обработка ошибок, логгирование, проверки ввода на корректность/безопасность и т.д и т.п.
                                                                                                                    При мало-мальски сложной логике предметной области, которую реализует программа, читать вычленить «основной смысл» кода будет весьма трудоёмко.
                                                                                                                      0
                                                                                                                      Так мы о проектировании говорим, а не документировании. Цитата: «И если не продумать все в деталях, то вероятность запороть проект взлетит до небес.»
                                                                                                                      То есть делается утверждение: для проектирования нужно не брать редактор кода и не пилить там скрипт, делающий «основную деятельность программы», без излишних подробностей, а брать какую-то визуальную тулзу, и проектировать в ней, дебажа поведение общающихся конечных автоматов в уме. И якобы это ведет к лучшим продуктам.
                                                                                                                      Вот мне это вообще не очевидно.
                                                                                                                  +2
                                                                                                                  Вы уже должны были понять: дело не в каких-то недостатках UML.

                                                                                                                  Автор — евангелист того самого UML и подсознательно не хочет принимать очевидное — дело именно в недостатках UML.

                                                                                                                  Автор не раскрыл предыстории, но до UML были относительно популярны стандарты IDEF, которые использовались для описания различных систем. Пробовались и для софта, но особой популярности не было из-за сложности читания и создания диаграмм. Есть такой чувак — Гради Буч, широко известный в узких кругах, который еще с двумя чуваками и придумал в середине 90-х UML. UML опирался на подход OOP, который в то время казался очень перспективным, а чуть позже появилась Java, которая сильно помогла популярности UML. Буч работал в Rational Software, которая выпустила кучу софта для проектирования и описания софта с использованием UML, в том числе и с поддержкой Java и UML+Java было довольно популярной связкой в конце 90-х, начале 2000-х в энтерпрайзе.

                                                                                                                  Почему UML оказался нахер не нужным большинству? Ответ простой — слишком сложно, долго и муторно. Любые небольшие изменения в софте требовали перелопатить UML-диаграммы. Хорошо, если у вас есть софт, который это помогает сделать, но он платный и вообще есть далеко не у всех. Чтобы просто читать UML — нужно неслабо так инвестировать время в обучение. А чтобы создавать их — нужно еще больше времени. А так как на рынке даже просто грамотных Java-спецов всегда нехватало, то требовать от них еще и знание UML стало несовместимым с рынком труда. Так UML и отошел в сугубо нишевое применение.
                                                                                                                    +3

                                                                                                                    PlantUML генерация UML из текста. Поддерживается в Gitlab из коробки, в IDE (VSCode и JetBrains точно) поддержка добавляется плагинами. Используем для документации и иногда для разработки. Легко вносятся изменения, мержится наглядно (ибо текст первичен). Поддерживаются темы

                                                                                                                      +2

                                                                                                                      Диаграммы последовательности не умрут никогда

                                                                                                                        0
                                                                                                                        Не устану цитировать подслушанную фразу: Agile придуман и продвигается слабоквалифицированными сильномотивированными людьми (с).
                                                                                                                        Квалификация в среднем упала. Предметную область программисты знать не хотят (мы, сегодня АБС пишем, а завтра игру). ТЗ читать тоже не хотят: Аналитик (sic!), дай нам задачку в jire и мы ее сделаем. Даже в огромных проектах нет Главного конструктора или хотя бы Ведущего инженера. В лучшем случае есть Архитектор всего проекта и куча миниАрхитекторов модулей… В общем, тоска…
                                                                                                                          0
                                                                                                                          Отличный перевод ​
                                                                                                                            +1
                                                                                                                            Схемы подобные UML никому не помогли, только навредили. Дело в том что недалекие люди возомнившие себя начальниками отвлекали своих подчиненных на составление этих UML-лайк схем, всем совсем бесполезных, причем без согласование с верхним начальством которым все эти рассуждения об правильности делания проектов вообще не интересны. Из-за этого страдали проекты и их высшее начальство это не оценивало и соответственно этих самых подчиненных увольняло как не справившихся, а с вот с этих начальников среднего звена взятки гладки. Понятно что из-за таких начальничков проекты все равно погибали, ведь занимаются глупостями не от большого ума, но крови попортили многим.
                                                                                                                              0
                                                                                                                              Я бы так сказал… Вместо UML можно подставить много чего другого. Видимо, менеджеры среднего звена вцепились в UML, потому что картинки им понятнее непонятных буковок
                                                                                                                              +1
                                                                                                                              UML был мертворождённым.
                                                                                                                              Чтобы он работал его должны были знать как разработчики, так и бизнес, а на практике знали только аналитики.
                                                                                                                              Смысл в инструменте, который усложняет и увеличивает трудозатраты, потому что в итоге всё равно приходилось описывать процессы и структуру обычными словами.
                                                                                                                                0

                                                                                                                                Использую uml в повседневной работе: activity, state, deployment, enity. Очень удобно и наглядно. Но у нас специфика такая, что платформа интеграционная, тут без схемы потоков никуда.

                                                                                                                                  0
                                                                                                                                  UML — это попытка мыслить системно. Но мне кажется, что этот язык разрабатывался не специалистами по системному анализу и общей теории систем.
                                                                                                                                    –6
                                                                                                                                    мда, грустная тема… даже по комментариям видно, что engineering culture стремительно вымирает. не знать UML из той же оперы, что и не знать алгоритмы т.к. есть фреймворк, который все сделает…

                                                                                                                                    короче, если ты называешь себя инженером — ты обязать знать и использовать UML в дизайне. иначе ты не инженер, а говнокодер. UML — самый мощный и лаконичный инструмент для описания деталей реализации и командной работы.
                                                                                                                                      +4
                                                                                                                                      если ты называешь себя инженером — ты обязать знать и использовать UML в дизайне. иначе ты не инженер, а говнокодер

                                                                                                                                      Сильное утверждение, я тоже так умею:
                                                                                                                                      если ты называешь себя инженером — ты обязать знать и использовать сопромат в дизайне. иначе ты не инженер, а говнарь.
                                                                                                                                      –4
                                                                                                                                      image

                                                                                                                                      Разработка без проектирования.
                                                                                                                                      Работает же! Если чО, то переделаем)))
                                                                                                                                        +5
                                                                                                                                        Обычное такое наоборот происходит, когда во главе всего ставят проект и тщательно его соблюдают, насмотрелся я на подобное уже.
                                                                                                                                        «В проекте написано, банкомат расположить на высоте 2 метра от тротуара — сделали на высоте 2 метра. То, что проект рисовали пол года назад, когда тут было крыльцо с лестницей — ниче не знаем, как было в проекте, так и сделали. Пользоваться нельзя — ну извините. Пишите служебку на имя ГИПа, потом согласуйте еще в пяти местах, подготовьте поправки к проекту, потом нужно добиться выделения бюджета — тогда и переделаем. Главное, чтобы за это время снова крыльцо с лестницей не построили, а то на корточках придется деньги снимать...»
                                                                                                                                        +1

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

                                                                                                                                        Что делает дядя Ашот, если нужно внести изменение в крепление глушителя? "Падажди здесь дарагой, щас Петрович докурит и в пять минут тебе всё как надо приварит".

                                                                                                                                        Наш любимый agile - это и есть методика гаража дяди Ашота, применяемая... да ко всему. Быстро, дёшево, сердито. А что халтура и времянка - так что ты хотел за свой нечастный косарь?

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

                                                                                                                                          +3

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

                                                                                                                                            0

                                                                                                                                            Я говорил не про крепление глушителя, а про деградацию качества инженерных решений при внедрении agile там, где не нужно.

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

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

                                                                                                                                              +3

                                                                                                                                              Нет никакой деградации. Типичный современный продукт на порядки сложнее и технологичнее, чем 20 лет назад.


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

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


                                                                                                                                              Это как если бы в материальном производстве ушли чертежи. Петровичу не нужны ни кульман, ни САПР. У него опыт и сварочный аппарат.

                                                                                                                                              Чертеж в материальном производстве — это часть спецификации. У нас основная спецификация — это код. Любые диаграммы — не больше, чем пояснительные записки. Код никуда не ушел. Инструменты работы с кодом стали на порядки лучше и оказалось, что "пояснительные записки" стали гораздо менее нужны. В материальном производстве то же самое. Работать с САПР удобнее, чем с бумажными чертежами

                                                                                                                                                0

                                                                                                                                                В магнитофоне (в коробке) три схемы: принципиальная, монтажная и кинематическая. В третью можно рыбу заворачивать.

                                                                                                                                                  0

                                                                                                                                                  >>Типичный современный продукт на порядки сложнее и технологичнее, чем 20 лет назад

                                                                                                                                                  Это потому что у нас сильно облегчилось накопление сложности. То, что современный продукт ради того, чтобы показать анимацию, поле ввода и кнопочку тянет в себя гигабайт разнообразных фреймворков, не делает его сложным. Он так и остаётся простым как валенок, а вся его сумасшедшая сложность на 99.9% является либо издержками техпроцесса, либо просто балластом. Следует ли нам гордиться этой сложностью? Ну, не уверен. Особенно с учётом того, что вместе со сложностью частенько возрастает хрупкость.

                                                                                                                                                  >>У нас основная спецификация — это код

                                                                                                                                                  Нет. Вот просто нет, и всё. Я не знаю, кто ввинтил этот тупейший мем в массовое сознание. Почитайте, например, документацию на Реакт, а потом поройтесь в его исходниках. Уверен, вы почувствуете разницу.

                                                                                                                                                    +3
                                                                                                                                                    Сложность у нас в архитектуре. Сейчас повсеместно все распределенное, масштабируемое и отказоустойчивое. Сейчас даже сайтик магазина одежды может содержать такую сложность, которая раньше никому и не снилась. Оно может избыточно для некоторых, но все же.
                                                                                                                                                      +3
                                                                                                                                                      Операционные системы не стали на порядки сложнее чем 20 лет назад?
                                                                                                                                                      Базы данных не стали на порядки сложнее чем 20 лет назад?
                                                                                                                                                      Фреймворки не стали на порядки сложнее чем 20 лет назад?
                                                                                                                                                      <Любая другая область> не стали на порядки сложнее чем 20 лет назад?
                                                                                                                                                        –3

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

                                                                                                                                                        +3
                                                                                                                                                        То, что современный продукт ради того, чтобы показать анимацию, поле ввода и кнопочку тянет в себя гигабайт разнообразных фреймворков, не делает его сложным.

                                                                                                                                                        Ну если у вас продукт только и делает, что показывает кнопочку, то, конечно, да. Впрочем 20 лет назад и показать кнопочку с анимацией было не то чтобы просто, кажется.


                                                                                                                                                        Почитайте, например, документацию на Реакт, а потом поройтесь в его исходниках. Уверен, вы почувствуете разницу.

                                                                                                                                                        Может быть это просто плохой пример?

                                                                                                                                                          0

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

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

                                                                                                                                                            0

                                                                                                                                                            При чем тут документация? Речь о спецификации результата и код тут единственно возможный вариант. Точно так же как из чертежа бывает сложно понять, что это за деталь и зачем она нужна, так же и из кода бывает сложно понять что он делает и зачем. Это нормально.


                                                                                                                                                            Во-первых, все очень просто. Если код непонятен — это либо хреновый код, либо неподготовленный читатель. Понятный код — это внятные абстракции и простые связи между ними. Если это соблюдается — любой код читать относительно просто, если нет — проблема в консерватории. Бывают исключения, связанные с теми или иными ограничениями (перфоманс, недостатки инструментов и языков etc), но никакие UML диаграммы тут не помогут. Тот же "визитор" — это лишь всего-лишь костыль, обходящий недостаточную выразительность языка, который на уровень проектирования совершенно непонятно зачем выносить.


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

                                                                                                                                                          +2
                                                                                                                                                          а вся его сумасшедшая сложность на 99.9% является либо издержками техпроцесса, либо просто балластом
                                                                                                                                                          Современные продукты кроссплатформенны, имеют много UI фишечек, могут работать в лагающей интернет-среде, многие автоматизируются (побочный эффект перехода на клиент-сервер и текстовые протоколы), а по качеству несравнимы с типичным для нулевых синхронным локальным windows-only кодом.
                                                                                                                                                          Можно, конечно, сказать, «а вот %проганейм% так могла в 2003, а сейчас %другаяпроганейм% так не может», но это будет ошибкой аргументации.
                                                                                                                                                          Почитайте, например, документацию на Реакт, а потом поройтесь в его исходниках. Уверен, вы почувствуете разницу.
                                                                                                                                                          Это будет разница между чертежом и инструкцией по эксплуатации.
                                                                                                                                                          Я не знаю, кто ввинтил этот тупейший мем в массовое сознание.
                                                                                                                                                          Тупейший мем — это представление, что код не является частью конструкторской документации, а что это что-то типа пола, стен, потолка и прочие стоительно-машиностроительные метафоры.
                                                                                                                                                        +1
                                                                                                                                                        Бывает крупносерийное, мелкосерийное и единичное производство, а также опытное. Отличаются они отношением стоимости выпуска партии к стоимости выпуска изделия. У разработки ПО оно примерно 1:1, оно максимально близко к опытному производству. Нет, миллионы потребителей ситуацию не меняют. Так же, как крупносерийным производством не является съемка фильмов, хотя баги в продукте могут огорчить миллионы. Это все равно штучная работа, которая потом тиражируется безо всяких усилий.
                                                                                                                                                        Опытные образцы на любом фольксвагене изготавливают свои Петровичи — у них свои станки, заточенные именно под штучную работу, свои бюджеты, и вообще сплошной аджайл. А далее возникает головная боль — адаптация к конвееру. И начинается — мелкая серия, испытания, крупная серия, испытания. Так много испытаний не потому что опытные образцы менее надежные, они более надежные, потому что разработчики их изучали под микроскопом, а потому что каждый этап масштабирования производства вносит новые ошибки и неопределенность.
                                                                                                                                                        В программировании же проблемы «адаптации к конвееру» нет. Та конструкторская документация, которая собирает опытный образец, точно так же собирает и миллион образцов. А если хочется надежности — нужно много QA, чудес не бывает. Софт ненадежен, потому что экономят на QA. В том числе и потому, что недобросовестные просиживатели штанов предпочитают программировать в визио и «ой, мы ща как макулатуры наплодим — и будет все надежно-надежно, платите мне, а не тестерам». Ну да блин, архитекторы у нас — гении, которые умеют программировать в визио и учитывать все нюансы. Знаем таких.
                                                                                                                                                        Такой подход в прошлом — результат того, что менджмент компаний компьютер первый раз в жизни увидел в 30 лет. Они тупо перенесли привычные практики, не очень понимая их суть. Глупо ожидать чего-то иного, если им для перехода на удаленку потребовался целый ковид. Но софт тех лет такая же забагованная хрень, как и всегда.
                                                                                                                                                          0
                                                                                                                                                          А если хочется надежности — нужно много QA, чудес не бывает.

                                                                                                                                                          Хочется не только надежности. Хочется того, чтобы вот лет через 10 после того, как проект как бы сделан (и до сих пор эксплуатируется, ага), те люди, к которым он в руки попадет для модификации, могли что-то понять, не потратив предварительно год на разбор кода.

                                                                                                                                                            0
                                                                                                                                                            Мой пост был о проектировании. Для документации UML в целом не плох и скорее даже хорош. Спасибо за посты с утилитами, положил в копилку многое. Но излишне подробная документация — зло, потому что через 10 лет никому эти подробности вперемежку с багами не будут нужны.
                                                                                                                                                    0
                                                                                                                                                    Году в 2011 работал в одном банке, где все описания систем были в UML в Sparx EA. Но там были очень длинные циклы разработки и ТЗ писалось по несколько месяцев, а в прод попадало хорошо если месяцев через 8, что было малоприемлимо для бизнеса. UML очень неплох, когда нужно реверснуть что-то и сохранить эти знания хоть в каком-то виде (ну не текстом же писать). Но как правильно написали, без знания нотации — никому это не нужно.
                                                                                                                                                      0
                                                                                                                                                      Оно повсеместно так даже там, где UML не используют. Однако вы предпочтете доку с парой диаграм той, где сплошной текст? особенно если у вас постоянно до 5ти разных пректов для разных клиентов. Хорошие диаграмы ониж как иероглифы схватываются сразу
                                                                                                                                                      0
                                                                                                                                                      В защиту UML могу сказать одно — в некоторых случаях реально дает понимание происходящего в бизнес процессах. Есть опыт из компании, в которой я впервые начинал работать. Московские ребята внедряли надстройку(модуль не знаю даже как назвать) для 1С, которая по факту с реальным миром ну вообще не пересекалась. Стоило ребятам нарисовать схемы, чуть погрузиться в предметную область — и всё стало на свои места. Ну и согласен с комментариями выше про ПО для рисования схем — ещё в университете приходилось с того же Rutracker'a качать ломанные старые программы, чтобы в диплом нарисовать эти UML/IDEF0/IDEF3/ диаграммы.
                                                                                                                                                        0
                                                                                                                                                        Ну хорошо, проект «с нуля» можно таким образом даже отполировать, сидя в продакшене всем отрядом в ожидании чудес. Но после определенного кол. +1 проектов и смены учавшестников, кто сможет ответить на вопрос — «а как оно работает?», или еще хуже — «Теперь нужно чтобы оно эдак работало, что нужно для этого?»
                                                                                                                                                          0
                                                                                                                                                          а как uml поможет в этом же случае? или uml сам под текущую реализацию переписывается?
                                                                                                                                                            0
                                                                                                                                                            Я говорю о user-stories — они, как замена uml в данном случае не выступают. В статье, UML и «обуза» в виде спецификаций, выглядят как оппонент «легкомысленым» user-stories. но я не представляю как без спецификации на систему можно впихнуть очередной +1 проект. Верней представляю, иногда у нас тоже такое практикуется: можно начать с исходников и пойти и предположениями, либо найти человека, кто был участником хоть какогото +1 пректа и пытать его непонятными (даже для себя) вопросами. В обоих случаях и девелоперы и имплементаторы остаются недовольны: «не разъяснили им как нужно… а еслиб спецификация бы была бы..»
                                                                                                                                                          +1
                                                                                                                                                          Сколько трагизма в этих словах. Но ни слова о том, собственно, а какие задачи то вы решали с помощью UML… Какие типы диаграмм использовали? Что именно не было востребовано клиентами?
                                                                                                                                                          UML это одна из многих нотаций. Точно так же можно разочароваться в любом инструменте моделирования, если неправильно его использовать.
                                                                                                                                                          Вобщем бездоказательно вы как то это все тут написали. Ну а уж про agile ну как то вообще не понятно. Ну не вошли юзерстори, ну не используй их, а UML то тут при чем?
                                                                                                                                                          Хорошо, допустим от UML отказались. А чем таки заменили то? Или просто отказались и все?
                                                                                                                                                            0
                                                                                                                                                            Никогда не понимал, для чего УМЛ нужен, и никогда им не пользовался за все многочисленные годы разработки софта. И даже, когда начальство требовало предоставить им эту хрень, старался перебросить эту задачу на кого-то другого ;-)
                                                                                                                                                              +1
                                                                                                                                                              UML нужен при разделении труда: алгортимист рисует UML и передаёт его кодеру, который и пишет код в точности по UML.
                                                                                                                                                              А когда вместо алгоритмист и кодера — один человек программист, то UML оказывается невостребованным.
                                                                                                                                                                +2
                                                                                                                                                                Да, помню, было такое. Лет 40, а скорее — 50, назад… Тогда ещё не было Algol-а. ;-)
                                                                                                                                                              +1
                                                                                                                                                              Boeing никогда бы не заказал у Rolls Royce реактивный двигатель на основе подобной неформальной масала-диаграммы.

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

                                                                                                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.