#критика
Противопоставлять моделирование и diagramming нельзя в принципе, потому что:
1. Диаграммы порождаются в процессе моделирования, проектирования, документировании и тп.
2. Диаграммы всегда являются моделями, без исключений; почему именно — рассмотрим в деталях позже.
Когда человек утверждает, что выполняет диаграмминг (diagramming), он часто не до конца осознает, что делает на самом деле (см. п.1).
Создавая диаграммы, мы создаем модели. А в одном из значений, построение и изучение моделей реальных объектов и явлений — это и есть моделирование.
Противопоставлять создание моделей моделированию - пустое занятие.
Противопоставлять моделирование и diagramming нельзя в принципе, потому что:
1. Диаграммы порождаются в процессе моделирования, проектирования, документировании и тп.
2. Диаграммы всегда являются моделями, без исключений; почему именно — рассмотрим в деталях позже.
Когда человек утверждает, что выполняет диаграмминг (diagramming), он часто не до конца осознает, что делает на самом деле (см. п.1).
Создавая диаграммы, мы создаем модели. А в одном из значений, построение и изучение моделей реальных объектов и явлений — это и есть моделирование.
Противопоставлять создание моделей моделированию - пустое занятие.
👍8😁1🤔1
Кстати, нашел только одно определение для diagramming:
«Diagramming - providing a chart or outline of a system
...
type of: representation»
https://www.vocabulary.com/dictionary/diagramming
При этом, chart (диаграмма) - это модель. И можно сказать, что модель это представление (representation) некоего объекта, предназначенное для рассмотрения определённых его аспектов (в разных целях).
Мы создаем модели в виде диаграмм в рамках таких процессов, как моделирование или проектирование. Даже скетчи (эскизы) мы рисуем не ради художественного самовыражения, а в более практичных целях (это тоже модели).
«Diagramming - providing a chart or outline of a system
...
type of: representation»
https://www.vocabulary.com/dictionary/diagramming
При этом, chart (диаграмма) - это модель. И можно сказать, что модель это представление (representation) некоего объекта, предназначенное для рассмотрения определённых его аспектов (в разных целях).
Мы создаем модели в виде диаграмм в рамках таких процессов, как моделирование или проектирование. Даже скетчи (эскизы) мы рисуем не ради художественного самовыражения, а в более практичных целях (это тоже модели).
Vocabulary.com
Diagramming - Definition, Meaning & Synonyms
providing a chart or outline of a system
👍3
#миф
Ну а о блеске и нищете C4 Model мы поговорим отдельно и расскажем, как пытались разработать метамодель для моделей в C4 Model. Это далось непросто.
Кстати, авторы C4 Model благоразумно не называют её нотацией. Они говорят: "The C4 model is an "abstraction-first" approach to diagramming software architecture,...
The C4 model is notation independent, and doesn't prescribe any particular notation"
https://c4model.com/#Notation
И да, относить C4 Model к нотациям действительно неверно — это миф.
Ну а о блеске и нищете C4 Model мы поговорим отдельно и расскажем, как пытались разработать метамодель для моделей в C4 Model. Это далось непросто.
Кстати, авторы C4 Model благоразумно не называют её нотацией. Они говорят: "The C4 model is an "abstraction-first" approach to diagramming software architecture,...
The C4 model is notation independent, and doesn't prescribe any particular notation"
https://c4model.com/#Notation
И да, относить C4 Model к нотациям действительно неверно — это миф.
👍9
Посты в этом канале я публикую по контент-плану, включающему мои многолетние наработки, которыми хочу поделиться. Правда стало понятно, что развитие мысли уводит от плана.
Иначе и быть не может, ведь развитие не происходит точно по плану.
Сейчас я пересматриваю контент-план и работаю над созданием навигации по каналу. При этом не хочется нарушать динамику и важно продолжать делиться мыслями.
Погружаясь в тему стратегий, у меня возникла идея сформулировать архитектурные максимы, по аналогии с максимами в управлении и стратегии.
Максима — это правило поведения, выраженное в краткой формуле.
Иначе и быть не может, ведь развитие не происходит точно по плану.
Сейчас я пересматриваю контент-план и работаю над созданием навигации по каналу. При этом не хочется нарушать динамику и важно продолжать делиться мыслями.
Погружаясь в тему стратегий, у меня возникла идея сформулировать архитектурные максимы, по аналогии с максимами в управлении и стратегии.
Максима — это правило поведения, выраженное в краткой формуле.
🔥5👍3
#доклад
Впервые я сформулировал рекомендации, некоторые из которых вполне можно отнести к максимам, на ArchDays в 2019 году: https://www.youtube.com/watch?v=hGXkpzOw78I
На тот момент эти рекомендации не воспринимались мной как максимы.
Впервые я сформулировал рекомендации, некоторые из которых вполне можно отнести к максимам, на ArchDays в 2019 году: https://www.youtube.com/watch?v=hGXkpzOw78I
На тот момент эти рекомендации не воспринимались мной как максимы.
YouTube
ArchDays 2019 • Как избежать гибели решения и дать ему шанс на эволюцию • Геннадий Круглов
Геннадий Круглов — Как избежать гибели решения и дать ему шанс на эволюцию
Из проекта в проект мы видим одни и те же ошибки, которые приводили и приводят к фатальным последствиям, потерям миллиардов рублей, утрате доверия у клиентов, разрушениям команд и…
Из проекта в проект мы видим одни и те же ошибки, которые приводили и приводят к фатальным последствиям, потерям миллиардов рублей, утрате доверия у клиентов, разрушениям команд и…
👍3🔥1
#максима
Не приступайте к разработке нового функционала без стабилизации текущего.
Многие современные системы быстро становятся легаси. Это часто происходит из-за непомерного технического долга. Непомерный технический долг приводит к утрате контроля над сложностью, когда методы управления сложностью уже не работают.
https://news.1rj.ru/str/IndustrialSoftwareArchitecture/90
Строители не начинают возводить стены, пока не застынет фундамент. Мы же почему-то считаем, что законы в «софте» не работают и долги отдавать не нужно.
Если вы перестали понимать, как работает система, или не можете спрогнозировать реакцию системы на очередные изменения, значит, вы утратили контроль над сложностью, и ваше решение теперь легаси.
Не приступайте к разработке нового функционала без стабилизации текущего.
Многие современные системы быстро становятся легаси. Это часто происходит из-за непомерного технического долга. Непомерный технический долг приводит к утрате контроля над сложностью, когда методы управления сложностью уже не работают.
https://news.1rj.ru/str/IndustrialSoftwareArchitecture/90
Строители не начинают возводить стены, пока не застынет фундамент. Мы же почему-то считаем, что законы в «софте» не работают и долги отдавать не нужно.
Если вы перестали понимать, как работает система, или не можете спрогнозировать реакцию системы на очередные изменения, значит, вы утратили контроль над сложностью, и ваше решение теперь легаси.
Telegram
Industrial Software Architecture
Поскольку мы говорим об архитектуре программных систем, то для нас:
Сложная система — это трудная для понимания система, которую невозможно исследовать, моделировать, проектировать и описывать без применения методов управления сложностью, таких как декомпозиция…
Сложная система — это трудная для понимания система, которую невозможно исследовать, моделировать, проектировать и описывать без применения методов управления сложностью, таких как декомпозиция…
👍3💯3❤🔥2🔥1
#FYI
Легаси (от англ. legacy — наследие) — в одном из значений это решение, в котором разобраться чрезвычайно трудно или вовсе невозможно. Такое решение практически не поддаётся развитию и зачастую рациональнее его «переписать», чем пытаться развивать.
Легаси (от англ. legacy — наследие) — в одном из значений это решение, в котором разобраться чрезвычайно трудно или вовсе невозможно. Такое решение практически не поддаётся развитию и зачастую рациональнее его «переписать», чем пытаться развивать.
👍2🤔1
Решение может стать легаси по разным причинам, не только из-за непомерного технического долга. Например, команда может уйти, не оставив документации, или используемые технологии могут устареть.
Легаси — это именно наследие, не обязательно наследство от предыдущей команды или вендора. Это также наследие наших собственных решений, бездействия и недальновидности.
В широком смысле легаси — это решение, которое невозможно или нецелесообразно развивать.
Легаси — это именно наследие, не обязательно наследство от предыдущей команды или вендора. Это также наследие наших собственных решений, бездействия и недальновидности.
В широком смысле легаси — это решение, которое невозможно или нецелесообразно развивать.
👍8
Там, где начинается легаси, заканчивается инженерия.
Напомню, инженерия это: «Творческое применение научных принципов для проектирования или конструирования машин, аппаратов или производственных процессов или эксплуатации их с полным пониманием их устройства; или прогнозирования их поведение…»
https://news.1rj.ru/str/IndustrialSoftwareArchitecture/45
Напомню, инженерия это: «Творческое применение научных принципов для проектирования или конструирования машин, аппаратов или производственных процессов или эксплуатации их с полным пониманием их устройства; или прогнозирования их поведение…»
https://news.1rj.ru/str/IndustrialSoftwareArchitecture/45
Telegram
Industrial Software Architecture
Подходящее для нас определение инженерии, достаточно ёмкое и полное, приводит American Engineers' Council for Professional Development (ECPD):
“Творческое применение научных принципов для проектирования или конструирования машин, аппаратов или производственных…
“Творческое применение научных принципов для проектирования или конструирования машин, аппаратов или производственных…
👍7🔥3🤨1
#максима
Сначала создайте коммерческий продукт, и только потом мигрируйте на него.
Если перед вами одновременно стоят задачи миграции легаси и коммерциализации итогового решения, начните с разработки коммерческого продукта.
Миграция, в целом, — это вынужденный и болезненный шаг, сопряжённый с выживанием, который редко приносит позитивный опыт. Цель при миграции — выжить, и целеполагание соответствующее.
Коммерческий же продукт, который принят рынком, будет и внутренних пользователей радовать.
Важные условия: решение должно быть модульным; коммерциализация всего функционала без исключения не обязательна; действовать стоит итеративно.
Эта формула (максима) применима, однако, только если есть ресурсы — время и деньги.
Сначала создайте коммерческий продукт, и только потом мигрируйте на него.
Если перед вами одновременно стоят задачи миграции легаси и коммерциализации итогового решения, начните с разработки коммерческого продукта.
Миграция, в целом, — это вынужденный и болезненный шаг, сопряжённый с выживанием, который редко приносит позитивный опыт. Цель при миграции — выжить, и целеполагание соответствующее.
Коммерческий же продукт, который принят рынком, будет и внутренних пользователей радовать.
Важные условия: решение должно быть модульным; коммерциализация всего функционала без исключения не обязательна; действовать стоит итеративно.
Эта формула (максима) применима, однако, только если есть ресурсы — время и деньги.
👍4❤1🤔1
Коммерческий продукт, лишённый лицензий, обновлений и поддержки, — это легаси. Такой продукт развивать невозможно.
👍2❤🔥1
Хочу поделиться видео Жени Лукьянова про микросервисы.
В начале этого видео Женя рассказывает историю появления микросервисов как архитектурного стиля и объясняет, откуда взялось это название, что уже представляет интерес.
Я же считаю, что с точки зрения инженерии микросервисы – это автономные модули. Эту точку зрения я подробно объясню в разделе, посвящённом конструированию, после обсуждения тем моделирования и проектирования.
Тем не менее, уже сейчас могу отметить, что многое из того, что Женя говорит о микросервисах, также применимо и к автономным модулям, хотя я и не со всем согласен безоговорочно.
https://youtu.be/ZwkoGV-4rSw?si=VvuC8hscN9yMhGak
В начале этого видео Женя рассказывает историю появления микросервисов как архитектурного стиля и объясняет, откуда взялось это название, что уже представляет интерес.
Я же считаю, что с точки зрения инженерии микросервисы – это автономные модули. Эту точку зрения я подробно объясню в разделе, посвящённом конструированию, после обсуждения тем моделирования и проектирования.
Тем не менее, уже сейчас могу отметить, что многое из того, что Женя говорит о микросервисах, также применимо и к автономным модулям, хотя я и не со всем согласен безоговорочно.
https://youtu.be/ZwkoGV-4rSw?si=VvuC8hscN9yMhGak
YouTube
Что такое микросервисы? Проще, чем кажется!
💻 Наш курс по карьере: https://howto.stringconcat.ru/career?utm_source=youtube&utm_medium=video&utm_campaign=microservices
🎯 Телеграмм-канал с кучей полезной информации: https://news.1rj.ru/str/stringconcat
В этом видео я расскажу вам, что такое микросервисы в IT и…
🎯 Телеграмм-канал с кучей полезной информации: https://news.1rj.ru/str/stringconcat
В этом видео я расскажу вам, что такое микросервисы в IT и…
🔥5👍3🤓2❤1
Наконец-то появилась возможность подвести итоги написанных постов. Начинаю публиковать резюме по разделам и выстраивать навигацию.
👍1🔥1
#итоги
Промышленная архитектура программных систем: Параллели со строительством и ключевые черты
В разделе вводится новый архитектурный стиль в программной инженерии "Промышленная архитектура программных систем" и проводятся параллели с аналогичным стилем в строительстве.
Основные моменты:
- В программной инженерии, как и в строительстве, существуют архитектурные стили, которые отражают исторический контекст и требования своего времени, и способствуют распространению и применению лучших практик для их реализации.
- Промышленная архитектура в строительстве ориентирована на проектирование зданий для производственных нужд, с акцентом на функциональность, экономическую эффективность, инновационность, надёжность, безопасность, модульность и автономность.
- Промышленная архитектура программных систем так же направлена на создание промышленных решений и сохраняет те же акценты.
- Общим трендом для промышленной архитектуры как в строительстве, так и в разработке программных систем является проектирование с учётом будущих изменений и обеспечение эволюционности
Начало раздела: https://news.1rj.ru/str/IndustrialSoftwareArchitecture/15
Промышленная архитектура программных систем: Параллели со строительством и ключевые черты
В разделе вводится новый архитектурный стиль в программной инженерии "Промышленная архитектура программных систем" и проводятся параллели с аналогичным стилем в строительстве.
Основные моменты:
- В программной инженерии, как и в строительстве, существуют архитектурные стили, которые отражают исторический контекст и требования своего времени, и способствуют распространению и применению лучших практик для их реализации.
- Промышленная архитектура в строительстве ориентирована на проектирование зданий для производственных нужд, с акцентом на функциональность, экономическую эффективность, инновационность, надёжность, безопасность, модульность и автономность.
- Промышленная архитектура программных систем так же направлена на создание промышленных решений и сохраняет те же акценты.
- Общим трендом для промышленной архитектуры как в строительстве, так и в разработке программных систем является проектирование с учётом будущих изменений и обеспечение эволюционности
Начало раздела: https://news.1rj.ru/str/IndustrialSoftwareArchitecture/15
Telegram
Industrial Software Architecture
#Промышленнаяархитектура
А что же такое “Промышленная архитектура”?
Для того, чтобы ответить на этот вопрос, нужно сначала определить, а что же такое “архитектурный стиль”.
В программной инженерии, как и в строительстве зданий и сооружений, присутствуют…
А что же такое “Промышленная архитектура”?
Для того, чтобы ответить на этот вопрос, нужно сначала определить, а что же такое “архитектурный стиль”.
В программной инженерии, как и в строительстве зданий и сооружений, присутствуют…
👍5❤1
Intelligent Systems Architecture pinned «#итоги Промышленная архитектура программных систем: Параллели со строительством и ключевые черты В разделе вводится новый архитектурный стиль в программной инженерии "Промышленная архитектура программных систем" и проводятся параллели с аналогичным стилем…»
#итоги
Системы и инженерия: Промышленная архитектура как элемент возрождения инженерных подходов в разработке программных систем
В разделе вводятся понятия системы и эмерджентности, инженерии; обсуждаются технические системы и современные вызовы, связанные с использованием Эждайл и микросервисной архитектуры. Также рассматриваются свойства программных систем в контексте промышленной архитектуры и принципы, которыми должны руководствоваться инженеры.
Основные моменты:
- Системы порождают эмерджентность — системный эффект, при котором возникают свойства, не характерные для её отдельных элементов.
- Понимание системного эффекта и применение инженерных подходов являются ключевыми факторами для успешного проектирования сложных программных решений.
- Ключевые свойства программных систем, как технических систем, выполненных в стиле Промышленной архитектуры: наличие потребительских качеств и выполнение полезных функций, способность к многократным изменениям состояния, многоэлементность и наличие множества связей между элементами, иерархичность.
- Применение Эджайл-методов и микросервисной архитектуры часто приводит к хаосу и непредсказуемости в эксплуатации и развитии систем.
- В настоящее время появилась необходимость в систематизации инженерных практик в архитектуре программных систем для создания предсказуемых, экономически эффективных и безопасных решений. В связи с этим предлагается новый стиль — «Промышленная архитектура программных систем».
Начало раздела: https://news.1rj.ru/str/IndustrialSoftwareArchitecture/26
Системы и инженерия: Промышленная архитектура как элемент возрождения инженерных подходов в разработке программных систем
В разделе вводятся понятия системы и эмерджентности, инженерии; обсуждаются технические системы и современные вызовы, связанные с использованием Эждайл и микросервисной архитектуры. Также рассматриваются свойства программных систем в контексте промышленной архитектуры и принципы, которыми должны руководствоваться инженеры.
Основные моменты:
- Системы порождают эмерджентность — системный эффект, при котором возникают свойства, не характерные для её отдельных элементов.
- Понимание системного эффекта и применение инженерных подходов являются ключевыми факторами для успешного проектирования сложных программных решений.
- Ключевые свойства программных систем, как технических систем, выполненных в стиле Промышленной архитектуры: наличие потребительских качеств и выполнение полезных функций, способность к многократным изменениям состояния, многоэлементность и наличие множества связей между элементами, иерархичность.
- Применение Эджайл-методов и микросервисной архитектуры часто приводит к хаосу и непредсказуемости в эксплуатации и развитии систем.
- В настоящее время появилась необходимость в систематизации инженерных практик в архитектуре программных систем для создания предсказуемых, экономически эффективных и безопасных решений. В связи с этим предлагается новый стиль — «Промышленная архитектура программных систем».
Начало раздела: https://news.1rj.ru/str/IndustrialSoftwareArchitecture/26
Telegram
Industrial Software Architecture
Мы немного разобрались с общими чертами Промышленной архитектуры в строительстве и нашли сходство с Промышленной архитектурой программных систем.
Теперь стоит погрузиться во вторую часть названия нового в программной инженерии архитектурного стиля и дать…
Теперь стоит погрузиться во вторую часть названия нового в программной инженерии архитектурного стиля и дать…
👍5🔥1
#оффтоп #холизм
Счёл важным привести пример системного подхода в одном из величайших трудов по стратегии «О войне», Клаузевица:
«В нашем предмете, более чем в каком-либо другом, вместе с частью должно мыслиться целое»
Что важно, автор задаёт эту установку (холизм) с самого начала, во вступительной части.
Счёл важным привести пример системного подхода в одном из величайших трудов по стратегии «О войне», Клаузевица:
«В нашем предмете, более чем в каком-либо другом, вместе с частью должно мыслиться целое»
Что важно, автор задаёт эту установку (холизм) с самого начала, во вступительной части.
👍8
Forwarded from Сообщество Архитекторов (CommunityManager)
57-й выпуск дайджеста для ваших выходных!
Understanding and implementing micro-frontends
on AWS
Руководство от Amazon в части формирования понимания архитектуры микрофронтенда и создания решений микрофронтенда на Amazon Web Services (AWS).
Apache Kafka Cluster Type Deployment Strategies
Несколько кластеров Kafka являются нормой, а не исключением. Варианты использования включают гибридную интеграцию, агрегацию, миграцию и аварийное восстановление. В этой записи
блога рассматриваются реальные истории успеха и кластерные стратегии для различных развертываний Kafka в разных отраслях.
Building A Generative AI Platform
Интересная статья про концептуализацию знаний про приложения с генеративным ИИ. Автор изучил, как компании внедряют приложения генеративного ИИ, и выделил много сходств в их платформах.
В этой статье он описываются общие компоненты платформы генеративного ИИ, что они делают и как они реализуются.
Thinking Like an Architect
Не устаревающая со временем концепция о роли архитектора от Gregor Hohpe. Автор книги «The Software Architect Elevator» недавно делал доклад «Thinking Like an Architect» на конференции
QCon London 2024. Эта статья представляет собой доклад, который начинается с объяснения ролей архитектора и концепции соединения уровней.
Control Flow—The Other Half of Integration Patterns
Еще одна статья от Gregor Hohpe. Он рассматривает концепцию Control Flow (поток управления) в части механизма реализации асинхронных взаимодействий.
Остальные статьи этого выпуска можно найти на Confluence.
Читаем
Understanding and implementing micro-frontends
on AWS
Руководство от Amazon в части формирования понимания архитектуры микрофронтенда и создания решений микрофронтенда на Amazon Web Services (AWS).
Apache Kafka Cluster Type Deployment Strategies
Несколько кластеров Kafka являются нормой, а не исключением. Варианты использования включают гибридную интеграцию, агрегацию, миграцию и аварийное восстановление. В этой записи
блога рассматриваются реальные истории успеха и кластерные стратегии для различных развертываний Kafka в разных отраслях.
Building A Generative AI Platform
Интересная статья про концептуализацию знаний про приложения с генеративным ИИ. Автор изучил, как компании внедряют приложения генеративного ИИ, и выделил много сходств в их платформах.
В этой статье он описываются общие компоненты платформы генеративного ИИ, что они делают и как они реализуются.
Thinking Like an Architect
Не устаревающая со временем концепция о роли архитектора от Gregor Hohpe. Автор книги «The Software Architect Elevator» недавно делал доклад «Thinking Like an Architect» на конференции
QCon London 2024. Эта статья представляет собой доклад, который начинается с объяснения ролей архитектора и концепции соединения уровней.
Control Flow—The Other Half of Integration Patterns
Еще одна статья от Gregor Hohpe. Он рассматривает концепцию Control Flow (поток управления) в части механизма реализации асинхронных взаимодействий.
Остальные статьи этого выпуска можно найти на Confluence.
Читаем
❤5
#оффтоп #комментирую
Прокомментирую пост выше.
Про микрофронтенды
В статье про микрофронтенды сочетание BFF и API Gateway заставляет задуматься: https://docs.aws.amazon.com/prenoscriptive-guidance/latest/micro-frontends-aws/introduction.html
Важный момент - микрофронты, это прежде всего орг паттерн.
В представленном варианте вслед за BFF у команды может появиться, да почти точно появится, свой бэкенд. Если это конечно «чисто фронтовая» команда и бэкенда у неё до сих пор не было.
В иных случаях, от BFF могут «пойти» запросы в обход API Gateway к «своим микросервисам».
Почему так? Потому что появление BFF у отдельной команды может говорить о том, что развитие API (выставленного через API Gateway) и бизнес-логики под ним, не успевает за потребностями команды (на сами деле за потребностями клиентов/заказчиков)
Про Control Flow
Статью Грега Хоупа про Control Flow читать обязательно: https://www.enterpriseintegrationpatterns.com/ramblings/queues_control_flow.html
Грег Хоуп - выдающийся автор.
Напомню, Грег один из авторов книги, которая по сути заложила стандарт (паттерны + набор символов) в интеграции: https://www.enterpriseintegrationpatterns.com/
Кто не читал, читать обязательно!!!
Данная статья - дальнейшее развитие темы интеграции Грегом.
Прокомментирую пост выше.
Про микрофронтенды
В статье про микрофронтенды сочетание BFF и API Gateway заставляет задуматься: https://docs.aws.amazon.com/prenoscriptive-guidance/latest/micro-frontends-aws/introduction.html
Важный момент - микрофронты, это прежде всего орг паттерн.
В представленном варианте вслед за BFF у команды может появиться, да почти точно появится, свой бэкенд. Если это конечно «чисто фронтовая» команда и бэкенда у неё до сих пор не было.
В иных случаях, от BFF могут «пойти» запросы в обход API Gateway к «своим микросервисам».
Почему так? Потому что появление BFF у отдельной команды может говорить о том, что развитие API (выставленного через API Gateway) и бизнес-логики под ним, не успевает за потребностями команды (на сами деле за потребностями клиентов/заказчиков)
Про Control Flow
Статью Грега Хоупа про Control Flow читать обязательно: https://www.enterpriseintegrationpatterns.com/ramblings/queues_control_flow.html
Грег Хоуп - выдающийся автор.
Напомню, Грег один из авторов книги, которая по сути заложила стандарт (паттерны + набор символов) в интеграции: https://www.enterpriseintegrationpatterns.com/
Кто не читал, читать обязательно!!!
Данная статья - дальнейшее развитие темы интеграции Грегом.
Amazon
Understanding and implementing micro-frontends on AWS - AWS Prenoscriptive Guidance
Learn about the advantages and complexities of implementing micro-frontends as a distributed-system approach.
👍6🤝1
#оффтоп
Итоги подводятся с трудом
Пытаюсь переварить нестыковки в терминологии. Похоже никто этим всерьёз не занимался. Не складывается целостная онтология.
А пока, чтобы подать признаки жизни, поделюсь своими наблюдателями и выводами в работе с ChatGPT (AI)
Наблюдения:
1. AI хорошо переводит код с одного языка на другой, если код написан хорошо; похоже, если человеку легко читать код, то и AI воспринимает его без проблем, вероятно, благодаря качественным обучающим данным, на которых он обучен
2. AI прекрасно помогает траблшутить (выявлять и устранять проблемы), но для этого нужно уметь траблшутить и задавать правильные вопросы, что требует опыта
3. AI хорошо генерирует примеры, если запросы точно сформулированы, но это также требует навыков и опыта
Выводы:
1. Уже не мыслю свою деятельность без AI, как помощника
2. AI как помощник в решении сложных задач пока пригоден только для опытных специалистов, поскольку умение задавать правильные вопросы требует глубокого понимания предмета
3. В обозримом будущем AI вряд ли сможет помочь в решении задач, сложнее тех, которые человек способен решить без AI
Итоги подводятся с трудом
Пытаюсь переварить нестыковки в терминологии. Похоже никто этим всерьёз не занимался. Не складывается целостная онтология.
А пока, чтобы подать признаки жизни, поделюсь своими наблюдателями и выводами в работе с ChatGPT (AI)
Наблюдения:
1. AI хорошо переводит код с одного языка на другой, если код написан хорошо; похоже, если человеку легко читать код, то и AI воспринимает его без проблем, вероятно, благодаря качественным обучающим данным, на которых он обучен
2. AI прекрасно помогает траблшутить (выявлять и устранять проблемы), но для этого нужно уметь траблшутить и задавать правильные вопросы, что требует опыта
3. AI хорошо генерирует примеры, если запросы точно сформулированы, но это также требует навыков и опыта
Выводы:
1. Уже не мыслю свою деятельность без AI, как помощника
2. AI как помощник в решении сложных задач пока пригоден только для опытных специалистов, поскольку умение задавать правильные вопросы требует глубокого понимания предмета
3. В обозримом будущем AI вряд ли сможет помочь в решении задач, сложнее тех, которые человек способен решить без AI
👍6
#кейс
К посту выше
С помощью ChatGPT за пару вечеров:
- обернул в FastAPI код несложного, но полноценного (не прототипа) приложения на Python, вообще не зная FastAPI на тот момент
- задокументировал API в Swagger, снабдив работающим примером
- упаковал в Docker (это) приложение на FastAPI вместе с зависимостями на Go
При этом, я много лет программировал на Java, а Python использую только изредка в последние годы, в основном ради удовольствия
К посту выше
С помощью ChatGPT за пару вечеров:
- обернул в FastAPI код несложного, но полноценного (не прототипа) приложения на Python, вообще не зная FastAPI на тот момент
- задокументировал API в Swagger, снабдив работающим примером
- упаковал в Docker (это) приложение на FastAPI вместе с зависимостями на Go
При этом, я много лет программировал на Java, а Python использую только изредка в последние годы, в основном ради удовольствия
👍8🔥2❤1