На какой воркшоп сходили бы?
Anonymous Poll
52%
Как обеспечить НФТ на этапе архитектуры
33%
Трейдоффы в архитекуре
15%
Никакой, оба неинтересны
Год назад писал, как с помощью ChatGPT пробовал интегрироваться с разными публичными сервисами.
Тогда были проблемы с интерпретацией пользовательских сценариев, маппингом на технические вызовы, проектированием асинхронных взаимодействий.
Сейчас кинул ссылку на здоровую эквайринговую доку и надиктовал голосом, что хочу — Fable и Opus 4.8, задали правильные вопросы, построили схемы, задизайнили БД. В некоторых местах поправил, что было проще в будущем. Codex не тестил, но думаю, там тоже достойно будет.
Ну да, эквайринг — довольно типовая штука. Но факт остается.
Тогда были проблемы с интерпретацией пользовательских сценариев, маппингом на технические вызовы, проектированием асинхронных взаимодействий.
Сейчас кинул ссылку на здоровую эквайринговую доку и надиктовал голосом, что хочу — Fable и Opus 4.8, задали правильные вопросы, построили схемы, задизайнили БД. В некоторых местах поправил, что было проще в будущем. Codex не тестил, но думаю, там тоже достойно будет.
Ну да, эквайринг — довольно типовая штука. Но факт остается.
👍15❤8
Всем привет, есть кто из екб?
Завтра делаем митап вместе с аналитиками Контура, будем говорить про иишечку и тусить у них на набережной. Инфа ниже, приходите. А еще буду там всю среду — пишите, можем собраться на чаек или еще что.
Завтра делаем митап вместе с аналитиками Контура, будем говорить про иишечку и тусить у них на набережной. Инфа ниже, приходите. А еще буду там всю среду — пишите, можем собраться на чаек или еще что.
🔥7
Forwarded from Tech Analyst Club - проектирование, архитектура, AI
Привет, Екатеринбург!
Через неделю делаем оффлайн митап вместе с аналитиками Контура. Обсудим, чем AI может помочь в работе, и как эффективно использовать LLM.
Что в программе:
• Андрей Бураков — У нас был контекст, мы им управляли?
• Светлана Дергачева — AI-дизайн для аналитиков: design‑as‑code, работа с презентациями, кликабельные интерфейсы и генерация дизайн-системы
• Сергей Петров — Как мы автоматизировали создание Troubleshooting Guide с помощью LLM
• Афтепати и неформальное общение
📆 28 июля, вторник, сбор гостей с 18:30
📍 Адрес: ул. Малопрудная, д 5. Офис разработки Контура, конференц-зал, 1 этаж
🔗 Смотрите программу и регайтесь по ссылке
Через неделю делаем оффлайн митап вместе с аналитиками Контура. Обсудим, чем AI может помочь в работе, и как эффективно использовать LLM.
Что в программе:
• Андрей Бураков — У нас был контекст, мы им управляли?
• Светлана Дергачева — AI-дизайн для аналитиков: design‑as‑code, работа с презентациями, кликабельные интерфейсы и генерация дизайн-системы
• Сергей Петров — Как мы автоматизировали создание Troubleshooting Guide с помощью LLM
• Афтепати и неформальное общение
📍 Адрес: ул. Малопрудная, д 5. Офис разработки Контура, конференц-зал, 1 этаж
🔗 Смотрите программу и регайтесь по ссылке
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥3
#API
Не прошло и пяти лет, как в HTTP утвердили глагол QUERY. Вот теперь заживем!
Краткая история:
• сложные запросы плохо ложатся в query-параметры
• 10 лет назад пытались пофиксить, разрешив слать тело в GET, но никто это особо не поддержал
• сейчас решили вынести этот кейс в отдельный глагол
Как это будет выглядеть:
Чем же QUERY отличается от привычной реализации через POST?
— Он ИДЕМПОТЕНТНЫЙ
Ну да, а мы-то сейчас при чтении постом полбазы апдейтим
— Его можно кэшировать!!!
Вы предлагаете кэшировать на уровне тела, мы давно так делаем в GraphQL и прочих RPC
— Результат работы QUERY можно повторно получить с помощью GET
Получается, мы создаем некий вспомогательный ресурс с помощью QUERY. Т.е. это не только чтение?
Обновление актуально для тех, кто все еще стремиться делать "каноничное REST API", остальные давно оставили в покое несвежий труп стюардессы. Справедливости ради, даже для нормальных рестов первого уровня было бы удобно выделить логику из POST в другой глагол для единообразия, но вангую, что судьба этого обновления будет примерно такой же, как у GET-body и стандарта на описание ошибок в HTTP.
Не прошло и пяти лет, как в HTTP утвердили глагол QUERY. Вот теперь заживем!
Краткая история:
• сложные запросы плохо ложатся в query-параметры
• 10 лет назад пытались пофиксить, разрешив слать тело в GET, но никто это особо не поддержал
• сейчас решили вынести этот кейс в отдельный глагол
Как это будет выглядеть:
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json
select=surname,givenname,email&limit=10&match=%22email=*@example.*%22
HTTP/1.1 200 OK
Content-Type: application/json
Content-Location: /contacts/stored-results/17
Location: /contacts/stored-queries/42
Last-Modified: Sat, 25 Aug 2012 23:34:45 GMT
Date: Sun, 17 Nov 2024, 16:10:24 GMT
[
{ "surname": "Smith",
"givenname": "John",
"email": "smith@example.org" },
{ "surname": "Jones",
"givenname": "Sally",
"email": "sally.jones@example.com" },
{ "surname": "Dubois",
"givenname": "Camille",
"email": "camille.dubois@example.net" }
]
Чем же QUERY отличается от привычной реализации через POST?
— Он ИДЕМПОТЕНТНЫЙ
Ну да, а мы-то сейчас при чтении постом полбазы апдейтим
— Его можно кэшировать!!!
Вы предлагаете кэшировать на уровне тела, мы давно так делаем в GraphQL и прочих RPC
— Результат работы QUERY можно повторно получить с помощью GET
Получается, мы создаем некий вспомогательный ресурс с помощью QUERY. Т.е. это не только чтение?
Обновление актуально для тех, кто все еще стремиться делать "каноничное REST API", остальные давно оставили в покое несвежий труп стюардессы. Справедливости ради, даже для нормальных рестов первого уровня было бы удобно выделить логику из POST в другой глагол для единообразия, но вангую, что судьба этого обновления будет примерно такой же, как у GET-body и стандарта на описание ошибок в HTTP.
👍2😁2
Други, приходите порисовать стрелочки и квадратики на нашем архмитапе в «Школе 21» послезавтра в Москве. Регу завтра в 12:00 мск закрываем, не тяните.
https://t.me/techanalyst_club/481
https://t.me/techanalyst_club/481
Telegram
Tech Analyst Club - проектирование, архитектура, AI
Так, у нас опять митап. Теперь архитектурный.
Через неделю идем в гости к «Школе 21»: будем обсуждать распределенные системы, принимать архитектурные решения и рисовать стрелочки с квадратиками, конечно.
Декомпозиция системы на (микро)сервисы — на интерактивном…
Через неделю идем в гости к «Школе 21»: будем обсуждать распределенные системы, принимать архитектурные решения и рисовать стрелочки с квадратиками, конечно.
Декомпозиция системы на (микро)сервисы — на интерактивном…
🔥7❤1
Смотрю отзывы с последнего потока интеграции и архитектуры систем и думаю: зачем я, буренка, тебя закрываю?
Провести в полностью живом формате уже не осилю, но хочу попробовать полуасинхронный: ключевую теорию и вопросы записываю видосами-статьями и высылаю в начале недели, а по субботам встречаемся для практической работы.
Возможно, потом переделаю в симулятор, чтобы добро не пропадало.
Если кратко, о чем курс:
— про самостоятельный поиск решений, когда ты встречаешь новую задачу, а у тебя нет заученных паттернов и бест практик
— про понимание протоколов и инфры под ними, а не механическую работу по чек-листам и чужим критериям выбора
— про распределенные системы и фундаментальные проблемы проектирования, а не модные базворды
— про умение сформулировать архитектурный вопрос, провести исследование, оценить возможные решения
Начинаем 29 августа, рега здесь.
Отзывы с последних потоков смотрите тут
Провести в полностью живом формате уже не осилю, но хочу попробовать полуасинхронный: ключевую теорию и вопросы записываю видосами-статьями и высылаю в начале недели, а по субботам встречаемся для практической работы.
Возможно, потом переделаю в симулятор, чтобы добро не пропадало.
Если кратко, о чем курс:
— про самостоятельный поиск решений, когда ты встречаешь новую задачу, а у тебя нет заученных паттернов и бест практик
— про понимание протоколов и инфры под ними, а не механическую работу по чек-листам и чужим критериям выбора
— про распределенные системы и фундаментальные проблемы проектирования, а не модные базворды
— про умение сформулировать архитектурный вопрос, провести исследование, оценить возможные решения
Начинаем 29 августа, рега здесь.
Отзывы с последних потоков смотрите тут
🔥15❤5🎉2
А как правильно-то?
На занятиях регулярно повторяется ситуация: разобрали задачу, спроектировали несколько вариантов решения, обсудили плюсы и минусы каждого. Далее следует вопрос: "А как правильно-то?"
Обычно в такой ситуации просят чеклист. Обычно я отвечаю, что чеклист - абсолютное зло. Кроме своего.
Но как принимать решения?
1. Описываем задачу и контекст
2. Описываем варианты решения
3. Каждое решение обладает характеристиками, часть будет отличаться
4. Собираем табличку: характеристики vs варианты решения
5. Сортируем свойства по важности в рамках задачи
6. Заполняем клетки значениями
7. Анализируем, делаем выбор
Пример на картинке.
Где брать нужные свойства?
• Атрибуты качества системы aka NFR
• Ограничения: сроки, бюджеты, организационное, техрадар
• Продуктовые метрики - реже, но бывает
Что важно:
• Чаще всего хватает 3-4 характеристик, важных для нашей задачи.
• Максимально старайтесь использовать численные оценки, где это возможно. gRPC быстрее REST - правда? А на сколько? В 10 раз или на 10%? А оно нам надо?
• Не надо улучшать все сразу. Нам точно нужны 10.000+ rps в региональном магазине мебели?
• Когда мы улучшаем одну характеристику системы, обычно ухудшаем другую. Если решение ничего не ухудшает - скорее всего что-то пропустили.
• Обязательно прикрепляем табличку к ADR, Decision Log, Летописям Гениальных Костылей, или что там у нас. Команде, потомкам и агентам в будущем будет намного проще.
Проделывать это упражнение можно на любых уровнях абстракции и сложности: от выбора типа поля, до выделения границ сервисов. Каждый раз, когда рука тянется за чеклистом - рисуйте табличку. Потому что чужой заведомо делали в рамках другого контекста, задачи и целей.
Правда, для этого нужно понимать особенности технологий и принципы построения распределенных систем, этим мы займемся на курсе по интеграции и архитектуре, стартует 29 августа.
На занятиях регулярно повторяется ситуация: разобрали задачу, спроектировали несколько вариантов решения, обсудили плюсы и минусы каждого. Далее следует вопрос: "А как правильно-то?"
Обычно в такой ситуации просят чеклист. Обычно я отвечаю, что чеклист - абсолютное зло. Кроме своего.
Но как принимать решения?
1. Описываем задачу и контекст
2. Описываем варианты решения
3. Каждое решение обладает характеристиками, часть будет отличаться
4. Собираем табличку: характеристики vs варианты решения
5. Сортируем свойства по важности в рамках задачи
6. Заполняем клетки значениями
7. Анализируем, делаем выбор
Пример на картинке.
Где брать нужные свойства?
• Атрибуты качества системы aka NFR
• Ограничения: сроки, бюджеты, организационное, техрадар
• Продуктовые метрики - реже, но бывает
Что важно:
• Чаще всего хватает 3-4 характеристик, важных для нашей задачи.
• Максимально старайтесь использовать численные оценки, где это возможно. gRPC быстрее REST - правда? А на сколько? В 10 раз или на 10%? А оно нам надо?
• Не надо улучшать все сразу. Нам точно нужны 10.000+ rps в региональном магазине мебели?
• Когда мы улучшаем одну характеристику системы, обычно ухудшаем другую. Если решение ничего не ухудшает - скорее всего что-то пропустили.
• Обязательно прикрепляем табличку к ADR, Decision Log, Летописям Гениальных Костылей, или что там у нас. Команде, потомкам и агентам в будущем будет намного проще.
Проделывать это упражнение можно на любых уровнях абстракции и сложности: от выбора типа поля, до выделения границ сервисов. Каждый раз, когда рука тянется за чеклистом - рисуйте табличку. Потому что чужой заведомо делали в рамках другого контекста, задачи и целей.
Правда, для этого нужно понимать особенности технологий и принципы построения распределенных систем, этим мы займемся на курсе по интеграции и архитектуре, стартует 29 августа.
👍13🔥5👎1🤣1
#архитектура
Немногокошмаров интересного на ночь.
Взгляд на архитектуру через теорию систем от Фила, без паттернов и технологий.
Основное содержание разработки — это управление сложностью и борьба с ней.
Архитектура — это не про стрелочки и квадратики, это про текст.
Немного
Взгляд на архитектуру через теорию систем от Фила, без паттернов и технологий.
Основное содержание разработки — это управление сложностью и борьба с ней.
Архитектура — это не про стрелочки и квадратики, это про текст.
YouTube
Теория систем и архитектурная практика / Филипп Дельгядо
В своём докладе на big tech night Филипп Дельгядо, архитектор департамента в lekton.io, рассказывает о базовых понятиях теории систем и о том, как они помогают при проектировании современных решений. А ещё Филипп демонстрирует различные взгляды на связи между…
❤4🔥2👍1
Yet Another Analyst
А как правильно-то? На занятиях регулярно повторяется ситуация: разобрали задачу, спроектировали несколько вариантов решения, обсудили плюсы и минусы каждого. Далее следует вопрос: "А как правильно-то?" Обычно в такой ситуации просят чеклист. Обычно я отвечаю…
Ок, для анализа и выбора решения можно использовать простую табличку. Когда оно того стоит? Понятно, что нет смысла рисовать ее на каждый чих.
Когда точно будет полезно:
• Уже видим несколько решений, но не знаем что выбрать. Плюс такого представления - удобно обсуждать с коллегами, в том числе значимость и полноту характеристик.
• Когда несколько дней идет холивар, и никак не получается договориться. Часто баталии возникают лишь потому, что разные люди и роли смотрят на решения с разных сторон, им важны разные характеристики, и они не осознают полную стоимость (последствия) каждого решения.
• Если предстоит важная защита решения, например, на этапе пресейла, архкоме, или просто нужно договориться с другой компанией, то с помощью таблички можно подобрать более чОткие и сильны аргументы, почему наше решение прекрасно со всех сторон, а чужое всех погубит.
• Ну и самое интересное - иногда вообще нет идей, с чего начинать, или наоборот, чистое поле с бесконечным количеством вариантов. Тогда таблицу можно использовать для брейншторма:
1. выделяем важные характеристики будущего решения
2. указываем желаемое/достаточное значение для каждой характеристики
3. пробуем сгенерить решение, которое обладает таким набором
4. если пилим не новую систему, то текущее состояние берем как Решение 0 - для сравнения
Наверное, существуют еще кейсы.
Точно знаю, что 29 августа стартует курс по интеграции и архитектуре систем, там приложим эту идею к практике, в том числе к выбору паттернов и технологий.
Когда точно будет полезно:
• Уже видим несколько решений, но не знаем что выбрать. Плюс такого представления - удобно обсуждать с коллегами, в том числе значимость и полноту характеристик.
• Когда несколько дней идет холивар, и никак не получается договориться. Часто баталии возникают лишь потому, что разные люди и роли смотрят на решения с разных сторон, им важны разные характеристики, и они не осознают полную стоимость (последствия) каждого решения.
• Если предстоит важная защита решения, например, на этапе пресейла, архкоме, или просто нужно договориться с другой компанией, то с помощью таблички можно подобрать более чОткие и сильны аргументы, почему наше решение прекрасно со всех сторон, а чужое всех погубит.
• Ну и самое интересное - иногда вообще нет идей, с чего начинать, или наоборот, чистое поле с бесконечным количеством вариантов. Тогда таблицу можно использовать для брейншторма:
1. выделяем важные характеристики будущего решения
2. указываем желаемое/достаточное значение для каждой характеристики
3. пробуем сгенерить решение, которое обладает таким набором
4. если пилим не новую систему, то текущее состояние берем как Решение 0 - для сравнения
Наверное, существуют еще кейсы.
Точно знаю, что 29 августа стартует курс по интеграции и архитектуре систем, там приложим эту идею к практике, в том числе к выбору паттернов и технологий.
❤8🔥1
#API #интеграция
Не верю, что снова пишу об этом... но в интернетах опять кто-то неправ.
Есть два рестамежду прошлым и будущем: REST-как-архитектура и REST-как-апи.
REST как архитектурный стиль - это та самая работа Филдинга, в которой он описывает 6 ограничений, которые нужно накладывать на распределенную систему, чтобы получить определенные свойства. И это вообще не про API и не про HTTP.
В этом смысле REST можно ставить в один ряд с SOA, MSA и другими арх стилями.
REST как стиль API - неформальное понятие, родившееся на фоне холиваров "Как правильно использовать HTTP" и "И что же такое RESTful-сервис". Тогда Лео Ричардсон предложил модель зрелости REST API, которую приняли Филдинг и индустрия.
Строится она на том, на сколько "правильно" мы используем HTTP-глаголы, проектируем URL, ресурсно-ориентированы, и вообще поддерживаем гипермедиа. Поэтому REST API в отрыве от HTTP никто особо не рассматривает. Кстати, по версии Филдинга, настоящего REST API почти никто не видел.
НО
На прошлой неделе я узнал, что существует протокол CoAP - Constrained Application Protocol. Там буквально взяли семантику HTTP и перекроили под специфику IoT, плюс он работает поверх UDP. Спасибо чатам за ночные срачи.
Если задуматься, то и честный GraphQL в этом смысле можно отнести к REST API. Причем реста там будет больше, чем в "каноничном" REST API over HTTP. Но вслух об этом лучше не говорить, конечно.
Вся эта метафизика в реальности никому особо неинтересна. Про REST-как-архитектуру давно никто не думает, хотя отдельные персонажи продолжают спрашивать на собесах(кстати, зачем?) . Когда обсуждают ресты, скорее всего подразумевают REST API второго уровня зрелости.
А морали не будет. С окончанием понедельника вас.
———
29 августа стартует курс Интеграция и архитектура систем для опытных системных аналитиков
Не верю, что снова пишу об этом... но в интернетах опять кто-то неправ.
Есть два реста
REST как архитектурный стиль - это та самая работа Филдинга, в которой он описывает 6 ограничений, которые нужно накладывать на распределенную систему, чтобы получить определенные свойства. И это вообще не про API и не про HTTP.
В этом смысле REST можно ставить в один ряд с SOA, MSA и другими арх стилями.
REST как стиль API - неформальное понятие, родившееся на фоне холиваров "Как правильно использовать HTTP" и "И что же такое RESTful-сервис". Тогда Лео Ричардсон предложил модель зрелости REST API, которую приняли Филдинг и индустрия.
Строится она на том, на сколько "правильно" мы используем HTTP-глаголы, проектируем URL, ресурсно-ориентированы, и вообще поддерживаем гипермедиа. Поэтому REST API в отрыве от HTTP никто особо не рассматривает. Кстати, по версии Филдинга, настоящего REST API почти никто не видел.
НО
На прошлой неделе я узнал, что существует протокол CoAP - Constrained Application Protocol. Там буквально взяли семантику HTTP и перекроили под специфику IoT, плюс он работает поверх UDP. Спасибо чатам за ночные срачи.
Если задуматься, то и честный GraphQL в этом смысле можно отнести к REST API. Причем реста там будет больше, чем в "каноничном" REST API over HTTP. Но вслух об этом лучше не говорить, конечно.
Вся эта метафизика в реальности никому особо неинтересна. Про REST-как-архитектуру давно никто не думает, хотя отдельные персонажи продолжают спрашивать на собесах
А морали не будет. С окончанием понедельника вас.
———
29 августа стартует курс Интеграция и архитектура систем для опытных системных аналитиков
🔥20❤4
Мне тут шок-контента подвезли.
Знакомьтесь, Ольга. Два года назад она прошла курс по интеграции и архитектуре. По всем традициям жанра тут должна быть невероятная история успеха. Но нет, случилось ВНЕЗАПНОЕ.
Ольга пришла на курс второй раз. Нужно пафосно написать, как это круто, и какая у нас огненная программа, но вы и сами догадались.
А еще сейчас в группе всего 8 человек, поэтому сможем лампово и размеренно разобрать все волнующие вопросы.
Начинаем в субботу, запрыгивайте.
Знакомьтесь, Ольга. Два года назад она прошла курс по интеграции и архитектуре. По всем традициям жанра тут должна быть невероятная история успеха. Но нет, случилось ВНЕЗАПНОЕ.
Ольга пришла на курс второй раз. Нужно пафосно написать, как это круто, и какая у нас огненная программа, но вы и сами догадались.
А еще сейчас в группе всего 8 человек, поэтому сможем лампово и размеренно разобрать все волнующие вопросы.
Начинаем в субботу, запрыгивайте.
❤6
#оффтоп #ненависть
Скажите, что должно случиться с этим миром, чтобы люди перестали сравнивать ESB с брокерами? Уж лучше бы про PUT vs PATCH спорили.
Краткая памятка из шиномонтажа.
Скажите, что должно случиться с этим миром, чтобы люди перестали сравнивать ESB с брокерами? Уж лучше бы про PUT vs PATCH спорили.
Краткая памятка из шиномонтажа.
Telegram
Yet Another Analyst
#интеграция #архитектура
Страх и ненависть в шиномонтаже.
Шина, это как REST - все обсуждают, но каждый говорит о своем. Иногда интерпретации могут путать и сбивать с толку. Короткая памятка о том, что могут называть шиной и какие они бывают.
Enterprise…
Страх и ненависть в шиномонтаже.
Шина, это как REST - все обсуждают, но каждый говорит о своем. Иногда интерпретации могут путать и сбивать с толку. Короткая памятка о том, что могут называть шиной и какие они бывают.
Enterprise…
1😁11🎃1
Architecture Trade-Off Analysis Method
На последнем митапе меня обвинили в излишнем снобизме по отношению к аналитикам. Успех ящитаю. Теперь добавим пафоса.
Например, эту идею анализа решений можно обозвать Trade-offs Analysis Framework - ToAF. Красиво же?
Но почему-то я не слышал про аналоги, хотя есть достаточно форматов для фиксации решений. Пошел гуглить, раскопал ATAM - Architecture Trade-Off Analysis Method.
Тяжеловесный метод для обстоятельной оценки решений, который за 15 лет особой популярности не набрал. Полный процесс анализа пересказывать не буду, выделил интересное.
Метод крутится вокруг измеримых quality attributes (они же НФТ), хотя ничто не мешает смотреть на другие характеристики. Причем работают с ними через Quality Attribute Scenario, которые связывают атрибуты качества и конкретные цифры, что-то в таком духе:
Если хочется формальности, то можно использовать шаблон:
Дальше из таких сценариев собирается Utility Tree (Дерево Полезности?), где для каждого листа указываем важность и степень риска: Low, Medium, High. Фактически, это аналог приоритезированной таблицы. Примеры на картинках.
Отдельно при анализе выделяют:
• sensitivity point - решение или его часть, которое сильно влияет на один из quality attributes
• tradeoff point - решение, которое влияет сразу на несколько quality attributes, причем двигает значения в разные стороны.
Полезные термины, т.к. заставляют думать о последствиях.
Идея идти от сценариев хороша, т.к. помогает ответить на вопрос: а какие quality attributes или характеристики системы в широком смысле нам сейчас важны? Правда на больших задачах там будет 100500 таких сценариев, и придется думать об их полноте.
В целом подход выглядит интересно прикольно, но сложно. Хотя можно для небольших решений адаптировать.
• Если есть желание упороться, вот большое подробное описание метода
• Еще можно посмотреть, как ATAM использовали на реальном проекте, картинки из этой презы утащил.
Мб кто-то пробовал на практике? Как впечатления?
На последнем митапе меня обвинили в излишнем снобизме по отношению к аналитикам. Успех ящитаю. Теперь добавим пафоса.
Например, эту идею анализа решений можно обозвать Trade-offs Analysis Framework - ToAF. Красиво же?
Но почему-то я не слышал про аналоги, хотя есть достаточно форматов для фиксации решений. Пошел гуглить, раскопал ATAM - Architecture Trade-Off Analysis Method.
Тяжеловесный метод для обстоятельной оценки решений, который за 15 лет особой популярности не набрал. Полный процесс анализа пересказывать не буду, выделил интересное.
Метод крутится вокруг измеримых quality attributes (они же НФТ), хотя ничто не мешает смотреть на другие характеристики. Причем работают с ними через Quality Attribute Scenario, которые связывают атрибуты качества и конкретные цифры, что-то в таком духе:
При падении primary DB при пиковой нагрузке (более 5000 заказов в минуту) система должна восстановить обработку заказов не более чем за 30 секунд без потери уже подтверждённых заказов.
Если хочется формальности, то можно использовать шаблон:
- Source: отказ primary DB
- Stimulus: primary DB недоступна
- Environment: нагрузка 5 000 заказов/мин
- Artifact: система обработки заказов / persistence layer
- Response: failover и возобновление обработки
- Response measure: восстановление ≤ 30 с; потерянных подтверждённых заказов = 0
Дальше из таких сценариев собирается Utility Tree (Дерево Полезности?), где для каждого листа указываем важность и степень риска: Low, Medium, High. Фактически, это аналог приоритезированной таблицы. Примеры на картинках.
Отдельно при анализе выделяют:
• sensitivity point - решение или его часть, которое сильно влияет на один из quality attributes
• tradeoff point - решение, которое влияет сразу на несколько quality attributes, причем двигает значения в разные стороны.
Полезные термины, т.к. заставляют думать о последствиях.
Идея идти от сценариев хороша, т.к. помогает ответить на вопрос: а какие quality attributes или характеристики системы в широком смысле нам сейчас важны? Правда на больших задачах там будет 100500 таких сценариев, и придется думать об их полноте.
В целом подход выглядит интересно прикольно, но сложно. Хотя можно для небольших решений адаптировать.
• Если есть желание упороться, вот большое подробное описание метода
• Еще можно посмотреть, как ATAM использовали на реальном проекте, картинки из этой презы утащил.
Мб кто-то пробовал на практике? Как впечатления?
Знания — яд
Учеба — прокрастинация
Третью строку для кликбейта не придумал, подсказывайте.
———
Четыре года назад я писал, почему курсы бесполезны, если вы не привыкли учиться самостоятельно.
———
Лет десять Дорофеев рассказывает, почему обучение — это не потребление "знаний", а их осмысление и применение к практике:
Вот его доклад с кодфеста, очень рекомендую.
———
В XVI веке Монтень критиковал людей, которые непрерывно потребляют мысли из книг, вместо того, чтобы формировать собственные суждения:
———
В 2026 году получение обучающего контента вообще не представялет никакой проблемы. Причем выделить из него качественный без погружения в тему все равно не получится. Поэтому первично осмысление, критическая оценка, применение на практике.
А выводы писать мне лень. Всех с праздником
Учеба — прокрастинация
Третью строку для кликбейта не придумал, подсказывайте.
———
Четыре года назад я писал, почему курсы бесполезны, если вы не привыкли учиться самостоятельно.
———
Лет десять Дорофеев рассказывает, почему обучение — это не потребление "знаний", а их осмысление и применение к практике:
Когда получение знания не уравновешивается его осмыслением и применением на практике, наступает своего рода отравление знанием
На входе в его сознание формируется фильтр: "Я это уже слышал или нет?" Если новая информация хоть как-то похожа на то, что человек уже знает, он пропускает ее мимо ушей
Вот его доклад с кодфеста, очень рекомендую.
———
В XVI веке Монтень критиковал людей, которые непрерывно потребляют мысли из книг, вместо того, чтобы формировать собственные суждения:
Сильная память обыкновенно соединяется со слабым суждением
Мы берем на веру знания и мнения других людей
Следует спрашивать, кто лучше образован, а не кто больше знает
———
В 2026 году получение обучающего контента вообще не представялет никакой проблемы. Причем выделить из него качественный без погружения в тему все равно не получится. Поэтому первично осмысление, критическая оценка, применение на практике.
А выводы писать мне лень. Всех с праздником
🔥18❤2👍2
Завтра проведем открытую сессию систем дизайна в Tech Analyst Club, будем проектировать LMS, учебный год все-таки. Приходите, это бесплатно, но нужно зарегаться в ботике.
Telegram
Tech Analyst Club - проектирование, архитектура, AI
🔔 Ну что, пора в школу? Эту неделю посвятим архитектуре
📆 3 сентябя - System Design. Проектируем LMS
В четверг приглашаем всех на открытый воркшоп, где будем проектировать образовательную платформу, что-то между Coursera, Stepik и GetCourse: есть авторы…
📆 3 сентябя - System Design. Проектируем LMS
В четверг приглашаем всех на открытый воркшоп, где будем проектировать образовательную платформу, что-то между Coursera, Stepik и GetCourse: есть авторы…
👍5