Помню когда устраивался на первую работу в поддержку в 21 у меня hr спросила, почему я не иду на программисты. На что я ответил, что уже как бы поздно в программисты идти.. Через 5 лет я понял что не поздно и сменил работу лида поддержки на рядового джуна прогера - не жалею)
Если прилагаешь много усилий и получаешь результат - это не путь в выгоранию. Выгорают вроде от монотонной беспросветной работы без мотивации, тут кажется мотивация есть.
Выучился, устроился и дальше работай нормально, читай книжки, ходи на конференции - никто не говорит что надо всю жизнь только и делать что учиться все свободное время)
Основная мысль статьи, как мне кажется, заключается в том, что без упорного труда не получится сменить профессию, тем более на ИТ, где довольно высокий порог входа.
Я не спорю, что если ты в школе любил компьютеры, пошёл учиться по ИТ в универ, то можно без особых усилий освоить любую ИТ профессию - без особых усилий в единицу времени. Потому, что ты будешь много лет постепенно погружаться в эту работу.
А герои статьи, как мы видим, не пошли по этому пути. И теперь им придётся приложить все те же усилия, только в короткий промежуток времени.
Кажется, что автор статьи не выступает в роли учителя, а является скорее наставником. Причём бесплатным наставником - тратит личное время после работы на помощь человеку. Учитель может и учит всех, но вот что будет с учеником после учёбы, ему уже не важно, зарплата получена. А автору важно, его цель, кажется, помочь человеку изменить жизнь к лучшему.
Я тоже был наставником у нескольких человек, один учился с 0 на разработчика, другой на аналитика. Они оба были гипер мотивированными и тратили все свободное время. И даже когда они выучились, они оба столкнулись с тяжелейшей задачей найти работу, которую кстати им удалось решить.
Я бы подитожил так - если ты не можешь найти мотивацию на один час учёбы каждый день, даже не пытайся идти в ИТ. На этом пути встретится большие препятствия. Правда есть и другая сторона, что если приложить усилия, за год можно освоить профессию, а результат того стоит)
Отличная статья, прям с языка снял) Становиться ментором можно только для людей, которые готовы чем-то жертвовать. Если человек не готов для начала купить хороший курс и пройти его, то и начинать работу с таким человеком не стоит.
А те, кто прикладывают усилия, всегда добиваются результата!
В Яндексе до сих пор не отошли от эпохи неоколониализма, когда в Москве зарплата больше, чем в других городах. У ребят видимо эффективность сотрудников оценивается их местоположением...
Код как бы говорит, что для того, чтобы декодировать токен, нужно передать туда ключ JWT_SECRET. Но это же не так, ключ нужен только чтобы проверить подпись токена. Получается метод проверяет и декодирует токен, и лучше бы его назвать validateAndDecode. А глядя на это имя кажется, тут еще лучше было бы разделить метод на два.
Также мне не совсем понятно, как вы в реальности делаете авторизацию. У вас монолит или микросервисы? Если микросервисы, то они все получается знают ключ? Вы не думали вынести логику генерации токена в отдельный сервис и перейти на схему с ассиметричным шифрованием?
Спасибо за подробный ответ. Интересно, что мы с Вами почти в 1 день написали статьи на одну тему, но у нас очень разные подходы к компонентным тестам получились - из общего только моунтбанк и концепция поднятия зависимостей в докере)
В тесте в Assert блоке вы обращаетесь прямо в БД сервиса для проверки того, что сущность создана корректно. Получается тест завязан прямо на реализацию сервиса - он знает не только про внешний контракт, но и про то какая моделька хранится в самой базе. Вам не кажется, что лучше было бы не обращаться в БД, а выполнить get запрос и проверить, что сервис вернул верный ответ?
Метод Prepare кажется вызывается каждый раз. Возможно стоит вынести его и пометить атрибутом [BeforeScenario]?
Получается вы не используете механизм WebApplicationFactory. Т.е. вы тестируете не тот код, который в проекте сейчас, а тот, который упакован в контейнер? А удобно ли это дебажить? Пока ci не прошёл и не упаковал контейнер ты же не проверишь, что у тебя все хорошо? А в какой момент в CI эти тесты запускаются, уже после того как образ собрался и запушился в реджистри? Шаг с этими тестами блокирует CI?
А почему эти тесты дешевле поддерживаются, чем e2e? Мне показалось что они почти как e2e, только на моках-зависимостях.
Я вижу что много работы делается руками. Вы не думали делать её из кода? Поднимать контейнеры, например? Как это окружение поднимается в CI?
Если я все правильно понял, то ServiceContext -> ServiceProvider это как бы DI для тестов. servicecollection.AddScoped<AuthByCurrentContextRequestHandler>(); интересно, что такое здесь Scoped? Мне показалось как-то это сложно, поэтому возник следующий вопрос.
А у вас эти тесты пишут только разработчики или тестировщики тоже?
Вы пробовали написать сложный сценарий из 10 шагов пользователя, к примеру. Как-то код тестов переиспользуется или это просто шаг с большим блоком Act? Или Act и Assert чередуются?
Дебажится локально без проблем. Запускаешь тест в дебаге, ставишь брейкпоинт в коде сервиса и он сработает. Никакого remote debug не нужно. Удобный дебаг - это один из главных плюсов этого подхода.
Я их всегда мокаю. В таком случае можно проверить что будет если сервис-зависимость вернёт 500ку или вообще любой нужный ответ. К тому же у сервиса-зависимости могут быть свои сервисы и так далее. Все локально не поднимешь. Лучше написать простой end2end тест в дополнение, который прямо на тестовом стенде проверит базовые сценарии.
Помню когда устраивался на первую работу в поддержку в 21 у меня hr спросила, почему я не иду на программисты. На что я ответил, что уже как бы поздно в программисты идти..
Через 5 лет я понял что не поздно и сменил работу лида поддержки на рядового джуна прогера - не жалею)
Если прилагаешь много усилий и получаешь результат - это не путь в выгоранию. Выгорают вроде от монотонной беспросветной работы без мотивации, тут кажется мотивация есть.
Выучился, устроился и дальше работай нормально, читай книжки, ходи на конференции - никто не говорит что надо всю жизнь только и делать что учиться все свободное время)
Основная мысль статьи, как мне кажется, заключается в том, что без упорного труда не получится сменить профессию, тем более на ИТ, где довольно высокий порог входа.
Я не спорю, что если ты в школе любил компьютеры, пошёл учиться по ИТ в универ, то можно без особых усилий освоить любую ИТ профессию - без особых усилий в единицу времени. Потому, что ты будешь много лет постепенно погружаться в эту работу.
А герои статьи, как мы видим, не пошли по этому пути. И теперь им придётся приложить все те же усилия, только в короткий промежуток времени.
Кажется, что автор статьи не выступает в роли учителя, а является скорее наставником. Причём бесплатным наставником - тратит личное время после работы на помощь человеку. Учитель может и учит всех, но вот что будет с учеником после учёбы, ему уже не важно, зарплата получена. А автору важно, его цель, кажется, помочь человеку изменить жизнь к лучшему.
Я тоже был наставником у нескольких человек, один учился с 0 на разработчика, другой на аналитика. Они оба были гипер мотивированными и тратили все свободное время. И даже когда они выучились, они оба столкнулись с тяжелейшей задачей найти работу, которую кстати им удалось решить.
Я бы подитожил так - если ты не можешь найти мотивацию на один час учёбы каждый день, даже не пытайся идти в ИТ. На этом пути встретится большие препятствия. Правда есть и другая сторона, что если приложить усилия, за год можно освоить профессию, а результат того стоит)
Отличная статья, прям с языка снял) Становиться ментором можно только для людей, которые готовы чем-то жертвовать. Если человек не готов для начала купить хороший курс и пройти его, то и начинать работу с таким человеком не стоит.
А те, кто прикладывают усилия, всегда добиваются результата!
Взял яндекс телевизор. Он даже в их же кинопоиске не умеет в управление через Алису. Я в шоке. В целом все сыро у ребят.
Спасибо, исправил)
В Яндексе до сих пор не отошли от эпохи неоколониализма, когда в Москве зарплата больше, чем в других городах. У ребят видимо эффективность сотрудников оценивается их местоположением...
Отличная статья, чтобы освежить знания. Большое спасибо)
Код как бы говорит, что для того, чтобы декодировать токен, нужно передать туда ключ JWT_SECRET. Но это же не так, ключ нужен только чтобы проверить подпись токена.
Получается метод проверяет и декодирует токен, и лучше бы его назвать validateAndDecode. А глядя на это имя кажется, тут еще лучше было бы разделить метод на два.
Также мне не совсем понятно, как вы в реальности делаете авторизацию. У вас монолит или микросервисы? Если микросервисы, то они все получается знают ключ?
Вы не думали вынести логику генерации токена в отдельный сервис и перейти на схему с ассиметричным шифрованием?
Спасибо за подробный ответ. Интересно, что мы с Вами почти в 1 день написали статьи на одну тему, но у нас очень разные подходы к компонентным тестам получились - из общего только моунтбанк и концепция поднятия зависимостей в докере)
Если вы вдруг пропустили, то вот она https://habr.com/ru/articles/758888/, может вам что-то зайдёт оттуда.
В тесте в Assert блоке вы обращаетесь прямо в БД сервиса для проверки того, что сущность создана корректно. Получается тест завязан прямо на реализацию сервиса - он знает не только про внешний контракт, но и про то какая моделька хранится в самой базе. Вам не кажется, что лучше было бы не обращаться в БД, а выполнить get запрос и проверить, что сервис вернул верный ответ?
Метод Prepare кажется вызывается каждый раз. Возможно стоит вынести его и пометить атрибутом [BeforeScenario]?
Получается вы не используете механизм WebApplicationFactory. Т.е. вы тестируете не тот код, который в проекте сейчас, а тот, который упакован в контейнер? А удобно ли это дебажить? Пока ci не прошёл и не упаковал контейнер ты же не проверишь, что у тебя все хорошо? А в какой момент в CI эти тесты запускаются, уже после того как образ собрался и запушился в реджистри? Шаг с этими тестами блокирует CI?
А почему эти тесты дешевле поддерживаются, чем e2e? Мне показалось что они почти как e2e, только на моках-зависимостях.
Я вижу что много работы делается руками. Вы не думали делать её из кода? Поднимать контейнеры, например? Как это окружение поднимается в CI?
Если я все правильно понял, то ServiceContext -> ServiceProvider это как бы DI для тестов.
servicecollection.AddScoped<AuthByCurrentContextRequestHandler>();
интересно, что такое здесь Scoped? Мне показалось как-то это сложно, поэтому возник следующий вопрос.
А у вас эти тесты пишут только разработчики или тестировщики тоже?
Вы пробовали написать сложный сценарий из 10 шагов пользователя, к примеру. Как-то код тестов переиспользуется или это просто шаг с большим блоком Act? Или Act и Assert чередуются?
Дебажится локально без проблем. Запускаешь тест в дебаге, ставишь брейкпоинт в коде сервиса и он сработает. Никакого remote debug не нужно. Удобный дебаг - это один из главных плюсов этого подхода.
Я их всегда мокаю. В таком случае можно проверить что будет если сервис-зависимость вернёт 500ку или вообще любой нужный ответ.
К тому же у сервиса-зависимости могут быть свои сервисы и так далее. Все локально не поднимешь. Лучше написать простой end2end тест в дополнение, который прямо на тестовом стенде проверит базовые сценарии.
Да, кажется что coverage можно корректно считать только на юнит тестах.
Идея хорошая - нужно будет сделать перевод, заодно английский подтянуть)
Рад, что статья принесёт пользу)