Pull to refresh
34
0

User

Send message

Например есть статья от человека, который придумал SP: https://ronjeffries.com/articles/019-01ff/story-points/Index.html
Про оценки сроков и трудоемкости неплохо написано у ДиМарко и Листера в "Вальсируя с медведями", короткий пересказ, например, в https://dev.to/tlakomy/why-i-don-t-like-story-point-driven-estimates-28h7
Но вообще бессмысленность оценок сложности, не соотнесенных с исполнителем достаточно очевидна, не понятно, зачем для этого что-то читать.
Вообще, Scrum как магнит притягивает к себе кучу разнообразных плохих практик, по вполне понятным причинам.

На самом деле SP вообще не пригодны для каких-то оценок, кроме оценок рисков (и тогда сводятся к майкам). Вообще использование SP в большинстве случаев антипаттерн, но в предложенной методике и так настолько много сомнительных решений, что одним больше или меньше - уже не важно.

Да и "по возможности стоит избегать" - не совсем верно. Скорее уж асинхронное взаимодействие по возможности лучше избегать - как сложно контролируемое, увеличивающее latency и сложность кода.

Нет разницы, как запрашивать данные, синхронно или асинхронно, в обоих случаях результат можно сохранить, если он нужен.

(Прошу прощения, промахнулся по оценке, постарался компенсировать в других ваших комментариях).
В конкретных случаях - да, может быть, так как фактически речь идет о стриминге изменений между двумя bounded contexts. Правда, кролик тут неудачный выбор и нужно бы Transaction Outbox прикрутить. Впрочем, когда есть TO, то он может и синхронно отправлять события, зачем там асинхронный MQ.
Но, в любом случае, это не про "синхронные взаимодействия вообще плохи".

  1. Это неверно. Если нужен ответ от сервиса, то все равно вызывающий ждет response-сообщения от MQ, только при этом требуется гораздо больше времени. А если ответ не нужен - то зачем его ждать?
    Клиенту нужен результат и если для его получения нужно вызвать 10 методов - они все будут вызваны, не важно, через MQ или синхронно. Но если вызывать через http/grpc, то результат будет быстрее и нагрузка на систему будет гораздо меньше.

  2. Если приляжет MQ, то нужно будет сделать точно то же, так что логика retry в коде все равно будет нужна. Впрочем, нормальный resilience для http есть во всех языках и странно его не использовать.

В общем, не видно, с чего бы вызовы через ненадежный и без гарантий рэббит был бы хоть по каким-то параметрам лучше, чем прямой http вызов. Ну а если в кролике включать гарантии доставки (или, лучше, ставить кафку), то latency вырастет еще выше. Да и проблему с отправкой сообщений все равно не решить (

Но это же не так.
Сделать http вызов с serviceA на serviceB очевидно дешевле, чем с ServiceA к брокеру и с брокера на ServiceB.
Я уж не говорю, что тот же кролик "из коробки" не дает никаких гарантий, а для доставки at-least-once нужно будет громоздить кластер, персистанс и специального человека на поддержку всего этого добра. Впрочем, чистый http call тоже не дает никаких гарантий, но хотя бы не является SPOF

Автор пишет "Такое взаимодействие называется синхронным. Его лучше избегать". Хотелось бы понять, чем обусловлена такая рекомендация?

А чем все-таки плох синхронный подход? Простой и, в данном сценарии, наиболее надежный, с минимальной latency, простотой контроля и развития.

На 10000 серверах на каждом есть пайтон для запуска скриптов, написанных разработчиком? И к каждому с доступом на выполнение скриптов? И с логами, которые пишутся в файлы?
Я не верю )

Хм, они нормально работают от масштабов "один маленький сервер в чужом облаке" и до масштабов Гугла. А у тебя какой масштаб?

Кстати, yaznahar, а вы действительно не знаете про современные подходы к observability?
Про системы сбора и хранения метрик, про системы сбора и хранения логов, про разделение метрик, логов и трейсов, про алертинги, про концепцию сайдкаров, про изоляцию продакшена от админов и разработчиков, про контейнеризацию и так далее и так далее?
Пост действительно выглядит как пришедший из прошлого тысячелетия.

Нет, зачем там метрика с хоста? Достаточно метрики на основании запроса в систему логов, так все и делают обычно.

Э, нет конечно. Мы просто вешаем алерт на систему логгинга (которых бесконечное количество на любой вкус). И делаем это без каких-либо операций с продакшен-системой (типа добавления однострочников), крона и так далее.
В стандартном стеке это делается в несколько кликов в графане. Она при этом еще и письмо пришлет или в телегу напишет.

Ну вот серьезно, уже XXI век на дворе, откуда эти идеи времен "приходящих виндовс-админов"?

А зачем вообще руками смотреть логи, да еще и запоминать позицию? Вроде бы уже XXI век, для постоянной работы с логами есть куча утилит и стоит пользоваться именно ими.

На Шекспира еще больше ссылок из научных трудов, что не делает "Сон в летнюю ночь" валидным научным трудом по межвидовой коммуникации.
Проблема не в увлечении феминизмом, а в откровенной научной безграмотности конкретных утверждений.
Но я уже понял, никаких обоснований хоть какого-то статуса DISC не будет.

Ну как, автор создал и продавал полиграф (нет научных подтверждений его работы и каких-либо подтверждений его работоспособности), развивал примитивный феминизм (женщины честнее и прочую фигню), а большую часть жизни вообще рисовал комиксы. Научных публикаций (кроме диссертации) я не смог найти.

Из персональных характеристик, насколько я помню, какое-то обоснование имеет только Big5, все прочие модели не имеют подтверждения. Но Big5 не предполагает быстрого определения параметров и довольно сложным образом коррелирует с поведением. Использование же ложной модели для выстраивания коммуникации хуже, нежели отсутствие моделей вообще.

А у DISC есть хоть какое-то научное обоснование? Я вот не смог найти никаких подтверждений. Да и биография автора вызывает очень много обоснованных сомнений в сколь-нибудь полезности модели.

Конечно, от модели DISC может быть польза. Если менеджер сообщает, что он ее использует - то, скорее всего, он некомпетентен. Это помогает выстраивать коммуникацию с этим менеджером.

Ага, значит описать решение конкретной простой задачи - не можешь.
Ну, что и хотелось понять.

Кажется, что ES как "хайповая идея" постарше, нежели хайп вокруг DDD. Но это не важно.
В DDD очень неплохие стратегические паттерны. А вот тактические - да, бесполезны...

Information

Rating
Does not participate
Works in
Registered
Activity