1. container - это глобальный объект? 2. Можем ли иметь несколько контейнеров? 3. Насколько эффективно ресолвятся зависимости? 4. Не совсем понял пример с тем, что меняется входная схема. Да, мы не привязываемся к неймингу, отдаем сырые данные , там под капотом происходит магия. Но в таком случае получается, что мы ничего как клиент не знаем о контракте, если контракт поменяется мы бы в любом случае получили проблему совместимости, но когда явно указываешь схему передачи, ide подсветит тебе, что у тебя синус с косинусом не сходятся или ту же проблему получишь при запуске линтов. Как бы никто не защищен, если от того, что у тебя и исходную схему модернизируют, так что она перестанет работать у клиентов сервиса. Но тут мы это прячем на слой поглубже.
DI в целом очень хорош, нужен ли он в django проекте?
Тестовые задания, как и лайфкодинг - инструменты, которые показывают как человек будет делать свою работу. Опять же при условии, что нет каких то прям уж очень жестких ограничений на используемые ресурсы в качестве способа выполнения тестового.
Условно даже то, как человек будет коммуницировать - говорит о том, как он это будет делать в команде. Без лишних вопросов/сообщений сделанная таска не всегда говорит о самостоятельности кандидата, как и постоянный диалог о том, что кандидат пытается накопить как можно больше информации по т.з. Это субъективно, но объясняет, что лид команды должен проводить лайфкодинг/выступать коммуникацией по тз, ещё лучше, если лид подбирает кандидата себе в команду.
В целом моё скромное мнение, сходится во многом с содержанием статьи.
Хороша ознакомительная статья, есть момент небольшой, который немного испортил впечатление:
>Для простоты используем довольно простой проект.
Очень большое количество ссылок в самой статье, как будто открыл пдф-брошуру Зетелькастена и начинаешь ходить по ссылкам. Очень удобно с учётом, что материал подается последовательно.
Статья неплохая, есть ряд вопросов:
1. container - это глобальный объект?
2. Можем ли иметь несколько контейнеров?
3. Насколько эффективно ресолвятся зависимости?
4. Не совсем понял пример с тем, что меняется входная схема. Да, мы не привязываемся к неймингу, отдаем сырые данные , там под капотом происходит магия. Но в таком случае получается, что мы ничего как клиент не знаем о контракте, если контракт поменяется мы бы в любом случае получили проблему совместимости, но когда явно указываешь схему передачи, ide подсветит тебе, что у тебя синус с косинусом не сходятся или ту же проблему получишь при запуске линтов. Как бы никто не защищен, если от того, что у тебя и исходную схему модернизируют, так что она перестанет работать у клиентов сервиса. Но тут мы это прячем на слой поглубже.
DI в целом очень хорош, нужен ли он в django проекте?
Тестовые задания, как и лайфкодинг - инструменты, которые показывают как человек будет делать свою работу. Опять же при условии, что нет каких то прям уж очень жестких ограничений на используемые ресурсы в качестве способа выполнения тестового.
Условно даже то, как человек будет коммуницировать - говорит о том, как он это будет делать в команде. Без лишних вопросов/сообщений сделанная таска не всегда говорит о самостоятельности кандидата, как и постоянный диалог о том, что кандидат пытается накопить как можно больше информации по т.з. Это субъективно, но объясняет, что лид команды должен проводить лайфкодинг/выступать коммуникацией по тз, ещё лучше, если лид подбирает кандидата себе в команду.
В целом моё скромное мнение, сходится во многом с содержанием статьи.
Хороша ознакомительная статья, есть момент небольшой, который немного испортил впечатление:
>Для простоты используем довольно простой проект.
Очень большое количество ссылок в самой статье, как будто открыл пдф-брошуру Зетелькастена и начинаешь ходить по ссылкам. Очень удобно с учётом, что материал подается последовательно.
>Vue 3 имеет лучшую поддержку TypeScript
По сравнению с чем?
Статья обширная, делает ряд моментов более прозрачными.
Огромный мануал, примеры из разряда: проверяешь мр/пр и кидаешь ссылку на конкретный хедер статьи