Добрый день. Реализация таких event-driven-specific техник интересна, но выходит за рамки миграции архитектуры, а статья именно об этом. Возможно, вы пропустили следующую ремарку:
Честно скажу, разбор всего кода не осилил. Но тезисно проблематика в первой части статьи интересна, и действительно, часто встречается в новых командах.
По моему опыту, полезно держать фокус на балансе скорость\качество, т.к. почти нигде не стоит задачи писать идеальный код. Исходя из этого можно использовать полезный подход от Джефа Безоса "I disagree but commit". Другими словами, когда возникает обсуждение, которое перетекает в академические споры, хороший техлид может поставить их на паузу и сказать что-то вроде: "ребята, это очень интересная дискуссия, но у нас нет цели писать идеальный код, так что давайте пока выберем вариант Х и будем двигаться дальше, а если увидим, что он приносит проблемы, то позже пересмотрим". Если правильно это подать, то люди, даже не согласные с выбранным подходом, согласятся ему следовать, просто потому что спорить можно бесконечно.
По поводу Unit tests и TDD - наверное, озвучу непопулярное мнение, но я стараюсь вообще отходить от юнит-тестов. По опыту они долги в написании, у них высокий maintenance cost, а ловят реально nasty проблемы они редко. Так что тут пришел к фразе одного умного человека:
Write tests. Not too many. Mostly integration.
Тесты писать нужно, но лучше на уровне абстракции повыше unit :-)
Здесь в память загружаются абсолютно все привязанные к пользователю токены.
Правильно понимаю, что если этого места не было, и вместо него был бы, например, запрос в базу за конкретным токеном, то lazy-load по связи всё же срабатывал бы при сериализации юзера? Спрашиваю, потому что при code review у меня бы зацепило взгляд именно это место.
По опыту двух проектов, HTTP оверхед интуитивно пугает больше, чем он есть на самом деле. В обоих случаях сервисы находились в рамках одного дата-центра, и данный оверхед почти не имел импакта на latency. Если не изменяет память, то RPS в нашем случае колебался от 10 до 100.
Что же касается async, то здесь картина другая, и нужно хорошо продумывать архитектуру. В большинстве случаев как минимум необходим autoscaling консумеров и хороший мониторинг с алертами, чтобы сообщения в очередях не копились. Зато потенциально такая архитектура масштабируется даже лучше.
Помимо всего прочего, это ещё и база валидных сотовых номеров. При попытке войти на большинство аккаунтов, предлагает подтвердить смену пароля на новый, при этом указывается в открытом виде привязанный к почте номер.
kiaplayer как раз-таки говорит о том, что пользователю в их случае не обязательно менять привычные форматы XLS/XLSX на что-то другое — система переконвертирует сама.
Уважаемый автор, по вашим словам «функция критического мышления во сне подавлена». Как вы относитесь к идеи о том, что этот факт — минус и было бы правильно от него избавляться (развивать осознанность, чтобы она сохранялась даже во сне)? Лично мне в голову приходят аналогии о том, что человек даже в течение дня многие вещи делает «на автомате», практически не обращая внимание на процесс и никак его не оценивая. Хорошо ли это?
Вы ограничили функционал мозга понятием «компьютер» и отталкиваетесь от этого термина, хотя возможности и механизм его работы до конца не изучены. Вам не приходила мысль, что в будущем человек, возможно, сможет продуктивно использовать время сна и в этом не будет ничего необычного?
Добрый день. Спасибо за мнение. Рад, что вы нашли полезные мысли и вещи.
Добрый день. Реализация таких event-driven-specific техник интересна, но выходит за рамки миграции архитектуры, а статья именно об этом. Возможно, вы пропустили следующую ремарку:
Спасибо за статью!
Честно скажу, разбор всего кода не осилил. Но тезисно проблематика в первой части статьи интересна, и действительно, часто встречается в новых командах.
По моему опыту, полезно держать фокус на балансе скорость\качество, т.к. почти нигде не стоит задачи писать идеальный код. Исходя из этого можно использовать полезный подход от Джефа Безоса "I disagree but commit". Другими словами, когда возникает обсуждение, которое перетекает в академические споры, хороший техлид может поставить их на паузу и сказать что-то вроде: "ребята, это очень интересная дискуссия, но у нас нет цели писать идеальный код, так что давайте пока выберем вариант Х и будем двигаться дальше, а если увидим, что он приносит проблемы, то позже пересмотрим". Если правильно это подать, то люди, даже не согласные с выбранным подходом, согласятся ему следовать, просто потому что спорить можно бесконечно.
По поводу Unit tests и TDD - наверное, озвучу непопулярное мнение, но я стараюсь вообще отходить от юнит-тестов. По опыту они долги в написании, у них высокий maintenance cost, а ловят реально nasty проблемы они редко. Так что тут пришел к фразе одного умного человека:
Тесты писать нужно, но лучше на уровне абстракции повыше unit :-)
Спасибо за статью!
Правильно понимаю, что если этого места не было, и вместо него был бы, например, запрос в базу за конкретным токеном, то lazy-load по связи всё же срабатывал бы при сериализации юзера? Спрашиваю, потому что при code review у меня бы зацепило взгляд именно это место.
Добрый день. Спасибо за комментарий.
По опыту двух проектов, HTTP оверхед интуитивно пугает больше, чем он есть на самом деле. В обоих случаях сервисы находились в рамках одного дата-центра, и данный оверхед почти не имел импакта на latency. Если не изменяет память, то RPS в нашем случае колебался от 10 до 100.
Что же касается async, то здесь картина другая, и нужно хорошо продумывать архитектуру. В большинстве случаев как минимум необходим autoscaling консумеров и хороший мониторинг с алертами, чтобы сообщения в очередях не копились. Зато потенциально такая архитектура масштабируется даже лучше.
Во сне мозг что-то вычисляет?
…
}
:-)