В целом, согласен с Вами и вся разработка ПО это, в принципе, про баланс. Но вот с тем, что E2E это "хрупкие" тесты, не соглашусь. Современный инструментарий для backend и frontend позволяет писать E2E тесты, которые не имеют свойства ломаться.
Под коллегами имею ввиду разработчиков. Исследованиями здесь не оперирую, все это не более чем философия и изложение субъективного опыта работы. Согласен, стоило написать "по моему опыту", чтобы не вводить в заблуждение объективностью. Поправлю.
Понятно, что ситуация варьируется от места к месту, но то, что конкретно в Вашем случае только запуск системы для прогона E2E тестов занимает больше времени, чем все модульные тесты, может быть показательно как раз с точки зрения метрик.
Возможно, стоит подумать о том, как эту систему можно сделать проще и быстрее, возможно декомпозировать? Или время старта E2E теста подразумевает время запуска инструментария тестирования?
Почему Вы считаете, что разработчику тяжело поддерживать E2E тесты? Для меня, как разработчика, не представляет сложности написать HTTP-запрос, кинуть сообщение в Rabbit или Kafka, потыкать web-интерфейc или взаимодействовать с БД. Это даже проще, потому как ты просто используешь API уже существующего ПО. Возможно, я что-то упускаю?
Коротко: docker-compose up -d — только для одного сервера, docker stack deploy — для множества объединенных в кластер Swarm.
И в продакшене можно, вопрос как именно используется инфраструктура. Если имеется один сервак, то бонуса от Swarm не будет. А вот если серверов много, их может быть проще объединить в Swarm-кластер и управлять всем из одной точки, а не бегать по SSH между серваками или постоянно переключать контекст Docker. Использование кластера Swarm может дать много плюсов, но это тема для отдельной статьи.
Да, более того не только на руководящие, но и в принципе на любые должности (говорю про middle/senior уровень). Практика показывает, что в результате можно получить очень интересные ответы от собеседника, варьирующиеся от «хрен знает» и заканчивая ответами в виде «да все нормально будет, не волнуйся». Что, между прочим, является тревожным звоночком.
Даты образования не обязательно позволяют вычислить возраст. Иногда ведь люди получают образование в более позднем возрасте. Неопределенности добавляет еще и заочная форма обучения. Ее, к слову, вообще никак по диплому не отличить.
Правда, смешно, что HH до сих пор не дает возможности вытащить «о себе» (эбаут) в самый верх. Т.е. выше, чем все предыдущие места работы. Это же банально не позволяет следовать советам из статьи на том же HH. Следовательно, «питчинг» может и не получится.
Если не меняли предметную область, то добро пожаловать в сеньёры (4-5 лет суммарно).
Не обязательно, вполне можно прыгать между предметными областями. Главное, чтобы был интерес, тогда изучение предметной области не будет проблемой. Если открыты к общению с людьми, особенно из бизнеса, все становится еще проще.
После окончания очередного этапа я задал вопрос девушке — эйчару о компании, или о дальнейших шагах. Не помню уже. И в ее глазах увидел стену страха и непонимания.
Не совсем понятно, что есть «стена страха и непонимания». Она же Вас не поняла, как же Вы сделали вывод, что «компания основана не на уважении, а на страхе»?
Это, конечно, в некоторой степени ад, сочувствую вам. С подобным уровнем диверсии не сталкивался, но элементы этих проблем встречал, этого достаточно. Полностью понимаю боль отчетности для разрабов.
Было у меня одно место, на котором требовался отчет за 8 рабочих часов. Неприятно, когда тебя воспринимают как «винтик» в системе и рубят на корню творческий процесс. А ведь его, на мой взгляд, адекватно оценить крайне сложно.
Отвлекся на импровизированное обсуждение актуального технического вопроса с коллегами? Занимаешься менторингом, а компания это не признает? Задача заняла больше времени, чем требовалось? Вот ищи теперь, где время взять, а куда приписать…
Подождите, но ведь пишу теряется возможность выбора, а не невозможна разработка. И пишут на одном ЯП. Есть проблемы, тонкости, но пишут.
К сожалению, эти страшные мысли — это реальность для некоторых компаний, в которых работал. Если абстрагироваться от технических деталей, то конечно, практически можно реализовать любой алгоритм на любом ЯП (полном по Тьюрингу). Проблема в том, что тот самый единственный ЯП может быть субоптимален для реализации алгоритма.
Вы правильно подметили, что микросервисы повсюду. Шаг назад тут в целом для IT, на мой взгляд, потому как используется этот подход без разбора, без объективных данных о необходимости применения.
Полностью согласен с Вами, что микросервисы ведут к накладным расходам и что в это надо вкладываться. И действительно, есть крупные компании, которые это успешно делают и получают преимущества от микросервисной архитектуры.
Ключевой элемент здесь — крупные, не до 10 разработчиков, а значительно больше. И хотя у таких компаний часто есть основной язык, он обычно не единственный.
По монолиту также согласен. Тут я упомянул «классическую» (утрированную) версию, которой пугают обычно менеджмент на питчингах микросервисов. Конечно, он таким может и не быть, если соответствующим образом его писать.
В целом, согласен с Вами и вся разработка ПО это, в принципе, про баланс. Но вот с тем, что E2E это "хрупкие" тесты, не соглашусь. Современный инструментарий для backend и frontend позволяет писать E2E тесты, которые не имеют свойства ломаться.
Под коллегами имею ввиду разработчиков. Исследованиями здесь не оперирую, все это не более чем философия и изложение субъективного опыта работы. Согласен, стоило написать "по моему опыту", чтобы не вводить в заблуждение объективностью. Поправлю.
Понятно, что ситуация варьируется от места к месту, но то, что конкретно в Вашем случае только запуск системы для прогона E2E тестов занимает больше времени, чем все модульные тесты, может быть показательно как раз с точки зрения метрик.
Возможно, стоит подумать о том, как эту систему можно сделать проще и быстрее, возможно декомпозировать? Или время старта E2E теста подразумевает время запуска инструментария тестирования?
Почему Вы считаете, что разработчику тяжело поддерживать E2E тесты? Для меня, как разработчика, не представляет сложности написать HTTP-запрос, кинуть сообщение в Rabbit или Kafka, потыкать web-интерфейc или взаимодействовать с БД. Это даже проще, потому как ты просто используешь API уже существующего ПО. Возможно, я что-то упускаю?
E2E расшифровывается как End-to-End. Обновил статью, чтобы уточнить.
По поводу добавить новые сервер Swarm — однозначно согласен. А вот масштабироваться можно и с помощью
docker-compose up --scale service=N.Коротко:
docker-compose up -d— только для одного сервера,docker stack deploy— для множества объединенных в кластер Swarm.И в продакшене можно, вопрос как именно используется инфраструктура. Если имеется один сервак, то бонуса от Swarm не будет. А вот если серверов много, их может быть проще объединить в Swarm-кластер и управлять всем из одной точки, а не бегать по SSH между серваками или постоянно переключать контекст Docker. Использование кластера Swarm может дать много плюсов, но это тема для отдельной статьи.
Правда, смешно, что HH до сих пор не дает возможности вытащить «о себе» (эбаут) в самый верх. Т.е. выше, чем все предыдущие места работы. Это же банально не позволяет следовать советам из статьи на том же HH. Следовательно, «питчинг» может и не получится.
Не обязательно, вполне можно прыгать между предметными областями. Главное, чтобы был интерес, тогда изучение предметной области не будет проблемой. Если открыты к общению с людьми, особенно из бизнеса, все становится еще проще.
Не совсем понятно, что есть «стена страха и непонимания». Она же Вас не поняла, как же Вы сделали вывод, что «компания основана не на уважении, а на страхе»?
Было у меня одно место, на котором требовался отчет за 8 рабочих часов. Неприятно, когда тебя воспринимают как «винтик» в системе и рубят на корню творческий процесс. А ведь его, на мой взгляд, адекватно оценить крайне сложно.
Отвлекся на импровизированное обсуждение актуального технического вопроса с коллегами? Занимаешься менторингом, а компания это не признает? Задача заняла больше времени, чем требовалось? Вот ищи теперь, где время взять, а куда приписать…
К сожалению, эти страшные мысли — это реальность для некоторых компаний, в которых работал. Если абстрагироваться от технических деталей, то конечно, практически можно реализовать любой алгоритм на любом ЯП (полном по Тьюрингу). Проблема в том, что тот самый единственный ЯП может быть субоптимален для реализации алгоритма.
Ключевой элемент здесь — крупные, не до 10 разработчиков, а значительно больше. И хотя у таких компаний часто есть основной язык, он обычно не единственный.
По монолиту также согласен. Тут я упомянул «классическую» (утрированную) версию, которой пугают обычно менеджмент на питчингах микросервисов. Конечно, он таким может и не быть, если соответствующим образом его писать.