Расскажи пожалуйста почему ты ищешь новое место работы в моём случае всё крайне Просто мой текущий проект попадает под заморозку и поэтому мне пришлось выйти на рынок и осмотреться чего же есть ещё и найти себе какой-нибудь новый проект который бы меня чем-то зацепил и захотелось присоединиться к его команде И развивать Какие проблемы можешь назвать которые могут возникнуть при использовании по точности и как избежать ну одна из типовых проблем Когда у нас есть данные которые надо разделять между потоками то
00:00:00 - 00:01:22
есть при взаимодействии надо учитывать чтобы эти данные поменялись корректно и не прочитали из другого потока некорректно для решения этой проблемы есть класс илов примитиво синхронизации и так далее Ну ещё там логики То есть когда мы не просто по в то что данные некорректные А когда мы сталкиваемся с тем что мы обеспечили какую-то защищенность данных критической секции кода но при этом встали в делок из-за того что всем нужны эти данные Но кто-то их не отпускает как бы ты предложил избежать дело чаще Это надо именно
00:00:41 - 00:02:02
смотреть на код в основном делок у нас возникает по причине какой-то грубо говоря ошибки программиста когда мы в каком-то из случаев вышли из критической секции но не освободили ресурс Ну а второй частый вариант это когда у нас критическая секция выполняется на самом деле Достаточно долго скажем простой совет как его пытаться избегать избегать ошибок и пытаться делать крайне маленькие операции над данными ческой секции чтобы эти операции проходили как можно быстрее и освобождали для других а помимо этого
00:01:21 - 00:02:42
Какие можешь ещ посоветовать способы избегания таких проблем с многопоточность Как вариант вообще отказаться от многопоточности Нам же не обязательно всегда на одной машине обрабатывать все данные тоже будет параллельно обработка мы Для чего делаем многопоточность да чтобы приложение стало более производительным Был ли опыт какой-то у тебя по оптимизации можетли проводите действительно есть в памяти что мы протянули Но необходимо всё это дело Прочитать то есть где-то что-то просуммировать и там делились данные
00:02:02 - 00:03:16
действительно параллельно несколько потоков Ну использовались соответствующие классы в том числе там класс позволяющий разделить входящий массив между потоками То есть он сам каким-то внутри механизм хитрым нарезал на определённые куски отдавал разным потокам чтобы они не пересекались А как это следили вот сам процесс этого нарезания как оно в процессе работает оптимально не оптимально Может там что-то поть надо было профилировщик может быть какие-то Ну в профилировщик да бывало отслеживали но конкретно вот
00:02:42 - 00:04:05
эту ситуацию здесь уже не отслеживали то есть сам профилировщик применяли на изначальном этапе что действительно у нас там к примеру полно ресурсов но мы данные молотим молотим а э время там к примеру мы до каких-то оптимизаций все эти даные там молотили условно час а в одном потоке покойно А и получалось что мы вот видели что у нас там нагрузка на процессор там какая-то смешная условно 15% а оперативки тоже свободно но данные при этом быстрее не обрабатываются и вот как раз профилировщик подбирали количества потоков и так далее
00:03:23 - 00:04:56
но там после всех расчётов и оптимизации мониторинга мы пришли к тому что прямо брали служебную переменную то есть от машин Сколько на машине ядер сколько вот стандартно предлагает нам использовать потоков среда фреймворка соответственно мы столько и давали и у нас нагрузка действительно была процессор 100% но он отвал эти данные уже за 15 минут Супер А если не про само приложени говорить например про оптимизацию запросов в базе данных там сервисного какого-то взаимодействия был опыт был соответственно Ну тут Если мы будем
00:04:09 - 00:05:32
говорить про какие-то более старые версии достаточно Мне кажется сложно раньше было Вот это всё отследить оптимизировать с позиции того что к примеру Лично я ловил запросы прямо когда работал с майкрософта ской базой в их мониторе Ну профилировщик тоже таком же отлавливать подключался отдельным пользователям чтобы легко было отфильтровать Ага всё вот такой запрос сгенерировал туда Не туда современной версии к счастью и позволяют и в отладке увидеть чего там наге нери посмотреть запрос понять о даже на визуальный
00:04:50 - 00:06:15
взгляд оптимальный нет и потом соответственно если мы там визуально не видим явно к чему докопаться А всё равно заработает медленно всегда можно уйти на сторону базы данных посмотреть её планы запросов как она там чего гуляет и понять Надо ли там нам индексы прикручивать какие-то Надо ли переделывать структуру данных где там у нас проседает пате проектировать такой додин знаком знаком но так скажем вживую я его не видел кроме как в теоретических статьях и подходах всё должно чётко читаться то есть мы не
00:05:38 - 00:07:00
просто там программируем и обзываем там наши методы какими-то выгодными названиями это долж быть названия связа с областью под которую мы пишем то есть они должны чаще всего делается какой-то словарик садится с бизнесом обсуждается что вот у нас есть существуют такие-то понятия и вот в рамках этих понятий наш код достаточно легко читать и понимать взаимосвязи и в рамках доменной области в которой мы работаем а как насчёт такого паттерна как инсорсинг Знаком это паттерн отвечающий за то что мы взаимодействуем по событиям То есть у
00:06:19 - 00:07:44
нас существуют какие-то события которые происходят в том или ином месте и мы их каким-то образом обрабатываем то есть у нас код не жёстко связан что вот у нас такие-то и такие-то действия а у нас есть события которые могут обрабатываться в одном в нескольких местах то есть мы можем выбросить события что у нас создался покупатель в этот момент соответственно всех кому надо кто подписан на это события отработают его и там не знаю к этому покупателю зарегистрирует там виртуальный аккаунт в банке к этому
00:07:02 - 00:08:21
покупателю там создастся к примеру промоакция для новых покупателей и так далее а такая аббревиатура как cqrs знакома Да тоже знакома и соответственно она больше про то что мы должны чётко разделять для запросов которые на чтение и для запросов которые на изменения и запросы на чтени мы можем максимально оптимизировать там где-то сказать что они там условно либо почти не меняются либо ещё что-то но оптимизировать сам путь запроса меньше делать каких-то валидации проверок и за с этого ускорить производительно
00:07:42 - 00:09:13
более детально всё валидировать ой иначе не на запись более детально всё валидировать и записывать понимая что записи там у нас происходят реже чем чтение и соответственно когда мы записываем Мы можем потерять немножко времени но обеспечить большее качество А на чтении нам важно как можно быстрее дать результат такие у нас подходы в основном используется в микросервисной архитектуре Что такое микросервисы можешь подсказать микросервисы - это так скажем такая штука которая позволяет разделять какую-то функциональность в
00:08:30 - 00:09:58
рамках Ну то есть у нас есть большое приложение условно там большая доменная область как раз что не знаю Ну вот также покупательская платформа какой-то пожалуй и в рамках неё могут существовать микросервисы отвечающие за конкретный функционал что позволяет сужать во-первых объём кода во-вторых позволяет эти микросервисы писать разным людям разным командам даже на разных языках при этом всём существуют механизмы взаимодействия между микросервисами Ну и главное оно позволяет именно раздеть логику и чем
00:09:13 - 00:10:45
меньше бизнес логики в одном микросервис и она при этом связана по одной тематике чётко мы Когда понимаем эту связанность нам проще работать и меньше шансов что мы допустим ошибки и окажем какое-то влияние на другие части кода Окей это получается такой положительный момент один а какие ещё есть положительные и отрицательные моменты у микросервисов Ну вот из положительных ещё раз я проговори на всякий случай То есть то что мы позволяем работать там раздельно людям не заморачиваюсь сильно не конфликту у нас меньше шансов что задачи
00:09:59 - 00:11:29
какие-то параллельные у людей заблокируют друг друга У нас есть возможность нанимать разные команды на разных языках для поддержки и реализации того или иного микросервиса У нас вот есть чёткая связь по логике По функциональности меньше шансов чего-то сломать Но с другой стороны Да всегда за за что-то хорошее надо чем-то платить и у нас появляются как раз сложности взаимодействия то есть нужно продумывать правильные механизмы для взаимодействия между микросервисами продумывать какие-то общие библиотеки продумывать надежность этой
00:10:46 - 00:12:16
истории потому что у нас часто в работе всегда используют Ну не всегда А часто именно используется подход транзакционный То есть когда нам надо гарантировать что чего-то пройдёт от сих до сих и вот если целиком прошло тогда мы это зафиксировали Если нет то нет И вот когда мы говорим про микросервисы э история сильно усложняется проблематика э структу есть е надо поддерживать каждый микросервис Да действительно должен друг друга видеть у них должна быть какая-то общая сеть ещё что-то то есть надо много нюансов учитывать при
00:11:30 - 00:12:55
поддержке этой структуры супер и Давай с тобой перейдём в есть основная задача это работать управления мивиной архите поз получается сервис для управления информацией о продукто обновления То есть со стандартным потом инве сервис для управления состояния складом количество продуктов рования ор сервис для управления заказами создать заказ лата gway который единая точка для входа так и механизм обмена о Ну ты знаешь ты как-то попал в эту в плюс-минус мою область то есть немножко такое у меня и есть Так
00:12:13 - 00:14:20
что давай пройдёмся поэтапно по каждому то есть давай во-первых хорошо у нас есть чётких три микросервиса соответственно пожалуйста мы выделяем эти три проекта которые Ну в нашем случае мы там не будем пользоваться какими-то достоинствами что они могут быть на разных языках и прочем всё будет наша пожалуйста и Ну вот мне понравился подход завен на мом проек микросервис у меня Пусть будут в основном их функционал описываться профа то есть в рамках микросервисов будет заш grpc общаться Они между собой будут
00:13:21 - 00:15:00
Соответственно по grpc со шлюзом они будут общаться также по jpc и соответственно шлю уже будет действительно у нас единой точкой входа которая так скажем отдаёт результаты и позволяет получить в единой структуре доступ куда нам надо не знает Так скажем какой сервис за это будет отвечать а может быть несколько сервисов такое тоже вполне возможно и получается механизм обмена сообщениями между сервисами пример с использованием предлагаю здесь так скажем применить библиотеку абстрагируясь применить ма
00:14:11 - 00:16:08
Транзит у которого транспортом Ну может вполне быть Т но теоретически и технически может быть абсолютно любой другой транспорт который также подключается совестно чего нам надо бы написать так ну в рамках фидлера Я не знаю насколько мы можем опуститься в какую-то глубину но у нас соответственно здесь проекты там можно создавать скорее всего нельзя и класс сильно не разгуляе ну из того что я озвучил соответственно нам нужны минимум три проекта для каждого сервиса По какой причине Объясняю В одном проекте у нас будет вся
00:15:10 - 00:16:53
бизнес логика в том числе там какие-то модельки какая-то живучая живу логика работы внутри с базой данных и соответственно логика взаимодействи с другими микросервисами синхронно ели это у нас взаимодействие с другим микросервиса Возможно асинхронным мы воспользуемся а механизмом обмена сообщениями то есть здесь можно как раз применить денсон то есть в рамках событий мы будем забрасывать какие-то сообщения в очередь которые события соответственно у нас будет потреблять другой сервис вот так и соответственно у нас
00:16:07 - 00:17:48
первый проект Вот это всё содержит второй проект содержит какие-то абстракции необходимые То бишь это у нас э к примеру как раз-таки описание событий которые мы можем а ловить из других сервисов и обрабатывать А и второй момент какие-то действительно общий абстракции ну к примеру перечисления какого-то вида и получается третий проект - это проект клиента кото через которого мы будем взаимодействовать с этим микросервисов микросервис которых у нас три штуки но сервис сервис о сервис с три проек проек
00:17:01 - 00:18:52
будут суффиксы Первый проект с суфикса содержит логи реализуемую микросервиса второй акции для коммуникации с другими сервисами и шлю рети крое ле сервисом и с шлюзы и других проектов которые не будут использовать jpc на Прим я вот так соответственно немножко про структуру поговорили вот в основном проекте у нас будут необходимые модели для взаимодействия с базой данных также рация базы данных игра Так чего ещё там будет самые главное там будет логика взаимодействия об этом бы выше прописано в вания печатки Ну суть Я думаю
00:18:44 - 00:21:43
понятно да это можно не обращать внимания Ну пока остановимся не будем дальше копать сильно сервисы взаимодействи другом так и так Маст се которым может являться rit MQ Пусть по умолчанию выявляется умолчанию и будет использовано само взаимодействие происходит как я уже сказал через события так хотя не только сервисы взаимодействи и Чере J вызовы сервиса асинхронно через события и их консьюмер люс люс а-а реализует механизм доступа к механизм для взаимодействия более общепринятым особенно стороны
00:21:31 - 00:24:20
фронта у нас кстати ничего не сказано ВМ пороше нуж какая-то валидация в люм с есть у где-то должен быть обязательно какой-то сервис для валидации и аутентификация тут у нас может быть как стандартно прирученный какой-нибудь ин сервер нос на маленьких проектах использу сто и облачные решения какие-то для закрытия этой истории то есть на память название не скажу но есть популярное решение которое в принципе вот я так по документации смотрел копал оно очень сильно схоже с идентити сервером но так скажем я не
00:24:18 - 00:26:13
удивлюсь если внутри он и лежит но кастомизированный но с нагрузками определёнными но я про то что обязательно у нас должен должна быть какая-то авторизация и аутентификация соответственно шлюз у нас должен приходить тон по которому мы Валиди что он вообще действительный что он живой по времени валидации и так далее потом разбираемся кто нам пришёл с какими полномочиями Ну условно говоря там Покупатель не знаю работник склада Кто у нас ещё Т может быть продавец который продаёт товар и так далее То есть в зависимости от этого
00:25:24 - 00:27:14
тоже море Като логику срезов Какие кому данные отдавать до каких методов микросервисов пускать кого не пускать Ну и в самих микросервисах желательно всё равно какую-то валидацию минимальную предусмотреть но уже не настолько так скажем заморачиваться потому что как мы говорим шлюз у нас Центральная точка входа и всё что внутри микросервисов особенно если микросервисы все делает одна команда мы где-то там друг другу доверяем всё равно и э совсем фигни не натворит но опять же вот надо исходить из контекста если микросервисы ведут
00:26:25 - 00:27:49
разные команды которые может быть даже с разных городов с разными тайм зонами тут Надо чётко понимать что надо тогда любой jpc запрос детально валидировать и не пропускать фильмы Угу чего ещё мы тут должны уточнить Ну вот конкретика решения какая-то такая Давай наверное пойдём по уточняющим вопросам то есть чего не хватает для понимания сам код мы явно писать не будем это слишком много долго Ну и средствами фидлера мы это не обыграем Угу Согласен у меня такой вопрос тогда уточняющий Зачем нам одновременно и jpc
00:27:08 - 00:28:44
и rit MQ Ну вот как раз то что я проговорил синхронно и асинхронное взаимодействие если мы можем какое-то действие сделать асинхронно Зачем воровать время на ответ и выполнять его синхронно Когда мы можем бросить события и обработать его даже не факт что одним сервисом мы можем действий сделать в рамках нашей системы разными микросервисами асинхронно которые там явно не не нужны пользователю Ну вот прямо сейчас условно если он проходит регистрацию там создали мы пользователи ему не факт что прямо
00:28:00 - 00:29:39
сейчас не знаю промоакция ещё что-то может быть мы там после создания ему какое-то интро проводим и за это время мы спокойно хроно всё до создали Ну а вот применимо к нашим текущим трём сервисам Где бы ты применил синхронные методы вызовы А где асинхронные А давай да давай посмотрим на эту историю А у нас есть добавление удаления обновление списка товаров Ну вернее информации о них количество продуктов на складе резервирования и создание заказ вот ну при создании заказа нам чаще всего надо взаимодействовать более-менее
00:28:49 - 00:30:24
синхронно со всем Потому что нам в момент создания заказа надо сразу пользователю сказать Дада мы под тебя зарезервировать товар этот товар действительно есть у нас ты там не пытаешься заказать то чего нету в принципе в системе то есть здесь скорее всего синхронно в соседний сервис когда мы говорим про Так давай посмотреть где мы асинхрон явно можем применить Ну вот к примеру мы добавляем товар либо удаляем товар мы удаляем информацию о товаре То есть в принципе мы можем не синхронно удалять также
00:29:38 - 00:31:10
информацию о том что этот товар У нас есть на складе в таком количестве там его чего-то там зарезервировать и так далее а сделать Это непосредственно асинхронно но при этом надо учесть что будет не совсем правильно и корректно удалить товар сразу по крайней мере без какого-то к примеру изменения что товар скрыт в начале в случае если у на зарезервирован То есть у него есть активные заказы мы там ещё не завершили лоу этого товара поэтому скорее всего Нам надо сходить в начале синхронно и проверить какой-то минимум то есть там
00:30:31 - 00:31:47
действительно товар не находится в данный момент в работе там к примеру ещё что-то а потом уже удалить информацию и создать события об удалении товара которое соответственно при обработке удалит всю информацию со склада име каким-то образом делим либо ещё чем-то что всё нам эта информация не нужна и она не актуальна так такого товара больше не существует на витрине заказах Угу Окей Итого мы по всем прошлись да или нет вроде ещё Да вроде да то есть мы можем копаться в примерах синхронного асинхронного взаимодействия ещё больше
00:31:09 - 00:32:43
то есть их можно тут больше сильно приводить Но вопрос Действительно ли нам это надо Если надо мы можем ещё покопаться нет нет не надо Давай мы пробежимся вот по этим методам раздельно и посмотрим какой бы ты сделал синхронным какой асинхронным то есть прямо вот подпишем Вот здесь например в скобочках там асинхронный Ну смотри То есть я бы вс-таки как вот мы сейчас обсуждали на методе удаления не ограничивался чётко что вот это только синхрон или только асинхронный я бы просто помел где возможно добавить какую-то асинхронность
00:31:59 - 00:33:15
потому что асинхронность всё равно должна быть и что какие-то операции Мы выполняем всё равно синхронно и вот как при удалении сказал что мы можем синхронно сделать какой-то минимум проверить что у настльно можем спокойно удалять Давай действительно помет внем Но это будет означать не просто что выполняется асинхронно том что в НМ есть какая-то асинхронная изюминка которую дела Давай давай предложу немножко перечить нашу Легенду Давай будет PC Давай попробуем Говорю Вполне вероятно что у нас часто будет И то и другое вместе
00:32:40 - 00:34:23
взят Смотря какой сценарий мы Придумай Ну соответственно давай ну вот к пример прямо по создали мы этот товар синхронно в рамках нашего сервиса соответственно нам об этом синхронно уведомлять кого-то не надо но можно уведомить вот Да действительно асинхронно То есть через т сервис складов к примеру чтобы там не обрабатывать когда мы получаем информацию о товаре условно какие-то что товара в принципе нет на складе значит у него нулевые оста остатки А чтобы у нас красиво создалось что да такой товар существует в рамках
00:33:39 - 00:35:11
склада мы понимаем что он есть но у него сейчас количество на складе нулевое зарезервировано у него ноль штук а соответственно удаление то есть вот здесь уже сложнее то есть здесь у нас должно быть как мы проговаривать уже и синхронное и асинхронное взаимодействие то есть мы должны можно можно те на минуточку рву как мы это должны представить в виде сервиса то есть сервис одновременно делает и запрос по jpc и в очередь ещё отсылает что-то да именно так тем как перед тем как товар удалить то есть
00:34:37 - 00:36:06
в рамках логики валидации какой-то делаем Запрос к сервису складов ус спрашиваем У тебя этот товар зарезервирован он есть на складе и так далее если мы получаем что Да действительно товар исправный товар там не зарезервирован соответственно может спокойно зачищать мы говорим что да Всё мы поем товар под удаление либо даже пря сразу удаляем и вс хорошо мы товар Удали если же товар к примеру зарезервирован мы говорим что по нашей текущей логике к примеру зарезервированные товары нельзя удалять потому что они вот сейчас ещё в
00:35:23 - 00:37:01
работе и по ним могут быть какие-то действия поэтому мы отвечаем пользователю Извини Мы товар не можем удалить но там к примеру если ты хочешь его скрыть С витри Е чтото ровал пожалуйста Воспользуйся функцией обновления и измени там статус твоего товара что он к примеру скрыть Угу И когда мы вот эту логику сделали то есть когда мы вернули пользователя когда вернее мы удалили товар мы можем в этот же момент асинхронно выбросить сообщение в сервис склада и сказать ему ты знае мы удалили этот товар ты можешь у себя
00:36:13 - 00:37:47
зачистить информацию по этому товару то есть она больше не нужна угу угу Согласен полностью согласен Давай немножко минимизируем наш скоуп то есть будем рассматривать вот наш сервис продукт сервис Да как AP некоторое и соответственно он предоставляет нам четыре функции добавление удаление обновление и получение списка вот в сервисе как реализовали добавление то есть мы сигнал Да команду на добавление мы принимаем по rpc по или и так и так сигнал на добавление мы принимаем соответственно точно по
00:37:00 - 00:38:31
grpc То есть у нас тут Ну то есть до немного в другом ключе Я размышлял но если мы именно ЧМ мы принимаем сигнал в принципе на любой из вот этих историй мы сигнал принимаем по ну к примеру даже от того же шлюза то есть от шлюза Мы всегда так или иначе сигнал примем по потому что чаще всего со шлюза к нам приходит Запрос который на который пользователю надоть сказа это десте сде что это будет отложенное действительно асинхронное действие там к примеру что мы там запустили какой-то расчёт вернуть пользователю синхрон
00:37:45 - 00:39:25
ожидай то есть в моём понимании сигнал который приходит в микросервис он всегда придёт по grpc Чаще всего именно в рамках описанных э явно в ТЗ Угу А давай рассмотрим пример с удалением продуктов Да ты как раз про него уже рассказывал что мы например можем пойти в inventory Service и спросить есть ли что-то зарезервировано или нет Есть ли что-то у нас там с заказами например вот количество и так далее это сервис идёт делает что-то долго Ну представим что у нас там проверка резервирования продуктов может
00:38:39 - 00:40:01
занимать 5 минут Да нужно ли на Ну вот тут Да очень важен контекст именно кто как мысли и в каком контексте потому что вот в моём понимании именно Проверка резервирование как таковая должна проходить достаточно быстро возможно вот удаление информации либо там ещё чтото может проходить дольше там к примеру во время удаления там мы на самом деле должны ещё не просто там удалить запись о том что на складе есть отправить уведомление там Подготовь вот такой-то товар Перенеси в такую-то секцию в товары которые мы больше не
00:39:20 - 00:40:48
продаём отправить письмо поставщику что там Заберите ваш товар со склада и так далее Ну какой-то вот длительный Фло может быть а когда мы говорим проверить просто резервирование должно быстро проходить но если мы отталкивается от ТЗ что ты даёшь Что у нас соответственно резервирование продукта - это то Что проходит Достаточно долго ну к примеру вот было приведено 5 минут это достаточно долго тоже с моей стороны то есть в этом случае Да можно а это сделать асинхронно И сказать что Да мы вроде как товар пометили под
00:40:04 - 00:41:22
удаление Ну тогда тут надо обыгрывать именно статусами в продакт сервисе корректно чтобы мы не сказали пользователю что да мы твой товар удалили а потом вдруг не удалили то есть надо вводить какое-то промежуточное состояние что да мы действительно пометили товар под удаление он уже там скрыт с витрины но мы сейчас проверяем Действительно ли мы можем его удалить через какое-то время мы тебе скажем точно что мы товар либо удалили либо Извини он остаётся скрыть он ещё задействован где-то в чём да да
00:40:43 - 00:42:00
Супер давай вот наверное последний такой вопросик добавление Да мы сделали его через jpc ты сказал что нужно обязательно давать сразу клиенту обратно ответ добавили мы товар или нет продукт А в чём вот такая бизнес необходимость именно сейчас получить почему мы не можем это сделать через rit MQ а но чаще всего это связано к примеру с тем что во-первых пользователь чаще всего хочет сразу получать какой-то результат ну у на нет каких-то явных технических сложностей которые мы не можем обыграть Я придерживаюсь всегда концепции что чем
00:41:21 - 00:42:51
U отзывчивый напрямую завязан нак для своей отзывчивость чем отзыв тем пользователю приятнее тем меньше вероятность что пользователь помм к примеру что у нас товар который мы добавляем он должен отвечать там каким-то критериям То есть к примеру мы при добавлении товара проверяем что этот товар имеет там уникальное название или этот товар ю там чтото с сцену или он там прямо сейчас появится на витрине вот для всех этих историй нам желательно сразу выполнить запрос синхронно и сказать что да да мы
00:42:06 - 00:43:57
действительно добавили а не так что мы вот пытаемся добавить твой товар Ну ты пока мы добавляли там кто-то ещё создал товар с таким названием ты извини Вот твой товар меняй пользователь уже там Расслабился выпил кофе и ушёл по свои дела думаю о всё хорошо я создал товар приходит а у него ноль заказа Почему А у нас товар на самом деле не добавился Да не хотел бы оказаться на месте этого пользователя что-то из этого да да согласен О'кей спасибо большое Константин предлагаю на этом завершать э ощ а Ну
00:43:08 - 00:44:52
соответственно более-менее достаточно хорошо ощущение именно с позиции того что ну здесь в любом собеседовании Мне кажется всё равно есть элемент удачи то есть всегда могут попасть в ту область в которой ты более-менее подкован и менее подкован А вот в данном случае С практической частью тут даже не возникло какого-то диссонанса с позиции углубиться куда-то за области своих границ то есть так или иначе я обо всех вот этих вещах что мы проговорили рано или поздно уже думал либо как-то где-то вокруг до около ходил То есть это
00:44:02 - 00:45:41
был больше приятный разговор на тесть поразмышлять здесь может быть э хорошего чего нехорошего и так далее То есть и в этом плане тут я считаю вот элемент удачи он всегда присутствует и поэтому можно э сходить на 10 собеседований и на одном Тебя возьмут э и скажут да ты сверх профессионал а на к примеру пяти скажут Ты середнячок она и ещё двух вообще скажут какой-то пришёл Непонятно чего ничего не знает И чего вообще пришёл на собеседование на кого он претендует вот так что 100% э Тут есть элемент удачи всегда и
00:44:51 - 00:46:34
приятно когда тебе немножко везёт Ну это про практическое Да а теоретическое как вопрос те а теоретические вопросы в любом случае интересные вот Единственное не хватает какой-то явной обратной связи вот в реальных собеседованиях в принципе бывает та же самая история а то есть есть интервьюеры которые тебе действительно сразу дают понять что А да да Слушай ну нас ответ устраивает А давай ещё вот в эту сторону отойдём посмотрим вот в эту А вот по твоей реакции далеко не всегда было понятно То есть ты до конца раскрыл вопрос или нет
00:45:43 - 00:47:07
Или мы просто там переходим к следующему вопросу Потому что ты вообще там к примеру А рассказал базируясь на своём опыте какую-то историю но не попал в заданный вопрос и интервьюер такой ну это не туда не буду его мучить двигаемся дальше Вот вот э история и здесь Ну возможно надо было мне сразу так скажем задать тон с первых вопросов а сразу попытаться дёргать эту обратную связь то есть да да нет нет Угу здесь смотри формат да такой что я собираю всю обратную связь а потом в конце тебе её рассказываю чтобы не
00:46:25 - 00:47:49
сбивать тебя с ритма чтобы ты спокойненько рассказывал и отвечал на вопросы не прерываясь потому что для многих людей может быть для тебя это не так Я понимаю что ты очень такой открытый общительный человек но многие люди когда им скажешь там на первый вопрос ты ответил Хорошо ты говоришь хорошо Он на второй отвечает хорошо на третий вопрос он отвечает плохо ты ему говоришь Ну как бы Извини вдг на этот вопрос ты ответил плохо и всё и человек уже на четвёртый на пятый уже просто не может отвечать у него голова не работает
00:47:07 - 00:48:00
потому что всё он на третий вопрос ответил плохо и человек просто теряется он не может больше продолжать иногда даже просят там всё типа Давайте с вами закончим Я больше не могу такое тоже бывает Поэтому согласен такое бывает но здесь мне кажется именно решается По большей части опыта то есть у меня действительно такое тоже случалось Но именно когда ты нарабатывать э приятнее получать обратную связь сразу именно с позиции того что тогда ваш диалог кажется каким-то более живым и как будто Вы действительно не просто вот
00:47:34 - 00:48:51
там пришли закрыть сухую функцию про собеседовать А вы общаетесь с коллегами с профессионалами и обсуждайте какие-то насущные вопросы да да согласен здесь на самом деле если бы это было реальное собеседование всё было бы совсем по-другому ну лично у меня потому что у меня была бы обязательно цель у меня были бы какие-то критерии по которым нужно человек чтобы соответствовал чтобы прошёл ко мне в команду Вот и соответственно вопросы были бы построены именно с такой целью и там было бы Понятно Куда дальше двигать
00:48:14 - 00:49:21
и двигать ли вглубь не двигать насколько это вообще важно нам неважно есть у нас люди которые могут закрыть такие компетенции мо ВС пря совсем по-другому да согласен Есть такое в реальных собеседованиях Я даже это где-то Ну то есть когда проходило реальное собеседование где-то Я получал эту историю По обратной связи а где-то видел просто по реакции людей что там к примеру ты там в какой-то области плаваешь Но для них э область крайне важна из что вот этог бы зарыть Но вот это нам очень крайне важно в реальных собеседованиях есть
00:48:48 - 00:50:15
такой ключ тут его можно Как чувствовать так и не чувствовать опять же Ну и по теоретической части в любом случай то есть говорю некоторые вещи сейчас посмотрим что расскажешь по обратной связи некоторые вещ ты отвечаешь как чувству и иногда Уно говоря може что-то применять применять ежедневно там условно даже сталкиваться с этим названием но ты не акцентирует это прям такой-то Патер точка опять же про То есть я вот уточнил что я в Рем прося и дано именно с вот этой красивой семантикой что у нас есть и словарик и так далее То
00:49:32 - 00:51:18
есть вот этой красивой теоретической обр кой которую нам часто продают статьи это как скрам то есть если мы будем смотреть вакансии и так далее То есть там чуть ли не в каждой вакансии будет что мы работаем по скрам и так далее но выдержать все принцип Искра могла и я не встречал ещ ни одной команды которые сказали бы Мы прям без каких-то оговорок действительно вс всё прям по концепции ни шагу влево ни шагу вправо вот так иту потому что у нас вот даже говорю либо применяется специальная которая
00:50:32 - 00:51:48
заточена под эту историю и она вот сразу в себе несёт И пропагандирует что надо доно такой красивой вни вживую Я не видел Пока да да согласен ну Однако есть на самом деле тоже компании в которых это вживую применяется есть в которых применялось но уже отходят есть в которых наоборот пытаются прийти есть разные А по поводу этого да D и тоже тоже расскажу но давай может быть начнём по порядку обратную связь Да соответственно мы начали про многопоточность есть некоторые нюансы там ну чувствовалось что недостаточно
00:51:13 - 00:52:56
практики Да немножко поплавал в ответах в то же время про Локи отлично рассказал Однако про профилировщик скажем так хватило полного ВМ про профилирование и про проф который встроенный Да здесь можно было там дальше уже пошл чуть-чуть про профилировщик запросов например вот чтобы понять как у нас в процессе запроса к базе данных всё происходит там индексы сказал что прямо вызываем планировщик запросов и осматриваем а то есть как у нас идёт поиск где просаживается то есть примерно такая фраза была возможно выпал не услышал Прости
00:52:07 - 00:53:53
если так вот а про ddd дальше Да тоже немножечко не хватило вот тут же про ивент сорсинг э ивент сорсинг в целом это такая концепция когда мы объект храним не в виде какого-то статичного набора элементов там например у нас пользователь Окей баланс пользователя Да самый такой наверное стандартный пример А изначально он у нас был нулём потом пришли деньги он стал там плю 400 руб потом стал не знаю 350 потратил стало -350 то есть У пользователя в обычной концепции обычной методологии у нас будет просто объект баланс и у него
00:53:11 - 00:54:40
будет написано 50 руб это в стандарте в инсорсинг у нас будет баланс и будет написано 0 П 400 - 350 и мы сможем По вот этой вот хронологии понять какое сообщение Какой сейчас текущий статус Какое состояние у нашего объекта вот а то про что мы вот видишь да получается вот получив эту обратную связь немножко я не то разуме пон и вот про что я и говорил то есть когда ты её сразу получаешь ты хотя бы после не ссылается на этом ложном ключе вот здесь согласен проигры здесь Да мне наверное надо было тоже чуть пораньше
00:53:56 - 00:55:35
вот эту обратную именно про обратную связь дать про что ты говори ты говори соответственно ВС Понятно Я транслировал в архитектуру и бы ВС нормального надо познакомиться по Дета я вот По примеру твоему Понятно Я в принципе на такое натыкался Но более живого так скажем более полного примера не читал не углублялся в этот он довольно ограни используется но Вот про чтение больше чем записи здесь у тебя есть очень классная такая вещь что ты отвечаешь исходя из своего опыта сразу же там Если можешь на вопрос
00:54:46 - 00:56:27
приводишь какие-то примеры своего опыта что вот у меня было Вот так мы делали вот это очень круто показывает что чеп больше наверно с такой Западной точки зрения да то есть там США и может быть в Европе где-то там сиру нельзя отвечать на вопрос грубо говоря что вот если у нас есть проблема X то мы используем инструмент Y это просто тебя закапывает мгновенно потому что в одной ситуации Ты должен использовать Y в другой ситуации Ты должен использовать Z в третьей ситуации там ещ что-то вот в некоторых
00:55:43 - 00:56:57
ситуациях комбинацию или там какое-то в таком случае одно в другом другое вот и когда ты говоришь что там обычно у нас чтений больше чем записи Ну нет далеко не во всех проектах такое не во всех согласен да но видишь ты привык к этому привык к такому подходу привык с ним работать и ты сразу же просто сказал что вот в этом проекте у нас будет Вот так хотя там ничего про это не написано Да но мы уже исходим из таких предположений и соответственно согн Ты кстати не первый кто меня на этом ловит то есть есть такие истории
00:56:26 - 00:57:38
которые у тебя почему-то где-то отпечатывается и ты автоматом подсовывает в ТЗ которых там на самом деле нет и это ну не всегда хорошая история и бывает что ты делае именно оговорки не позии того что вот этой привычки если тебя поправляют то ты сразу так Ну да да да и раскрываешь более глубоко так скажем более обширно но есть такая история Да соглас здесь ещё смотри на самом деле это тоже зависит от компании потому что например в индийских компаниях чтобы стать синем прой на соседова чается вот в России чуть-чуть
00:57:04 - 00:58:42
посложнее Однако вот те вопросы там тоже недавно штудировать по-моему или на ри было написано что там кто-то спрашивал Подскажите какие вопросы задавать на собеседовании синьору по СИ шарпу вот один парень привёл в пример что говорит Вот мы у себя сеньоров Тестируем вот так ему второй отвечает что извини но это как бы как как максимум на медла только тянет вот такие вопросы То есть это и от компании зависит и от место от вообще страны в целом таких подходов более глобальных но в идеальном случае да сир
00:57:57 - 00:59:07
он не должен сразу же предлагать какое-то своё решение потому что он его знает потому что он с ним работал это очень явно было видно на три проекта для каждого сервиса Ну то есть сразу же вопрос а Всегда ли это справедливо Действительно ли это нужно воз нено скам Ну то есть в каких-то Ключах Я согласен с этой формулировкой нельзя сразу предлагать А вот конкретно в этой ситуации но так получилось что это не просто так скажем А какой-то вот я с этим работал и так и буду делать я на тему архитектуры Ну
00:58:32 - 00:59:59
достаточно часто бывает размышляю Я всегда в поисках какой-то интересной архитектуры и вот э история которую к сожалению придумал не я Я там лишь некоторые концепции под внс она меня Настолько зацепила и я считаю что это прям какая-то одна из лучших вариаций я пока лучше не видел я всегда открыт к тому чтобы кто-то показал Но пока я лучше не видел подхода который позволял бы вот слабо связано действительно об сви льно закрывать типовые задачи там то есть очень много можно вот трудовской части и так
00:59:17 - 01:00:50
далее закрыть типовыми запросами какие-то написать в прото файлах общий и поэтому как бы я так смело предложил что вот три проекта и так далее Потому что действительно считаю что это одно из лучших вариантов согласен Тут даже спорить не собираюсь Да не планирую это очень классный подход для тех задач которые ты уже привык решать вот но например если мы поговорим про какой-нибудь Вот мы с рассматривали систему в которой были продукты в которой были заказы и склады вот есть блин вылетел из головы до сих пор не
01:00:03 - 01:01:38
вспомнил В общем есть система на которой можно shopify во на котором можно создавать свои интернет-магазины и продавать товары на этой системе у нас Я не знаю там в сутки могут Ну утрированно очень так из головы миллионы товаров создаваться и За день За один день миллионы товаров соответственно создани вот этих вот товаров У нас очень много И порой нет необходимости Ну мне вот сейчас лично не видится вообще никакого такого случая примера необходимо было бы в виде jpc в виде такого вообще rpc то есть проду Call
01:00:51 - 01:02:14
вызов который синхронный идёт создавать какой-то товар вот мы всегда можем сказать пользователю Окей Мы тебя услышали товар создастся через там 5 минут вот ну или как создастся Когда создастся приходи позже Вот то есть это всё можно было перевести именно в MQ Да вот тут я пытался тебя как раз вывести толкнуть на такой момент что не всегда и не везде нужно сразу же rpc впихнуть Же принципы которые ты преследуешь Я говорю я всегда буду Ну то есть Возможно если мы будем оценивать действительно там
01:01:32 - 01:02:55
какую-то нагруженность позиции того кто нужен для сопровождения и так далее возможно здесь эта история проиграет с позиции того что на более высокоуровневым для поддержки Там либо для хостинга но с позиции обеспечить максимальную говорю производительность отклик Ну то есть я всегда за вот это то есть максимально быстро надёжно чётко Ну смотри вот представим что у нас опять же тот же самый shif и создаётся миллионы вот этих вот товаров один сервис у нас вполне скорее всего не выдержит такой нагрузки нужно будет
01:02:13 - 01:03:41
больше сервисов Как как в такой ситуации жить что делать с др доводить больше НСО А как раутио взаимодействие между друг дружкой когда они напрямую будут пытаться ходить Ну ну вот в шлюз пришло что-то да хотим создать товар у нас есть три сервиса которые умеют создавать товар Ну то есть три копии одного и того же сервиса я понял так скажем в эту сторону я сильно глубоко не копал но в моём понимании можно всё-таки вкрутить какой-то промежуточный баланс который будет понимать какой сервис Какая нода больше
01:02:57 - 01:04:31
загружена и отправлять туда и у нас появляются дополнительные сложности которых можно было бы избежать если бы это делать асинхронно И вот мне казалось что как раз когда ты отвечал на вопрос Ты сказал что лучше всего если что-то есть возможность сделать асинхронно то лучше это делать асинхронно ну с одной стороны да но с как бы это да это Абсолютно верно и я действительно такое произносил но с позиции Ну я немного в другом ключе это использовал Аа просто за асинхронность тоже в определённом ключе надо чем-то платить
01:03:46 - 01:05:07
то есть если мы говорим что мы асинхронно создаём товар то нам немножко надо более детально проработать вот эту экосистему как я уточнил Ну то есть какие-то статусы промежуточные какое-то вот взаимодействие с пользователем что Дада Мы это сделаем но Мы это сделаем ээ за какое-то время ты подожди Да полностью согласен Вот ну и здесь тоже наверное уже знакомый нам всем момент что ты произнёс враз такой классный пользователь чаще всего хочет И вот как как это человеку который несколько погружён в продакт
01:04:34 - 01:05:53
менеджмент не можешь ты говорить Ну я или там программист или ещё кто-то из сам продакт менеджер за пользователя право имеешь только вряд ли ты будешь Даже те кто выдвигают прям реально какие-то гипотезы по проверки маркетологи и прочее продук то не всегда имеют право такой фразой располагать могут там действительно кто-то успешный когда там у тебя проект который там Все думали что не может ты сказал пользователь так по крайней мере в рамках этого проекта точно имеешь право так говорить Ну да да показать свою экспертность но
01:05:13 - 01:06:41
согласен абсолютно плохая фраза паразит которая у меня тоже часто проскакивает но абсолютно верное замечание и хочу заметить другую фразу которая прям очень классная у тебя была фраза не паразит зависит от ситуации то есть вот в самом начале ты Отвечая на теоретические вопросы прям сказал что вот можно сделать так можно это но зависит от ситуации и вот это как раз-таки именно то чего требуется от синера То есть ты должен сказать что нет там нет какого-то единого Серебряной пули потому что я уже знаю Я уже там
01:06:01 - 01:07:12
собаку съел на этом в одной ситуации нужно одно в другой другое Поэтому Давайте определимся что у нас за ситуация и что здесь именно Нам подойдёт вот потом про Согласен Это такой самый правильный ожидаемый подход от синдра но выдерживать логику весь день не всегда получается и часто мо пытается увести в стандартный тебе привычный контекст Да согласен Есть такое у всех есть мне кажется Ну может у большинства е не у всех про разделение на машины то есть там про многопоточность Я спросил да как можно избавиться от многопоточности ты
01:06:37 - 01:07:58
говориш ну зачем многопоточность на одной машине давайте мы просто их на разные машины раскидаем на разные процессы приложение и пусть они каждый по одному делают А что Вполне себе решение Вот так микросервисы работают например мы не нагружая один всем всем всем создаём кучу инстан сов и каждый занимается по чуть-чуть обще одним общим каким-то заданием вот помимо этого было много примеров из опыта тоже в плюс Да и про D Мне понравилось тоже я у тебя спросил ты сказал что Ну не особо с ним знаком и
01:07:18 - 01:08:32
потом продолжил что но на самом деле Вот я считаю вот так вот это вот это прям очень классно То есть ты не оставляешь такую негативную информацию в конце то есть если ты просто отвечаешь что я не знаю я с этим не работал и замолкает это очень плохо Вот лучше если ты чего-то не знаешь опять же как говори желательно в начале сказать из ключа негативного а потом вс-таки постараться закрыть на положительно потому что поменяв одной и другой местами всё равно всегда человек склонен запоминать послед есть такое ну говорят начало и
01:07:54 - 01:09:34
конец а середину там можно менять Как хочешь Как показывает практика и тоже может быть про Давай дальше про sec пате Мне очень понравилось тоже как-то ответил Классно Мне очень зашло Я не знаю вот тут тебя тоже хотел спросить ты смотрел говорил же что видео предыдущее и когда задание я тебе скинул ссылку ты его начал читать вслух ты обычно это сам делаешь или пос видео сго вижу не в формате Ну по крайней мере в рамках интервью я вижу их чаще всего в виде кода а не в виде какого-то ТЗ и давай как-то
01:08:43 - 01:10:15
проработаем какую-то архитектуру то есть в этом случае я чаще всего код именно всегда зачитывал но как бы триггером что действительно надо зачитать именно в слух текста я вс-таки подчеркнул это из прошлого и в целом согласен с тем что читая слух оно как-то малость попроще воспринимается ты не чувствуешь вот эту саму нагрузку тишины когда грубо говоря ты читаешь и ты не понимаешь ты долго читаешь или недолго нет вот этой какой-то до психологической момен чувствовалось что ты не очень вроде как привык к этому но ты это
01:09:36 - 01:11:10
делаешь и у тебя это хорошо получается вот и наверное последний такой тоже момент это то что ты изначально когда прочитал задание ты всё продумал ты всё рассказал как это должно быть и только после того как ты уже всё рассказал проваливался ты начал писать архитектуру записывать то что ты проговорил словами Вот это очень здорово Да вот такие нюансы такие примеры Спасибо Слушай это на самом деле очень крутая обратная связь то есть я на самом деле рассчитывал на что-то более меньшее Но действительно это прям крутая
01:10:27 - 01:11:51
обратная связь именно как у полноценных интервьюеров когда какую-то такую скидки типа ну человек же действительно там не ищет там работника себе вот там под какой-то проект это ну там какие-то нюансы опустится и так далее что-то может быть не заметите Но у тебя вот классный Скил вот этого ну то есть прокаченный Может быть связан преподавательский опыт ещё что-то Но действительно ты даёшь классную обратную связь и очень много вещей замечаешь и успел зафиксировать их при этом и действительно мне это будет полезно
Расскажи пожалуйста почему ты ищешь новое место работы в моём случае всё крайне Просто мой текущий проект попадает под заморозку и поэтому мне пришлось выйти на рынок и осмотреться чего же есть ещё и найти себе какой-нибудь новый проект который бы меня чем-то зацепил и захотелось присоединиться к его команде И развивать Какие проблемы можешь назвать которые могут возникнуть при использовании по точности и как избежать ну одна из типовых проблем Когда у нас есть данные которые надо разделять между потоками то
00:00:00 - 00:01:22
есть при взаимодействии надо учитывать чтобы эти данные поменялись корректно и не прочитали из другого потока некорректно для решения этой проблемы есть класс илов примитиво синхронизации и так далее Ну ещё там логики То есть когда мы не просто по в то что данные некорректные А когда мы сталкиваемся с тем что мы обеспечили какую-то защищенность данных критической секции кода но при этом встали в делок из-за того что всем нужны эти данные Но кто-то их не отпускает как бы ты предложил избежать дело чаще Это надо именно
00:00:41 - 00:02:02
смотреть на код в основном делок у нас возникает по причине какой-то грубо говоря ошибки программиста когда мы в каком-то из случаев вышли из критической секции но не освободили ресурс Ну а второй частый вариант это когда у нас критическая секция выполняется на самом деле Достаточно долго скажем простой совет как его пытаться избегать избегать ошибок и пытаться делать крайне маленькие операции над данными ческой секции чтобы эти операции проходили как можно быстрее и освобождали для других а помимо этого
00:01:21 - 00:02:42
Какие можешь ещ посоветовать способы избегания таких проблем с многопоточность Как вариант вообще отказаться от многопоточности Нам же не обязательно всегда на одной машине обрабатывать все данные тоже будет параллельно обработка мы Для чего делаем многопоточность да чтобы приложение стало более производительным Был ли опыт какой-то у тебя по оптимизации можетли проводите действительно есть в памяти что мы протянули Но необходимо всё это дело Прочитать то есть где-то что-то просуммировать и там делились данные
00:02:02 - 00:03:16
действительно параллельно несколько потоков Ну использовались соответствующие классы в том числе там класс позволяющий разделить входящий массив между потоками То есть он сам каким-то внутри механизм хитрым нарезал на определённые куски отдавал разным потокам чтобы они не пересекались А как это следили вот сам процесс этого нарезания как оно в процессе работает оптимально не оптимально Может там что-то поть надо было профилировщик может быть какие-то Ну в профилировщик да бывало отслеживали но конкретно вот
00:02:42 - 00:04:05
эту ситуацию здесь уже не отслеживали то есть сам профилировщик применяли на изначальном этапе что действительно у нас там к примеру полно ресурсов но мы данные молотим молотим а э время там к примеру мы до каких-то оптимизаций все эти даные там молотили условно час а в одном потоке покойно А и получалось что мы вот видели что у нас там нагрузка на процессор там какая-то смешная условно 15% а оперативки тоже свободно но данные при этом быстрее не обрабатываются и вот как раз профилировщик подбирали количества потоков и так далее
00:03:23 - 00:04:56
но там после всех расчётов и оптимизации мониторинга мы пришли к тому что прямо брали служебную переменную то есть от машин Сколько на машине ядер сколько вот стандартно предлагает нам использовать потоков среда фреймворка соответственно мы столько и давали и у нас нагрузка действительно была процессор 100% но он отвал эти данные уже за 15 минут Супер А если не про само приложени говорить например про оптимизацию запросов в базе данных там сервисного какого-то взаимодействия был опыт был соответственно Ну тут Если мы будем
00:04:09 - 00:05:32
говорить про какие-то более старые версии достаточно Мне кажется сложно раньше было Вот это всё отследить оптимизировать с позиции того что к примеру Лично я ловил запросы прямо когда работал с майкрософта ской базой в их мониторе Ну профилировщик тоже таком же отлавливать подключался отдельным пользователям чтобы легко было отфильтровать Ага всё вот такой запрос сгенерировал туда Не туда современной версии к счастью и позволяют и в отладке увидеть чего там наге нери посмотреть запрос понять о даже на визуальный
00:04:50 - 00:06:15
взгляд оптимальный нет и потом соответственно если мы там визуально не видим явно к чему докопаться А всё равно заработает медленно всегда можно уйти на сторону базы данных посмотреть её планы запросов как она там чего гуляет и понять Надо ли там нам индексы прикручивать какие-то Надо ли переделывать структуру данных где там у нас проседает пате проектировать такой додин знаком знаком но так скажем вживую я его не видел кроме как в теоретических статьях и подходах всё должно чётко читаться то есть мы не
00:05:38 - 00:07:00
просто там программируем и обзываем там наши методы какими-то выгодными названиями это долж быть названия связа с областью под которую мы пишем то есть они должны чаще всего делается какой-то словарик садится с бизнесом обсуждается что вот у нас есть существуют такие-то понятия и вот в рамках этих понятий наш код достаточно легко читать и понимать взаимосвязи и в рамках доменной области в которой мы работаем а как насчёт такого паттерна как инсорсинг Знаком это паттерн отвечающий за то что мы взаимодействуем по событиям То есть у
00:06:19 - 00:07:44
нас существуют какие-то события которые происходят в том или ином месте и мы их каким-то образом обрабатываем то есть у нас код не жёстко связан что вот у нас такие-то и такие-то действия а у нас есть события которые могут обрабатываться в одном в нескольких местах то есть мы можем выбросить события что у нас создался покупатель в этот момент соответственно всех кому надо кто подписан на это события отработают его и там не знаю к этому покупателю зарегистрирует там виртуальный аккаунт в банке к этому
00:07:02 - 00:08:21
покупателю там создастся к примеру промоакция для новых покупателей и так далее а такая аббревиатура как cqrs знакома Да тоже знакома и соответственно она больше про то что мы должны чётко разделять для запросов которые на чтение и для запросов которые на изменения и запросы на чтени мы можем максимально оптимизировать там где-то сказать что они там условно либо почти не меняются либо ещё что-то но оптимизировать сам путь запроса меньше делать каких-то валидации проверок и за с этого ускорить производительно
00:07:42 - 00:09:13
более детально всё валидировать ой иначе не на запись более детально всё валидировать и записывать понимая что записи там у нас происходят реже чем чтение и соответственно когда мы записываем Мы можем потерять немножко времени но обеспечить большее качество А на чтении нам важно как можно быстрее дать результат такие у нас подходы в основном используется в микросервисной архитектуре Что такое микросервисы можешь подсказать микросервисы - это так скажем такая штука которая позволяет разделять какую-то функциональность в
00:08:30 - 00:09:58
рамках Ну то есть у нас есть большое приложение условно там большая доменная область как раз что не знаю Ну вот также покупательская платформа какой-то пожалуй и в рамках неё могут существовать микросервисы отвечающие за конкретный функционал что позволяет сужать во-первых объём кода во-вторых позволяет эти микросервисы писать разным людям разным командам даже на разных языках при этом всём существуют механизмы взаимодействия между микросервисами Ну и главное оно позволяет именно раздеть логику и чем
00:09:13 - 00:10:45
меньше бизнес логики в одном микросервис и она при этом связана по одной тематике чётко мы Когда понимаем эту связанность нам проще работать и меньше шансов что мы допустим ошибки и окажем какое-то влияние на другие части кода Окей это получается такой положительный момент один а какие ещё есть положительные и отрицательные моменты у микросервисов Ну вот из положительных ещё раз я проговори на всякий случай То есть то что мы позволяем работать там раздельно людям не заморачиваюсь сильно не конфликту у нас меньше шансов что задачи
00:09:59 - 00:11:29
какие-то параллельные у людей заблокируют друг друга У нас есть возможность нанимать разные команды на разных языках для поддержки и реализации того или иного микросервиса У нас вот есть чёткая связь по логике По функциональности меньше шансов чего-то сломать Но с другой стороны Да всегда за за что-то хорошее надо чем-то платить и у нас появляются как раз сложности взаимодействия то есть нужно продумывать правильные механизмы для взаимодействия между микросервисами продумывать какие-то общие библиотеки продумывать надежность этой
00:10:46 - 00:12:16
истории потому что у нас часто в работе всегда используют Ну не всегда А часто именно используется подход транзакционный То есть когда нам надо гарантировать что чего-то пройдёт от сих до сих и вот если целиком прошло тогда мы это зафиксировали Если нет то нет И вот когда мы говорим про микросервисы э история сильно усложняется проблематика э структу есть е надо поддерживать каждый микросервис Да действительно должен друг друга видеть у них должна быть какая-то общая сеть ещё что-то то есть надо много нюансов учитывать при
00:11:30 - 00:12:55
поддержке этой структуры супер и Давай с тобой перейдём в есть основная задача это работать управления мивиной архите поз получается сервис для управления информацией о продукто обновления То есть со стандартным потом инве сервис для управления состояния складом количество продуктов рования ор сервис для управления заказами создать заказ лата gway который единая точка для входа так и механизм обмена о Ну ты знаешь ты как-то попал в эту в плюс-минус мою область то есть немножко такое у меня и есть Так
00:12:13 - 00:14:20
что давай пройдёмся поэтапно по каждому то есть давай во-первых хорошо у нас есть чётких три микросервиса соответственно пожалуйста мы выделяем эти три проекта которые Ну в нашем случае мы там не будем пользоваться какими-то достоинствами что они могут быть на разных языках и прочем всё будет наша пожалуйста и Ну вот мне понравился подход завен на мом проек микросервис у меня Пусть будут в основном их функционал описываться профа то есть в рамках микросервисов будет заш grpc общаться Они между собой будут
00:13:21 - 00:15:00
Соответственно по grpc со шлюзом они будут общаться также по jpc и соответственно шлю уже будет действительно у нас единой точкой входа которая так скажем отдаёт результаты и позволяет получить в единой структуре доступ куда нам надо не знает Так скажем какой сервис за это будет отвечать а может быть несколько сервисов такое тоже вполне возможно и получается механизм обмена сообщениями между сервисами пример с использованием предлагаю здесь так скажем применить библиотеку абстрагируясь применить ма
00:14:11 - 00:16:08
Транзит у которого транспортом Ну может вполне быть Т но теоретически и технически может быть абсолютно любой другой транспорт который также подключается совестно чего нам надо бы написать так ну в рамках фидлера Я не знаю насколько мы можем опуститься в какую-то глубину но у нас соответственно здесь проекты там можно создавать скорее всего нельзя и класс сильно не разгуляе ну из того что я озвучил соответственно нам нужны минимум три проекта для каждого сервиса По какой причине Объясняю В одном проекте у нас будет вся
00:15:10 - 00:16:53
бизнес логика в том числе там какие-то модельки какая-то живучая живу логика работы внутри с базой данных и соответственно логика взаимодействи с другими микросервисами синхронно ели это у нас взаимодействие с другим микросервиса Возможно асинхронным мы воспользуемся а механизмом обмена сообщениями то есть здесь можно как раз применить денсон то есть в рамках событий мы будем забрасывать какие-то сообщения в очередь которые события соответственно у нас будет потреблять другой сервис вот так и соответственно у нас
00:16:07 - 00:17:48
первый проект Вот это всё содержит второй проект содержит какие-то абстракции необходимые То бишь это у нас э к примеру как раз-таки описание событий которые мы можем а ловить из других сервисов и обрабатывать А и второй момент какие-то действительно общий абстракции ну к примеру перечисления какого-то вида и получается третий проект - это проект клиента кото через которого мы будем взаимодействовать с этим микросервисов микросервис которых у нас три штуки но сервис сервис о сервис с три проек проек
00:17:01 - 00:18:52
будут суффиксы Первый проект с суфикса содержит логи реализуемую микросервиса второй акции для коммуникации с другими сервисами и шлю рети крое ле сервисом и с шлюзы и других проектов которые не будут использовать jpc на Прим я вот так соответственно немножко про структуру поговорили вот в основном проекте у нас будут необходимые модели для взаимодействия с базой данных также рация базы данных игра Так чего ещё там будет самые главное там будет логика взаимодействия об этом бы выше прописано в вания печатки Ну суть Я думаю
00:18:44 - 00:21:43
понятно да это можно не обращать внимания Ну пока остановимся не будем дальше копать сильно сервисы взаимодействи другом так и так Маст се которым может являться rit MQ Пусть по умолчанию выявляется умолчанию и будет использовано само взаимодействие происходит как я уже сказал через события так хотя не только сервисы взаимодействи и Чере J вызовы сервиса асинхронно через события и их консьюмер люс люс а-а реализует механизм доступа к механизм для взаимодействия более общепринятым особенно стороны
00:21:31 - 00:24:20
фронта у нас кстати ничего не сказано ВМ пороше нуж какая-то валидация в люм с есть у где-то должен быть обязательно какой-то сервис для валидации и аутентификация тут у нас может быть как стандартно прирученный какой-нибудь ин сервер нос на маленьких проектах использу сто и облачные решения какие-то для закрытия этой истории то есть на память название не скажу но есть популярное решение которое в принципе вот я так по документации смотрел копал оно очень сильно схоже с идентити сервером но так скажем я не
00:24:18 - 00:26:13
удивлюсь если внутри он и лежит но кастомизированный но с нагрузками определёнными но я про то что обязательно у нас должен должна быть какая-то авторизация и аутентификация соответственно шлюз у нас должен приходить тон по которому мы Валиди что он вообще действительный что он живой по времени валидации и так далее потом разбираемся кто нам пришёл с какими полномочиями Ну условно говоря там Покупатель не знаю работник склада Кто у нас ещё Т может быть продавец который продаёт товар и так далее То есть в зависимости от этого
00:25:24 - 00:27:14
тоже море Като логику срезов Какие кому данные отдавать до каких методов микросервисов пускать кого не пускать Ну и в самих микросервисах желательно всё равно какую-то валидацию минимальную предусмотреть но уже не настолько так скажем заморачиваться потому что как мы говорим шлюз у нас Центральная точка входа и всё что внутри микросервисов особенно если микросервисы все делает одна команда мы где-то там друг другу доверяем всё равно и э совсем фигни не натворит но опять же вот надо исходить из контекста если микросервисы ведут
00:26:25 - 00:27:49
разные команды которые может быть даже с разных городов с разными тайм зонами тут Надо чётко понимать что надо тогда любой jpc запрос детально валидировать и не пропускать фильмы Угу чего ещё мы тут должны уточнить Ну вот конкретика решения какая-то такая Давай наверное пойдём по уточняющим вопросам то есть чего не хватает для понимания сам код мы явно писать не будем это слишком много долго Ну и средствами фидлера мы это не обыграем Угу Согласен у меня такой вопрос тогда уточняющий Зачем нам одновременно и jpc
00:27:08 - 00:28:44
и rit MQ Ну вот как раз то что я проговорил синхронно и асинхронное взаимодействие если мы можем какое-то действие сделать асинхронно Зачем воровать время на ответ и выполнять его синхронно Когда мы можем бросить события и обработать его даже не факт что одним сервисом мы можем действий сделать в рамках нашей системы разными микросервисами асинхронно которые там явно не не нужны пользователю Ну вот прямо сейчас условно если он проходит регистрацию там создали мы пользователи ему не факт что прямо
00:28:00 - 00:29:39
сейчас не знаю промоакция ещё что-то может быть мы там после создания ему какое-то интро проводим и за это время мы спокойно хроно всё до создали Ну а вот применимо к нашим текущим трём сервисам Где бы ты применил синхронные методы вызовы А где асинхронные А давай да давай посмотрим на эту историю А у нас есть добавление удаления обновление списка товаров Ну вернее информации о них количество продуктов на складе резервирования и создание заказ вот ну при создании заказа нам чаще всего надо взаимодействовать более-менее
00:28:49 - 00:30:24
синхронно со всем Потому что нам в момент создания заказа надо сразу пользователю сказать Дада мы под тебя зарезервировать товар этот товар действительно есть у нас ты там не пытаешься заказать то чего нету в принципе в системе то есть здесь скорее всего синхронно в соседний сервис когда мы говорим про Так давай посмотреть где мы асинхрон явно можем применить Ну вот к примеру мы добавляем товар либо удаляем товар мы удаляем информацию о товаре То есть в принципе мы можем не синхронно удалять также
00:29:38 - 00:31:10
информацию о том что этот товар У нас есть на складе в таком количестве там его чего-то там зарезервировать и так далее а сделать Это непосредственно асинхронно но при этом надо учесть что будет не совсем правильно и корректно удалить товар сразу по крайней мере без какого-то к примеру изменения что товар скрыт в начале в случае если у на зарезервирован То есть у него есть активные заказы мы там ещё не завершили лоу этого товара поэтому скорее всего Нам надо сходить в начале синхронно и проверить какой-то минимум то есть там
00:30:31 - 00:31:47
действительно товар не находится в данный момент в работе там к примеру ещё что-то а потом уже удалить информацию и создать события об удалении товара которое соответственно при обработке удалит всю информацию со склада име каким-то образом делим либо ещё чем-то что всё нам эта информация не нужна и она не актуальна так такого товара больше не существует на витрине заказах Угу Окей Итого мы по всем прошлись да или нет вроде ещё Да вроде да то есть мы можем копаться в примерах синхронного асинхронного взаимодействия ещё больше
00:31:09 - 00:32:43
то есть их можно тут больше сильно приводить Но вопрос Действительно ли нам это надо Если надо мы можем ещё покопаться нет нет не надо Давай мы пробежимся вот по этим методам раздельно и посмотрим какой бы ты сделал синхронным какой асинхронным то есть прямо вот подпишем Вот здесь например в скобочках там асинхронный Ну смотри То есть я бы вс-таки как вот мы сейчас обсуждали на методе удаления не ограничивался чётко что вот это только синхрон или только асинхронный я бы просто помел где возможно добавить какую-то асинхронность
00:31:59 - 00:33:15
потому что асинхронность всё равно должна быть и что какие-то операции Мы выполняем всё равно синхронно и вот как при удалении сказал что мы можем синхронно сделать какой-то минимум проверить что у настльно можем спокойно удалять Давай действительно помет внем Но это будет означать не просто что выполняется асинхронно том что в НМ есть какая-то асинхронная изюминка которую дела Давай давай предложу немножко перечить нашу Легенду Давай будет PC Давай попробуем Говорю Вполне вероятно что у нас часто будет И то и другое вместе
00:32:40 - 00:34:23
взят Смотря какой сценарий мы Придумай Ну соответственно давай ну вот к пример прямо по создали мы этот товар синхронно в рамках нашего сервиса соответственно нам об этом синхронно уведомлять кого-то не надо но можно уведомить вот Да действительно асинхронно То есть через т сервис складов к примеру чтобы там не обрабатывать когда мы получаем информацию о товаре условно какие-то что товара в принципе нет на складе значит у него нулевые оста остатки А чтобы у нас красиво создалось что да такой товар существует в рамках
00:33:39 - 00:35:11
склада мы понимаем что он есть но у него сейчас количество на складе нулевое зарезервировано у него ноль штук а соответственно удаление то есть вот здесь уже сложнее то есть здесь у нас должно быть как мы проговаривать уже и синхронное и асинхронное взаимодействие то есть мы должны можно можно те на минуточку рву как мы это должны представить в виде сервиса то есть сервис одновременно делает и запрос по jpc и в очередь ещё отсылает что-то да именно так тем как перед тем как товар удалить то есть
00:34:37 - 00:36:06
в рамках логики валидации какой-то делаем Запрос к сервису складов ус спрашиваем У тебя этот товар зарезервирован он есть на складе и так далее если мы получаем что Да действительно товар исправный товар там не зарезервирован соответственно может спокойно зачищать мы говорим что да Всё мы поем товар под удаление либо даже пря сразу удаляем и вс хорошо мы товар Удали если же товар к примеру зарезервирован мы говорим что по нашей текущей логике к примеру зарезервированные товары нельзя удалять потому что они вот сейчас ещё в
00:35:23 - 00:37:01
работе и по ним могут быть какие-то действия поэтому мы отвечаем пользователю Извини Мы товар не можем удалить но там к примеру если ты хочешь его скрыть С витри Е чтото ровал пожалуйста Воспользуйся функцией обновления и измени там статус твоего товара что он к примеру скрыть Угу И когда мы вот эту логику сделали то есть когда мы вернули пользователя когда вернее мы удалили товар мы можем в этот же момент асинхронно выбросить сообщение в сервис склада и сказать ему ты знае мы удалили этот товар ты можешь у себя
00:36:13 - 00:37:47
зачистить информацию по этому товару то есть она больше не нужна угу угу Согласен полностью согласен Давай немножко минимизируем наш скоуп то есть будем рассматривать вот наш сервис продукт сервис Да как AP некоторое и соответственно он предоставляет нам четыре функции добавление удаление обновление и получение списка вот в сервисе как реализовали добавление то есть мы сигнал Да команду на добавление мы принимаем по rpc по или и так и так сигнал на добавление мы принимаем соответственно точно по
00:37:00 - 00:38:31
grpc То есть у нас тут Ну то есть до немного в другом ключе Я размышлял но если мы именно ЧМ мы принимаем сигнал в принципе на любой из вот этих историй мы сигнал принимаем по ну к примеру даже от того же шлюза то есть от шлюза Мы всегда так или иначе сигнал примем по потому что чаще всего со шлюза к нам приходит Запрос который на который пользователю надоть сказа это десте сде что это будет отложенное действительно асинхронное действие там к примеру что мы там запустили какой-то расчёт вернуть пользователю синхрон
00:37:45 - 00:39:25
ожидай то есть в моём понимании сигнал который приходит в микросервис он всегда придёт по grpc Чаще всего именно в рамках описанных э явно в ТЗ Угу А давай рассмотрим пример с удалением продуктов Да ты как раз про него уже рассказывал что мы например можем пойти в inventory Service и спросить есть ли что-то зарезервировано или нет Есть ли что-то у нас там с заказами например вот количество и так далее это сервис идёт делает что-то долго Ну представим что у нас там проверка резервирования продуктов может
00:38:39 - 00:40:01
занимать 5 минут Да нужно ли на Ну вот тут Да очень важен контекст именно кто как мысли и в каком контексте потому что вот в моём понимании именно Проверка резервирование как таковая должна проходить достаточно быстро возможно вот удаление информации либо там ещё чтото может проходить дольше там к примеру во время удаления там мы на самом деле должны ещё не просто там удалить запись о том что на складе есть отправить уведомление там Подготовь вот такой-то товар Перенеси в такую-то секцию в товары которые мы больше не
00:39:20 - 00:40:48
продаём отправить письмо поставщику что там Заберите ваш товар со склада и так далее Ну какой-то вот длительный Фло может быть а когда мы говорим проверить просто резервирование должно быстро проходить но если мы отталкивается от ТЗ что ты даёшь Что у нас соответственно резервирование продукта - это то Что проходит Достаточно долго ну к примеру вот было приведено 5 минут это достаточно долго тоже с моей стороны то есть в этом случае Да можно а это сделать асинхронно И сказать что Да мы вроде как товар пометили под
00:40:04 - 00:41:22
удаление Ну тогда тут надо обыгрывать именно статусами в продакт сервисе корректно чтобы мы не сказали пользователю что да мы твой товар удалили а потом вдруг не удалили то есть надо вводить какое-то промежуточное состояние что да мы действительно пометили товар под удаление он уже там скрыт с витрины но мы сейчас проверяем Действительно ли мы можем его удалить через какое-то время мы тебе скажем точно что мы товар либо удалили либо Извини он остаётся скрыть он ещё задействован где-то в чём да да
00:40:43 - 00:42:00
Супер давай вот наверное последний такой вопросик добавление Да мы сделали его через jpc ты сказал что нужно обязательно давать сразу клиенту обратно ответ добавили мы товар или нет продукт А в чём вот такая бизнес необходимость именно сейчас получить почему мы не можем это сделать через rit MQ а но чаще всего это связано к примеру с тем что во-первых пользователь чаще всего хочет сразу получать какой-то результат ну у на нет каких-то явных технических сложностей которые мы не можем обыграть Я придерживаюсь всегда концепции что чем
00:41:21 - 00:42:51
U отзывчивый напрямую завязан нак для своей отзывчивость чем отзыв тем пользователю приятнее тем меньше вероятность что пользователь помм к примеру что у нас товар который мы добавляем он должен отвечать там каким-то критериям То есть к примеру мы при добавлении товара проверяем что этот товар имеет там уникальное название или этот товар ю там чтото с сцену или он там прямо сейчас появится на витрине вот для всех этих историй нам желательно сразу выполнить запрос синхронно и сказать что да да мы
00:42:06 - 00:43:57
действительно добавили а не так что мы вот пытаемся добавить твой товар Ну ты пока мы добавляли там кто-то ещё создал товар с таким названием ты извини Вот твой товар меняй пользователь уже там Расслабился выпил кофе и ушёл по свои дела думаю о всё хорошо я создал товар приходит а у него ноль заказа Почему А у нас товар на самом деле не добавился Да не хотел бы оказаться на месте этого пользователя что-то из этого да да согласен О'кей спасибо большое Константин предлагаю на этом завершать э ощ а Ну
00:43:08 - 00:44:52
соответственно более-менее достаточно хорошо ощущение именно с позиции того что ну здесь в любом собеседовании Мне кажется всё равно есть элемент удачи то есть всегда могут попасть в ту область в которой ты более-менее подкован и менее подкован А вот в данном случае С практической частью тут даже не возникло какого-то диссонанса с позиции углубиться куда-то за области своих границ то есть так или иначе я обо всех вот этих вещах что мы проговорили рано или поздно уже думал либо как-то где-то вокруг до около ходил То есть это
00:44:02 - 00:45:41
был больше приятный разговор на тесть поразмышлять здесь может быть э хорошего чего нехорошего и так далее То есть и в этом плане тут я считаю вот элемент удачи он всегда присутствует и поэтому можно э сходить на 10 собеседований и на одном Тебя возьмут э и скажут да ты сверх профессионал а на к примеру пяти скажут Ты середнячок она и ещё двух вообще скажут какой-то пришёл Непонятно чего ничего не знает И чего вообще пришёл на собеседование на кого он претендует вот так что 100% э Тут есть элемент удачи всегда и
00:44:51 - 00:46:34
приятно когда тебе немножко везёт Ну это про практическое Да а теоретическое как вопрос те а теоретические вопросы в любом случае интересные вот Единственное не хватает какой-то явной обратной связи вот в реальных собеседованиях в принципе бывает та же самая история а то есть есть интервьюеры которые тебе действительно сразу дают понять что А да да Слушай ну нас ответ устраивает А давай ещё вот в эту сторону отойдём посмотрим вот в эту А вот по твоей реакции далеко не всегда было понятно То есть ты до конца раскрыл вопрос или нет
00:45:43 - 00:47:07
Или мы просто там переходим к следующему вопросу Потому что ты вообще там к примеру А рассказал базируясь на своём опыте какую-то историю но не попал в заданный вопрос и интервьюер такой ну это не туда не буду его мучить двигаемся дальше Вот вот э история и здесь Ну возможно надо было мне сразу так скажем задать тон с первых вопросов а сразу попытаться дёргать эту обратную связь то есть да да нет нет Угу здесь смотри формат да такой что я собираю всю обратную связь а потом в конце тебе её рассказываю чтобы не
00:46:25 - 00:47:49
сбивать тебя с ритма чтобы ты спокойненько рассказывал и отвечал на вопросы не прерываясь потому что для многих людей может быть для тебя это не так Я понимаю что ты очень такой открытый общительный человек но многие люди когда им скажешь там на первый вопрос ты ответил Хорошо ты говоришь хорошо Он на второй отвечает хорошо на третий вопрос он отвечает плохо ты ему говоришь Ну как бы Извини вдг на этот вопрос ты ответил плохо и всё и человек уже на четвёртый на пятый уже просто не может отвечать у него голова не работает
00:47:07 - 00:48:00
потому что всё он на третий вопрос ответил плохо и человек просто теряется он не может больше продолжать иногда даже просят там всё типа Давайте с вами закончим Я больше не могу такое тоже бывает Поэтому согласен такое бывает но здесь мне кажется именно решается По большей части опыта то есть у меня действительно такое тоже случалось Но именно когда ты нарабатывать э приятнее получать обратную связь сразу именно с позиции того что тогда ваш диалог кажется каким-то более живым и как будто Вы действительно не просто вот
00:47:34 - 00:48:51
там пришли закрыть сухую функцию про собеседовать А вы общаетесь с коллегами с профессионалами и обсуждайте какие-то насущные вопросы да да согласен здесь на самом деле если бы это было реальное собеседование всё было бы совсем по-другому ну лично у меня потому что у меня была бы обязательно цель у меня были бы какие-то критерии по которым нужно человек чтобы соответствовал чтобы прошёл ко мне в команду Вот и соответственно вопросы были бы построены именно с такой целью и там было бы Понятно Куда дальше двигать
00:48:14 - 00:49:21
и двигать ли вглубь не двигать насколько это вообще важно нам неважно есть у нас люди которые могут закрыть такие компетенции мо ВС пря совсем по-другому да согласен Есть такое в реальных собеседованиях Я даже это где-то Ну то есть когда проходило реальное собеседование где-то Я получал эту историю По обратной связи а где-то видел просто по реакции людей что там к примеру ты там в какой-то области плаваешь Но для них э область крайне важна из что вот этог бы зарыть Но вот это нам очень крайне важно в реальных собеседованиях есть
00:48:48 - 00:50:15
такой ключ тут его можно Как чувствовать так и не чувствовать опять же Ну и по теоретической части в любом случай то есть говорю некоторые вещи сейчас посмотрим что расскажешь по обратной связи некоторые вещ ты отвечаешь как чувству и иногда Уно говоря може что-то применять применять ежедневно там условно даже сталкиваться с этим названием но ты не акцентирует это прям такой-то Патер точка опять же про То есть я вот уточнил что я в Рем прося и дано именно с вот этой красивой семантикой что у нас есть и словарик и так далее То
00:49:32 - 00:51:18
есть вот этой красивой теоретической обр кой которую нам часто продают статьи это как скрам то есть если мы будем смотреть вакансии и так далее То есть там чуть ли не в каждой вакансии будет что мы работаем по скрам и так далее но выдержать все принцип Искра могла и я не встречал ещ ни одной команды которые сказали бы Мы прям без каких-то оговорок действительно вс всё прям по концепции ни шагу влево ни шагу вправо вот так иту потому что у нас вот даже говорю либо применяется специальная которая
00:50:32 - 00:51:48
заточена под эту историю и она вот сразу в себе несёт И пропагандирует что надо доно такой красивой вни вживую Я не видел Пока да да согласен ну Однако есть на самом деле тоже компании в которых это вживую применяется есть в которых применялось но уже отходят есть в которых наоборот пытаются прийти есть разные А по поводу этого да D и тоже тоже расскажу но давай может быть начнём по порядку обратную связь Да соответственно мы начали про многопоточность есть некоторые нюансы там ну чувствовалось что недостаточно
00:51:13 - 00:52:56
практики Да немножко поплавал в ответах в то же время про Локи отлично рассказал Однако про профилировщик скажем так хватило полного ВМ про профилирование и про проф который встроенный Да здесь можно было там дальше уже пошл чуть-чуть про профилировщик запросов например вот чтобы понять как у нас в процессе запроса к базе данных всё происходит там индексы сказал что прямо вызываем планировщик запросов и осматриваем а то есть как у нас идёт поиск где просаживается то есть примерно такая фраза была возможно выпал не услышал Прости
00:52:07 - 00:53:53
если так вот а про ddd дальше Да тоже немножечко не хватило вот тут же про ивент сорсинг э ивент сорсинг в целом это такая концепция когда мы объект храним не в виде какого-то статичного набора элементов там например у нас пользователь Окей баланс пользователя Да самый такой наверное стандартный пример А изначально он у нас был нулём потом пришли деньги он стал там плю 400 руб потом стал не знаю 350 потратил стало -350 то есть У пользователя в обычной концепции обычной методологии у нас будет просто объект баланс и у него
00:53:11 - 00:54:40
будет написано 50 руб это в стандарте в инсорсинг у нас будет баланс и будет написано 0 П 400 - 350 и мы сможем По вот этой вот хронологии понять какое сообщение Какой сейчас текущий статус Какое состояние у нашего объекта вот а то про что мы вот видишь да получается вот получив эту обратную связь немножко я не то разуме пон и вот про что я и говорил то есть когда ты её сразу получаешь ты хотя бы после не ссылается на этом ложном ключе вот здесь согласен проигры здесь Да мне наверное надо было тоже чуть пораньше
00:53:56 - 00:55:35
вот эту обратную именно про обратную связь дать про что ты говори ты говори соответственно ВС Понятно Я транслировал в архитектуру и бы ВС нормального надо познакомиться по Дета я вот По примеру твоему Понятно Я в принципе на такое натыкался Но более живого так скажем более полного примера не читал не углублялся в этот он довольно ограни используется но Вот про чтение больше чем записи здесь у тебя есть очень классная такая вещь что ты отвечаешь исходя из своего опыта сразу же там Если можешь на вопрос
00:54:46 - 00:56:27
приводишь какие-то примеры своего опыта что вот у меня было Вот так мы делали вот это очень круто показывает что чеп больше наверно с такой Западной точки зрения да то есть там США и может быть в Европе где-то там сиру нельзя отвечать на вопрос грубо говоря что вот если у нас есть проблема X то мы используем инструмент Y это просто тебя закапывает мгновенно потому что в одной ситуации Ты должен использовать Y в другой ситуации Ты должен использовать Z в третьей ситуации там ещ что-то вот в некоторых
00:55:43 - 00:56:57
ситуациях комбинацию или там какое-то в таком случае одно в другом другое вот и когда ты говоришь что там обычно у нас чтений больше чем записи Ну нет далеко не во всех проектах такое не во всех согласен да но видишь ты привык к этому привык к такому подходу привык с ним работать и ты сразу же просто сказал что вот в этом проекте у нас будет Вот так хотя там ничего про это не написано Да но мы уже исходим из таких предположений и соответственно согн Ты кстати не первый кто меня на этом ловит то есть есть такие истории
00:56:26 - 00:57:38
которые у тебя почему-то где-то отпечатывается и ты автоматом подсовывает в ТЗ которых там на самом деле нет и это ну не всегда хорошая история и бывает что ты делае именно оговорки не позии того что вот этой привычки если тебя поправляют то ты сразу так Ну да да да и раскрываешь более глубоко так скажем более обширно но есть такая история Да соглас здесь ещё смотри на самом деле это тоже зависит от компании потому что например в индийских компаниях чтобы стать синем прой на соседова чается вот в России чуть-чуть
00:57:04 - 00:58:42
посложнее Однако вот те вопросы там тоже недавно штудировать по-моему или на ри было написано что там кто-то спрашивал Подскажите какие вопросы задавать на собеседовании синьору по СИ шарпу вот один парень привёл в пример что говорит Вот мы у себя сеньоров Тестируем вот так ему второй отвечает что извини но это как бы как как максимум на медла только тянет вот такие вопросы То есть это и от компании зависит и от место от вообще страны в целом таких подходов более глобальных но в идеальном случае да сир
00:57:57 - 00:59:07
он не должен сразу же предлагать какое-то своё решение потому что он его знает потому что он с ним работал это очень явно было видно на три проекта для каждого сервиса Ну то есть сразу же вопрос а Всегда ли это справедливо Действительно ли это нужно воз нено скам Ну то есть в каких-то Ключах Я согласен с этой формулировкой нельзя сразу предлагать А вот конкретно в этой ситуации но так получилось что это не просто так скажем А какой-то вот я с этим работал и так и буду делать я на тему архитектуры Ну
00:58:32 - 00:59:59
достаточно часто бывает размышляю Я всегда в поисках какой-то интересной архитектуры и вот э история которую к сожалению придумал не я Я там лишь некоторые концепции под внс она меня Настолько зацепила и я считаю что это прям какая-то одна из лучших вариаций я пока лучше не видел я всегда открыт к тому чтобы кто-то показал Но пока я лучше не видел подхода который позволял бы вот слабо связано действительно об сви льно закрывать типовые задачи там то есть очень много можно вот трудовской части и так
00:59:17 - 01:00:50
далее закрыть типовыми запросами какие-то написать в прото файлах общий и поэтому как бы я так смело предложил что вот три проекта и так далее Потому что действительно считаю что это одно из лучших вариантов согласен Тут даже спорить не собираюсь Да не планирую это очень классный подход для тех задач которые ты уже привык решать вот но например если мы поговорим про какой-нибудь Вот мы с рассматривали систему в которой были продукты в которой были заказы и склады вот есть блин вылетел из головы до сих пор не
01:00:03 - 01:01:38
вспомнил В общем есть система на которой можно shopify во на котором можно создавать свои интернет-магазины и продавать товары на этой системе у нас Я не знаю там в сутки могут Ну утрированно очень так из головы миллионы товаров создаваться и За день За один день миллионы товаров соответственно создани вот этих вот товаров У нас очень много И порой нет необходимости Ну мне вот сейчас лично не видится вообще никакого такого случая примера необходимо было бы в виде jpc в виде такого вообще rpc то есть проду Call
01:00:51 - 01:02:14
вызов который синхронный идёт создавать какой-то товар вот мы всегда можем сказать пользователю Окей Мы тебя услышали товар создастся через там 5 минут вот ну или как создастся Когда создастся приходи позже Вот то есть это всё можно было перевести именно в MQ Да вот тут я пытался тебя как раз вывести толкнуть на такой момент что не всегда и не везде нужно сразу же rpc впихнуть Же принципы которые ты преследуешь Я говорю я всегда буду Ну то есть Возможно если мы будем оценивать действительно там
01:01:32 - 01:02:55
какую-то нагруженность позиции того кто нужен для сопровождения и так далее возможно здесь эта история проиграет с позиции того что на более высокоуровневым для поддержки Там либо для хостинга но с позиции обеспечить максимальную говорю производительность отклик Ну то есть я всегда за вот это то есть максимально быстро надёжно чётко Ну смотри вот представим что у нас опять же тот же самый shif и создаётся миллионы вот этих вот товаров один сервис у нас вполне скорее всего не выдержит такой нагрузки нужно будет
01:02:13 - 01:03:41
больше сервисов Как как в такой ситуации жить что делать с др доводить больше НСО А как раутио взаимодействие между друг дружкой когда они напрямую будут пытаться ходить Ну ну вот в шлюз пришло что-то да хотим создать товар у нас есть три сервиса которые умеют создавать товар Ну то есть три копии одного и того же сервиса я понял так скажем в эту сторону я сильно глубоко не копал но в моём понимании можно всё-таки вкрутить какой-то промежуточный баланс который будет понимать какой сервис Какая нода больше
01:02:57 - 01:04:31
загружена и отправлять туда и у нас появляются дополнительные сложности которых можно было бы избежать если бы это делать асинхронно И вот мне казалось что как раз когда ты отвечал на вопрос Ты сказал что лучше всего если что-то есть возможность сделать асинхронно то лучше это делать асинхронно ну с одной стороны да но с как бы это да это Абсолютно верно и я действительно такое произносил но с позиции Ну я немного в другом ключе это использовал Аа просто за асинхронность тоже в определённом ключе надо чем-то платить
01:03:46 - 01:05:07
то есть если мы говорим что мы асинхронно создаём товар то нам немножко надо более детально проработать вот эту экосистему как я уточнил Ну то есть какие-то статусы промежуточные какое-то вот взаимодействие с пользователем что Дада Мы это сделаем но Мы это сделаем ээ за какое-то время ты подожди Да полностью согласен Вот ну и здесь тоже наверное уже знакомый нам всем момент что ты произнёс враз такой классный пользователь чаще всего хочет И вот как как это человеку который несколько погружён в продакт
01:04:34 - 01:05:53
менеджмент не можешь ты говорить Ну я или там программист или ещё кто-то из сам продакт менеджер за пользователя право имеешь только вряд ли ты будешь Даже те кто выдвигают прям реально какие-то гипотезы по проверки маркетологи и прочее продук то не всегда имеют право такой фразой располагать могут там действительно кто-то успешный когда там у тебя проект который там Все думали что не может ты сказал пользователь так по крайней мере в рамках этого проекта точно имеешь право так говорить Ну да да показать свою экспертность но
01:05:13 - 01:06:41
согласен абсолютно плохая фраза паразит которая у меня тоже часто проскакивает но абсолютно верное замечание и хочу заметить другую фразу которая прям очень классная у тебя была фраза не паразит зависит от ситуации то есть вот в самом начале ты Отвечая на теоретические вопросы прям сказал что вот можно сделать так можно это но зависит от ситуации и вот это как раз-таки именно то чего требуется от синера То есть ты должен сказать что нет там нет какого-то единого Серебряной пули потому что я уже знаю Я уже там
01:06:01 - 01:07:12
собаку съел на этом в одной ситуации нужно одно в другой другое Поэтому Давайте определимся что у нас за ситуация и что здесь именно Нам подойдёт вот потом про Согласен Это такой самый правильный ожидаемый подход от синдра но выдерживать логику весь день не всегда получается и часто мо пытается увести в стандартный тебе привычный контекст Да согласен Есть такое у всех есть мне кажется Ну может у большинства е не у всех про разделение на машины то есть там про многопоточность Я спросил да как можно избавиться от многопоточности ты
01:06:37 - 01:07:58
говориш ну зачем многопоточность на одной машине давайте мы просто их на разные машины раскидаем на разные процессы приложение и пусть они каждый по одному делают А что Вполне себе решение Вот так микросервисы работают например мы не нагружая один всем всем всем создаём кучу инстан сов и каждый занимается по чуть-чуть обще одним общим каким-то заданием вот помимо этого было много примеров из опыта тоже в плюс Да и про D Мне понравилось тоже я у тебя спросил ты сказал что Ну не особо с ним знаком и
01:07:18 - 01:08:32
потом продолжил что но на самом деле Вот я считаю вот так вот это вот это прям очень классно То есть ты не оставляешь такую негативную информацию в конце то есть если ты просто отвечаешь что я не знаю я с этим не работал и замолкает это очень плохо Вот лучше если ты чего-то не знаешь опять же как говори желательно в начале сказать из ключа негативного а потом вс-таки постараться закрыть на положительно потому что поменяв одной и другой местами всё равно всегда человек склонен запоминать послед есть такое ну говорят начало и
01:07:54 - 01:09:34
конец а середину там можно менять Как хочешь Как показывает практика и тоже может быть про Давай дальше про sec пате Мне очень понравилось тоже как-то ответил Классно Мне очень зашло Я не знаю вот тут тебя тоже хотел спросить ты смотрел говорил же что видео предыдущее и когда задание я тебе скинул ссылку ты его начал читать вслух ты обычно это сам делаешь или пос видео сго вижу не в формате Ну по крайней мере в рамках интервью я вижу их чаще всего в виде кода а не в виде какого-то ТЗ и давай как-то
01:08:43 - 01:10:15
проработаем какую-то архитектуру то есть в этом случае я чаще всего код именно всегда зачитывал но как бы триггером что действительно надо зачитать именно в слух текста я вс-таки подчеркнул это из прошлого и в целом согласен с тем что читая слух оно как-то малость попроще воспринимается ты не чувствуешь вот эту саму нагрузку тишины когда грубо говоря ты читаешь и ты не понимаешь ты долго читаешь или недолго нет вот этой какой-то до психологической момен чувствовалось что ты не очень вроде как привык к этому но ты это
01:09:36 - 01:11:10
делаешь и у тебя это хорошо получается вот и наверное последний такой тоже момент это то что ты изначально когда прочитал задание ты всё продумал ты всё рассказал как это должно быть и только после того как ты уже всё рассказал проваливался ты начал писать архитектуру записывать то что ты проговорил словами Вот это очень здорово Да вот такие нюансы такие примеры Спасибо Слушай это на самом деле очень крутая обратная связь то есть я на самом деле рассчитывал на что-то более меньшее Но действительно это прям крутая
01:10:27 - 01:11:51
обратная связь именно как у полноценных интервьюеров когда какую-то такую скидки типа ну человек же действительно там не ищет там работника себе вот там под какой-то проект это ну там какие-то нюансы опустится и так далее что-то может быть не заметите Но у тебя вот классный Скил вот этого ну то есть прокаченный Может быть связан преподавательский опыт ещё что-то Но действительно ты даёшь классную обратную связь и очень много вещей замечаешь и успел зафиксировать их при этом и действительно мне это будет полезно
01:11:14 - 01:12:41
Спасибо большое
01:11:57 - 01:12:01