М
Только он не Алиев
Да, Левенчук, поправил
Size: a a a
2021 January 13
YG
Причина в том, что про archimate я уже кое-что знаю, читал А.И.Левенчука и составлял модели, хоть и не самого лучшего качества. А про c4model я не знаю практически ничего
Левенчук сам говорит «отказывайтесь от визуального проектирования на диаграммах» (лично с ним говорил по этому поводу)))
GK
Левенчук сам говорит «отказывайтесь от визуального проектирования на диаграммах» (лично с ним говорил по этому поводу)))
А как предлагает?)
YG
Это я к тому что рекомендую на AS IS обратить внимание именно таблицы или текст (псевдо код). Мне по долгу службы приходилось очень быстро делать анализ AS IS (работал некоторое время управленческим консультантом).
Все визуальное моделирование отпадало сразу когда макс за 3-5 неделю нужно Business, App, IT Infrastructure проанализировать. Люди врут)) Постоянно приходилось все переделывать)) И невозможно нормальную совместную работу делать было 3-5 консультантами.
У меня пришло к таблицам (точнее к таблицам у которых в ячейках можно несколько ссылок сразу - сначала airtable, потом к coda.io). А потом из них через их API - конверт в plantuml чтобы быстро схемки красивые (plamtuml умеет красивые если его «поднастроить один раз на всю жизнь - шаблон правильный сделать»), и в отчеты, например через бесплатный powerbi (чтобы всякие hitmap и т.д.).
Потом перешел в coda.io т.к. а. почти бесплатно на толпу (если чуть с лицензированием разобраться), б. быстрее и удобнее airtable + есть не только таблицы, но и обычный текст - а это значит проблему таблиц «нет дерева» сразу решаем текстом - просто лесенку делаем и вообще там удобнее.
Сейчас мы MBSE делаем в coda.io (не бейте гуру-разработчики, это про верхнеуровневый дизайн).
Все визуальное моделирование отпадало сразу когда макс за 3-5 неделю нужно Business, App, IT Infrastructure проанализировать. Люди врут)) Постоянно приходилось все переделывать)) И невозможно нормальную совместную работу делать было 3-5 консультантами.
У меня пришло к таблицам (точнее к таблицам у которых в ячейках можно несколько ссылок сразу - сначала airtable, потом к coda.io). А потом из них через их API - конверт в plantuml чтобы быстро схемки красивые (plamtuml умеет красивые если его «поднастроить один раз на всю жизнь - шаблон правильный сделать»), и в отчеты, например через бесплатный powerbi (чтобы всякие hitmap и т.д.).
Потом перешел в coda.io т.к. а. почти бесплатно на толпу (если чуть с лицензированием разобраться), б. быстрее и удобнее airtable + есть не только таблицы, но и обычный текст - а это значит проблему таблиц «нет дерева» сразу решаем текстом - просто лесенку делаем и вообще там удобнее.
Сейчас мы MBSE делаем в coda.io (не бейте гуру-разработчики, это про верхнеуровневый дизайн).
YG
В целом что я написал - это развитие идеи Максима про архитектурный репозиторий в confluence с типизацией.
Те инструменты нам больше подошли т.к. нативно поджерживают типизацию (т.к. таблицы out of box) и API к ним простой и нормальный для горе-проектантов которые не особо разработчики прямо супер.
Те инструменты нам больше подошли т.к. нативно поджерживают типизацию (т.к. таблицы out of box) и API к ним простой и нормальный для горе-проектантов которые не особо разработчики прямо супер.
YG
А как предлагает?)
Сейчас он предлагает использовать псевдокод т.к. код через GIT etc поддерживает все красоты - совместную работу, управл конфигурацией (ветки), изменениями (ticket git); на одной странице кода умещается читабельно то, что на картинке никогда.
Еще одно от себя: писать нас учат с первого класса до бесконечности, поэтому проектирование текстом очень-очень быстро заходит (хотя ново, мы привыкли в картинах).
Я в прошлом январе-феврале такой эксперимент провел (на своих детях и сотрудниках):
Еще одно от себя: писать нас учат с первого класса до бесконечности, поэтому проектирование текстом очень-очень быстро заходит (хотя ново, мы привыкли в картинах).
Я в прошлом январе-феврале такой эксперимент провел (на своих детях и сотрудниках):
YG
Yuri Geronimus, [18 февр. 2020 г., 20:09:41]:
История про проектирование в текстовых нотациях....
В январских праздниках решил я, так как дети болели, не гулять, а сделать псевдоязык проектирования на JavaScript, слелав его на русском, какого же было мое удивление когда мой 9-летний ребёнок сам спокойно сел и начал проектировать семью деревом, со связями, тетями дядями, фио, тяжелыми случаями как папа и отчим, любит не любит, живет там, работает там, и так далее))) И тут я понял, что текст это гениально) я понимаю, что ребёнку не то что визуальную нотацию не объяснишь, но он даже понятия таблица не знает, а в тексте, в настоящем JavaScript (обёрнутом по-русски), он сделал все сам и даже ему это интересно было, сам попросил!!
Так что думаю текстовая нотация уже тем хороша, что с 6 лет в тексте людей проектировать учат)
И там и роли были, и ролевое поведение, и модули, и размещения, и это так естественно у него пошло))
Со взрослыми было намного сложнее, кстати.
Им хорошо зашла иерархия текстовая.
Остальное осталось через таблицы, в тексте не пошло.
История про проектирование в текстовых нотациях....
В январских праздниках решил я, так как дети болели, не гулять, а сделать псевдоязык проектирования на JavaScript, слелав его на русском, какого же было мое удивление когда мой 9-летний ребёнок сам спокойно сел и начал проектировать семью деревом, со связями, тетями дядями, фио, тяжелыми случаями как папа и отчим, любит не любит, живет там, работает там, и так далее))) И тут я понял, что текст это гениально) я понимаю, что ребёнку не то что визуальную нотацию не объяснишь, но он даже понятия таблица не знает, а в тексте, в настоящем JavaScript (обёрнутом по-русски), он сделал все сам и даже ему это интересно было, сам попросил!!
Так что думаю текстовая нотация уже тем хороша, что с 6 лет в тексте людей проектировать учат)
И там и роли были, и ролевое поведение, и модули, и размещения, и это так естественно у него пошло))
Со взрослыми было намного сложнее, кстати.
Им хорошо зашла иерархия текстовая.
Остальное осталось через таблицы, в тексте не пошло.
F
А как предлагает?)
Текст. В целом давно вообще витает что делать все текстом, с связанными и пере используемыми блоками. есть даже ответ (из архитектуры зданий и инженерии ее реализующей) - тагирование. Но для ИТ все никак и никто, дорого делать тулы, а спрос не очень что бы большой думаю. если посмотреть "гуру" оформления дата сетов табличных, там тоже советую таблицу минимум таблицей, даже строки не отделять цветами. черт возьми при правильном scale выглядит из результаты лучше чем мои попытки настроить таблицу с минимальными границами.
p
да-да-да, а потом выясняется, что хотят обычный монолит сделать распределенным монолитом, потому, что термин "микросервисная архитектура" слышали, а что под ним скрывается, когда этот подход оправдан, какие задачи позволяет решить - не, это уже не интересно. Зато у всех кубер, контейнеры и надо выделить еще ресурсов разработки, чтобы переписать на Go :)
Но переписать на go вполне полезно 😂😂
F
Yuri Geronimus, [18 февр. 2020 г., 20:09:41]:
История про проектирование в текстовых нотациях....
В январских праздниках решил я, так как дети болели, не гулять, а сделать псевдоязык проектирования на JavaScript, слелав его на русском, какого же было мое удивление когда мой 9-летний ребёнок сам спокойно сел и начал проектировать семью деревом, со связями, тетями дядями, фио, тяжелыми случаями как папа и отчим, любит не любит, живет там, работает там, и так далее))) И тут я понял, что текст это гениально) я понимаю, что ребёнку не то что визуальную нотацию не объяснишь, но он даже понятия таблица не знает, а в тексте, в настоящем JavaScript (обёрнутом по-русски), он сделал все сам и даже ему это интересно было, сам попросил!!
Так что думаю текстовая нотация уже тем хороша, что с 6 лет в тексте людей проектировать учат)
И там и роли были, и ролевое поведение, и модули, и размещения, и это так естественно у него пошло))
Со взрослыми было намного сложнее, кстати.
Им хорошо зашла иерархия текстовая.
Остальное осталось через таблицы, в тексте не пошло.
История про проектирование в текстовых нотациях....
В январских праздниках решил я, так как дети болели, не гулять, а сделать псевдоязык проектирования на JavaScript, слелав его на русском, какого же было мое удивление когда мой 9-летний ребёнок сам спокойно сел и начал проектировать семью деревом, со связями, тетями дядями, фио, тяжелыми случаями как папа и отчим, любит не любит, живет там, работает там, и так далее))) И тут я понял, что текст это гениально) я понимаю, что ребёнку не то что визуальную нотацию не объяснишь, но он даже понятия таблица не знает, а в тексте, в настоящем JavaScript (обёрнутом по-русски), он сделал все сам и даже ему это интересно было, сам попросил!!
Так что думаю текстовая нотация уже тем хороша, что с 6 лет в тексте людей проектировать учат)
И там и роли были, и ролевое поведение, и модули, и размещения, и это так естественно у него пошло))
Со взрослыми было намного сложнее, кстати.
Им хорошо зашла иерархия текстовая.
Остальное осталось через таблицы, в тексте не пошло.
частный случай. например https://github.com/mermaid-js/mermaid, но все равно не очень. Ну т.е. не тянет для быстрых срезов для топов. и на энтерпрайз уровень не вариант.
F
Но переписать на go вполне полезно 😂😂
GK
Сейчас он предлагает использовать псевдокод т.к. код через GIT etc поддерживает все красоты - совместную работу, управл конфигурацией (ветки), изменениями (ticket git); на одной странице кода умещается читабельно то, что на картинке никогда.
Еще одно от себя: писать нас учат с первого класса до бесконечности, поэтому проектирование текстом очень-очень быстро заходит (хотя ново, мы привыкли в картинах).
Я в прошлом январе-феврале такой эксперимент провел (на своих детях и сотрудниках):
Еще одно от себя: писать нас учат с первого класса до бесконечности, поэтому проектирование текстом очень-очень быстро заходит (хотя ново, мы привыкли в картинах).
Я в прошлом январе-феврале такой эксперимент провел (на своих детях и сотрудниках):
Ну не знаю)) визуальные образы вроде более информативны)
Левенчуку конечно виднее)) но я так точно делать не буду, имею ввиду псевдокод
Возьмём несложную схему. Она может поместиться на одном экране, а её псевдокод на десяти, а может и на ста
Интересно, Левечук сам так давно руками своими делал)
Левенчуку конечно виднее)) но я так точно делать не буду, имею ввиду псевдокод
Возьмём несложную схему. Она может поместиться на одном экране, а её псевдокод на десяти, а может и на ста
Интересно, Левечук сам так давно руками своими делал)
YG
p
Монолит - это, в моем понимании, подход к построению приложения, который при изменении/отказе части системы приводит к лавинообразному изменению/отказу других частей системы. Например, три бинарника, работающие в разных контейнерах и имеющие общее хранилище данных - монолит. Я не говорю, что это плохой подход, просто он имеет свои плюсы и минусы. Если вам нужны, например, ACID транзакции в какой-то части системы, то там, с высокой долей вероятности, будет монолит.
Распределенный монолит - это когда один бинарник разбивают на кучу бинарников, которые взаимодействуют между собой на основе синхронных запросов. Такой подход может иметь свои плюсы, вы можете горизонтально масштабировать части системы, но это по прежнему структура в которой изменение/отказ одного из компонентов приводит к изменению/отказу других компонентов системы.
Распределенный монолит - это когда один бинарник разбивают на кучу бинарников, которые взаимодействуют между собой на основе синхронных запросов. Такой подход может иметь свои плюсы, вы можете горизонтально масштабировать части системы, но это по прежнему структура в которой изменение/отказ одного из компонентов приводит к изменению/отказу других компонентов системы.
В такой парадигме вообще все становится монолитом. Тот же Google, у которого отсох auth и дальше по цепочке отсохло все остальное - это тоже тогда монолит
F
Ну не знаю)) визуальные образы вроде более информативны)
Левенчуку конечно виднее)) но я так точно делать не буду, имею ввиду псевдокод
Возьмём несложную схему. Она может поместиться на одном экране, а её псевдокод на десяти, а может и на ста
Интересно, Левечук сам так давно руками своими делал)
Левенчуку конечно виднее)) но я так точно делать не буду, имею ввиду псевдокод
Возьмём несложную схему. Она может поместиться на одном экране, а её псевдокод на десяти, а может и на ста
Интересно, Левечук сам так давно руками своими делал)
смысл что наоборот, псевдокод как центральная ветка. по сути ide для текстов) Да и вообще вопрос не code as diagram, это частный случай.
GK
В такой парадигме вообще все становится монолитом. Тот же Google, у которого отсох auth и дальше по цепочке отсохло все остальное - это тоже тогда монолит
Мы это обсуждали в другом чате. Даже не хочется комментировать этот вопрос
F
У Левенчука мне кажется очень хорошие критерии для архитектурного языка imho:
Вот в свое время делал оценку для airtable, так 21 из 27 критериев))
Здесь акцент хотел бы сделать именно на критерии))
Вот в свое время делал оценку для airtable, так 21 из 27 критериев))
Здесь акцент хотел бы сделать именно на критерии))
не знаю, по мне как даже половины критериев нет, что нужно. Да и опять все в таблице, я устал от генерации сотого экселя, потому что нет ide, а кто то хочет и такой срез еще. Нужна нормальная IDE для текста и документов. не процессор текстовый. а полноценная ide + фронт вебовский.
GK
смысл что наоборот, псевдокод как центральная ветка. по сути ide для текстов) Да и вообще вопрос не code as diagram, это частный случай.
Да я понимаю)) спорить на буду) давайте через пять лет на это посмотрим
YG
Ну не знаю)) визуальные образы вроде более информативны)
Левенчуку конечно виднее)) но я так точно делать не буду, имею ввиду псевдокод
Возьмём несложную схему. Она может поместиться на одном экране, а её псевдокод на десяти, а может и на ста
Интересно, Левечук сам так давно руками своими делал)
Левенчуку конечно виднее)) но я так точно делать не буду, имею ввиду псевдокод
Возьмём несложную схему. Она может поместиться на одном экране, а её псевдокод на десяти, а может и на ста
Интересно, Левечук сам так давно руками своими делал)
В моей практике качующего в ИТ между разными ролями сформировалось такое понимание:
1. «архитектурный репозиторий» - для ведения и проектирования. Это таблицы и текст.
2. Для взаимодействия со стейкхолдерами - всегда картинки (которые часто по кнопке выгружаются из п. 1 каким-нибудь скриптом который программист за 1 день написал и весь проект используем)
1. «архитектурный репозиторий» - для ведения и проектирования. Это таблицы и текст.
2. Для взаимодействия со стейкхолдерами - всегда картинки (которые часто по кнопке выгружаются из п. 1 каким-нибудь скриптом который программист за 1 день написал и весь проект используем)
GK
С мой точки зрения псевдокод годится только для автогенерации. Для проектирования необходимы визуальные образы, не обязательно диаграммы