Нас много раз спрашивали как удобнее всего обрабатывать ошибки и исключения. Рассказываем, как мы это делаем и почему стандартный try-catch не всегда удобен.

Если видос показался полезным — поделитесь с братюнями. И подпишитесь на канал, конечно же

Приятного просмотра!

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

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

Приятного просмотра!

Инфляция тайтлов: 18-летние синьоры уже реальность
(*пост не ставит целью оскорбить или унизить кого-либо)

И к сожалению эта напасть касается нас всех.

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

(Продолжение ниже)

В продолжение поста

Громкому тайтлу можно меньше платить

Громкий тайтл может перекрыть разницу в деньгах, так что получать Principal Software Architect & Visionary Technologist может меньше, чем обычный Developer. Ну и ещё это престижно звучит: уезжал из деревни студентом, а вернулся тем, кого и назвать сразу не получается. Почёт и уважение обеспечены, — думает уязвимый к брехне человек и принимает офер.

Громким званием проще сманить. Люди переходят охотнее в новые компании, если им предложить тайтл выше их текущего + небольшая прибавка зарплаты. Жертве кажется, что она много добилась и двигается по карьерной лестнице вверх, а там уже томятся ещё 20+ гибридных позиций, порождённых инфляцией.

И теперь ничего не понятно

Нельзя наверняка сказать, чем занимается Senior Staff Software Engineer. Где как. Одни компании требуют писать код в 2 раза быстрее, чем Senior Developer. Другие ждут на эту позицию динозавра с 15 годами опыта. В общем, пока не допросишь HR, не поймёшь, что скрывается за названием позиции. А увидя должность Associate Vice President, типичный разработчик вообще пройдёт мимо, подумав, что не про него. И совершенно зря.

Только Executive Director не пишет код. Даже Сеньер Вице-Президент код писать должен.

Хотя науке известен случай когда Executive Director перешел на позицию Senior Developer в другую "нормальную" компанию. Даже так случается 🙂

Ещё один способ оценки квалификации

Если вы руководите не только собой, вам рано или поздно потребуется как-то оценивать и называть квалификацию сотрудников. Самая живучая практика — модель Junior/Middle/Senior/Principal/etc. Но, как мы все понимаем, эти слова мало что говорят о человеке:

— В каждой конторе свой уровень сложности проектов, и что для одних Senior, для других — Middle+

— Инструментов много, владеют ими все по-разному. Вполне нормально, когда Senior не владеет чем-то, что на конкретном проекте не нужно.

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

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

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

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

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

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

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

В Индии же наоборот: все учатся проходить собеседование, а не работать. Количество и качество резюме очень высокое, но по опыту скажу, что всё из индусского резюме можно смело делить на три. Как следствие, требования при наборе в Индии становятся жёстче, чтобы отсеивать Д'артаньянов, которые потом будут SQL-запросы из контроллеров делать. 

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

В комментариях к одной из наших заметок упоминали пассажиров. Мол, зачем нам люди, которые просто сидят и машут веслом, как велено. Они же не добавляют команде ценности. Хотелось бы немного развить эту мысль.
Мы выделяем три главных качества: адекватность, исполнительность и обучаемость. Есть и четвёртое — инициативность.

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

Самостоятельность — способность оценить результат своей или не своей работы и улучшить её, не дожидаясь таски. Например, такой человек увидел повторяющуюся проблему, взял — и решил. Или что-то работало на 80%, а он взял — и улучшил до 99%.

Последовательность — доведение дел до логического завершения, хотя бы какого-то из этапов. Необязательно своими руками, но чтоб проследил и убедился, что готово.

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

К сожалению, таких людей хорошо, если 10%. Это не плохо, кому-то нравится просто веслать и в ус не дуть (мы тоже так хотим на самом деле, но не разрешаем сами себе). Но если у вас на проекте одни пассажиры, быть беде. Придётся директивно управлять, решат все проблемы самостоятельно, и вы как руководитель выгорите в угли. Особенно печально, если среди пассажиров окажутся лиды. Такие способны угробить любое начинание.

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

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

Наверное, самый частый вопрос нам задают про то, как продать команде всё, что мы тут рассказываем про подход, архитектуру и всё добро. И мы обычно отвечали занудно про наработку авторитета, бла-бла-бла. Но есть и альтернативный способ. Цитируем коллегу из внутреннего чата:

Я сказал, что мы будем делать так, потому что мы будем делать так. Это гораздо лучшая стратегия чем устраивать продажи и слушать прения сторон.

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

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

В общем, если у вас есть власть, иногда такой способ наиболее оптимален.

Ну что, признавайтесь, у кого так же на работе?

И это было бы смешно, если бы «скрам мастера» не считали что это действительно так и должно работать

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

Стрим будет сегодня в 18:30 мск, ссылку пришлем перед началом

https://youtube.com/live/NUBvpA1Dqjo?feature=share погнали!

На стриме обещал поделиться статистикой и анализом по багам. В итоге, в нашем проекте типовой баг на бекенде стоит примерно 6,5 часов работы команды - описать баг, назначить исполнителя, поправить, перепроверить, etc. Добавьте сюда время на коммуникацию, переключение контекстов и выйдет почти один рабочий день. При этом тест, который бы предотвратил появление бага пишется/дорабатывается максимум 30 минут (конкретно в нашем проекте). Вот такая интересная математика

На стриме был вопрос — можно ли заменить в e2e-тестах реальную зависимость на двойника (заглушку, мок и т.д.). Видимо, мы недостаточно подробно объяснили свою позицию, потому что от главного QA шлюпки, где я гребу пришел комментарий, что такой подход — харам. Давайте разбираться.

E2e-тесты действительно лучше проводить с реальными зависимостями, но в жизни бывают разные ситуации, например:
- Тестовых подключений может не быть. Провайдер не предоставляет такую возможность. Обычно демо-аккаунт существует, но не всегда. Приходится выводить в прод под фиче-флагом и отлаживаться на месте.
- Нет доступа к тестовым подключениям. Это подвид предыдущего случая. Бывают ситуации, когда тестовый контур изолирован от интернета, и вызовы вовне невозможны.
- Тестовые подключения нестабильны, и получить “зеленые прогоны” затруднительно. Иногда для демо-стенда выделяется слабый сервер, который подходит только для отладки подключения, но не для постоянного тестирования.
- E2e-тесты можно разделить на уровни. На одном уровне проверяется взаимодействие микросервисов А, Б и В, на другом — взаимодействие системы с внешним сервисом Д. Набор сценариев будет различаться между уровнями. Делается с целью возможности запуска тестов например на локальной машине, где внешние сервисы по какой-то причине недоступны
- Сложность или невозможность приведения внешней системы в нужное состояние. Например, для подтверждения заказа во внешнем сервисе требуется ручное воздействие оператора, а API для изменения состояния отсутствует.
- Высокая стоимость запросов к API. Тестовые запросы тоже могут тарифицироваться. В таких случаях можно разделить тесты на уровни и в некоторых сценариях использовать заглушки.

И в этих случаях использовать реальные подключения затруднительно. В идеале надо тестировать всё вместе, но если это невозможно, то можно использовать двойника. Его нужно поддерживать и дорабатывать, что требует затрат, но это лучше, чем ничего. Обычно двойник представляет собой отдельный сервис, который можно создать самостоятельно или использовать инструменты вроде Wiremock Standalone.