Не отрицаю, и таких почти сразу видно. Не вижу в этом ничего плохого. Я говорю про тех кто уверенно рассказывает о том какой он хороший лид и мудрый наставник, а базовые вещи не то, что говорит «не знаю» или «не смогу сказать» (что я считаю нормальным, невозможно знать абсолютно все), а начинает нести просто ересь в которую сам поверил. И это не единичный, а довольно частый случай, к сожалению. Такие наставники, потом и растят новое поколение уверенное, что let ввели ради хайпа и оно ничем от var не отличается (это из реальных ответов).
За пол года подобрали всего пару человек в команду и это отнюдь не вундеркинды. У нас не завышенные требования. Просто на позиции senior ожидается, что человек не просто пользуется инструментом, а копает глубже и понимает как инструмент работает и вникает в то для чего сделана та или иная конструкция, а не использует что-то потому что так принято.
Сейчас же 90% сеньоров это джуны или мидлы заучившие react life cycle и набор популярных библиотек без понимания как они работают.
Полностью согласен с автором. Сам собеседую часто сеньоров JS на $3k-$4k на руки и реально некоторые даже про var и let не могут сказать. Спрашиваю не как тестирование обычно, а просто мнение о разных спецификах языка (зачем и почему их добавили в спецификацию) и небольшое обсуждение о том как может быть реализована та или иная функция. Из любимого, спрашиваю как реализована или как реализовал бы сам кардидат функцию animate, например из jquery, на абстрактном уровне, без конкретных строчек и определения переменных. Функция удобна тем что можно по ней спуститься до ивент лупа и понять знает ли кондидат хотя бы примерное представления работы лупа. Но бывают реально кандидаты которые на полном серьёзе считают, что внутри animate обычный for от исходного значения до желаемого (на senior JS !!!), не говоря уж о разнице реализации на setTimeout и setInterval (про requestAnimationFrame вообще мало кто знает).
А вот про '==' или '===' я вообще не спрашиваю даже сеньоров, так как это реально сложные особенности языка в которых очень легко запутаться. Хочешь завалить любого? Начти спрашивать про сраврение разных типов.
Главное как кандидат мыслит, а не то что он помнит или не помнит. Если понимаешь механизм, но что-то забыл, всегда можно нагуглить, но если считаешь что animate сделан на for, то хорошего кода можно не ждать.
это жуткое ощущение практической бесполезности всей этой работы: когда ты весь день занят тысячей мелких проблем а к вечеру кажется, что не успел фактически ничего.
Самое тяжелое при этом потом распределять затраченное время если работаешь на почасовой оплате…
Отлично! Тогда с нетерпением жду продолжения. Если надо будет материала подкинуть, обращайтесь. Могу еще своего опыта добавить. У нас проект специфичный: hiload, bigdata и все такое…
> 1. При дроблении приложения на много маленьких возрастает дублирование кода. Есть код, который должен быть в каждом проиложении (те же модели ORM) и описывать их придется везде отдельно.
Как уже было сказано выделяется в подключаемые модули и либы. Это даже становится плюсом, т.к. упрощается переиспользование кода не только в рамках текущего проекта…
> 2. Усложняется деплой. При изменении схемы бд, мне скорее всего придется обновить не одно приложение, а все пять. Это, конечно, автоматизируется. Но сам факт.
Если при изменении схемы бд приходится править все приложения, то это скорее недопонимание микросервисной архитектуры. Разделение на микросервисы это просто новая ступенька модульности и инкапсуляции.
Т.е. разделение происходит по функциональностям с соответствующим разделением ответственности. В итоге получаем что у каждого сервиса своя бд наиболее подходящая под его тип данных. Или бд общая но за определенные даные отвечает только конкретный сервис.
В таком варианте изменения схемы затронут только те сервисы чьи схемы были изменены.
> 3. Накладные расходы на общение сервисов между собой. Если взять из примера сервисы, общающиеся между собой через rest. Получается вместо прямого вызова нужного кода, мне надо будет делать http запросы и терпеть сетевые задержки.
Это один из наиболее ощутимых минусов который мы ощутили на своем проект. Но мы его решили разработкой своей серверной и клиентской либы с прямым сокетным соединением.
Для этого git должен уметь обращаться по api к CI. Не везде есть интеграция c api конкретного используемого CI. Придется писать дополнительный промежуточный скрипт. А вот мониторинг репозитория есть почти в каждом CI. Поэтому просто идем от того что проще.
А представьте себе разработчика, которому надо помимо написания кода, написать о том что сделал в таске, запустить тесты, написать тестировщику что можно проверять, самому задеплоить, зайти еще на какой-нибудь сервис поставить там галочку, зайти еще в одно место чтобы указать время затраченное на задачу и т.д. В некоторых случаях список можно продолжать и продолжать. Чем больше используется инструментов, тем больше разработчику приходится отвлекаться от работы, тем чаще подстраиваться под разные интерфейсы, и как пример, тем дольше вводить в курс дела нового сотрудника.
Не просто так большинство сервисов стремятся к принципу «все в одном».
Суть в том что надо рассматривать staging именно как будущий master и вести его так что бы его в любой необходимый момент можно было выкатить. Если на master'е проводить тесты, то они будут полностью дублировать тесты со staging'а. Это может очень сильно увеличить время деплоя. В нашем случае master служит только как метка для понимания того что сейчас на продакшене. Таким образом важной веткой за которой действительно надо следить становится staging.
если с таском есть проблемы то он откатывается из staging и доделывается в своей ветке. при необходимости staging можно смержить в ветку таска для воспроизведения проблемы.
Критичными ситуациями я называю те в которых нет времени на долгие тесты. Быстрые тесты в любом случае пройдут, а долгие пойдут параллельно с деплоем при мерже ветки master в staging.
Если проблема не критичная, но и до конца спринта ждать не может, то фикс проходит через staging и деплоится вместе с тем что уже накопилось за часть спринта.
Если срочно, то через capistrano делается rollback. В остальных случаях откатывается мерж коммит. Все мержи мы делаем с ключом --no-ff, поэтому они в истории в виде отдельного коммита, который можно дотаточно быстро откатить.
Конечно любые правила не без исключений. Совсем в критичных ситуациях таск мержится в master минуя staging. После чего master сразу мержится в staging, про прогона тестов и для актуализации ветки. Такие случаи бывали, но в большинстве случаев мы все же решаем делать откат релиза и в течении спринта без аврала фиксим. Спринты у нас короткие всего 1 неделя, поэтому обновляем небольшими порциями и фиксы приходят быстро.
По поводу возврата задачи, у нас тоже такая идея была, но просто рук не хватило пока реализовать. Но я думаю скоро тоже сделаем и я добавлю это в статью.
А в Вашем случае, я так понимаю запрет сделан на прекомит хуках?
За пол года подобрали всего пару человек в команду и это отнюдь не вундеркинды. У нас не завышенные требования. Просто на позиции senior ожидается, что человек не просто пользуется инструментом, а копает глубже и понимает как инструмент работает и вникает в то для чего сделана та или иная конструкция, а не использует что-то потому что так принято.
Сейчас же 90% сеньоров это джуны или мидлы заучившие react life cycle и набор популярных библиотек без понимания как они работают.
Прошу прощения, если кого обидел.
А вот про '==' или '===' я вообще не спрашиваю даже сеньоров, так как это реально сложные особенности языка в которых очень легко запутаться. Хочешь завалить любого? Начти спрашивать про сраврение разных типов.
Главное как кандидат мыслит, а не то что он помнит или не помнит. Если понимаешь механизм, но что-то забыл, всегда можно нагуглить, но если считаешь что animate сделан на for, то хорошего кода можно не ждать.
Самое тяжелое при этом потом распределять затраченное время если работаешь на почасовой оплате…
Как уже было сказано выделяется в подключаемые модули и либы. Это даже становится плюсом, т.к. упрощается переиспользование кода не только в рамках текущего проекта…
> 2. Усложняется деплой. При изменении схемы бд, мне скорее всего придется обновить не одно приложение, а все пять. Это, конечно, автоматизируется. Но сам факт.
Если при изменении схемы бд приходится править все приложения, то это скорее недопонимание микросервисной архитектуры. Разделение на микросервисы это просто новая ступенька модульности и инкапсуляции.
Т.е. разделение происходит по функциональностям с соответствующим разделением ответственности. В итоге получаем что у каждого сервиса своя бд наиболее подходящая под его тип данных. Или бд общая но за определенные даные отвечает только конкретный сервис.
В таком варианте изменения схемы затронут только те сервисы чьи схемы были изменены.
> 3. Накладные расходы на общение сервисов между собой. Если взять из примера сервисы, общающиеся между собой через rest. Получается вместо прямого вызова нужного кода, мне надо будет делать http запросы и терпеть сетевые задержки.
Это один из наиболее ощутимых минусов который мы ощутили на своем проект. Но мы его решили разработкой своей серверной и клиентской либы с прямым сокетным соединением.
Можете рассказать на какие грабли вы наткнулись и как решали?
Не просто так большинство сервисов стремятся к принципу «все в одном».
Если проблема не критичная, но и до конца спринта ждать не может, то фикс проходит через staging и деплоится вместе с тем что уже накопилось за часть спринта.
По поводу возврата задачи, у нас тоже такая идея была, но просто рук не хватило пока реализовать. Но я думаю скоро тоже сделаем и я добавлю это в статью.
А в Вашем случае, я так понимаю запрет сделан на прекомит хуках?