Комментарии 185
Перевели всё-таки...
И только в высоконагруженных или нестандартных задачах этап планирования достаточно подробный, чтобы для него нужен был отдельный язык. И этот язык —
Дело не в UML. Дело в падении образования, если коллеги перестают отличать планирование от проектирования. UML, как я привык думать, это как раз про второе.
Ремесленный подход, взять удобный для себя фреймворк, как — то реализовать в нем хотелки клиента и с чувством выполненного долга называть себя программистом. Я не спорю, это тоже нужно, возможно, большинству заказчиков только это и нужно — примитивное отображение его рабочих процессов в интерфейсе системы. Но для этой деятельности много ума не надо, хорошо подвешенный язык, немного знаний об избранном языке программирования, немного знаний об избранном фреймворке, и все.
не спорю, это тоже нужно, возможно, большинству заказчиков только это и нужно — примитивное отображение его рабочих процессов в интерфейсе системы
Вы так говорите, как будто взять и просто решить задачу, это плохо :)
Если это промышленная система, где надёжность, безотказность, много лет поддерживать и расширять не методом «напишем с нуля» — это отвратительно.
Если это промышленная система, где надёжность, безотказность, много лет поддерживать и расширять не методом «напишем с нуля» — это отвратительно
В каких-то частных случаях задач в частных случаях систем — да. В общем случае и там точно так же успешно действует подзабытый принцип KISS. Простое и быстрое решение в общем случае лучше сложного и обвешенного бюрократией. Потому что
1. Простое и быстрое — не означает «ненадёжное» или «трудно поддерживаемое»
2. Тщательное глубокое проектирование не означает получение надёжного и масштабируемого результата.
3. С увеличением сложности решения надёжность снижается, количество точек отказа и потенциальных ошибок увеличивается.
4. А ещё примитивное отображение рабочих процессов в системе (как бы ни иронизировали на тему «автоматизированного бардака») означает, что решение сразу и практически гарантированно будет функционировать. В то же время в случае перестройки рабочих процессов в формулу успеха добавляется изрядное количество человеческого фактора, который легко может похоронить проект.
Это очень утрировано, но вроде мысль понятна. А вообще, низкий уровень работы и так описан кодом, а для понимания связности блоков мансала вполне удобно выглядит.
Если мы ведем речь о ПО для ядерных реакторов или самолетов, то тут вы правы бесспорно. Но если речь идёт о каком-то интернет-сервисе, то пока Вася планирует, проектирует, разрабатывает, Петя хренак-хренак на коленке, криво-косо выкидывает в продакшн MVP. Через год-два Петя уже обрастает клиентурой, и уже может нанимать людей. А Вася, сделав крутой, качественный, проект, внезапно осознаёт, что, во-первых, рынок занят, а во-вторых, изменились требования — и его наработки устарели, еще не взлетев. Поэтому Вася, понурив голову, идёт к Пете с резюме.
Совсем нет. Частные заказчики позволяют существовать программистам не только в рамках больших корпораций.
На эстраде проблема не в том, что Оля Бузова поет плохие песни, проблема в том, что через 20 лет они станут классикой. В программировании та же история, выживают простейшие.
Утратило популярность само планирование.Ситуация существенно хуже. Утрата планирования это следствие отсутствия адекватного целеполагания в разработке. И категорическое нежелание оценивать эффективность изначальной задуманной идеи. Т.е. необходимо демонстрировать деятельность, что-то разрабатывать, писать отчеты, в которые никто не вчитывается и которые мало кто понимает. Оценивать результаты деятельности категорически отказываются. Это засилье дилетантов и театрально-показательного подхода в руководстве. Платят не за результат, а за демонстрацию усталости, управленческие фантазии, гору кода и потраченное время жизни разработчиков. И Agile со всей его умопомрачительной театральностью и показательностью напряженной работы рабов тут как нельзя к месту.
Когда рисуется масала-диаграмма ее может до некоторой степени понять (или думать, что понял) любой дилетант. А вот UML хоть немного, но надо учить. Никто из руководителей и бизнес заказчиков этого делать не будет.
Zanak
Дело в падении образованияДело не в падении образования, а в деградации подхода ко всему IT. Каждая дворняга считает себя специалистом в IT. У начальника есть сын-балбес, которого он считает светилом в IT и специалистом по нажиманию кнопок на всех компьютерах. А тут какие-то придурки, чтобы начальник понял что будут разрабатывать, требуют от него учить нотацию UML. Не будет он этого делать. Дело не в падении образования, а в торжестве невежества. При этом работу в среде полного невежества называют софт скилами.
И вы думаете, что такая деградация в разработке только в дефолтовой стране? Посмотрите на новый Skype. Новые разработчики сломали почти все что могли сломать в старом Skype. При этом нахерачили лайки, обратную связь, и продолжают добавлять и громогласно рекламировать странные фичи при кривой и не исправляемой основной работе мессенджера. За то деньга капает и гиря пилится.
Можно называть это деградацией, но, как вы говорите, "деньга капает", а значит, это работает. Деньга же появляется не из ниоткуда. При этом мы живём в условиях рынка, т.е. если бы описанное вами было изначально неверным подходом, то оно, по идее, должен было бы вскоре затухнуть из-за безоговорочных побед конкурентов с более формализованными/бюрократизированными подходами. Но оно продолжает жить и внедряться, так что, возможно, это c'est la vie, с которым нужно просто смириться :)
Ну очень часто деньга капает совсем из других источников, а сам продукт убыточный на постоянной основе
Если цель - просто проесть деньги инвесторов, то уже как бы всё равно, agile там или не agile, если результат заведомо известен.
Вот про Скайп в точку. С каждой версией всё тормознутей и глючнее :(
Хотя уже давно Teams появился...
Имхо, Teams существенно хуже Skype.
Лично у меня он сильнее тормозит. Переключение между чатами медленное.
Отвратительный текстовый редактор.
Иногда в нем тормозит ввод текста, это же просто немыслимо
Непредсказуемый wysiwyg markdown ввод.
Вставка форматированного текста может провести к тому, что к обычному тексту он не возвращается (например, вставил список)
Жутко тормозит редактирование сообщений
Нет цитирования/ответа
Изображения регулярно не прогружаются
Да, шило на мыло... Ещё что в тимсе очень бесит, так это кружок статуса на таскбаре. Статус показывает свой, а фамилию человека, с которым последний раз был открыт чат.
В общем что что, а мессенджеры микрософт так и "ниасилил" :(
А недавно, так просто слов цензурных нет: решил отправить видеофайл, который спокойно открывается браузером и проигрывателем. Перетащил файл в вайбер и вайбер завис, причем завис так, что даже после перезагрузки компа продолжил висеть. Я уже думал удалять гада, но вспомнил про телефон, зашел с телефона и оттуда смог удалить отправленное видео, только после этого вайбер на компе стал работать.
это который без телефона не работает совсем?
А упомянутое приложение Viber (для Windows), по-моему, как будто работает через какой-то ортогональный сервер: последствия его использования, если вдруг Viber на смарте удалён, предсказать сложно. Я, к примеру, полгода назад столкнулся с тем, что новые чаты, заведенные в ПК-приложении пока Android-приложение временно отсутстовало на смарте, не синхронизируются со смартом вообще никак…
Просто разрыв шаблона какой-то: а что так можно? :)
В контексте данной статьи было бы интереснее узнать от инсайдеров, у какого мессенджера при разработке аджайл позабористее был :)
И соглашуть, и не соглашусь. В каких-то проектах достаточно "масала-диаграммы", поскольку ни заказчик, ни исполнитель не знают, что реально надо получить, и идут к этому итерациями. Или наоборот нужно воспроизвести стандартный функционал с минимальной кастомизацией. Да это облегчает жизнь некоторым людям. Насколько это эффективно — вопрос двоякий. В других проектах это не работает. И да, будут сделаны ошибки, но в конечном итоге система прийдет в баланс, будет планирование, будет проектирование и тп. Поэтому говорить о деградации наверное не стоит, просто произошло разделение проектов по методам разработки.
Что касательно UML как такогово, то он сам себя и убил, как только стал стандартом. Стандарты/унификация — это замечательно, позволяет уменьшить сроки разработки и тп, но другая сторона этой палки — стагнация, а жизнь уходит вперед.
О, да!
"Выйти из скайпа" в трее меня в лоб убило...
Историческое наследие, которое сразу и резко ломать нельзя. Так-то они сейчас все постепенно в одну кучу стягивают
Вместо того, чтобы продумывать процессы в системе, её набрасывают в общих чертах (так, нам нужна БД, резервная БД, бэк на ноде, потому что мы её умеем, и редиску не забыть) — и сразу бросаются делать MVP. А поскольку все компоненты из проекта в проект одинаковые, то это всё «само собой» соединяется.
Точно, раньше же круче было. Можно было два года рисовать диаграмки, только для того, чтобы понять, что требования давно изменились, да и сам продукт потерял актуальность.
Легаси ад будет в любом случае, тк диаграмки перестают соответствовать реальности еще на этапе их имплементации. А к моменту, когда они действительно понадобились, через X лет, они представляют исключительно исторических интерес и к действительности не имеют ни малейшего отношения. Наблюдал неоднократно. Тут комментарии в коде мгновенно становятся не актуальными и теряют смысл, а вы хотите, чтобы артефакт лежащие отдельно от кода и никак с ним не верифицируемые, были хоть зачем-то полезны.
Пример про рисование диаграмок на протяжении нескольких лет без создания реального продукта — это не голые слова, а печальные реалии многочисленных проектов периода расцвета uml (~2000-ые). Все движение в аджайл возникло не на пустом месте. Людям нужен был продукт, а не набор артефактов в розе и тп продуктах
А глядя на скорость работы и UI большинства UML-редакторов — современные программисты впадают в депрессию.
Это тоже, ну такое… дорогой в ад попахивает, в 2000-ые у нас уже были, например, perl и cpan, где были пакеты для чего угодно. Но это другой вопрос.
UML, когда он используется без фанатизма и излишней формализации, не плох как универсальный язык для общения, записи каких-то идей, но проектировать систему от и до — это явный перебор.
Опять же — это все было еще в Смоллтоке и других средах, просто сегодня стало намного доступнее.
Подкину по теме "Несеребряные пули или кратко про методы софтостроения"
Нет, не лучше. Чрезмерная локализация в угоду узнаваемости для аудитории, не желающей расширять свою эрудицию и желающей оставаться в рамках национальной специфики — убивает узнаваемость терминов. А желающий понять иронию, но не знающий значения слова — в секунду гуглит, что такое масала.
Меньше «локализации» — меньше перлов типа "написание программ на языке высокого уровня С++ для персональных ЭВМ".
А я поддержу Мориарти. Масалу не надо переводить, это ещё и отсылка к индусам.
1. Вы поставили минус статье за непереведенные картинки?
2. Вы считаете что переводчик должен был «пересобрать» иллюстрацию и вставить фотографию солянки/винигрета?
В гугле по запросу "masala diagram" на первом месте выводится именно оригинал этой статьи. То есть никакой это не узнаваемый термин, а авторская метафора. Поэтому для удобства читателей лучше её перевести (ну или хотя бы добавить "прим пер." с дополнительным контекстом).
Я не соглашусь с автором и снова повторю свой любимый тезис по этому поводу. UML умер потому, что он графический. Что практически целиком убивает совместную работу и работу с Version Control. Т.е. упомянутый анализ и проектирование в результате завязывается на одного человека. Плюс рисовать эти картинки — довольно так долго и утомительно. Т.е. сам цикл анализа и исправления соответствующих результатов замедляется.
Был бы этот UML нормально-текстовым, а картинки — генерировались бы из текста для удобства просмотра — может бы и использовали бы.
Кроме того, он таки язык. Если окружающие не учить семантику значков и постоянно их не используют — то для них оно ни чуть не полезнее этих самых "масала-диаграмм".
В статье упоминается graphviz - инструмент достаточно мощный чтобв в т.ч. описыватт uml текстом. Вот только вдобавок к знанию uml, аналитикам придётся учить еще и dot, учитывая то, что этот инстркмент не специализирован именно на uml. До популяризации git, были распространены и другие системы контроля версий (кое-где и до сих пор используются), в т.ч. те, в которых можно блокировать бинарники перед измением. С данной фичей, совместная работа с бинарниками вполне удобна.
В статье упоминается graphviz — инструмент достаточно мощный чтобв в т.ч. описыватт uml текстом.
Он еще PlantUML забыл, Но это неправильное использование текста. Потому что в этом случае текст не содержат нужной семантики, а просто рисуют картинку. Весь этот анализ должен описываться именно в языке, где есть нужные смысловые термины и конструкции.
draw.io тоже штука крутая и хранит в тексте
То же возражение. Оно хранит картинку, а не ее смысл.
Особенно с учетом, что правильное отрисовка графа задача неформальная и текстом это не опишешь.
А не надо. Если оно красиво само не нарисовалось — значит, описание слишком сложное и надо его на кусочки разрезать. Или прямо так с текстом и работать. Как с текстом программ работаем, а не рисуем сложно-запутанную схему вызовов или блок-диаграмму.
То же возражение. Оно хранит картинку, а не ее смысл.
Это понятно, я не спорю, что это тоже неправильное использование текста. Но они хотя бы смогли мержи сделать и совместное редактирование. Явно не в последнюю очередь благодаря текстовой структуре.
А не надо. Если оно красиво само не нарисовалось — значит, описание слишком сложное и надо его на кусочки разрезать. Или прямо так с текстом и работать. Как с текстом программ работаем, а не рисуем сложно-запутанную схему вызовов или блок-диаграмму.
Не бывает так. Речь о том, что человек банально хочет определенное расстояние между блоками, определенный их порядок, местоположение. Все это словами описывать что ли? Куда проще это делается перетаскиванием блоков мышкой. Поэтому я не уверен, что получится сделать подобный язык описания диаграмм, которым люди реально захотят пользоваться.
Вот с openapi там все просто. Процесс трансформации кода в HTML страничку полностью формализован.
Речь о том, что человек банально хочет определенное расстояние между блоками, определенный их порядок, местоположение.
Ну, что graphviz, что yEd, который является демонстрацией работы соответствующей коммерческой библиотеки, как-то более-менее справляются. Не, диаграмму можно и руками поправить, но обычно оно бессмысленно.
Поэтому я не уверен, что получится сделать подобный язык описания диаграмм
Я не про язык диаграмм, а про язык описания того, что UML пытался описывать. Т.е. архитектуры и так далее.
Дык, все равно конечная цель получить на выходе картинку.
Нет. Конечная цель — понять описание системы. Картинка да, исключительно для иллюстрации для тех, кому почему-то так удобнее.
В чисто графическом виде он хотя бы как-то понятен людям.
Большая часть его диаграмм за небольшим исключением — совершенно непонятен без знания смысла символов. И тут возникает вопрос, который я не в первый раз задаю — эти самые люди (аналитики и прочие близкие к ним люди) почему-то могут выучить смысл формальных графических значков, но не могут выучить смысл формального синтаксиса и грамматики? Это как?
Но тут похоже всплывает недостаток UML как подхода, который пытается мир ИТ и бизнеса состыковать этими диаграммами. Если картинки оставить бизнесу, ИТ дать язык описания архитектур, и продумать какой-то мостик между этими мирами, то наверное получится.
Не забываем, что бизнес вполне читает законы/договора/инструкции и прочие весьма немаленькие и сложные текстовые документы. Т.е. с текстами работать умеет.
И я не очень понимаю, почему принято считать, что для него прямо таки необходимо увидеть все в простых неформальных картинках, а не, скажем, в дюжине столь же неформальных текстовых строк.
Человеческий текст и программный код это разные вещи. Любую uml-диа6рамму можно описать человеческим текстом, но будет гораздо менее наглядно и, как следствие - ошибку допустить становится проще.
С другой стороны, на диаграмме часто иллюстрируют чтото нетривиальное с кучей объектов и связей, следовательно, вариантов того, как это изобразить, будет множество. И большинство - не удачные. Значит, любая тулза практически гарантированно не будет рендерить самое удачное представление. И тут мы приходим к двум вариантам:
Довольствуемся тем, что получается (но, скорее всего, такой результат никому не нужен)
Внедряем в текстовый формат разметку, определяющую, как лучше отрисовать. Пример - формат bpmn. Там есть формально-описательная часть, где описаны основные элементы, и часть, описывающая в т.ч. координаты и размеры элементов. Получаем текстовый формат, с которым уже можно работать, но.... Если работать с софтом, позволяющим редактирование диаграммы, получаем выхлоп с силь переменчивой второй частью и, как следствие, повышенную вероятность конфликтов, в итоге такой формат будет не сильно лучше бинарного формата, ну либо им смогут пользоваться только программисты.
И я не очень понимаю, почему принято считать, что для него прямо таки необходимо увидеть все в простых неформальных картинках, а не, скажем, в дюжине столь же неформальных текстовых строк.
И там и там речь о неформальном. В этом и смысл. Диаграмма UML может восприниматься неформально, а уж неформальные диаграммы бизнесу тем более знакомы. Программный код, который эту архитектуру описывает, нет. И бизнес не работает с подобными вещами, чтобы опираться на какой-то другой опыт. Поэтому чисто наименьшее сопротивление будет у UML диаграмм, а еще лучше просто неформальные картинки и описание. Вон на последнем вроде все и остановились.
Борланд сделал штуку, рисуешь UML, потом компилируешь в программу. Но она взлетела не сильно, а на фоне этого вектора развития Дельфи перешла другим владельцам. В итоге загнулся и Борланд.
До это был продукn Rational Rose Realtime, который умел тоже самое только не в Java, а в С++.
Насколько я знаю сейчас довольно много продуктов BPM которые используют нотацию UML:JBPM/Activity или WWF.
Кстати RUP проповедовал итерационный подход задолго до Agile.
При этом это в чистом виде графический код.
И рисовать блюпринты весьма удобно. Начинающим часто быстрее чем код писать, потому что есть контекстная помощь.
Почему этого всего не было в UML? Как видно дело не в графическом представлении. Просто никому не надо было.
При этом это в чистом виде графический код
неужели прям как .jpg хранится? Нет же.
Так что выглядит, как будто дело именно в графическом представлении, потому что без нормальной IDE не работает. Unreal себе сделал — вот у них и работает. А если в условном пейнте рисовать...
mermaid-js.github.io/mermaid/#
Был бы этот UML нормально-текстовым, а картинки — генерировались бы из текста для удобства просмотра — может бы и использовали бы.
Так ведь был же такой вариант языка! (Правда, только для интерфейсов, последовательности и прочее подобное не поддерживалось). Он назывался IDL, и помимо возможности версионного контроля (благодаря текстовости) обладал ещё кучей киллер-фич. (Например, все IDE того времени под самую популярную платформу того времени умели из IDL — через .tlb — генерировать кодо-заготовки). Картинки из него тоже можно было строить. Как результат, в нашей компании он полностью вытеснил UML через год-другой (с UML работа просто удваивалась и не было гарантий, что программист не напишет всё по-своему, сделав документацию нерелевантной). Ну а потом всякие дотнеты свели всё, что можно и нельзя (от разметки до документации), обратно к ЯП. Всемирная история, банк Империал ^^
Дотнеты еще WSDL пропихивали — причем вроде как стандартный, но специально сделанный «чуть-чуть» несовместимым.
Э-э-э, чуть-чуть несовместимый с чем?
А чтобы клиента на другой платформе сгенерировать — приходилось предварительно WSDL через XSLT прогонять. Но это лет 10 назад было — я уже подробностей не помню. Помню, что в ADFS то же самое было — их assertions «понимали» далеко не все системы, спокойно работавшие с identity providers других вендоров.
UML умер потому, что он графический.
Не надо путать визуализацию и хранение. *.uml — вполне себе XML, положите его в git или еще куда и радуйтесь.
К сожалению, я видел такой XML, описывающий диаграмму, лежащий в git. Если формат изначально не затачивался на то, что его человек читать будет — этот xml ничуть не лучше бинарника. Ну показывает diff что какие-то строчки в рандомных местах изменились — а что это означает? А если у нас конфликты по мержу этой самой диаграммы — то вообще ничего сделать нельзя.
Диаграммы в репо кладут для того, чтобы можно было контролировать и ревьювить их изменения. XML с этим не очень помогает. А graphviz — вполне читаемый на ревью PR.
Картинки в репу класть не надо, есть прекрасные человекочитаемые нотации, которые можно и в репу положить, и почитать, если уж картинки не нравятся — см. PlantUML, например.
Эджайлу и прочим модным вещам UML как и проектирование системы заранее вообще не противоречит. А уж полезность графических нотаций обычно недооценивают, а потом берут на вооружение даже самые модники мира разработки. Оказывается, графическое изображение, например, взаимодействия 5 сущностей намного проще воспринимать и обсуждать, чем сбивчивое объяснение с маханием руками в зуме.
Относится это, кстати, не только к UML, но и прочим графическим языкам. BPMN например )
Собственно, так и работаем. Этап проектирования никуда не делся, но проходит в головах и на бумаге. На выходе рисуется общие неформальные схема железа, софта, компонентов. Как оно с кем взаимодействует и зачем. Но сама схема при этом предельно простая и не используется десяток разных форматов стрелочек и фигур. Всем более менее из функционала и так понятно, что оно делает и зачем. А что непонятно проще парой предложений описать. Плюс за время разработки все десять раз поменяться может. Заказчика тоже вполне устраивают такие схемы, т.к. он их интуитивно может понять.
Хотя с обратной стороной этого всего тоже постоянно сталкиваешься. Упомянутый openshift вот. Часто для таких систем нужно понять write-path, read-path. Четко понять, что какой компонент когда делает и зачем. А никто задачей описания этого даже не занимался. Только и остается по крупицам комментарии расшифровывать или копаться в исходниках, если они вообще доступны.
Всмысле знать не будет? Это все ложится в схемы и описание системы. Да просто сам код, выбранные библиотеки, протоколы, базы и прочее, все продиктовано этими решениями.
Логическая ошибка заключается в том, что подразумевается следующая конструкция: «взрослые дяди годами моделируют и создают макулатуру при создании надежных вещей типа самолетов, следовательно это моделирование и макулатура и создает надежные вещи».
Нет. Надежные вещи создает злой QA. А моделирование и написание макулатуры по моделям — это от бедности и является неизбежным злом. Прототипы в мире, отличном от разработки ПО, — штука крайне дорогая, а труд инженеров — нет. Приходится заменять реальные прототипы виртуальными моделями, и по ним делать выводы, максимально откладывая создание первого прототипа. Моделирование штука тоже дорогая, но дешевле прототипов. Неизбежное зло.
Но подобный процесс не делает самолеты автоматически надежными. Наоборот, появляются точки расхождения между кучей моделей и реальным изделием. Но если собрать и испытать реактивный двигатель стоило бы 1 цент, конечно боинг бы просто его купил, обвесил датчиками и испытал — и это было бы более надежно и информативно.
В случае программ, в подавляющем большинстве случаев нажал F5 — вот он твой прототип. Моделирование не просто не требуется, оно вредно. И целью должна быть понятность кода — через создание DSL, разного рода визуализаторы и прочую машинерию. А диаграммы нужно оставить там, где они и нужны — для эскизного проектирования и иллюстраций. А не для того, чтобы быть более плохой и плохо отлаженной версией кода.
Но хотел бы добавить от себя ещё следующие аспекты:
1. Широкой публике намного сложнее понять уродливость очередной инкарнации Skype по сравнению с уродливостью новой инкарнации автомобильной марки или уродливым новым зданием.
2. По Марксу — мы переживаем финальную стадию консолидации производства, когда почти всё в конечном счёте принадлежит финансовым монстрам. Их финансовые возможности несопоставимы с возможностями независимых стартапов. Конкурентной борьбы в главных сферах программирования практически нет. Эффективность и качество востребованы существенно меньше, чем 50 или даже 20 лет назад.
3. «Кровавый энтерпрайз» полностью анонимизировал труд разработчиков, превратил их в безымянных кочевников. В этих условиях атрофируются чувства стыда и гордости за сделанную работу.
4. Немыслимое для других отраслей удешевление основного ресурса — hardware — часто сводит на нуль необходимость качественного проектирования. Зачем тратить сумму х с целью ускорить работу на у процентов, если можно на те же деньги арендовать z новых серверов и ускорить работу св к*у раз?
И тем не менее, UML не мертв. Просто прошёл хайп связанных с ним надежд, ожиданий и спекуляций. Производители UML-tools не разорились и не перепрофилировались. Половодье интереса схлынуло, оставив после себя по-своему хорошо функционирующую систему озер с развитой экосистемой. Вопрос в том, где вам сейчас приходится работать — в сухой степи или у озера, где по утрам плещется рыбка.
ну да, если вспомнить, что проектирование изначально нужно было для снижения затрат на переделывание. А если затраты на переделывание сопоставимы с проектированием, то смысл в проектировании отпадает
Если бы ученые и инженеры не занимались моделированием законов физики и т.д., то они могли бы совершенно обосновано бесконечное количество раз пытаться строить вечный двигатель. А че такого, ведь попытка ничего нам не стоит, глядишь и выгорит.
Кроме всего прочего, проектирование позволяет не только сберечь деньги, но еще и показать наиболее оптимальное решение из всех возможных.
Но если и это не имеет значения, то да, можно лепить че-попало, лишь бы работало, и гордо рассказывать всем о том, что ты ваще-то технический специалист и решаешь сложные инженерные задачи… методом тыка.
Смысл в проектирования заключается в том, чтобы не тратить усилия на реализацию неработающей ерунды.
А это просто так не работает:
Кроме всего прочего, проектирование позволяет не только сберечь деньги, но еще и показать наиболее оптимальное решение из всех возможных.
Метод полного перебора, комбинаторика, метод проб и ошибок, научные опыты — зачем все эти сложные действия, если можно просто:
Все эти сложные действия только для тех задач, в решении которых они могут быть единственным выходом.
А это просто так не работает:
Ну а кто сказал, что хорошее решение должно даваться легко?
Хотя с другой стороны, кто сказал, что кому-то вообще нужно хорошее решение?))))
Здесь же предлагается перед созданием чертежа паровоза сначала сделать UML-модель чертежа паровоза, в которой все нюансы вплоть до габаритных размеров отдельных деталей уже учтены, и, только построив эту модель, приступать, собственно, к черчению.
Говоря еще проще: как можно пользоваться сложным языком формализации задачи, если в половине случаев заказчик сам не может внятно сформулировать требования, а во второй половине случаев непонятно, как именно эти требования реализовать? Под UML остаются известные задачи, решаемые известными способами, но в современном айти такое не то что не формализуется - такое спрашивают у джунов на первом собеседовании.
Я ещё UML использую, когда нужно заниматься реверс-инжинирингом легаси. Как раз недавно подкинули задачу - есть модуль, написанный пред-предыдущими исполнителями, как именно он работает не знает никто, точных требований не знает даже заказчик. И от меня требовалось понять и описать что там происходит. Выбрал как раз UML, так как он более наглядный. Не писать же юзер-сторис с нуля :)
Ну то есть не средство, но цель. "А что, так можно было?"
Не совсем понял, что вы имеете в виду.
Я выбрал UML только потому, что на мой взгляд он более наглядный, чем текст.
Но если бы текст был (например описанные юзер-сторис, или тест-кейсы, или просто подробный список требований, то вряд ли бы UML кто-то рисовал, так как диаграммы дублировали бы имеющуюся документацию.
У среднестатистического программиста вероятность за карьеру наткнуться на проект, где будут использоваться инструменты проектирования снизилась, из-за непомерно возросшего количества потребительских программ разного толка, где такое серьезное проектирование совсем не нужно. Вот и создается впечатление что «и без UML обходимся, значит он не нужен».
Я работаю ежедневно с тулом где все это предусмотрено, но я не видел, чтобы кем-то использовались эти возможности. Тул у нас используется только как более удобный и мощный аналог визио для рисования диаграмм. А сами диаграммы — только лишь как способ визуализации идеи.
Если где-то проектируют и поддерживают софт строго по этой методологии — от UML диаграмм до реализации в коде — расскажите плз как у вас это организовано.
У нас UML был сразу спецификацией для разработчиков, практически без сопроводительного текста. Поэтому их было много, они были всегда актуальные, продуманные и правильные. И да, сложные. Их нужно было внимательно читать.
Тестирование было тоже на основе диаграмм, так что разработчикам приходилось им следовать.
Нет времени создавать диаграмму → редко пользуешься софтиной для создания диаграмм → не успеваешь запоминать синтаксис и знаки форматирования (как в том же markdown) → т.к. не успеваешь запоминать способ работы, создание диаграммы занимает много времени → нет времени создавать диаграмму. Круг замкнулся.
И вообще UML диаграммы это от инженеров и для инженеров, масала-диаграммы от дизайнеров, манагеров для клиентов, манагеров рангом выше.
Тот же красочный пример в статье вряд ли создан инженером (программистом). Либо у него свободного времени слишком много.
Пробовали VS code + plantuml? Прирост в скорости разработки и изменения сиквенсов x10 по сравнению с Visio тем же.
Код прошлых диаграмм очень удобно использовать для новых.
Согласен с вами. Добавлю, что еще проблема в отсутствии фиксированного формата внешнего представления. Вы взяли тулзу, нарисовали диаграмму, а как остальным участникам ее посмотреть? Им надо такую же тулзу, и можно с уверенностью утверждать, что у большинства ее не окажется. Поэтому вам приходится сохранять все в jpg. А когда кто-то захочет вашу диаграмму доработать, ему придется сначала исходник найти, затем инструмент, которым его можно открыть, и не факт, что получится.
Кстати, по поводу поиска исходника. Если png-диаграмма сделана в plantuml, то картинку можно конвертировать в исходный код. Встроенная функция в плагин plantuml для VS Code. Главное, чтобы там кириллицы только не было, а иначе придется руками надписи переписывать. Это еще один фактор, почему я полностью перешел на plantuml и других мотивирую.
Использовали UML для детального проектирования одной ИС для транспортной компании. Покрытие моделями было под 95% для процессов, детальные макеты и прототип, который было не отличить от работающего ПО. В итоге через год после старта проект из самого рискованного превратился в самый стабильный и прибыльный для компании. А проблемы, на которые у других команд уходили дни, мы решали за считанные часы. При всём при этом сроки были сжатые, как обычно, договор фикс.
Считаю, что моделирование и проектирование крайне недооценено для успеха проекта. Ну и мало кто видел действительно качественное проектирование, вот и сформировалось мнение, что оно не нужно.
Ну и мало кто видел действительно качественное проектирование
Мало кто видел действительно качественную разработку в принципе :)
Plantuml + Visual studio code (с плагином plantuml) + git для исходников. Для визуализации схемы выгружались в формат svg. Просмотр и ссылки между схемами посредством sharepoint-а. Версионный контроль и сравнение через git.
Если используется confluence и bitbucket, то можно генерировать диаграммы на странице confluence прямо из кода диаграммы в ветке master, например. Но плагин для этого платный и довольно дорогой.
Если настроить PlantUML сервер, то можно заиспользовать препроцессинг. Он позволит выносить общие части диаграмм в отдельные библиотеки. Например, можно включить все ИС компании в такую библиотеку, добавить ее в диаграмму через !include, описать взаимодействия и активировать отображение только включенных во взаимодействие ИС. +100500 к унификации.
Еще есть алгоритмы и инструменты автоматической генерации диаграмм, но до этого я даже не дошёл.
В общем как инструмент plantuml очень мощный, изучать его можно долго.
В современном Skype нет UML и внятного проектирования, а в Telegram очевидно есть. Сравнить нетрудно. И совершенно ясно, что грамотно спроектированная система заведомо лучше тупо нашлепанной по фидбекам. Причем фидбек в грамотно спроектированной системе даже не исключается.
Но! Бизнес - это не инженерия. По крайней мере современный его этап. Суть не в UML, а в инженерном или маркетинговом подходе. Маркетологи почти всегда побеждают инженеров, пока продукт покупают люди. Сделать крутой продукт это 5 процентов работы. Раскрутить и продать - вот где реальные события разворачиваются.
А значит - UML неизбежно мертв. Пока в строгих нотациях пилится архитектурно красивое решение у маркетологов (читай бизнеса) уже три раза концепция продукта поменялась. UML просто не успевает в этой дикой гонке. Даже не UML, а инженерия.
Выход есть - фреймворки. Набор кубиков на все случаи жизни. Условный Spring на backend все больше и все страньше. Но он решает проблему скорости. Скорости разработки. На frontend та же история, тоже фреймворки. И все. UML мертв.
Вот, например, S-выражения изобрели jsonlogic.com :)
То, что там картинка озаглавлена словом «architecture» — не стоит думать что на этом архитектура заканчивается. Это всего лишь общее устройство, принципиальная схема. Это не значит, что при реализации таких систем не нужно пользоваться UML. Наоборот, чтобы описать коммуникационную стурктуру каждого компонента, там очень даже нужны диаграммы последовательности, диаграмма деятельности, блок-схемы и пр. Потому что «под капотом» такие системы могут быть умопомрачительно сложными. И если не продумать все в деталях, то вероятность запороть проект взлетит до небес.
Ощущение, что в статье описан мир человека который никогда не видел программного архитектора и плоды его работы. И не работал на проектах сложнее мобильного приложения.
P.S.
У меня складывается стойкое ощущение, что мы начинаем тут по кругу обьяснять малообразованым, неопытным «изобретателям-рационализаторам» какие-то прописные истины.
Сегодня пиарить свою необразованность, создавая полезную для карьеры медийность, может любой. А инженеров хороших со временем больше не становится.
Почему это просто не закодировать?
Как комиксы рисовать? А что их рих рисовать взял и нарисовал. Художник нужен хороший. Сториборды? Раскадровка? Не ну можно сделать, но тогда дольше будет.
Как компьютерные игры делать? Да вобщем все несложно. Персонажей и предметы смоделировал, анимации к ним прикрутил, там программист потом запрограммировал движения и реакции на события, коллизии например, физику. Окружение создал, карты, освещение и тени где надо проставил. Систему погоды можно прикрутить, ну это покруче если проект, но в принципе все это уже из коробки системами разработки поддерживается. Потом там собрал под разные платформы, выставил в аппстор, рекламную кампанию провел. Все впринципе вполне шаблонно.
[sarcasm=off]
Я работал на проекте где были диаграммы состояний и переходов для описания поведения фронтенда, и диаграммы последовательностей для описания протокола коммуникации с железом через интерфейс абстракции. Чтобы связать морду и железо нужен четко очерченый протокол. Т.е. последовательность общения. Оповещения например могут приходить вне очереди, а какие-то данные приходят только по запросу. Или у тебя многоканальная коммуникация, где несколько событий могут влиять на состояние. Типа, пришел сигнал с интерфейса А, тогда данные с интерфейса X нужно представить таким образом, а если не пришл — то другим. А если это под японский рынок то там вообще два сигнала, и решает их комбинация, а под американский — нет функции такой вовсе. И это только касается показывать какой-то там значок в строке статуса или нет.
Эти диаграммы предоставлял заказчик, и в тех частях программы где диаграмм таких не было или они были сделаны плохо — разработчики тратили много лишних сил на согласование поведения. Железо и HAL делает один подрядчик, интерфейс к нему -другой, и железо еще и для разных рынков разное. На каждый компонент — свой подрядчик, соседние разделы приложения тоже делают другие подрядчики. На проекте задействовано более 500 человек. Серийное производство. 34 варианта продукта при каждой сборке, и это только основные варианты. Разработка идет внахлест, новый продукт основывается на старом с добавлениями и доработками и ты не можешь начать с чистого листа. Два-три поколения приложения одновременно в одной кодовой базе, до финального вычленения продуктов. И приходится следить чтобы не сломать старый протокол, реализуя новый. А от твоих функций зависят функции других подрядчиков, а работоспособность всей сборки необходима потому, что идет регулярная интеграция с железом и ПО в идеале всегда должно быть рабочим. Просто мало кто себе представляет такой масштаб.
И когда у тебя есть такие диаграммы спецификации, ты всегда можешь на них сослаться. Не на пестрые презентации которые «concept, not final», где каждый интерпретирует цвет рамочки по своему, a на жесткую спецификацию интерфейса и протокола коммуникации. На слайдах удобно смотреть новые функции чтобы понимать идею с т.з. пользователя. Моки там, вайрфреймы, все такое.
На таком крупном проекте, без жесткой спецификации далеко не уедешь. Она помогает поддерживать темп разработки. И когда ты это понимаешь — то выбор инструмента один — UML.
никогда не бывает «хорошей» документацииБезусловно не будет идеальной документации, но при таком масштабе важно уже не это, а что ту, которая есть, все понимают одинаково. В этом смысл универсального языка моделирования.
Как можно разработать четко очерченый протокол, не разработав его референсную имплементацию?
А если есть референсная имплементация — зачем нужно дублировать ее в виде UML?
По мне это просто уход от ответственности — когда архитектор вместо референса программирует в ворде и в случае косяков виноват кто угодно, но не он.
А далее вместо простейшего юнит-теста с обращением к референсу, приходится ломать глаза, вглядываясь в диаграмму и пытаясь понять, кто из вас троих мудак — ты, автор диаграммы, или автор программы на другом конце протокола.
Апи обнови, схему обнови, а если апи работает не по схеме то кто виноват?
Тот, кто делал code/documentation review. Он, теоретически, должен был на сопроводительную документацию посмотреть и убедится, что она коду соответствует.
А если для разных веток будут разные схемы и лучше их хранить прямо в гите?
Да. Именно там и хранить.
Почему это просто не закодировать?Например, потому что кроме «основной деятельности» программы, в коде будут обработка ошибок, логгирование, проверки ввода на корректность/безопасность и т.д и т.п.
При мало-мальски сложной логике предметной области, которую реализует программа,
То есть делается утверждение: для проектирования нужно не брать редактор кода и не пилить там скрипт, делающий «основную деятельность программы», без излишних подробностей, а брать какую-то визуальную тулзу, и проектировать в ней, дебажа поведение общающихся конечных автоматов в уме. И якобы это ведет к лучшим продуктам.
Вот мне это вообще не очевидно.
Вы уже должны были понять: дело не в каких-то недостатках 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 и отошел в сугубо нишевое применение.
PlantUML генерация UML из текста. Поддерживается в Gitlab из коробки, в IDE (VSCode и JetBrains точно) поддержка добавляется плагинами. Используем для документации и иногда для разработки. Легко вносятся изменения, мержится наглядно (ибо текст первичен). Поддерживаются темы
Диаграммы последовательности не умрут никогда
Квалификация в среднем упала. Предметную область программисты знать не хотят (мы, сегодня АБС пишем, а завтра игру). ТЗ читать тоже не хотят: Аналитик (sic!), дай нам задачку в jire и мы ее сделаем. Даже в огромных проектах нет Главного конструктора или хотя бы Ведущего инженера. В лучшем случае есть Архитектор всего проекта и куча миниАрхитекторов модулей… В общем, тоска…
Чтобы он работал его должны были знать как разработчики, так и бизнес, а на практике знали только аналитики.
Смысл в инструменте, который усложняет и увеличивает трудозатраты, потому что в итоге всё равно приходилось описывать процессы и структуру обычными словами.
Использую uml в повседневной работе: activity, state, deployment, enity. Очень удобно и наглядно. Но у нас специфика такая, что платформа интеграционная, тут без схемы потоков никуда.
короче, если ты называешь себя инженером — ты обязать знать и использовать UML в дизайне. иначе ты не инженер, а говнокодер. UML — самый мощный и лаконичный инструмент для описания деталей реализации и командной работы.
Разработка без проектирования.
Работает же! Если чО, то переделаем)))
Что делает Фольксваген, когда нужно внести изменение, например, в крепление глушителя? Пригоняет толпу конструкторов, материаловедов, сопроматчиков, технологов, они плодят кучу расчётов, чертежей, смет, и прочей фигни. Потом изготавливаются опытные образцы, которые испытываются на стенде, потом натурно. Опять же, несколько машинок разбить в краш-тестах чисто на всякий случай.
Что делает дядя Ашот, если нужно внести изменение в крепление глушителя? "Падажди здесь дарагой, щас Петрович докурит и в пять минут тебе всё как надо приварит".
Наш любимый agile - это и есть методика гаража дяди Ашота, применяемая... да ко всему. Быстро, дёшево, сердито. А что халтура и времянка - так что ты хотел за свой нечастный косарь?
По мере продолжения победного шествия agile по планете, я ожидаю всё больше и больше самых неожиданных вещей, сделанных быстро, дёшево и очень сердито.
Нет, конечно. Так не делают. В любой нормально спроектированной инженерной системе, неважно софтварной или хардварной, есть изоляция сущностей инкапсуляция. Изменение в креплении глушителя, если машина нормально спроектирована, потребует минимума расчетов в районе точек крепления и все. Причем сейчас 99% этих расчетов будут сделаны автоматизированно в каком-нибудь сапре и в железо пойдет уже готовое или почти готовое изделие, с которым придется пройти только минимальный набор тестов. Никто и никогда при небольших изменениях требований не переделывает весь проект.
Я говорил не про крепление глушителя, а про деградацию качества инженерных решений при внедрении agile там, где не нужно.
Нас разбаловало то, что в нашем уютном мирке инфотеха мы можем нажать кнопочку, и заплатка разлетится миллионам пользователей. В "большом" мире всё сложнее. Отзыв миллиона автомобилей это капец как муторно и дорого. Проще лишний человекомесяц потратить на проектирование, а потом ещё один на испытания.
Заметьте, мы это всё обсуждаем под статьёй про упразднение за ненужностью стандартизованных нотаций, использовавшихся при проектировании софта. Ушло проектирование - ушли и нотации. Это как если бы в материальном производстве ушли чертежи. Петровичу не нужны ни кульман, ни САПР. У него опыт и сварочный аппарат.
Нет никакой деградации. Типичный современный продукт на порядки сложнее и технологичнее, чем 20 лет назад.
Нас разбаловало то, что в нашем уютном мирке инфотеха мы можем нажать кнопочку, и заплатка разлетится миллионам пользователей. В "большом" мире всё сложнее. Отзыв миллиона автомобилей это капец как муторно и дорого. Проще лишний человекомесяц потратить на проектирование, а потом ещё один на испытания.
Что-то криво раскатав в каком-нибудь гугле-фейсбуке можно "при удаче" за час потерять денег куда больше, чем в любой компании по отзыву автомобилей.
Это как если бы в материальном производстве ушли чертежи. Петровичу не нужны ни кульман, ни САПР. У него опыт и сварочный аппарат.
Чертеж в материальном производстве — это часть спецификации. У нас основная спецификация — это код. Любые диаграммы — не больше, чем пояснительные записки. Код никуда не ушел. Инструменты работы с кодом стали на порядки лучше и оказалось, что "пояснительные записки" стали гораздо менее нужны. В материальном производстве то же самое. Работать с САПР удобнее, чем с бумажными чертежами
В магнитофоне (в коробке) три схемы: принципиальная, монтажная и кинематическая. В третью можно рыбу заворачивать.
>>Типичный современный продукт на порядки сложнее и технологичнее, чем 20 лет назад
Это потому что у нас сильно облегчилось накопление сложности. То, что современный продукт ради того, чтобы показать анимацию, поле ввода и кнопочку тянет в себя гигабайт разнообразных фреймворков, не делает его сложным. Он так и остаётся простым как валенок, а вся его сумасшедшая сложность на 99.9% является либо издержками техпроцесса, либо просто балластом. Следует ли нам гордиться этой сложностью? Ну, не уверен. Особенно с учётом того, что вместе со сложностью частенько возрастает хрупкость.
>>У нас основная спецификация — это код
Нет. Вот просто нет, и всё. Я не знаю, кто ввинтил этот тупейший мем в массовое сознание. Почитайте, например, документацию на Реакт, а потом поройтесь в его исходниках. Уверен, вы почувствуете разницу.
Базы данных не стали на порядки сложнее чем 20 лет назад?
Фреймворки не стали на порядки сложнее чем 20 лет назад?
<Любая другая область> не стали на порядки сложнее чем 20 лет назад?
Сложность эту, к сожалению, на хлеб не намажешь. Мы наворачиваем всё новые и новые уровни абстракции, городим фреймворки поверх фреймворков, оборачиваем многослойные виртуализации дополнительными слоями виртуализации, и всё ради упрощения. Только проще не становится, а становится только сложнее. Сюрприз?
То, что современный продукт ради того, чтобы показать анимацию, поле ввода и кнопочку тянет в себя гигабайт разнообразных фреймворков, не делает его сложным.
Ну если у вас продукт только и делает, что показывает кнопочку, то, конечно, да. Впрочем 20 лет назад и показать кнопочку с анимацией было не то чтобы просто, кажется.
Почитайте, например, документацию на Реакт, а потом поройтесь в его исходниках. Уверен, вы почувствуете разницу.
Может быть это просто плохой пример?
Нормальный пример. Более того, я даже не могу припомнить пример из своей практики, когда принцип "код сам себе документация" работал на все сто. Ну кроме совсем примитивных случаев, когда и так всё понятно.
Во-первых, профессиональный код всегда лихо наворочен. Важные нюансы могут быть закопаны вглубь каких-нибудь миксинов и срабатывать через паттерн "визитор". Чтобы в этом разобраться, мало того, что нужно потратить кучу времени, так ещё нежно обладать квалификацией не ниже, чем у того перца, который это ваял. Продираться через код джунов, кстати, ещё мучительнее. Во-вторых, для понимания нужен контекст. Не просто куча как-то связанных внутренней логикой файлов, а ещё и понимание, что вообще за задача решалась, исходя из каких ограничений принимались решения, как это всё предполагалось вписать в окружающий ландшафт. В код это вписывать просто некуда. В ридми? Ну да, так иногда делают, но согласитесь, это уже определённо отход от принципа "код сам себе документация".
При чем тут документация? Речь о спецификации результата и код тут единственно возможный вариант. Точно так же как из чертежа бывает сложно понять, что это за деталь и зачем она нужна, так же и из кода бывает сложно понять что он делает и зачем. Это нормально.
Во-первых, все очень просто. Если код непонятен — это либо хреновый код, либо неподготовленный читатель. Понятный код — это внятные абстракции и простые связи между ними. Если это соблюдается — любой код читать относительно просто, если нет — проблема в консерватории. Бывают исключения, связанные с теми или иными ограничениями (перфоманс, недостатки инструментов и языков etc), но никакие UML диаграммы тут не помогут. Тот же "визитор" — это лишь всего-лишь костыль, обходящий недостаточную выразительность языка, который на уровень проектирования совершенно непонятно зачем выносить.
Во-вторых, контекст — это бизнес-требования. UML — всего лишь графическое отображение принятых на основе этих требований в какой-то момент решений и сам по себе несет не больше (а меньше) контекста, чем написанный программный код. В UML еще труднее вписать зачем и почему, чем непосредственно в код. В коде можно хоть на два листа комментариев написать, а в диаграммах длинные комментарии превратятся в совершенно нечитаемую хрень.
Современные продукты кроссплатформенны, имеют много UI фишечек, могут работать в лагающей интернет-среде, многие автоматизируются (побочный эффект перехода на клиент-сервер и текстовые протоколы), а по качеству несравнимы с типичным для нулевых синхронным локальным windows-only кодом.
Можно, конечно, сказать, «а вот %проганейм% так могла в 2003, а сейчас %другаяпроганейм% так не может», но это будет ошибкой аргументации.
Почитайте, например, документацию на Реакт, а потом поройтесь в его исходниках. Уверен, вы почувствуете разницу.
Это будет разница между чертежом и инструкцией по эксплуатации.
Я не знаю, кто ввинтил этот тупейший мем в массовое сознание.
Тупейший мем — это представление, что код не является частью конструкторской документации, а что это что-то типа пола, стен, потолка и прочие стоительно-машиностроительные метафоры.
Опытные образцы на любом фольксвагене изготавливают свои Петровичи — у них свои станки, заточенные именно под штучную работу, свои бюджеты, и вообще сплошной аджайл. А далее возникает головная боль — адаптация к конвееру. И начинается — мелкая серия, испытания, крупная серия, испытания. Так много испытаний не потому что опытные образцы менее надежные, они более надежные, потому что разработчики их изучали под микроскопом, а потому что каждый этап масштабирования производства вносит новые ошибки и неопределенность.
В программировании же проблемы «адаптации к конвееру» нет. Та конструкторская документация, которая собирает опытный образец, точно так же собирает и миллион образцов. А если хочется надежности — нужно много QA, чудес не бывает. Софт ненадежен, потому что экономят на QA. В том числе и потому, что недобросовестные просиживатели штанов предпочитают программировать в визио и «ой, мы ща как макулатуры наплодим — и будет все надежно-надежно, платите мне, а не тестерам». Ну да блин, архитекторы у нас — гении, которые умеют программировать в визио и учитывать все нюансы. Знаем таких.
Такой подход в прошлом — результат того, что менджмент компаний компьютер первый раз в жизни увидел в 30 лет. Они тупо перенесли привычные практики, не очень понимая их суть. Глупо ожидать чего-то иного, если им для перехода на удаленку потребовался целый ковид. Но софт тех лет такая же забагованная хрень, как и всегда.
А если хочется надежности — нужно много QA, чудес не бывает.
Хочется не только надежности. Хочется того, чтобы вот лет через 10 после того, как проект как бы сделан (и до сих пор эксплуатируется, ага), те люди, к которым он в руки попадет для модификации, могли что-то понять, не потратив предварительно год на разбор кода.
UML это одна из многих нотаций. Точно так же можно разочароваться в любом инструменте моделирования, если неправильно его использовать.
Вобщем бездоказательно вы как то это все тут написали. Ну а уж про agile ну как то вообще не понятно. Ну не вошли юзерстори, ну не используй их, а UML то тут при чем?
Хорошо, допустим от UML отказались. А чем таки заменили то? Или просто отказались и все?
Boeing никогда бы не заказал у Rolls Royce реактивный двигатель на основе подобной неформальной масала-диаграммы.
Не могу сказать, что это хорошо и является достоинством. Это просто говорит, о том что самолёт очень хрупкая и вместе с тем жёсткая система, в которую трудно вписать абсолютно любой двигатель. На счастье, разработка софта намного гибче и ближе к жизни, чем машиностроение.
UML умер, а никто и не заметил?