Пирамида тестирования была ошибкой


Тестирование собственного кода, неотъемлемая часть разработки у профессиональных разработчиков. Но тестирование тестированию рознь. Обычно, когда речь заходит о тестировании, то в разговоре сразу всплывает пирамида тестирования по Фаулеру и заходит речь о юнит тестах, о том что их должно быть много, в первую очередь надо писать их и так далее.

Когда-то очень много лет назад, я пошел по этому же пути, но быстро понял что фокус на юнит тестах не самое эффективное вложение. Сейчас об этом уже говорят многие и пишут тоже https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications Если вы не знакомы с Кентом, то обязательно посмотрите, он говорит о сдвиге парадигмы (хотя откровенно говоря, для меня подобная структура всегда была более естественной). Но есть и другой Кент, на которого очень любят ссылаться все кто пишут тесты. А вот что он сказал в 2005 году:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.
Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we’ll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order.

И я с ним согласен

Производительный программист. Переоткрываем Oh My Zsh

Одна из моих любых тем, это эффективное рабочее окружение. И сегодня я хочу поговорить про Oh My Zsh, который значительно поднимает эффективность работы в командной строке, причем не только личную, но и командную.

В двух словах что это если вы не знакомы. Oh My Zsh это система плагинов + набор плагинов добавляющая разные фичи в zsh (если вы на баше, то стоит перейти). По умолчанию включено всего лишь несколько плагинов, среди них git, который автоматически начинает показывать текущую ветку в git как на скрине выше.

Многие на этом останавливаются, думая что это все возможности Oh My Zsh, но мякотка находится дальше. Я сам не сразу понял это. Дело в том, что каждый плагин Oh My Zsh связан с какой-то утилитой, для которой, помимо прочего, он добавляет алиасы. Например правильный способ сливать изменения из origin в git это команда git pull —rebase. Поставив Oh My Zsh вы можете сразу же начать использовать сокращение gupa. Посмотрите в документацию: https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/git этих комбинаций сотни! Все их запомнить невозможно, но достаточно взять самые используемые. Благодаря этому я полностью поменял свою работу в git, docker, docker compose и других инструментах.

Дополнительный кайф в том, что так легче распространять знания в команде и использовать единый подход в организации работы с кодом и инструментами вокруг него.

Домашнее задание: Поищите среди плагинов те, что вам интересны и попробуйте потыкать их горячие клавиши https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins

Как TypeScript выпиливали из Turbo
Неделю назад отшумела история, с тем что ребята из basecamp выпилили typescript из их библиотеки Turbo. И что тут началось. DHH аж пришлось писать еще один пост https://world.hey.com/dhh/open-source-hooliganism-and-the-typescript-meltdown-a474bfda где он офигивает и немного негодует от происходящего.

Если она прошла мимо вас, обязательно посмотрите, это классный кейс в копилку нашей биологии) Кстати забавно, я в Твиттере про это тоже написал и мне тут же прилетел вопрос “а что ты думаешь по этому поводу?”. Подозреваю если бы я дал неправильный ответ, то мог бы попасть.

Есть у меня два тезиса, которые я бы хотел коротко разобрать.

Я не понимаю этих людей

Так часто пишут, когда пытаются показать, что люди с другой стороны делают какую-то херню. Так или иначе мы все что-то подобное говорили вслух или про себя. Но если отбрасывать эмоции в сторону, моя позиция по этому вопросу всегда такая. Если я удивляюсь поведению других людей, то я просто плохо понимаю как устроены люды, потому что мы все чертовски разные и как это ни странно, различия только усиливаются за счет того, что сейчас все живут в своих изолированных пузырях, пересекаясь только на каких-то массовых темах. Наши представления то что мы потребляем в интернете (во многом), а интернет сейчас крайне персонализированный.

Поэтому я довольно спокойно смотрю на аргументы тех кто за и тех кто против, какими бы отмороженными они мне не казались.

Они не разбираются

Вот что-что, а бизнес меня научил не судить никого, пока нет понимания контекста. Когда ты сам не организовывал что то не тривиальное, начиная от создания канала на ютубе или сообщества в телеграмме до своей кофейни, то говорить о том что там сидят дебилы которые не видят очевидных вещей и не могут нормально сделать, слегка опрометчиво.

Всегда, когда так кажется, а потом ты общаешься с теми кто за этим стоит, выясняются такие детали, что ты понимаешь, блин, ребята в сложной ситуации, понятно почему были приняты те или иные решения.

Так поручилось и тут. Я уверен что только единицы из тех кто накинулись на DHH, знают о том какие конкретно кейсы стали проблемой, сколько это длится, чего им это стоило и так далее.

p.s. Буду иногда пробовать формат не трансляции моих знаний и опыта из разработки и связанных тем, а комментирование каких-то интересных мне событий и новостей. Если что подкидывайте материалы.

Фильтрация данных: язык вместо кода

Хочу рассказать про интересное решение, которое позволяет унифицировать и значительно упростить фильтрацию данных в api или при обычных запросах с параметрами запроса.

Обычно подобная фильтрация выглядит так: site.com/items?size=5&city=london

Как правило, реализация подобных фильтров делается руками. Мы придумываем набор полей, по которым надо фильтровать и дальше в бекенде формируем sql запрос через билдер.

app.get('/employees', (req, res) => {
  const { firstName, lastName, age } = req.query;
  let results = [...employees];
  if (firstName) {
    results = results.filter(r => r.firstName === firstName);
  }
  if (lastName) {
    results = results.filter(r => r.lastName === lastName);
  }
  if (age) {
    results = results.filter(r => +r.age === +age);
  }
  res.json(results);
});

Самая мякотка в этой системе появляется тогда, когда у нас не просто совпадение по значению, а разнообразные предикаты в стиле “больше”, “меньше равно”, “содержит”, поиск по связным сущностям и так далее. В большинстве случаев такой код пишется прямо под конкретную ситуацию на бекенде. В интернете немало статей про это: graphql https://www.apollographql.com/blog/graphql/filtering/how-to-search-and-filter-results-with-graphql/ java https://medium.com/@cmmapada/advanced-search-and-filtering-using-spring-data-jpa-specification-and-criteria-api-b6e8f891f2bf

Но существует и более интересный подход, который позволяет автоматизировать задачу практически на 100%, убрать написание большей части предикатов и получить возможность реализовывать фильтры высокой сложности за полчаса работы. Познакомился я с этим подходом в библиотеке ransack, которая автоматически встраивается в Rails ORM. Работа этой библиотеки с точки зрения сервера сводится буквально к одной строчке: Model.ransack(params). А дальше начинается самое интересное. Концепция этой библиотеки состоит в том, что вместо императивного описания что делать на бекенде, мы декларативно описываем как фильтровать через правильное именование параметров.

Например, если мы хотим точное соответствие по полю name, то мы должны назвать параметр name_eq, если мы хотим искать по вхождению то name_cont. Тоже самое с числами. Если нам нужен возраст старше или равно, то мы пишем age_gt (greater than). Если мы хотим тоже самое но по связанным сущностям, то тогда описываем имя через связь user__name_eq (то есть ищем по имени пользователя, где пользователь это связь).

<input type="text" name="q[first_name_or_last_name_cont]">
<input type="text" name="q[email_cont]">

Хекслет весь насквозь увешан такими фильтрами. В большинстве случаев нам хватает дефолтных предикатов, но есть и пара кастомных. В любом случае даже кастомные предикаты работают по такой же схеме и мы можем применять их к разным сущностям если они это технически позволяют.

Дока по предикатам: https://activerecord-hackery.github.io/ransack/getting-started/using-predicates/
Демо Ransack: https://ransack-demo.herokuapp.com/users/advanced_search

Домашнее задание: Подобные библиотеки существуют и в других языках, но не все о них знают. Попробуйте найти библиотеку для своего стека и сбросьте в комментарии ссылку на гитхаб

Что не так с юнит-тестами


Помните мой недавний пост про изменении концепции тестирования на trophy? Там мы видим что количество юнит-тестов сведено к минимуму, что идет в разрез с общепринятым “пишем в первую очередь юниты”. И в этом посте я хочу рассказать про проблемы юнитов, которые существовали всегда и многие опытные разработчики на это не раз натыкались.

Часто говорят, что юниты помогают рефакторить код. Я же скажу, что именно юниты мешают его рефакторить. Полезный рефакторинг, как правило это не изменение того как написан, например, конкретный цикл, это переработка абстракций, выделение слоев, перемещение кода, перераспределение кода между функциями и методами. Что происходит с юнитами в таком случае? Правильно, они становятся полностью бесполезными, так как их придется переписывать. В моей практике была ситуация, когда 35 000 строк кода юнит тестов просто выкинули, так как в проекте делался важный рефакторинг и команда поняла что просто не потянет апгрейд тестов (по факту написание их с нуля).

Но и это еще не все, наличие большого числа таких юнитов заранее пугает разработчиков, так как они понимают что рефакторинг заставит их все переписывать, что убивает любую мотивацию рефакторить код.

Следующий пункт про гарантии. Все знают что гарантии от юнитов минимальны, поэтому их наличие не может быть оправданием того, что не пишутся тесты более высокого уровня, например, интеграционные. И пишутся они тоже программистами. Тогда возникает вопрос, зачем писать юниты, если уже есть интеграционные?

Ответом может быть: но они же быстрые. В реальности, в современных фреймворках скорость выполнения интеграционных тестов достаточно быстрая, чтобы не испытывать проблем. Да, при этом есть определенные техники работы с базой данных (не Моки!) которые надо соблюдать, но это уже давно отработанная история. Медленно же выполняются e2e тесты, но они пишутся независимо от юнит тестов, поэтому тут даже нет выбора.

p.s. Какие тесты в основном пишут в вашем проекте?

Когда стоит писать юниты

То есть юниты не нужны совсем?

Не совсем, есть немало мест где они нужны, но они все имеют специфические условия. В первую очередь это касается кусков кода (это может быть модуль, класс или даже просто функция), которые имеют сложную логику с большим количеством состояний (разных выходов в зависимости от условий). Такие штуки сложно тестировать косвенно, так как слишком большое количество вариантов работы, поэтому на такие компоненты пишутся юниты. Хорошим примером служат разные парсеры.

Но и тут есть детали. Понимание того, что является юнитом, а что не является – довольно не простой вопрос, на который по разному ответят разные программисты. Кто-то скажет что юнит это отдельный модуль в их системе. Кто-то скажет что это код, который включает в себя небольшой кусок кода, скажем один метод или класс, кто то скажет что юнит, это скорее когда мы все замокали так, что не вызывается ничего кроме нашего кода. Кто-то скажет что в юнитах можно делать запросы к базе данных, кто-то скажет что нет. Об этом мы поговорим в следующем посте и потом тему с тестами временно закроем)

Как делать правильно ревью кода?

У этого вопроса есть куча аспектов, но я хочу тут сосредоточиться только на технической составляющей.

Стандарты кодирования

Должный проверяться автоматически через CI. Не должно быть историй, когда вам приходится глазами выискивать несоответствия и писать комментарии в стиле “убери точку с запятой”, “добавь точку с запятой”

Чистота

Изменение разных частей приложения по разному влияет на качество кода и его поддерживаемость. Деление проходит где-то в районе слоев MVC и публичных контрактов.

Например сущности которые мы вводим и их отношения между собой вместе со структурой базы это ключевая вещь для прикладного кода. Здесь мы должны четко понимать что движемся в правильную сторону и решаем задачи так как нужно их решать. Эта часть кода должна быть самой чистой.

Модель в этом отношении сильно влияет на публичный API и к нему предъявляются такие же строгие, а может быть местами и более строгие требования. Поменять публичный API задача в какой-то момент невозможная без введения нового API. Каждый эндпоинт, принципы его работы, параметры и все вот это должно быть предельно аккуратным с прицелом на будущее.

Следующим уровнем являются контроллеры и сервисы (в зависимости от того что есть и как организовано). Здесь уровень требований к качеству ниже, так как этот код переписывается без каких-то серьезных проблем, по крайней мере до определенного уровня.

Ну и самое простое это слой View, здесь в целом допустимо делать всякое, потому что View это терминальный слой, на него ничего не завязывается. То что написано здесь не очень, может бесконечно находиться в этом состоянии не влияя ни на что другое.


Тред про чистоту: https://twitter.com/mokevnin/status/1433474955036012547

Прошу понять и простить. На этой неделе не факт что напишу, лечу в Алматы.

Конференция прошла и хотя доклад пока еще не выложили отдельно, он доступен в общем стриме. Все что вы хотели (или не хотели) узнать про конечные автоматы с точки зрения прикладного программирования. Обязательно к просмотру: https://www.youtube.com/watch?v=Yi2E1DIqoow&t=20041s

2 недели в Алматы. Итоги
Послезавтра домой. Поездка получилась зачетной, познакомился со множеством ребят, провел три митапа, выступил на конфе, записался в подкасте (скоро выйдет), договорился с тремя компаниями о сотрудничестве в найме и обучении сотрудников (если у вас есть такой интерес, пишите, будем договариваться). Дай бог позовут и на следующий год)

Будем считать что после небольшого перерыва, я стартану второй сезон постов. Первый вроде бы прошел довольно неплохо, я слышал от некоторых ребят что им нравится мой канал, что конечно не может не радовать. Нас уже 2390 и надеюсь что к концу года будет 4000.

Поделитесь ребят, есть ли темы, которые были здесь и повлияли как-то на вас или вашу работу. Такие истории заряжают.

И пару слов о том, что будет дальше:

⁃ Бизнес для разработчиков, немного про взгляд со стороны владельца
⁃ SEO для разработчиков, о чем надо обязательно помнить
⁃ Операционные системы для разработчиков
⁃ Конечно же практики, принципы и шаблоны проектирования
⁃ Инфраструктура, devops и вот это все
⁃ Как работает и не работает обучение
⁃ Да и всего остального по немногу

p.s. доклад закрыли, но жду когда выложат уже нормальную версию

Моя цель, уволить максимальное количество программистов
Слайд с таким посылом недавно попался мне на глаза. Несмотря на кликбейт, она мне понравилась, потому что соответствует моему восприятию мира как владельцу бизнеса. Расскажу вам немного про это и если зайдет, то буду переодически писать посты про связь бизнеса со всем остальным. Тема эта достаточно болезненная, поэтому я буду аккуратен)

Среди разработчиков существует миф, что главное хороший продукт, остальное приложится. Когда разработчик мечтает о стартапе, он думает о том какой стек технологий он выберет, какие фичи реализует и как круто будет масштабировать проект под нагрузками.

В реальности все не так. Продукт имеет гораздо меньшее значение чем маркетинг и продажи. Маркетологи и продажники зарабатывают деньги, а программист их тратит. Никакие фичи не делают так что раз и мы стали зарабатывать больше денег. Максимум на что они влияют, в большинстве случаев, это на удержание пользователей.

Возьмем для примера Хекслет. Вы наверное удивитесь, но в компании работает около 100 человек из которых программистов работающих над платформой фултайм 4 человека. А вот в маркетинге и продажах 30 человек. Хватает ли нам столько программистов? Нет, мы хотим делать намного больше фич чем мы делаем. Будем ли мы нанимать больше программистов? Нет, потому что найм каждого программиста рождает такой сильный расход, что его не так просто окупить. А работа программиста сама по себе эти деньги не приносит.

Как тогда крупные компании нанимают сотнями и тысячами? Правда заключается в том, что большинство этих проектов адово убыточные и нередко существуют на шальные деньги (привет зеленый небанк). А такие проекты как Хекслет, которые живут на свои, должны быть прибыльными, потому что это единственный способ существовать и развиваться.

Все это приводит к тому, что мы максимально внимательно относимся ко всему что мы делаем. Можно что-то решить не разработкой, а административно? Тогда делаем так. Можно использовать готовый сервис, а не писать свое? Делаем так если справимся с поддержкой.

Ребят, мне нужен СТО или близкий к этому человек, который сможет провести обучение порядка сотни человек по темам:

Менеджмент: o2o, командообразование, роли, конфликты, мотивация, методологии
Бизнес: техдолг, управление скопом, приоритизация

Нужен человек с богатым и успешным опытом по всем этим темам + с опытом проведения подобных мероприятий в виде курсов/тренингов/семинаров/мастер-классов.

Писать можно на [email protected], там же обсудим и денежный вопрос. Лайк, шер, алишер

Что я понял о разработке начав общаться с бизнесом
Было время, когда я долго не мог отпустить разработку и мне было страшно от мысли, что я перестану общаться с этим кругом людей, где так здорово можно обсуждать новые фреймворки, функциональное программирование и высокие нагрузки. Но понемногу проблемы и задачи компании меня поглотили и разработки в моей жизни стало не более 10% времени.

Дальше произошло интересное, я вдруг увидел, что общаться с бизнесом не просто интересно, а очень интересно и, что меня особенно поразило, то как изменился формат общения.

Когда между собой общаются владельцы бизнесов в одной нише, то они всегда с жадностью слушают других, пытаясь узнать все до деталей и найти точки улучшения, например, подтвердить и опровергнуть существующие гипотезы, чтобы не тратить на это свои ресурсы. Споры, при этом, возникают редко, так как всегда можно показать работу тех или иных вещей на конечных цифрах. Например в эдтехе есть такой рейтинг, где можно понять кто есть кто и куда мы часто обращаемся https://edtechs.ru/

С разработкой же все часто по другому. При сравнении проектов друг с другом, у разработчиков часто возникает желание не разобраться в том как у них, а скорее получить подтверждение что у нас лучше, что мы правильнее. Причем я сам ловлю себя на мысли, что когда начинаю общаться с девами, то могу не заметить, как оказываюсь посреди спора о том, какой стек для бека надо выбрать или как лучше выстроить систему обработки событий.

В целом, такие споры конечно же нужны, но, все же, разработчики слишком категоричны. Вот так правильно вот так не правильно. Вы делаете по другому, значит у вас не правильно (посмотрите просто реакцию на некоторые мои твитты).

Я думаю, что одна из причин такой ситуации в том, что в разработке практически нет объективных показателей, позволяющих сравнивать команды и проекты между собой. Нельзя понять насколько вот то о чем говорит команда это нормально и сделать проще было нельзя. Все что происходит внутри это магия. Да можно долго рассказывать как все круто на конфах, а потом приходит Маск, увольняет большую часть инженеров и в течение года в разы уменьшает нагрузки, кодовую базу и сложность системы, значительно сокращая стоимость разработки и сопровождения. https://twitter.com/XEng/status/1717754398410240018

Выводов никаких нет, просто наблюдение. А вы чувствуете что-то в среде программистов?

Что отличает разработку от остальных направлений
Последний пост про отношение бизнеса и разработки. Дальше переключимся на технические темы

Когда управляешь компанией, то разработка становится одним из многих компонентов системы, причем в случае Хекслета, довольно автономным, команда отлично справляется и ее не нужно контролировать. Гораздо больше приходится заниматься образовательной частью, финансово-административной, наймом и другими вещами. Но несмотря на это, разработка занимает особое место в система из-за одной особенности, которая в других направлениях так не проявляется.

Речь идет про принятие решений в подразделениях и их дальнейшее влияние на компанию. В большинстве подразделений, ошибки на уровне исполнителей не являются фатальными. Даже если мы потеряли деньги, то сама ситуация обычно легко выправляется исправлением процессов, обучением или заменой людей. Принятие решений сейчас не имеет сильного влияние на решения принятые потом с точки зрения их реализации. Обычно мы можем сказать “забыли что было, делаем по новому”.

Так работает почти везде кроме нескольких направлений среди которых разработка. Главный риск с разработкой связан с тем, что неверно принятые решения сейчас, могут потом тянуть нас вниз годами вплоть до самого конца существования проекта без шансов это изменить. Причем это не всегда зависит от разработки, обстоятельства могут поменяться так сильно, что система просто для этого не преспособлена и это сказывается на time to market. Архитектура проекта имеет чертовски важное значение и поэтому человек, который отвечает за него с технической точки зрения, должен быть очень здравым и прокаченным одновременно.

С этим связана проблема, что при поиске такого человека, никто не может оценить его уровень, в отличии от остальных направлений, где владелец компании либо уже разбирается либо разберется. Поэтому очень часто такие люди являются сооснователями проектов.

Выложили мой доклад "Конечные автоматы как способы значительно упростить логику и понимание кода" https://youtube.com/watch?v=knoVv2ncwVI Если вам кажется что конечные автоматы это что-то на университетском, то обязательно посмотрите

Зачем спрашивать алгоритмы на собесах?
Недавно я записывался в подкасте, где мы с ребятами обсуждали вопрос требований опыта и накрутки опыта. Например в вакансии часто написано +3 года опыта или что-то такое. Многие от этого негодуют, так как увидеть разницу между теми кто в области 2 года и 3 очень непросто. Тут скорее уже зависит от того где и как конкретно провели эти два года человек. В целом, же, отношение со стороны разработчиков к этому скорее негативное, мол нафига они это делают и сами заставляют накрутить опыт, вот вам примеры.

И хотя я согласен, что с точки зрения реальных скилов +5 или +7 не делают разницы в большинстве случаев, мне же все же хочется подсветить эту проблему со стороны нанимающих. Почему многие компании делают такие ограничения. И не только такие. Например ставят на входе алгоритмические задачки или еще что похуже.

А ответ тут очень простой. Если у вас входящий поток больше чем требуется или его качество ниже чем вы бы хотели, то в этот момент начинается подкрутка таким образом, чтобы вход был более качественным. Причем ни у кого нет ни времени ни желании разбираться в том, какой с той стороны гениальный программист и даже со своим небольшим опытом, он даст фору всем остальным. Это все слишком долго и сложно. Гораздо проще выставить формальные критерии, которые оставят такой поток, который достаточно хорош чтобы с ним работать. А что если мы пропустим хорошего? В этом и смысл. Невозможно создать систему которая четко разграничивает правильных людей от неправильных. Если у вас низкие требования, то тогда попадает много ребят, которых вы бы не хотели брать на работу (и тратить ресурсы компании на работу с ними), если у вас высокие требования, то тогда вы начинаете пропускать хороших кандидатов и, что очень важно, это осознанный выбор таких компаний.

Сюда же, во многом, относится требование алгоритмов на собесах, даже если они на практике не понадобятся. Просто таким образом мы регулируем качество потока (а не отдельных личностей) плюс это влияет на культуру компании, так как ребята с таким бекграундом мыслят немного по другому, чем, например, самоучки (типа меня).

Для крупных компаний уровня фанга, гораздо важнее “не впустить в компанию неподходящего кандидата”, чем “упустить хорошего”.

Да от этого бывает больно, но система важнее, чем локальные оптимизации.

Классно об этом написано в книге https://market.yandex.ru/product--uiliam-paundstoun-kak-sdvinut-goru-fudzi-podkhody-vedushchikh-mirovykh-kompanii-k-poisku-talantov/1781729839

Мы готовы врываться снова в эфир! Второй сезон подкаста "Помогите, я джун" можно официально считать открытым!🎉

Выпуск с Кириллом уже на Яндекс.Музыка, YouTube, Spotify и других привычных платформах

Мы ожидали разговора про лайф хаки при подготовке к теоретическим вопросам и практическим заданиям, но Кирилл поднял вопросы о моральной подготовке, стрессе и рассказал много своих историй.

- Что поможет ощутить уверенность в готовности к первым собеседованиям?
- Что о вас скажет ваша реакция на стресс?
- Как подготовиться к теоретическим вопросам и лайв кодингу?

Вот ссылка на сборник тестовых заданий, о которых говорил Кирилл

Понравился выпуск? Нам тоже! Поддержите нас лайком на платформе, где вы прослушали выпуск. Нам это будет очень приятно ❤️

Насколько сложно поменять стек разработки?
Моя грубая оценка такая. Выход на тот же уровень производительности в другом стеке в том же направлении, например, беке или фронтенде займет полгода. Что входит в это время?

Самое простое это изучение нового языка. Для опытного разработчика, переход на соседний язык (та же парадигма) довольно простая задача. Пару недель на основы и еще пару месяцев на то, чтобы постичь более сложные концепции, которые будут встречаться в работе. Сюда же можно отнести адаптацию к новым подходам, которые приняты в языке или являются следствием его дизайна. Например в Ruby много метапрограммирования, в Java шаблонов проектирования, в JavaScript асинхронности, а в Go флоу построенного на горутинах.

Дальше идет экосистема. Вот эта часть пожалуй одна из самых сложных, так как количество библиотек и особенностей их использования в каждой экосистеме невообразимое количество. Чем более навороченная экосистема, тем сложнее и дольше будет этот процесс. Например переход на Spring Boot с фреймворков Rails, Django или Laravel это сложное занятие из-за количества компонентов и их глубины. По некоторым типа Spring Security пишут целые книги.

Ну и последняя часть инфраструктурная. Способы сборки, доставки, саппорта могут отличаться. То как собирается фронтенд это свой собственный мир. У статических языков есть этап компиляции и много построено вокруг этого. У динамики проще всего, но тоже есть свои особенности. В целом этот этап изучается довольно быстро, если конечно вам не приходится настраивать webpack.

Вы меняли стек? Сколько заняло время и откуда куда?

Не могу молчать. Ребят я очень рад тому что почти под каждым постом возникает большая дискуссия. Вы вдохновляете на то, чтобы продолжать писать! За какашку тоже спасибо, она радует глаз 🙂 p.s. Давайте посчитаемся сколько нас тут реально читает. Поставьте какашку если вы видели пост)