Честно пытаюсь понять, что такое API-first, но не могу.
...API-First. Это когда сначала проектируются API, а уже потом — сам сервис/система, форматы и правила описания этих самых API
Что тогда такое - проектирование API? Почему форматы и правила описания вынесены за пределы проектирования? Итого, что должно быть первым в таком подходе?
Что означает эта фраза?
Я head профессии по системному анализу
Глава по профессии? Ведущий в профессии? Быть head внутри компании внутри какого-то структурного подразделения или направления - понятно. Но как это - во всей профессии? Не могу понять смысл
В целом, сплошной текст тяжело воспринимается. Полезно было бы основные мысли отобразить визуально. Тот же процесс API-first, например
А мне, как ни странно, статья понравилась ) Тоже против солянок. Но тут выглядит как простое и доступное изложение, как аналитику выполнить интеграцию, от бизнес-целей (о чём некоторые мидлы и сеньоры почему-то забывают) до основных паттернов технических решений. Этакий быстрый справочник
В своём примере - "заказчик может прийти с требованием хочу показать людям сколько идти до ближайшено отделения почты" - это уже можно (с некоторой натяжкой, конечно, но) считать потребностью бизнеса. И следует (а не идёт в начале!) ваше решение - "эти данные забрать из Яндекс api".
А бизнес ваша реализация не интересует, бизнесу надо понимать дебет/кредит и время. Будет это интеграция, или прогнать 100500 человек по городу - ему без разницы.
Ещё раз: бизнесу не нужна никакая интеграция - ни новая, ни старая, ни ещё какая-либо. Ему нужно решение для своих целей. Интеграция - лишь вариант реализации
Ура. Теперь можно выкинуть все толстенные талмуды по системному дизайну, а также по требованиям к системе (зачем они, ведь вот же готовый дизайн на "всё"). Мы получили то, о чём втайне мечает каждый спец в своей области - универсальную таблетку на все случаи жизни. Всех архитекторов можно смело увольнять
Вчера на собесе в одну хорошую (без иронии) компанию (работает с госами) рассказал старшему аналитику ровно это же. А от меня ждали перечень конкретных диаграм, которые я должен показать заказчику. К тому, что даже в опытных, казалось бы, компаниях есть какие-то детские болезни.
С другой стороны, специфика заказчика не должна отменять внутренние процессы описанного в статье анализа. Это надо для проекта/продукта
Мы все стремимся упростить рутину. Если включать мозг для каждого вдоха, то мозг загнётся. Автоматизировать проверку - очень хорошая идея. Паниковать по любому багу и призывать всех по любому чиху включать мозг - так себе идея
Статья полезная. Но, при всём уважении к автору, у аналитиков от определений и терминологий здесь должна идти кровь из глаз. Прям с самого начала:
процессные движки (BPMN)
или всё-таки
Business Process Model and Notation — нотация и модель бизнес-процессов
?
За что глаз сразу зацепился:
Ромб с Х
Почему бы не использовать общепринятые и понятные названия элементов?
Прямоугольник с шестеренками — некий скрытый процесс, логика которого реализуется в рамках кода
Что такое "некий"? Почему он "скрытый" и от кого? Значит, остальные процессы - открытые? А логика остальных процессов, которые без шестерёнки, реализуется вне кода?
И понятно, почему так случилось (болд мой):
«Колдовать» над ними должны квалифицированные разработчики
В этом же ответ, почему в статье явно не выделены, а размазаны по тексту требования, от чего же автор отталкивался и к чему стремился в своей работе
Вот кроме случая, когда команде разработке надо освоить деньги в виде интеграции, других вариантов на ум ничего не приходит, чтобы такой вопрос в принципе существовал. Т.е. рассматривать интеграцию как субъект - ну очень странно. Наверное, у бизнеса есть выявленная (BA, тут - PO) потребность, и способ решения её - интеграция, ведь так?
Возможно, тут я плохо понимаю, кто такой пресейл. В моём розовом мире: 1. У потенциального заказчика решения возникла потребность/задача 2. Выдвигается бизнес-аналитик, с заказчиком полностью понимает что надо по бизнесу 3. И только тут подключается SA. Прикидывает архитектуру для данной задачи.
Разве схемы бизнес-процессов (БП) привязаны к реализации, будь то монолит или MSA? В БП акторы - бизнес-сущности, описывается бизнес-логика. Иначе это уже не БП, разве не так? Приведённые в тексте примеры меня не убедили
Описание как поставлена работа с заказчиком, про аккаунт-менеджеров и пресейлов, конечно, поразила. Удивительно читать такое странное про одну из крупнейших компаний в ИТ.
Язык статьи тяжёлый, в итоге кусками почитал. Много канцелярита, предложения никак не могут закончиться и начинаются повторы.
В статье получается, что SA, несмотря на название, ещё и бизнесовое решение придумывает. Хотя чего удивляться, см. как у них устроена продажа решений
Что делать, если у соседа получается, а у тебя нет? Правильно, гнобить успешных и драть с них деньги (шрафы) под всякими благовидными предлогами. И транжирить их на бюрократию (очередную рабочую группу) и подачки населению для поддержания лояльности. Но ни в коем случае не на развитие.
Интересно, что AIDA - имя андроида в Agents of S.H.I.E.L.D.
Смысл новости в том, что боты накручивают прослушивание ИИ-сгенерированных треков, поэтому Spotify удаляет эти треки? Т.е. если боты будут накручивать прослушивание "нормальных" треков, Spotify будет удалять "нормальные" треки?
Для меня слишком абстрактно. Нельзя ли поконкретнее - где, как это применить при проектировании ИС?
Честно пытаюсь понять, что такое API-first, но не могу.
Что тогда такое - проектирование API? Почему форматы и правила описания вынесены за пределы проектирования?
Итого, что должно быть первым в таком подходе?
Что означает эта фраза?
Глава по профессии? Ведущий в профессии? Быть head внутри компании внутри какого-то структурного подразделения или направления - понятно. Но как это - во всей профессии? Не могу понять смысл
В целом, сплошной текст тяжело воспринимается. Полезно было бы основные мысли отобразить визуально. Тот же процесс API-first, например
А мне, как ни странно, статья понравилась )
Тоже против солянок. Но тут выглядит как простое и доступное изложение, как аналитику выполнить интеграцию, от бизнес-целей (о чём некоторые мидлы и сеньоры почему-то забывают) до основных паттернов технических решений. Этакий быстрый справочник
Мы на каких-то разных языках говорим.
В своём примере - "заказчик может прийти с требованием хочу показать людям сколько идти до ближайшено отделения почты" - это уже можно (с некоторой натяжкой, конечно, но) считать потребностью бизнеса. И следует (а не идёт в начале!) ваше решение - "эти данные забрать из Яндекс api".
А бизнес ваша реализация не интересует, бизнесу надо понимать дебет/кредит и время. Будет это интеграция, или прогнать 100500 человек по городу - ему без разницы.
Ещё раз: бизнесу не нужна никакая интеграция - ни новая, ни старая, ни ещё какая-либо. Ему нужно решение для своих целей. Интеграция - лишь вариант реализации
Ура. Теперь можно выкинуть все толстенные талмуды по системному дизайну, а также по требованиям к системе (зачем они, ведь вот же готовый дизайн на "всё").
Мы получили то, о чём втайне мечает каждый спец в своей области - универсальную таблетку на все случаи жизни. Всех архитекторов можно смело увольнять
Пару скринов хотя бы, если можно
Вчера на собесе в одну хорошую (без иронии) компанию (работает с госами) рассказал старшему аналитику ровно это же. А от меня ждали перечень конкретных диаграм, которые я должен показать заказчику.
К тому, что даже в опытных, казалось бы, компаниях есть какие-то детские болезни.
С другой стороны, специфика заказчика не должна отменять внутренние процессы описанного в статье анализа. Это надо для проекта/продукта
Мы все стремимся упростить рутину. Если включать мозг для каждого вдоха, то мозг загнётся. Автоматизировать проверку - очень хорошая идея. Паниковать по любому багу и призывать всех по любому чиху включать мозг - так себе идея
Статья полезная.
Но, при всём уважении к автору, у аналитиков от определений и терминологий здесь должна идти кровь из глаз. Прям с самого начала:
или всё-таки
?
За что глаз сразу зацепился:
Почему бы не использовать общепринятые и понятные названия элементов?
Что такое "некий"? Почему он "скрытый" и от кого? Значит, остальные процессы - открытые? А логика остальных процессов, которые без шестерёнки, реализуется вне кода?
И понятно, почему так случилось (болд мой):
В этом же ответ, почему в статье явно не выделены, а размазаны по тексту требования, от чего же автор отталкивался и к чему стремился в своей работе
Вот кроме случая, когда команде разработке надо освоить деньги в виде интеграции, других вариантов на ум ничего не приходит, чтобы такой вопрос в принципе существовал. Т.е. рассматривать интеграцию как субъект - ну очень странно.
Наверное, у бизнеса есть выявленная (BA, тут - PO) потребность, и способ решения её - интеграция, ведь так?
У интеграции есть бизнес-цель? Очень интересно.
Интерграция - способ реализации требований, вытекающих из бизнес-цели.
Перепутаны причина и следствие
Все дружно считают проект (деньги, людей, ...) и пресейл(?) идёт к заказчику.
Дальше уже итерационно
Возможно, тут я плохо понимаю, кто такой пресейл.
В моём розовом мире:
1. У потенциального заказчика решения возникла потребность/задача
2. Выдвигается бизнес-аналитик, с заказчиком полностью понимает что надо по бизнесу
3. И только тут подключается SA. Прикидывает архитектуру для данной задачи.
Разве схемы бизнес-процессов (БП) привязаны к реализации, будь то монолит или MSA?
В БП акторы - бизнес-сущности, описывается бизнес-логика. Иначе это уже не БП, разве не так?
Приведённые в тексте примеры меня не убедили
К сожалению, интерфейсы для накопителей не бесплатные и ограничены железом.
Надо сравнивать 1 HDD - 1 SSD
В Lightroom недавно встроили Denoise, который использует AI. Очень хороший результат, на мой взгляд
Описание как поставлена работа с заказчиком, про аккаунт-менеджеров и пресейлов, конечно, поразила. Удивительно читать такое странное про одну из крупнейших компаний в ИТ.
Язык статьи тяжёлый, в итоге кусками почитал. Много канцелярита, предложения никак не могут закончиться и начинаются повторы.
В статье получается, что SA, несмотря на название, ещё и бизнесовое решение придумывает. Хотя чего удивляться, см. как у них устроена продажа решений
Пользователями этих чипов являются дата-центры и т.п.
Что делать, если у соседа получается, а у тебя нет? Правильно, гнобить успешных и драть с них деньги (шрафы) под всякими благовидными предлогами. И транжирить их на бюрократию (очередную рабочую группу) и подачки населению для поддержания лояльности. Но ни в коем случае не на развитие.
Интересно, что AIDA - имя андроида в Agents of S.H.I.E.L.D.
Смысл новости в том, что боты накручивают прослушивание ИИ-сгенерированных треков, поэтому Spotify удаляет эти треки?
Т.е. если боты будут накручивать прослушивание "нормальных" треков, Spotify будет удалять "нормальные" треки?