Если вам вдруг нечем заняться в зимний воскресный день, предлагаю задачку.
У программистов есть классическая, даже легендарная задача на собеседовании: FizzBuzz.
Нужно написать программу, которая для каждого числа от 1 до 100 выдает либо Fizz (если число делится без остатка на 3), либо Buzz (если число делится без остатка на 5), либо FizzBuzz, если число делится без остатка и на 3, и на 5. Если число не делится ни на 3, ни на 5 — нужно выдать само это число.
Задачу так часто давали разработчикам на интервью, что это стало уже анекдотом.
А решается она настолько просто, что появились разновидности с усложнением: FizzBuzz только с двумя if; FizzBuzz с двумя if без использования переменных; вообще без if и без переменных; без использования операции взятия остатка и т.д.
Есть решения невероятной сложности — например,
FizzBuzz на косинусах и дискретных преобразованиях Фурье: https://habr.com/ru/articles/969856/ (осторожно, в посте для вывода используется формула Эйлера комплексными числами, я вас предупредил), или
FizzBuzz на TensorFlow, на основе многослойного перцептрона со скрытым слоем: https://habr.com/ru/articles/301536/.
Впрочем, ближе к нам корпоративная реализация FizzBuzz: https://habr.com/ru/companies/contentai/articles/173885/ (язык — Java; 102 файла, разложенных по 44 папкам; используются такие ООП-паттерны, как Стратегия, Абстрактная фабрика, Декоратор, Адаптер; есть тесты). Впрочем, как пишут многие критики, до настоящего ПО корпоративного уровня этому решению далеко.
Вот я и предлагаю вам потренироваться — написать максимально полный набор требований к FizzBuzz. Что там должно быть? Что упускают все авторы? Давайте покажем этим программистам, что на самом деле они постоянно не учитывают в своих решениях!
У программистов есть классическая, даже легендарная задача на собеседовании: FizzBuzz.
Нужно написать программу, которая для каждого числа от 1 до 100 выдает либо Fizz (если число делится без остатка на 3), либо Buzz (если число делится без остатка на 5), либо FizzBuzz, если число делится без остатка и на 3, и на 5. Если число не делится ни на 3, ни на 5 — нужно выдать само это число.
Задачу так часто давали разработчикам на интервью, что это стало уже анекдотом.
А решается она настолько просто, что появились разновидности с усложнением: FizzBuzz только с двумя if; FizzBuzz с двумя if без использования переменных; вообще без if и без переменных; без использования операции взятия остатка и т.д.
Есть решения невероятной сложности — например,
FizzBuzz на косинусах и дискретных преобразованиях Фурье: https://habr.com/ru/articles/969856/ (осторожно, в посте для вывода используется формула Эйлера комплексными числами, я вас предупредил), или
FizzBuzz на TensorFlow, на основе многослойного перцептрона со скрытым слоем: https://habr.com/ru/articles/301536/.
Впрочем, ближе к нам корпоративная реализация FizzBuzz: https://habr.com/ru/companies/contentai/articles/173885/ (язык — Java; 102 файла, разложенных по 44 папкам; используются такие ООП-паттерны, как Стратегия, Абстрактная фабрика, Декоратор, Адаптер; есть тесты). Впрочем, как пишут многие критики, до настоящего ПО корпоративного уровня этому решению далеко.
Вот я и предлагаю вам потренироваться — написать максимально полный набор требований к FizzBuzz. Что там должно быть? Что упускают все авторы? Давайте покажем этим программистам, что на самом деле они постоянно не учитывают в своих решениях!
😁12❤6🔥5🥰2🤯2
Обсуждение FizzBuzz напомнило про старую задачку на моделирование классов и взаимодействия: как замоделировать ситуацию "человек пьет кофе из кружки".
Очевидно, у нас будут классы "человек" и "кружка", и, например, уровень кофе в кружке. А вот про взаимодействие вопрос: где живет метод "пить"? Класс "человек" отправляет сообщение "пить(объем кофе)" классу "кружка" ( person->cup.drink(30) )? Или человек пьет, а кружка тогда что делает? ( person.drinkFrom(cup,30) )
Я не помню, у кого я видел обсуждение этой задачи. Но пока искал, нашел прекрасную статью Грегора Хопа (соавтора "Паттернов интеграции корпоративных приложений") с иллюстрацией синхронной и асинхронной интеграции на примере Starbucks.
Если вы помните, заказ в Starbucks принимают синхронно: вы не можете в процессе заказа и оплаты отойти на минуточку, а потом вернуться. Заказ и оплата выполняются в одном синхронном взаимодействии, даже если растягивается по времени.
А вот приготовление выполняется асинхронно:
— разные напитки требуют разного времени приготовления
— разное оборудование может быть использовано параллельно
— приготовление может вставать в очередь, когда оборудование занято
— заказы могут быть готовы не в той последовательности, в которой были сделаны
Почему так сделано? Для увеличения пропускной способности. Если у вас один человек принимает оплату, а потом сам готовит кофе — вы получаете кофе быстрее (ваш заказ взят в работу сразу же), но за вами копится очередь, и часть людей может уйти, не дождавшись. Асинхронность позволяет легко организовать горизонтальное масштабирование — можно увеличить число барист.
Тем не менее, транзакция закончена только когда клиент получил напиток. В нашей гибридной архитектуре — с синхронным и асинхронным взаимодействием — транзакция становится распределенной. Тут можно увидеть несколько паттернов:
— Идентификатор корреляции (Correlation ID), чтобы сопоставить приготовленный напиток и заказ. В Starbucks в качестве этого идентификатора используют имя клиента.
— Обработка исключений. Когда описывают "саги", всегда пишут про компенсирующие действия. Но Хоп пишет, что есть три варианта:
1. Списание. Если транзакция завершилась неудачей, мы просто ничего не делаем. А что уже сделали — выбрасываем (списываем). Возможно, механизм исправления ошибки будет стоить дороже. Иногда у нас просто нет другой возможности, а иногда это бизнес-решение: если клиент не забрал напиток, его через какое-то время нужно вылить.
2. Повторная попытка. Если в ходе транзакции возник технический сбой, а не нарушение бизнес-правила, можно попробовать повторить действие. Чтобы не заморачиваться, можно повторить все действия (но для этого у нас должны быть идемпотентные получатели, чтобы можно было безопасно повторить все запросы, начиная с первого). Если кофемашина сломалась, нужно повторить все действия на другой.
3. Компенсирующие действия — выполнение обратных операций. Если мы совсем не смогли приготовить кофе, придется вернуть деньги.
— Альтернатива — двухфазный коммит, когда кассир выступает координатором, и принимает оплату только после приготовления напитка. Это сильно задерживает выполнение транзакции, но зато система никогда не находится в несогласованном состоянии. В реальном мире это, например, счета эскроу.
Что ещё можно вспомнить? Если рассмотреть другие закусочные, то можно увидеть паттерн Claim Check — когда клиент получает не финальный (тяжелый) результат, а чек, с которым он приходит за заказом. Тогда идентификатор корреляции — номер заказа, который есть на чеке.
И, раз мы используем гибридный подход, можем увидеть и паттерны синхронных взаимодействий:
— если у кассира сломалась касса или клиент замешкался с оплатой, можно открыть вторую кассу и перенаправить ожидающих клиентов туда — это паттерн Circuit Breaker, размыкатель. Как вариант — перестает принимать заказы на определенный вид напитка, например, если сломался капучинатор.
Все паттерны взаимодействия пришли из реального мира, в конечном счете.
Очевидно, у нас будут классы "человек" и "кружка", и, например, уровень кофе в кружке. А вот про взаимодействие вопрос: где живет метод "пить"? Класс "человек" отправляет сообщение "пить(объем кофе)" классу "кружка" ( person->cup.drink(30) )? Или человек пьет, а кружка тогда что делает? ( person.drinkFrom(cup,30) )
Я не помню, у кого я видел обсуждение этой задачи. Но пока искал, нашел прекрасную статью Грегора Хопа (соавтора "Паттернов интеграции корпоративных приложений") с иллюстрацией синхронной и асинхронной интеграции на примере Starbucks.
Если вы помните, заказ в Starbucks принимают синхронно: вы не можете в процессе заказа и оплаты отойти на минуточку, а потом вернуться. Заказ и оплата выполняются в одном синхронном взаимодействии, даже если растягивается по времени.
А вот приготовление выполняется асинхронно:
— разные напитки требуют разного времени приготовления
— разное оборудование может быть использовано параллельно
— приготовление может вставать в очередь, когда оборудование занято
— заказы могут быть готовы не в той последовательности, в которой были сделаны
Почему так сделано? Для увеличения пропускной способности. Если у вас один человек принимает оплату, а потом сам готовит кофе — вы получаете кофе быстрее (ваш заказ взят в работу сразу же), но за вами копится очередь, и часть людей может уйти, не дождавшись. Асинхронность позволяет легко организовать горизонтальное масштабирование — можно увеличить число барист.
Тем не менее, транзакция закончена только когда клиент получил напиток. В нашей гибридной архитектуре — с синхронным и асинхронным взаимодействием — транзакция становится распределенной. Тут можно увидеть несколько паттернов:
— Идентификатор корреляции (Correlation ID), чтобы сопоставить приготовленный напиток и заказ. В Starbucks в качестве этого идентификатора используют имя клиента.
— Обработка исключений. Когда описывают "саги", всегда пишут про компенсирующие действия. Но Хоп пишет, что есть три варианта:
1. Списание. Если транзакция завершилась неудачей, мы просто ничего не делаем. А что уже сделали — выбрасываем (списываем). Возможно, механизм исправления ошибки будет стоить дороже. Иногда у нас просто нет другой возможности, а иногда это бизнес-решение: если клиент не забрал напиток, его через какое-то время нужно вылить.
2. Повторная попытка. Если в ходе транзакции возник технический сбой, а не нарушение бизнес-правила, можно попробовать повторить действие. Чтобы не заморачиваться, можно повторить все действия (но для этого у нас должны быть идемпотентные получатели, чтобы можно было безопасно повторить все запросы, начиная с первого). Если кофемашина сломалась, нужно повторить все действия на другой.
3. Компенсирующие действия — выполнение обратных операций. Если мы совсем не смогли приготовить кофе, придется вернуть деньги.
— Альтернатива — двухфазный коммит, когда кассир выступает координатором, и принимает оплату только после приготовления напитка. Это сильно задерживает выполнение транзакции, но зато система никогда не находится в несогласованном состоянии. В реальном мире это, например, счета эскроу.
Что ещё можно вспомнить? Если рассмотреть другие закусочные, то можно увидеть паттерн Claim Check — когда клиент получает не финальный (тяжелый) результат, а чек, с которым он приходит за заказом. Тогда идентификатор корреляции — номер заказа, который есть на чеке.
И, раз мы используем гибридный подход, можем увидеть и паттерны синхронных взаимодействий:
— если у кассира сломалась касса или клиент замешкался с оплатой, можно открыть вторую кассу и перенаправить ожидающих клиентов туда — это паттерн Circuit Breaker, размыкатель. Как вариант — перестает принимать заказы на определенный вид напитка, например, если сломался капучинатор.
Все паттерны взаимодействия пришли из реального мира, в конечном счете.
❤25🔥12👍3
Удивительно, но я никогда не видел хороших чеклистов для микросервисов, особенно для проверки — правильно ли они выделены, всё ли продумано.
Обычно попадаются чеклисты для проверки технических вещей, чуть ли не на уровне DevOps. Примеры: раз, два.
Культура чеклистов вообще не очень развита, многие не понимают, что это. Дают просто существительные. [ ] Sync vs. Async/Event-based processing. И что я тут должен поставить?
Во многих чеклистах забывают или игнорируют вопрос — зачем сервисы вообще нужны? Это понятно, ведь составляют их архитекторы или разработчики.
Поэтому пришлось сделать свой чеклист, подходящий для системных аналитиков. Держите:
1. Идентичность и ответственность
1.1. Можем описать ответственность сервиса одной фразой без «и», «а также», «кроме того», «плюс».
1.2. Понятно, какой бизнес-драйвер обосновывает существование сервиса (скорость изменения этого субдомена, масштабирование/нагрузки, сокращение TTM, регуляторные требования/безопасность, снижение/изоляция ошибок и т.п.).
1.3. Можно назвать 1 ключевую бизнес-способность, за которую отвечает сервис
2. Границы и связи с другими сервисами
2.1. Для сервиса понятен список use-case’ов, в которых он:
— ведущий (владеет бизнес-логикой),
— участник (вызывается другим сервисом, реагирует на событие).
2.2. Сервису не нужен прямой доступ в базу других сервисов; только через API/события.
2.3. Есть разумный список зависимостей от других сервисов (входящих и исходящих), нет "всех со всеми".
2.4. Сервис не является "божественным объектом" — не пытается делать всё для всех.
3. Данные и инварианты
3.1. Определены основные агрегаты/сущности, которыми владеет сервис (список 3–7 штук).
3.2. Для ключевых данных описаны инварианты: что "никогда не должно нарушаться"
3.3. Для каждого инварианта определен механизм, за счет которого он соблюдается (бизнес-логика, ограничения БД, контракты взаимодействия)
3.4. Для сервиса определены объемы и профили хранения данных (типичный объем хранения; прирост; вывод устаревших данных/архивация; доля "горячих" и "холодных" данных)
3.5. Для 1–2 основных сущностей сервиса описаны: этапы жизненного цикла (статусы), допустимые переходы между ними, кто инициирует какой переход (use-case / входящее событие).
3.6. Для ключевых сущностей предусмотрены все операции CRUD (понятно, кто их делает, есть API) + архивирование/хранение истории
3.7. Приняты решения по модели чтения (CQRS, Event Sourcing)
4. Контракты, схемы и API
4.1. Составлен список внешних операций:
— команды (изменяют состояние),
— запросы (чтение),
— доменные события (что сервис публикует).
4.2. Методы разумно гранулированы: нет «мега-методов», которые делают всё сразу, и нет чрезмерно мелких операций, создающих "болтливые" (chatty) API.
4.3. Для ключевых операций определена модель ошибок и контракты ответов/обработки:
— ошибки бизнес-уровня (валидация полей, попытки нарушения инвариантов, недостаток данных из-за Eventual Consistency),
— какие — технические,
— как клиент понимает, что делать (повторять/не повторять/обращаться в поддержку).
4.4. Определена стратегия эволюции структуры API и схем данных: принудительное обновление клиентов / поддержка нескольких версий API / схем
4.5. Все события описаны как контракт: есть описание схемы; определены гарантии доставки / сохранения порядка
4.6. Определены идемпотентные операции и механизмы обеспечения идемпотентности
5. Надёжность, производительность, наблюдаемость
5.1. Для ключевых операций определены SLO:
— латентность
— доступность
— процент ошибок
5.2. Поведение при отказах: понятно, что делает сервис:
— при падении зависимого сервиса,
— при перегрузке (ограничение, деградация, очереди),
— есть ли таймауты, ретраи, circuit breaker, алгоритм перепосылок
5.3. Определена тактика горизонтального масштабирования и распределения нагрузки: round robin, деление по данным, по клиентам
5.4. Выявлены потенциальные узкие места (БД, внешняя интеграция, блокирующие операции, большие файлы, состояния гонки), приняты решения по их расшивке
5.5. Определены отслеживаемые бизнес-метрики, технические метрики и ключевые события для логирования
Обычно попадаются чеклисты для проверки технических вещей, чуть ли не на уровне DevOps. Примеры: раз, два.
Культура чеклистов вообще не очень развита, многие не понимают, что это. Дают просто существительные. [ ] Sync vs. Async/Event-based processing. И что я тут должен поставить?
Во многих чеклистах забывают или игнорируют вопрос — зачем сервисы вообще нужны? Это понятно, ведь составляют их архитекторы или разработчики.
Поэтому пришлось сделать свой чеклист, подходящий для системных аналитиков. Держите:
1. Идентичность и ответственность
1.1. Можем описать ответственность сервиса одной фразой без «и», «а также», «кроме того», «плюс».
1.2. Понятно, какой бизнес-драйвер обосновывает существование сервиса (скорость изменения этого субдомена, масштабирование/нагрузки, сокращение TTM, регуляторные требования/безопасность, снижение/изоляция ошибок и т.п.).
1.3. Можно назвать 1 ключевую бизнес-способность, за которую отвечает сервис
2. Границы и связи с другими сервисами
2.1. Для сервиса понятен список use-case’ов, в которых он:
— ведущий (владеет бизнес-логикой),
— участник (вызывается другим сервисом, реагирует на событие).
2.2. Сервису не нужен прямой доступ в базу других сервисов; только через API/события.
2.3. Есть разумный список зависимостей от других сервисов (входящих и исходящих), нет "всех со всеми".
2.4. Сервис не является "божественным объектом" — не пытается делать всё для всех.
3. Данные и инварианты
3.1. Определены основные агрегаты/сущности, которыми владеет сервис (список 3–7 штук).
3.2. Для ключевых данных описаны инварианты: что "никогда не должно нарушаться"
3.3. Для каждого инварианта определен механизм, за счет которого он соблюдается (бизнес-логика, ограничения БД, контракты взаимодействия)
3.4. Для сервиса определены объемы и профили хранения данных (типичный объем хранения; прирост; вывод устаревших данных/архивация; доля "горячих" и "холодных" данных)
3.5. Для 1–2 основных сущностей сервиса описаны: этапы жизненного цикла (статусы), допустимые переходы между ними, кто инициирует какой переход (use-case / входящее событие).
3.6. Для ключевых сущностей предусмотрены все операции CRUD (понятно, кто их делает, есть API) + архивирование/хранение истории
3.7. Приняты решения по модели чтения (CQRS, Event Sourcing)
4. Контракты, схемы и API
4.1. Составлен список внешних операций:
— команды (изменяют состояние),
— запросы (чтение),
— доменные события (что сервис публикует).
4.2. Методы разумно гранулированы: нет «мега-методов», которые делают всё сразу, и нет чрезмерно мелких операций, создающих "болтливые" (chatty) API.
4.3. Для ключевых операций определена модель ошибок и контракты ответов/обработки:
— ошибки бизнес-уровня (валидация полей, попытки нарушения инвариантов, недостаток данных из-за Eventual Consistency),
— какие — технические,
— как клиент понимает, что делать (повторять/не повторять/обращаться в поддержку).
4.4. Определена стратегия эволюции структуры API и схем данных: принудительное обновление клиентов / поддержка нескольких версий API / схем
4.5. Все события описаны как контракт: есть описание схемы; определены гарантии доставки / сохранения порядка
4.6. Определены идемпотентные операции и механизмы обеспечения идемпотентности
5. Надёжность, производительность, наблюдаемость
5.1. Для ключевых операций определены SLO:
— латентность
— доступность
— процент ошибок
5.2. Поведение при отказах: понятно, что делает сервис:
— при падении зависимого сервиса,
— при перегрузке (ограничение, деградация, очереди),
— есть ли таймауты, ретраи, circuit breaker, алгоритм перепосылок
5.3. Определена тактика горизонтального масштабирования и распределения нагрузки: round robin, деление по данным, по клиентам
5.4. Выявлены потенциальные узкие места (БД, внешняя интеграция, блокирующие операции, большие файлы, состояния гонки), приняты решения по их расшивке
5.5. Определены отслеживаемые бизнес-метрики, технические метрики и ключевые события для логирования
1❤22👍11🔥6👏1🤣1
Если вам удобнее использовать Canvas — для микросервисов есть и он, конечно. Точнее, даже не для самих микросервисов, а для ограниченных контекстов (спасибо Денису Мигулину за наводку).
Разделы:
Название
Смысл (Purpose) — бизнес-смысл существования этого контекста. Какую ценность несет этот контекст, кто получит выгоду, и как она обеспечивается? Сюда же можно записать бизнес-драйверы.
Стратегическая классификация, из трех частей:
💎 Уникальность — насколько этот контекст важен для успеха организации?
Он основной (core), то есть обеспечивает ключевое преимущество — или, как на английский манер говорят, является дифференциатором, отличает ваш бизнес от других? Или поддерживающий — обязательный для деятельности, но не уникальный? Или типовой (generic) — такой же, как у других компаний, ничего специфического?
⚙️ Роль в бизнес-модели:
— генерация прибыли,
— повышение вовлеченности/виральности,
— предотвращение рисков (регуляторных, репутационных, ...)
— снижение расходов
📊 Стадия эволюции (по Wardley map):
— Зарождение
— Заказная разработка
— Готовый продукт
— Типовое решение (commodity)
Архетип домена (роль):
— Конструктор (нужен для создания чего-то, возможно — совместными усилиями, возможно — черновика какого-то объекта)
— Исполнитель (выполняет или поддерживает исполнение бизнес-процесса)
— Аудитор (отслеживает выполнение)
— Контролер (принимает решение о возможности выполнения следующего шага, утверждает)
— Блюститель (Enforcer; принуждает другие контексты выполнить определенные операции в соответствии с внешними бизнес-правилами)
— Переводчик (переводит между разными "бизнес-языками")
— Шлюз (контролирует границы и внешние взаимодействия; может совмещаться с ролью переводчика)
— Пузырь (экранирует легаси-систему до её вывода)
— Воронка/трубопровод (перекачивает данные/документы из одного контекста в другой с обработкой)
— Аналитика (собирает и обобщает данные)
Язык домена: какие в этом контексте есть понятия и термины?
Входящие коммуникации: кто в этот контекст посылает сообщения, и какие? Это могут быть другие контексты, пользователи или устройства пользователей, существующие системы. Контексты с точки зрения коммуникаций делятся на восходящие (upstream) и нисходящие (downstream) — восходящие предоставляют информацию/сервисы и публикуют события, а нисходящие используют информацию и потребляют события.
У взаимодействий тоже есть свои типы, или паттерны мэппинга контекста:
— OHS, Open-host Service — контекст предоставляет одинаковые услуги всем, кому они нужны. Он не подстраивается под каждого клиента. Это upstream-контекст.
— CF, Conformist — паттерн для downstream-контекста: он подстраивается под язык upstream.
— ACL, Anticorruption layer — изолирующий слой для downstream-контекста, фильтрующий всю возможную "порчу", поступающую извне.
— SK, Shared Kernel — два контекста разделяют одну (компактную) модель. Создает зацепление, но облегчает понимание.
— PNR, Partnership — это больше про взаимодействие команд, когда они совместно согласуют взаимодействия (каждый может подвинуться)
— Customer / Supplier — отношения upstream/downstream, но, в отличие от OHS, upstream (supplier) зависит от cutomer'а, и учитывает его потребности в своей логике развития.
— PL, Published Language — дополнительный паттерн, определяющий специальный язык/формат для обмена. Типа vCard, или iCalendar, или какой-нибудь FHIR.
По паттерну взаимодействия тоже можно принять решение и зафиксировать на шаблоне.
Так же заполняется часть с исходящими коммуникациями, только теперь наш контекст будет upstream. Входящие и исходящие коммуникации удобно группировать в дорожки — юскейсы.
Бизнес-решения: какие приняты решения, политики и бизнес-правила.
Предположения: какими бизнес-предположениями в отношении контекста мы руководствовались.
Метрики верификации: у нас же были драйверы и предположения, а как мы измерим успех?
Открытые вопросы: что ещё нужно выяснить?
Я не знаю, как это заполняют программисты, но, кажется, это типовые вопросы для аналитика. Причем даже без связи с DDD, такие вопросы стоит задать при работе над любой задачей.
Разделы:
Название
Смысл (Purpose) — бизнес-смысл существования этого контекста. Какую ценность несет этот контекст, кто получит выгоду, и как она обеспечивается? Сюда же можно записать бизнес-драйверы.
Стратегическая классификация, из трех частей:
Он основной (core), то есть обеспечивает ключевое преимущество — или, как на английский манер говорят, является дифференциатором, отличает ваш бизнес от других? Или поддерживающий — обязательный для деятельности, но не уникальный? Или типовой (generic) — такой же, как у других компаний, ничего специфического?
— генерация прибыли,
— повышение вовлеченности/виральности,
— предотвращение рисков (регуляторных, репутационных, ...)
— снижение расходов
— Зарождение
— Заказная разработка
— Готовый продукт
— Типовое решение (commodity)
Архетип домена (роль):
— Конструктор (нужен для создания чего-то, возможно — совместными усилиями, возможно — черновика какого-то объекта)
— Исполнитель (выполняет или поддерживает исполнение бизнес-процесса)
— Аудитор (отслеживает выполнение)
— Контролер (принимает решение о возможности выполнения следующего шага, утверждает)
— Блюститель (Enforcer; принуждает другие контексты выполнить определенные операции в соответствии с внешними бизнес-правилами)
— Переводчик (переводит между разными "бизнес-языками")
— Шлюз (контролирует границы и внешние взаимодействия; может совмещаться с ролью переводчика)
— Пузырь (экранирует легаси-систему до её вывода)
— Воронка/трубопровод (перекачивает данные/документы из одного контекста в другой с обработкой)
— Аналитика (собирает и обобщает данные)
Язык домена: какие в этом контексте есть понятия и термины?
Входящие коммуникации: кто в этот контекст посылает сообщения, и какие? Это могут быть другие контексты, пользователи или устройства пользователей, существующие системы. Контексты с точки зрения коммуникаций делятся на восходящие (upstream) и нисходящие (downstream) — восходящие предоставляют информацию/сервисы и публикуют события, а нисходящие используют информацию и потребляют события.
У взаимодействий тоже есть свои типы, или паттерны мэппинга контекста:
— OHS, Open-host Service — контекст предоставляет одинаковые услуги всем, кому они нужны. Он не подстраивается под каждого клиента. Это upstream-контекст.
— CF, Conformist — паттерн для downstream-контекста: он подстраивается под язык upstream.
— ACL, Anticorruption layer — изолирующий слой для downstream-контекста, фильтрующий всю возможную "порчу", поступающую извне.
— SK, Shared Kernel — два контекста разделяют одну (компактную) модель. Создает зацепление, но облегчает понимание.
— PNR, Partnership — это больше про взаимодействие команд, когда они совместно согласуют взаимодействия (каждый может подвинуться)
— Customer / Supplier — отношения upstream/downstream, но, в отличие от OHS, upstream (supplier) зависит от cutomer'а, и учитывает его потребности в своей логике развития.
— PL, Published Language — дополнительный паттерн, определяющий специальный язык/формат для обмена. Типа vCard, или iCalendar, или какой-нибудь FHIR.
По паттерну взаимодействия тоже можно принять решение и зафиксировать на шаблоне.
Так же заполняется часть с исходящими коммуникациями, только теперь наш контекст будет upstream. Входящие и исходящие коммуникации удобно группировать в дорожки — юскейсы.
Бизнес-решения: какие приняты решения, политики и бизнес-правила.
Предположения: какими бизнес-предположениями в отношении контекста мы руководствовались.
Метрики верификации: у нас же были драйверы и предположения, а как мы измерим успех?
Открытые вопросы: что ещё нужно выяснить?
Я не знаю, как это заполняют программисты, но, кажется, это типовые вопросы для аналитика. Причем даже без связи с DDD, такие вопросы стоит задать при работе над любой задачей.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2
Про аналитиков мы уже говорили, а откуда взялись архитекторы ПО?
Термин "архитектура компьютера" вбросил Фред Брукс (руководитель проекта создания OS/360) и Lyle R. Johnson примерно в 1959 году. Определял он её как "то, что нужно знать пользователю". Пользователями тогда называли прикладных программистов.
Об архитектуре программ тогда речь не шла; идея, что разные части программы неплохо как-то логично организовать: структурное программирование только-только появилась.
В 1975 вышла книга Брукса "Мифический человеко-месяц", в которой он ввел понятие "программной системы", в отличие от отдельной программы. В том же году Frank DeRemer и Hans Kron опубликовали статьи "Программирование в большом [масштабе] против программирования в малом". В малом — это как раз про написание одиночной программы одним программистом, а "в большом" — как раз проектирование систем, состоящих из многих частей, написанных разными людьми. Но и это не привело к появлению профессии архитектора. Скорее стали разделять кодеров и программистов.
Прошло ещё 15 лет, прежде чем об архитектуре ПО заговорили, как об отдельном предмете. Первая книга про архитектуру появилась в 1990: Laurence J. Best, Application Architecture: Modern Large-Scale Information Processing. Речь тогда в основном шла о переиспользовании компонент, все носились с этой идеей переиспользования и выделения типовых объектов в объектно-ориентированных системах. Была даже целая объектно-ориентированная операционная система — OS/2 от IBM (проигравшая соревнование с Windows, но ставшая культовой в определенных кругах).
В 1992 опубликована статья Dewayne E. Perry и Alexander L. Wolf 'Foundations for the Study of Software Architecture', в которой обсуждается разница между архитектурой и дизайном, а также вводится формула:
Программная архитектура = {Элементы, Формы, Обоснования},
где Элементы делятся на элементы обработки, элементы данных и элементы связи,
а Формы — на взвешенные свойства элементов/системы и отношения между элементами.
В 1993 вышла работа 'An Introduction to Software Architecture' David Garlan и Mary Shaw, а 1996 их же книга 'Software Architecture: Perspectives on an Emerging Discipline' (перспективы зарождающейся дисциплины). Во "Введении в программную архитектуру" уже были перечислены такие архитектурные стили, как "трубы и фильтры", объектно-ориентированный стиль, событийно-ориентированный стиль, слоистые системы и т.д. (так что если вы видите такой список в каком-нибудь курсе или статье — помните, это список из 1993 года!) Основным вопросом было — кто в какой момент кого вызывает.
В 1995 году началась разработка стандарта IEEE 1471 Recommended Practice for Architectural Description for Software-Intensive Systems (будущий ISO 42010). Он вводил идею множества стейкхолдеров, точек зрения и архитектурных представлений. Для каждого архитектура — что-то своё, архитектура в глазах смотрящего.
Параллельно развивались подходы к оценке качества программного продукта: ISO 9126 впервые вышел в 1991 году. К началу 2000-х два направления сошлись: выяснилось, что на качество влияет как раз архитектура. Функции-то система будет выполнять с любой архитектурой, а вот для обеспечения разнообразных -ilities нужно подумать над внутренним устройством. Но это всё было не очень принципиально — пользователей было мало, данных было не очень много, вопросы если и возникали — то только в производительности или в скорости создания/изменения систем.
Звездный час для архитекторов наступил только в конце 2000-х, с расцветом веба — тут мы увидели такие нагрузки и такое количество данных, которых до этого никто никогда не видел. А вместе с ними — распределенные системы и жесткие требования по скорости обновления (TTM). И тогда появились специальные люди, определяющие основные развилки. Впрочем, на самом деле их настолько мало, что US Bureau of Labor Statistics отдельной роли архитектора вообще не выделяет, у них это обобщенные Software Developers, Quality Assurance Analysts and Testers. Так что, возможно, архитектор — это такая же специфическая для РФ роль, как и системный аналитик.
Термин "архитектура компьютера" вбросил Фред Брукс (руководитель проекта создания OS/360) и Lyle R. Johnson примерно в 1959 году. Определял он её как "то, что нужно знать пользователю". Пользователями тогда называли прикладных программистов.
Об архитектуре программ тогда речь не шла; идея, что разные части программы неплохо как-то логично организовать: структурное программирование только-только появилась.
В 1975 вышла книга Брукса "Мифический человеко-месяц", в которой он ввел понятие "программной системы", в отличие от отдельной программы. В том же году Frank DeRemer и Hans Kron опубликовали статьи "Программирование в большом [масштабе] против программирования в малом". В малом — это как раз про написание одиночной программы одним программистом, а "в большом" — как раз проектирование систем, состоящих из многих частей, написанных разными людьми. Но и это не привело к появлению профессии архитектора. Скорее стали разделять кодеров и программистов.
Прошло ещё 15 лет, прежде чем об архитектуре ПО заговорили, как об отдельном предмете. Первая книга про архитектуру появилась в 1990: Laurence J. Best, Application Architecture: Modern Large-Scale Information Processing. Речь тогда в основном шла о переиспользовании компонент, все носились с этой идеей переиспользования и выделения типовых объектов в объектно-ориентированных системах. Была даже целая объектно-ориентированная операционная система — OS/2 от IBM (проигравшая соревнование с Windows, но ставшая культовой в определенных кругах).
В 1992 опубликована статья Dewayne E. Perry и Alexander L. Wolf 'Foundations for the Study of Software Architecture', в которой обсуждается разница между архитектурой и дизайном, а также вводится формула:
Программная архитектура = {Элементы, Формы, Обоснования},
где Элементы делятся на элементы обработки, элементы данных и элементы связи,
а Формы — на взвешенные свойства элементов/системы и отношения между элементами.
В 1993 вышла работа 'An Introduction to Software Architecture' David Garlan и Mary Shaw, а 1996 их же книга 'Software Architecture: Perspectives on an Emerging Discipline' (перспективы зарождающейся дисциплины). Во "Введении в программную архитектуру" уже были перечислены такие архитектурные стили, как "трубы и фильтры", объектно-ориентированный стиль, событийно-ориентированный стиль, слоистые системы и т.д. (так что если вы видите такой список в каком-нибудь курсе или статье — помните, это список из 1993 года!) Основным вопросом было — кто в какой момент кого вызывает.
В 1995 году началась разработка стандарта IEEE 1471 Recommended Practice for Architectural Description for Software-Intensive Systems (будущий ISO 42010). Он вводил идею множества стейкхолдеров, точек зрения и архитектурных представлений. Для каждого архитектура — что-то своё, архитектура в глазах смотрящего.
Параллельно развивались подходы к оценке качества программного продукта: ISO 9126 впервые вышел в 1991 году. К началу 2000-х два направления сошлись: выяснилось, что на качество влияет как раз архитектура. Функции-то система будет выполнять с любой архитектурой, а вот для обеспечения разнообразных -ilities нужно подумать над внутренним устройством. Но это всё было не очень принципиально — пользователей было мало, данных было не очень много, вопросы если и возникали — то только в производительности или в скорости создания/изменения систем.
Звездный час для архитекторов наступил только в конце 2000-х, с расцветом веба — тут мы увидели такие нагрузки и такое количество данных, которых до этого никто никогда не видел. А вместе с ними — распределенные системы и жесткие требования по скорости обновления (TTM). И тогда появились специальные люди, определяющие основные развилки. Впрочем, на самом деле их настолько мало, что US Bureau of Labor Statistics отдельной роли архитектора вообще не выделяет, у них это обобщенные Software Developers, Quality Assurance Analysts and Testers. Так что, возможно, архитектор — это такая же специфическая для РФ роль, как и системный аналитик.
👍13❤4🔥1
Статья Дуэйна Перри и Александра Вольфа 'Foundations for the Study of Software Architecture' 1992 года достойна отдельного поста. Это одна из самых цитируемых работ по программной инженерии за всю историю.
В ней много интересных тезисов. Например, что архитектура ПО больше всего похожа на архитектуру зданий: требует нескольких отдельных видов, отражающих разные аспекты одной системы (или здания); имеет выраженные архитектурные стили, определяющие используемые элементы и их возможные связи; при этом стили связаны с инженерными принципами (то, что ты строишь, зависит от того, как ты строишь) и с материалом (...и из чего ты строишь).
Дальше они характеризуют разные уровни рассмотрения:
— требования определяют информацию, процессы её обработки, а также характеристики этой информации и процессов обработки, требуемые пользователям;
— архитектура занимается выбором архитектурных элементов, их взаимодействий, и ограничениями, накладываемыми на эти элементы и взаимодействия. Всё это нужно для создания основы, в рамках которой можно удовлетворить требования и которая послужит базой для проектирования.
— проектирование (дизайн) касается модульности, детальных интерфейсов элементов, алгоритмов и процедур, а также типов данных, необходимых для поддержки архитектуры и удовлетворения требований.
— реализация связана с представлением алгоритмов и типов данных, которые удовлетворяют проекту, архитектуре и требованиям. (Видимо, "представлением в виде кода")
Тут авторы оговариваются, что не во всех системах нужны все уровни, и иногда можно просто начать программировать (например, в проектах с искусственным интеллектом — напомню, это 1992 год!)
Распределение по уровням выглядит логично: сначала требования; потом выбор архитектуры, в которой, как кажется, можно реализовать эти требования; потом конкретный проект в выбранной архитектуре; и, наконец, реализация. Так что архитектор должен заниматься проектированием архитектуры, созданием основы. А конкретным дизайном может кто-то другой заняться. И если, по случайности, проектированием занимается архитектор — он просто выполняет другую роль в этот момент.
Итак, авторы определяют архитектуру через три понятия:
Software Architecture = { Elements, Form, Rationale }
Элементы архитектуры делятся на три класса:
* элементы обработки
* элементы данных
* соединительные элементы
Форма состоит из взвешенных свойств и отношений. Взвешенных — потому что не все свойства одинаково важны для конкретной системы (в соответствии с требованиями). Свойства ограничивают выбор архитектурных элементов. Отношения ограничивают "размещение" архитектурных элементов — то, где они расположены и как они связаны между собой.
Наконец, неотъемлемой, самой важной частью архитектуры является обоснование различных решений, принятых при определении архитектуры. Обоснование отражает мотивацию выбора архитектурного стиля, выбора элементов, и формы. Таким образом, главный документ архитектуры — не схема соединений конкретной системы (это проект). Главный документ — описание базовых принципов и принятых решений, то есть ADR.
Собственно, архитектурный стиль — это некий набор готовых решений, которые умные люди уже сделали за вас. Две главные проблемы архитектуры проявляются при изменении систем: эрозия и дрейф. Эрозия — это нарушение принципов определенной архитектуры или выбранного архитектурного стиля, а дрейф — когда сами принципы уже невозможно определить.
Интересно, как они определяют свойства — как состояния данных или результата обработки. То есть система описывается топологией связей и вот этими свойствами, практически через машину состояний. Это интересный подход, сегодня кажется утерянный. Мы моделируем потоки данных, процессы и команды, события, но архитекторы редко говорят про состояния (даже когда упоминают REST, который, по идее, должен как раз вокруг состояний строиться). А сложность архитектуры определяется как раз через сложность нотации, требуемой для описания состояний системы.
В ней много интересных тезисов. Например, что архитектура ПО больше всего похожа на архитектуру зданий: требует нескольких отдельных видов, отражающих разные аспекты одной системы (или здания); имеет выраженные архитектурные стили, определяющие используемые элементы и их возможные связи; при этом стили связаны с инженерными принципами (то, что ты строишь, зависит от того, как ты строишь) и с материалом (...и из чего ты строишь).
Дальше они характеризуют разные уровни рассмотрения:
— требования определяют информацию, процессы её обработки, а также характеристики этой информации и процессов обработки, требуемые пользователям;
— архитектура занимается выбором архитектурных элементов, их взаимодействий, и ограничениями, накладываемыми на эти элементы и взаимодействия. Всё это нужно для создания основы, в рамках которой можно удовлетворить требования и которая послужит базой для проектирования.
— проектирование (дизайн) касается модульности, детальных интерфейсов элементов, алгоритмов и процедур, а также типов данных, необходимых для поддержки архитектуры и удовлетворения требований.
— реализация связана с представлением алгоритмов и типов данных, которые удовлетворяют проекту, архитектуре и требованиям. (Видимо, "представлением в виде кода")
Тут авторы оговариваются, что не во всех системах нужны все уровни, и иногда можно просто начать программировать (например, в проектах с искусственным интеллектом — напомню, это 1992 год!)
Распределение по уровням выглядит логично: сначала требования; потом выбор архитектуры, в которой, как кажется, можно реализовать эти требования; потом конкретный проект в выбранной архитектуре; и, наконец, реализация. Так что архитектор должен заниматься проектированием архитектуры, созданием основы. А конкретным дизайном может кто-то другой заняться. И если, по случайности, проектированием занимается архитектор — он просто выполняет другую роль в этот момент.
Итак, авторы определяют архитектуру через три понятия:
Software Architecture = { Elements, Form, Rationale }
Элементы архитектуры делятся на три класса:
* элементы обработки
* элементы данных
* соединительные элементы
Форма состоит из взвешенных свойств и отношений. Взвешенных — потому что не все свойства одинаково важны для конкретной системы (в соответствии с требованиями). Свойства ограничивают выбор архитектурных элементов. Отношения ограничивают "размещение" архитектурных элементов — то, где они расположены и как они связаны между собой.
Наконец, неотъемлемой, самой важной частью архитектуры является обоснование различных решений, принятых при определении архитектуры. Обоснование отражает мотивацию выбора архитектурного стиля, выбора элементов, и формы. Таким образом, главный документ архитектуры — не схема соединений конкретной системы (это проект). Главный документ — описание базовых принципов и принятых решений, то есть ADR.
Собственно, архитектурный стиль — это некий набор готовых решений, которые умные люди уже сделали за вас. Две главные проблемы архитектуры проявляются при изменении систем: эрозия и дрейф. Эрозия — это нарушение принципов определенной архитектуры или выбранного архитектурного стиля, а дрейф — когда сами принципы уже невозможно определить.
Интересно, как они определяют свойства — как состояния данных или результата обработки. То есть система описывается топологией связей и вот этими свойствами, практически через машину состояний. Это интересный подход, сегодня кажется утерянный. Мы моделируем потоки данных, процессы и команды, события, но архитекторы редко говорят про состояния (даже когда упоминают REST, который, по идее, должен как раз вокруг состояний строиться). А сложность архитектуры определяется как раз через сложность нотации, требуемой для описания состояний системы.
❤7🔥4👍3
Нужно, наверное, какие-то итоги года подвести.
Итоги такие:
1. Канал немного не дотянул до 10 тыс.; число, конечно, символическое, но было бы приятно. В целом заметно замедление роста — то ли в алгоритмах рекомендаций что-то поменялось, то ли я стал писать про абстрактные вещи, не особо интересные. Оторвался от потребностей аудитории — а что, вполне возможно.
2. На рынке стал отчетливо виден спад, чтобы не сказать кризис. Найти работу стало сложнее. Проекты сжимаются, денег ощутимо меньше. И не думаю, что это как-то связано с ИИ, причины совсем в другом. Учебные группы набираются трудно, столько отмен и переносов не было раньше. На уровне ощущений — сейчас, кажется, должны быть востребованы менее дорогие форматы (но очень конкретные, которые дадут пользу прямо сейчас — либо с сохранением работы, либо с поиском).
3. О чем писал:
* Сильно обновил карту интеграций: раз и два
* С какими видами неопределенности работает аналитик и что с ними делать?
* Экономическая обоснованность автоматизации задач
* Шпаргалка по структуре http-запроса (надо бы сделать всё-таки сборник "интеграции в картинках")
* Вытащил в наглядную таблицу пример стоимости масштабирования
* Перевел несколько комиксов про разработку
* Написал про формулу Пуассона для расчета нагрузки в интеграциях
* Немного поборолся с распространенными мифами: про снижение неопределенности к концу проекта (Cone of uncertainty) и про стоимость исправления ошибки в зависимости от стадии обнаружения
* Запостил "Пирамиду требований", которую обычно на тренингах рисую
* Написал про эмоциональный компонент JTBD
* И про "Ясный язык"
* Про неизбежность диктатора при принятии коллективных решений и преодоление этой неизбежности
* Провел небольшое исследование — про среду в компаниях по методу Ясвина
* Про радар выбора процесса разработки — подходит ли для вашего проекта Agile?
* Какие решения и в каком виде можно передавать ИИ?
* Нашел граф со всеми возможными нефункциональными требованиями
* А ещё — каталог паттернов миграции со старой системы на новую
* И шаблон для PRD
* Сходил на новые конференции от JUG.ru — BiasConf и InBetween
* Пошутил про приколы интеграции (не протоколы!)
* Подсмотрел, как живут продакты (по отчету Atlassian)
* Поучаствовал в проектировании и анализе исследования системных аналитиков
* Завел отдельный канал про цифровизацию образования
* Написал про "Дома качества" — методику связывания функциональных и нефункциональных свойств с конструктивными особенностями и продуктовыми метриками
* Затеял несколько постов про DDD
* И вообще про роли аналитика и архитектора: раз, два и три
* А также сделал чеклист для выявления микросервисов и написал про канвас для ограниченных контекстов
Тема проектирования микросервисов получила развитие в виде курса, который уже один раз провел в декабре, и, надеюсь, буду повторять.
А вообще — много о чем за год удалось написать, хватает уже материала на книгу? "Современные методики анализа и проектирования систем"? Звучит, как учебник. Или "Записки аналитика"? ("у изголовья", подсказывает ассоциативная память).
В общем, не переключайтесь, в следующем году постараюсь для вас придумать что-нибудь менее философское и более прагматичное, а всем подписчикам желаю только самого лучшего — интересной работы, финансовой независимости, поддержки и понимания со стороны коллег и руководителей, уверенности в завтрашнем дне и профессионального роста! Ну и спокойствия ещё, всем нам оно необходимо.
С наступающим Новым годом!
🎄 🎁 🥂 🎆
Итоги такие:
1. Канал немного не дотянул до 10 тыс.; число, конечно, символическое, но было бы приятно. В целом заметно замедление роста — то ли в алгоритмах рекомендаций что-то поменялось, то ли я стал писать про абстрактные вещи, не особо интересные. Оторвался от потребностей аудитории — а что, вполне возможно.
2. На рынке стал отчетливо виден спад, чтобы не сказать кризис. Найти работу стало сложнее. Проекты сжимаются, денег ощутимо меньше. И не думаю, что это как-то связано с ИИ, причины совсем в другом. Учебные группы набираются трудно, столько отмен и переносов не было раньше. На уровне ощущений — сейчас, кажется, должны быть востребованы менее дорогие форматы (но очень конкретные, которые дадут пользу прямо сейчас — либо с сохранением работы, либо с поиском).
3. О чем писал:
* Сильно обновил карту интеграций: раз и два
* С какими видами неопределенности работает аналитик и что с ними делать?
* Экономическая обоснованность автоматизации задач
* Шпаргалка по структуре http-запроса (надо бы сделать всё-таки сборник "интеграции в картинках")
* Вытащил в наглядную таблицу пример стоимости масштабирования
* Перевел несколько комиксов про разработку
* Написал про формулу Пуассона для расчета нагрузки в интеграциях
* Немного поборолся с распространенными мифами: про снижение неопределенности к концу проекта (Cone of uncertainty) и про стоимость исправления ошибки в зависимости от стадии обнаружения
* Запостил "Пирамиду требований", которую обычно на тренингах рисую
* Написал про эмоциональный компонент JTBD
* И про "Ясный язык"
* Про неизбежность диктатора при принятии коллективных решений и преодоление этой неизбежности
* Провел небольшое исследование — про среду в компаниях по методу Ясвина
* Про радар выбора процесса разработки — подходит ли для вашего проекта Agile?
* Какие решения и в каком виде можно передавать ИИ?
* Нашел граф со всеми возможными нефункциональными требованиями
* А ещё — каталог паттернов миграции со старой системы на новую
* И шаблон для PRD
* Сходил на новые конференции от JUG.ru — BiasConf и InBetween
* Пошутил про приколы интеграции (не протоколы!)
* Подсмотрел, как живут продакты (по отчету Atlassian)
* Поучаствовал в проектировании и анализе исследования системных аналитиков
* Завел отдельный канал про цифровизацию образования
* Написал про "Дома качества" — методику связывания функциональных и нефункциональных свойств с конструктивными особенностями и продуктовыми метриками
* Затеял несколько постов про DDD
* И вообще про роли аналитика и архитектора: раз, два и три
* А также сделал чеклист для выявления микросервисов и написал про канвас для ограниченных контекстов
Тема проектирования микросервисов получила развитие в виде курса, который уже один раз провел в декабре, и, надеюсь, буду повторять.
А вообще — много о чем за год удалось написать, хватает уже материала на книгу? "Современные методики анализа и проектирования систем"? Звучит, как учебник. Или "Записки аналитика"? ("у изголовья", подсказывает ассоциативная память).
В общем, не переключайтесь, в следующем году постараюсь для вас придумать что-нибудь менее философское и более прагматичное, а всем подписчикам желаю только самого лучшего — интересной работы, финансовой независимости, поддержки и понимания со стороны коллег и руководителей, уверенности в завтрашнем дне и профессионального роста! Ну и спокойствия ещё, всем нам оно необходимо.
С наступающим Новым годом!
Please open Telegram to view this post
VIEW IN TELEGRAM
1🎉56❤33🔥12🎄4🥰3
С наступившим Новым годом!
В одном из новогодних обращений услышал: а ведь уже прошла четверть XXI века! Те, кто постарше (как я), помнят, что 21 век казался каким-то фантастическим. Ну он такой и есть! Вокруг нвс сплошная фантастика: у всех "персональные коммуникаторы", мы погружены в виртуальные миры, звоним с видео в любую точку мира, по улицам ездят роботы и машины без водителей, мы каждый день разговариваем с искусственным интеллектом, всерьёз собираемся колонизировать Луну и Марс, почти не используем наличные деньги, операции делают роботы и т.д. Фантастика!
Ну а для меня самый приятный символический подарок — достижение каналом 10k подписчиков, это круто!
Ну и традиционно — вам подарок от меня: пишите в комментариях о своих каналах, а я потом сделаю общий пост с упоминанием всех! Всем пишущим и снимающим — роста в этом году!
В одном из новогодних обращений услышал: а ведь уже прошла четверть XXI века! Те, кто постарше (как я), помнят, что 21 век казался каким-то фантастическим. Ну он такой и есть! Вокруг нвс сплошная фантастика: у всех "персональные коммуникаторы", мы погружены в виртуальные миры, звоним с видео в любую точку мира, по улицам ездят роботы и машины без водителей, мы каждый день разговариваем с искусственным интеллектом, всерьёз собираемся колонизировать Луну и Марс, почти не используем наличные деньги, операции делают роботы и т.д. Фантастика!
Ну а для меня самый приятный символический подарок — достижение каналом 10k подписчиков, это круто!
Ну и традиционно — вам подарок от меня: пишите в комментариях о своих каналах, а я потом сделаю общий пост с упоминанием всех! Всем пишущим и снимающим — роста в этом году!
❤29🎉7🔥5
В России можно посещать IT-мероприятия хоть каждый день: как оффлайн, так и онлайн
Но где их находить? Как узнавать о них раньше, чем когда все начнут выкладывать фотографии оттуда?
Переходите на канал IT-Мероприятия России. В нём каждый день анонсируются мероприятия со всех городов России
📆 в канале размещаются как онлайн, так и оффлайн мероприятия;
👩💻 можно найти ивенты по любому стеку: программирование, frontend-backend разработка, кибербезопасность, дата-аналитика, osint, devops и другие;
🎙 разнообразные форматы мероприятий: митапы с коллегами по цеху, конференции и вебинары с известными опытными специалистами, форумы и олимпиады от важных представителей индустрии и многое другое
А чтобы не искать по разным форумам и чатам новости о предстоящих ивентах:
🚀 IT-мероприятия России — подписывайся и будь в курсе всех предстоящих мероприятий!
Но где их находить? Как узнавать о них раньше, чем когда все начнут выкладывать фотографии оттуда?
Переходите на канал IT-Мероприятия России. В нём каждый день анонсируются мероприятия со всех городов России
А чтобы не искать по разным форумам и чатам новости о предстоящих ивентах:
🚀 IT-мероприятия России — подписывайся и будь в курсе всех предстоящих мероприятий!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6👎3❤2
Я слежу за статьями Пола Ральфа (который писал про иллюзию требований), но эта ветка исследований немного заглохла. Зато есть свежая статья: "Влияние генеративного ИИ на креативность в разработке ПО".
Там большой коллектив авторов, и это скорее призыв к дальнейшим исследованиям, как раз в тему в начале года (хотя опубликована она ещё в мае 2025). В каком-то смысле это всё-таки продолжение — ведь то, что мы делаем при создании программных продуктов, это, конечно, никакие не требования, а идеи. Идеи, которые мы придумываем, и креативность тут играет чуть ли не большую роль, чем продуктивность.
Авторы определяют креативность как "Способность придумывать идеи или создавать артефакты, которые являются новыми, неожиданными и ценными".
Дальше они раскладывают креативность по модели 4P: Person, Product, Process и Press (давление окружения) и пытаются анализировать влияние генеративного ИИ с позиций тетрадного анализа Маршалла Маклюэна — это, напомню, один из самых влиятельных философов XX века, описавший современные медиа и их влияние на общество. Тетрада задает рамку анализа новой технологии — какие практики технология усиливает, какие делает устаревшими, какие наоборот возвращает из забытья, и к чему приводит в пределе? (По Маклюэну — к противоположности)
Вот что получилось.
Влияние на личную креативность:
Усиливает:
- Генерацию идей
- Объединение идей из разных областей
- Быструю проверку/отладку
- Тщательный подход
- Понимание стейкхолдеров
- Выбор подходящего варианта
Делает устаревшим и ненужным:
- Различие в личных качествах
- Глубокое мышление
- Рефлексию
- Экспертизу
- Менторинг
Возвращает:
- Эскизное проектирование, наброски
- Верификацию
- Творческую работу
Приводит к обратному:
- Штамповке типовых решений
- Исключению анализа вариантов
- Потере креативных навыков
Влияние на продукт:
Усиливает:
- Непрерывное улучшение
- Кастомизированный UX
- Учет обратной связи
- Возможность делать "невозможные вещи"
- Радикальные инновации
Делает устаревшим:
- Стандартные решения
- Фреймворки
- Промежуточные артефакты проектирования
- Графический дизайн и элементы оформления
- Специализированные артефакты (музыку, звуки, дизайн уровней, баз данных, интерфейсы и т.п.)
Возвращает:
- Паттерны и стили
- Старые приемы проектирования и решения
- "Аналоговые" методы проектирования — на карточках, на бумаге
Приводит к обратному:
- Эффекту "эхо-камеры": подтверждение предвзятости, ограничение вариантов
- Однообразные продукты
- Чрезмерно креативным, вычурным продуктам
- Предвзятости
- Вредным продуктам, черному UX, эксплуатации аддикций
Влияние на процессы:
Усиливает:
- Обыденные задачи
- Быстрое прототипирование
- Коллаборацию
- Креативность по запросу
- Модерацию/фасилитацию
Делает устаревшим:
- Мозговые штурмы
- Специализацию, разделение ролей
- Техники проверки дизайна (изучение пользователей, фокус-группы, мысленное пошаговое прохождение интерфейсов и т.п.)
- Экспертов по креативным методикам и проектированию
Возвращает (тут всё в противодействие):
- Парное программирование
- Техники генерации идей (мозговые штурмы, дизайн-спринты)
- Аналоговые техники творчества (лего, бумажное прототипирование и т.п.)
- Ручные исследования пользователей
- Изучение других предметных областей
Приводит к обратному:
- Потере интуиции
- Потере доверия
- Потере работы
- Разложению ролей специалистов по созданию ПО
- Кафкианской безответственности
Влияние на среду:
Усиливает:
- Поиск контекстной информации
- Вдохновение окружающей средой
- Сборку команд
- Эффективность в виртуальных средах
- Психологическую безопасность
- Голос разума
- Готовность принимать риски
Делает устаревшим:
- Доски, флипчарты, стикеры
- Кубиклы
- Фиксированные пространства
- Офисы вообще
- Коллег
Возвращает:
- Креативность в движении
- Поддерживающее руководство
Приводит к обратному:
- Саботажу
- Изоляции
- Снижении гордости за результаты своего труда
- Давлению руководства
- Невозможности высказаться
- Ненужности креативности
Ну что, как вам такие предположения?
Там большой коллектив авторов, и это скорее призыв к дальнейшим исследованиям, как раз в тему в начале года (хотя опубликована она ещё в мае 2025). В каком-то смысле это всё-таки продолжение — ведь то, что мы делаем при создании программных продуктов, это, конечно, никакие не требования, а идеи. Идеи, которые мы придумываем, и креативность тут играет чуть ли не большую роль, чем продуктивность.
Авторы определяют креативность как "Способность придумывать идеи или создавать артефакты, которые являются новыми, неожиданными и ценными".
Дальше они раскладывают креативность по модели 4P: Person, Product, Process и Press (давление окружения) и пытаются анализировать влияние генеративного ИИ с позиций тетрадного анализа Маршалла Маклюэна — это, напомню, один из самых влиятельных философов XX века, описавший современные медиа и их влияние на общество. Тетрада задает рамку анализа новой технологии — какие практики технология усиливает, какие делает устаревшими, какие наоборот возвращает из забытья, и к чему приводит в пределе? (По Маклюэну — к противоположности)
Вот что получилось.
Влияние на личную креативность:
Усиливает:
- Генерацию идей
- Объединение идей из разных областей
- Быструю проверку/отладку
- Тщательный подход
- Понимание стейкхолдеров
- Выбор подходящего варианта
Делает устаревшим и ненужным:
- Различие в личных качествах
- Глубокое мышление
- Рефлексию
- Экспертизу
- Менторинг
Возвращает:
- Эскизное проектирование, наброски
- Верификацию
- Творческую работу
Приводит к обратному:
- Штамповке типовых решений
- Исключению анализа вариантов
- Потере креативных навыков
Влияние на продукт:
Усиливает:
- Непрерывное улучшение
- Кастомизированный UX
- Учет обратной связи
- Возможность делать "невозможные вещи"
- Радикальные инновации
Делает устаревшим:
- Стандартные решения
- Фреймворки
- Промежуточные артефакты проектирования
- Графический дизайн и элементы оформления
- Специализированные артефакты (музыку, звуки, дизайн уровней, баз данных, интерфейсы и т.п.)
Возвращает:
- Паттерны и стили
- Старые приемы проектирования и решения
- "Аналоговые" методы проектирования — на карточках, на бумаге
Приводит к обратному:
- Эффекту "эхо-камеры": подтверждение предвзятости, ограничение вариантов
- Однообразные продукты
- Чрезмерно креативным, вычурным продуктам
- Предвзятости
- Вредным продуктам, черному UX, эксплуатации аддикций
Влияние на процессы:
Усиливает:
- Обыденные задачи
- Быстрое прототипирование
- Коллаборацию
- Креативность по запросу
- Модерацию/фасилитацию
Делает устаревшим:
- Мозговые штурмы
- Специализацию, разделение ролей
- Техники проверки дизайна (изучение пользователей, фокус-группы, мысленное пошаговое прохождение интерфейсов и т.п.)
- Экспертов по креативным методикам и проектированию
Возвращает (тут всё в противодействие):
- Парное программирование
- Техники генерации идей (мозговые штурмы, дизайн-спринты)
- Аналоговые техники творчества (лего, бумажное прототипирование и т.п.)
- Ручные исследования пользователей
- Изучение других предметных областей
Приводит к обратному:
- Потере интуиции
- Потере доверия
- Потере работы
- Разложению ролей специалистов по созданию ПО
- Кафкианской безответственности
Влияние на среду:
Усиливает:
- Поиск контекстной информации
- Вдохновение окружающей средой
- Сборку команд
- Эффективность в виртуальных средах
- Психологическую безопасность
- Голос разума
- Готовность принимать риски
Делает устаревшим:
- Доски, флипчарты, стикеры
- Кубиклы
- Фиксированные пространства
- Офисы вообще
- Коллег
Возвращает:
- Креативность в движении
- Поддерживающее руководство
Приводит к обратному:
- Саботажу
- Изоляции
- Снижении гордости за результаты своего труда
- Давлению руководства
- Невозможности высказаться
- Ненужности креативности
Ну что, как вам такие предположения?
🔥8👏4❤3