в большинстве случаев масштабирование это задача, которая никогда не возникнет. Бизнес говорит: мы щас делаем 3 продажи в месяц, но у нас в стратегии написано, что будем продавать миллион к концу года, имейте это ввиду. И разработка закладывает фундамент для небоскреба, хотя почти всегда там будет стоять палатка с шавухой. Часто переделать потом выходит дешевле, чем сразу заложиться и всю дорогу страдать.
Сильно плавает глубина: текст позиционируется как ликбез, начинается с ввода и разбора терминов, а заканчивается паттернами проектирования приложений, сервис мешем и прочими высшими материями, которые и не разобраны детально (так как это не тема статьи) и лишний раз пугают начинающего читателя, так как кажется, что ему для собеседования и это тоже надо заботать;
Ссылка на вики "издатель-подписчик" не работает;
"Смешанная интеграция" - это уже прием для реализации флоу бизнес процесса, я бы не выделял это в отдельный вид, ну или оформил бы как вариацию асинхрона;
Вы говорите, что шаблон издатель-подписчик это пример использования очередей и в качестве иллюстрации упоминаете почту, но это некорректно: реализация Pub-Sub шаблона это, скорее, радиоэфир, когда много подписчиков подключаются к топику одного издателя и получают сообщение, пока подключены. Почта - хороший пример "Очереди", но это паттерн Уведомление (или запрос-ответ, если там двусторонняя переписка)
Слабая связанность и масштабируемость не являются плюсами асинхронной интеграции - эта связанность не "слабее" и не "сильнее", чем интеграционный контракт и пока он соблюдается, взаимодействие работает, что бы ни происходило внутри модулей (сервисов). При синхронном взаимодействии это будет работать так же.
Паттерн стейт-машина больно уж мудрено описан
Не согласен с тем, что сервисная шина это пример реализации оркестрации. Суть оркестрации в том, что есть стейтфул оркестровщик, который хранит состояние выполняемого процесса и в зависимости от этого состояния вызывает нужные сервисы. А сервисная шина - это, скорее, "умный" маршрутизатор запросов от системы А к одной и систем из списка на основании некоторых правил, которые учитывают занные в запросе.
Не согласен с выводом. Выбор интеграции базируется не на лучших практиках, а на исходных данных, включая известные ограничения. Лучшие практики - это опробованные ранее удачные решения для конкретных групп кейсов. Нельзя сказать "будем делать синхрон или сагу на хореографии, потому что вон гугл так сделал и у них все работает".
Там же, в выводах: RESTful API это не противопоставление сервисов действиям: RPC API тоже может реализовывать сервисную модель.
Это из крупного. Я бы посоветовал все-таки определиться с аудиторией и если это ликбез - сделать статью чуть полегче и без тяжелой артиллерии.
Я за всю свою карьеру не встречал разработчиков, которые бы хотели работать с ТЗ по ГОСТу. Очень часто такое ТЗ одновременно и избыточно, и недостаточно или неоптимально. В используемой в статье терминологии аналитик, который ограничивается классическим ТЗ - это "глупый аналитик".
Боюсь, академическое вузовское проектирование для большинства задач будет или слишком "теоретическим" или слишком тяжеловесным. Для ТЗ по ГОСТу оно, может, и подойдет, а вот для более динамичных команд - скорее нет.
И еще, как проектное управление поможет в проектировании?
Вы не одиноки, всего рынка сейчас такая проблема, по крайней мере в энтерпрайзе. В свете того, как сильно перегрет рынок, я все больше склоняюсь к тому, что нужно набирать стажеров, прям после вуза, пачку, два месяца их учить под себя, можно даже не давать рабочих задач, а только учебные материалы и если получится, то через какое-то время на выходе получим пачку лояльных и заточенных под конкретные задачи мидлов за небольшие деньги. Да, сложно, но одну из последних вакансий я закрывал около 10 месяцев - или нам не подходит, или компания не нравится или еще что-то.
К сожалению, я очень часто, в том числе и от друзей (не коллег) разработчиков, слышу подобное. И я думаю, что средний технический уровень системных аналитиков по отрасли действительно невысок. Я пришел в системный анализ будучи лидом разработки (так карьера сложилась), но это, скорее, исключение: обычно аналитики не имеют опыта разработки (институтские лабы не в счет).
Но есть решение (рабочее, проверяли): аналитика можно "настроить" под себя: во-первых, помочь с базовым техническим бекграундом, а во-вторых, совместно с ним проговорить и найти те области, где он будет вам действительно полезен и закрывать какую-то вашу боль.
В том и дело, что авторизацию с нуля никто не программировал, в этом проекте использовался Laravel. Сама авторизация заняла, я не знаю, меньше дня, плюс еще несколько дней на регистрацию - там было много работ по фронту, плюс UI для админа, который проверяет учетную запись и одобряет ее.
Для того, чтобы решить эту несложную задачу, нужно было, нарисовать дизайн макеты, согласовать их, сверстать фронт и только потом уже что-то кодить. Параллельно делались и другие задачи. В итоге по планам выходило, что к условному 31му числу эти две задачи завершены полностью, а другие - не полностью и формально их сдать нельзя.
Заказчик это воспринял как "месяц на авторизацию" и предложил сократить время способом, описанным в статье.
Представьте, что вы строите дом на заказ, вам нужно 12 месяцев на это. К вам через 11 месяцев приходит заказчик и говорит: "Вам что, не хватило 11 месяцев на то, чтоб поклеить обои и расставить цветки в горшках?"
В итоге удалось (вроде) объяснить, почему нельзя к кастомной разработке быстренько прикрутить авторизацию из вордпресса. К написанию статьи подтолкнул тот момент на переговорах, когда мы оба сделали круглые глаза: заказчик от удивления, что невозможно переиспользовать готовый кусок и сэкономить на этом время (критично было именно время, а не деньги), а я - от "крамольности" такого предложения.
в большинстве случаев масштабирование это задача, которая никогда не возникнет. Бизнес говорит: мы щас делаем 3 продажи в месяц, но у нас в стратегии написано, что будем продавать миллион к концу года, имейте это ввиду. И разработка закладывает фундамент для небоскреба, хотя почти всегда там будет стоять палатка с шавухой.
Часто переделать потом выходит дешевле, чем сразу заложиться и всю дорогу страдать.
Хорошо)
Позволю себе несколько замечаний к статье.
Сильно плавает глубина: текст позиционируется как ликбез, начинается с ввода и разбора терминов, а заканчивается паттернами проектирования приложений, сервис мешем и прочими высшими материями, которые и не разобраны детально (так как это не тема статьи) и лишний раз пугают начинающего читателя, так как кажется, что ему для собеседования и это тоже надо заботать;
Ссылка на вики "издатель-подписчик" не работает;
"Смешанная интеграция" - это уже прием для реализации флоу бизнес процесса, я бы не выделял это в отдельный вид, ну или оформил бы как вариацию асинхрона;
Вы говорите, что шаблон издатель-подписчик это пример использования очередей и в качестве иллюстрации упоминаете почту, но это некорректно: реализация Pub-Sub шаблона это, скорее, радиоэфир, когда много подписчиков подключаются к топику одного издателя и получают сообщение, пока подключены. Почта - хороший пример "Очереди", но это паттерн Уведомление (или запрос-ответ, если там двусторонняя переписка)
Слабая связанность и масштабируемость не являются плюсами асинхронной интеграции - эта связанность не "слабее" и не "сильнее", чем интеграционный контракт и пока он соблюдается, взаимодействие работает, что бы ни происходило внутри модулей (сервисов). При синхронном взаимодействии это будет работать так же.
Паттерн стейт-машина больно уж мудрено описан
Не согласен с тем, что сервисная шина это пример реализации оркестрации. Суть оркестрации в том, что есть стейтфул оркестровщик, который хранит состояние выполняемого процесса и в зависимости от этого состояния вызывает нужные сервисы. А сервисная шина - это, скорее, "умный" маршрутизатор запросов от системы А к одной и систем из списка на основании некоторых правил, которые учитывают занные в запросе.
Не согласен с выводом. Выбор интеграции базируется не на лучших практиках, а на исходных данных, включая известные ограничения. Лучшие практики - это опробованные ранее удачные решения для конкретных групп кейсов. Нельзя сказать "будем делать синхрон или сагу на хореографии, потому что вон гугл так сделал и у них все работает".
Там же, в выводах: RESTful API это не противопоставление сервисов действиям: RPC API тоже может реализовывать сервисную модель.
Это из крупного. Я бы посоветовал все-таки определиться с аудиторией и если это ликбез - сделать статью чуть полегче и без тяжелой артиллерии.
Я за всю свою карьеру не встречал разработчиков, которые бы хотели работать с ТЗ по ГОСТу. Очень часто такое ТЗ одновременно и избыточно, и недостаточно или неоптимально. В используемой в статье терминологии аналитик, который ограничивается классическим ТЗ - это "глупый аналитик".
Боюсь, академическое вузовское проектирование для большинства задач будет или слишком "теоретическим" или слишком тяжеловесным. Для ТЗ по ГОСТу оно, может, и подойдет, а вот для более динамичных команд - скорее нет.
И еще, как проектное управление поможет в проектировании?
Вы не одиноки, всего рынка сейчас такая проблема, по крайней мере в энтерпрайзе. В свете того, как сильно перегрет рынок, я все больше склоняюсь к тому, что нужно набирать стажеров, прям после вуза, пачку, два месяца их учить под себя, можно даже не давать рабочих задач, а только учебные материалы и если получится, то через какое-то время на выходе получим пачку лояльных и заточенных под конкретные задачи мидлов за небольшие деньги. Да, сложно, но одну из последних вакансий я закрывал около 10 месяцев - или нам не подходит, или компания не нравится или еще что-то.
К сожалению, я очень часто, в том числе и от друзей (не коллег) разработчиков, слышу подобное. И я думаю, что средний технический уровень системных аналитиков по отрасли действительно невысок. Я пришел в системный анализ будучи лидом разработки (так карьера сложилась), но это, скорее, исключение: обычно аналитики не имеют опыта разработки (институтские лабы не в счет).
Но есть решение (рабочее, проверяли): аналитика можно "настроить" под себя: во-первых, помочь с базовым техническим бекграундом, а во-вторых, совместно с ним проговорить и найти те области, где он будет вам действительно полезен и закрывать какую-то вашу боль.
Это был репутационный ведомственный проект, портал не должен был приносить прибыль, поэтому все комментарии про деньги - не очень релевантны.
В том и дело, что авторизацию с нуля никто не программировал, в этом проекте использовался Laravel. Сама авторизация заняла, я не знаю, меньше дня, плюс еще несколько дней на регистрацию - там было много работ по фронту, плюс UI для админа, который проверяет учетную запись и одобряет ее.
Для того, чтобы решить эту несложную задачу, нужно было, нарисовать дизайн макеты, согласовать их, сверстать фронт и только потом уже что-то кодить. Параллельно делались и другие задачи. В итоге по планам выходило, что к условному 31му числу эти две задачи завершены полностью, а другие - не полностью и формально их сдать нельзя.
Заказчик это воспринял как "месяц на авторизацию" и предложил сократить время способом, описанным в статье.
Представьте, что вы строите дом на заказ, вам нужно 12 месяцев на это. К вам через 11 месяцев приходит заказчик и говорит: "Вам что, не хватило 11 месяцев на то, чтоб поклеить обои и расставить цветки в горшках?"
В итоге удалось (вроде) объяснить, почему нельзя к кастомной разработке быстренько прикрутить авторизацию из вордпресса. К написанию статьи подтолкнул тот момент на переговорах, когда мы оба сделали круглые глаза: заказчик от удивления, что невозможно переиспользовать готовый кусок и сэкономить на этом время (критично было именно время, а не деньги), а я - от "крамольности" такого предложения.