Как не уронить свою пирамиду тестирования?

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

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

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

На прошлой неделе я потратил несколько дней, чтобы разобраться с падающими тестами в одном из сервисов.

Причем, если ответственные за тесты не указаны, то следуете алгоритму:

1. Ищешь возможную проблему в связанных сервисах (кто-то мог сообщить об этом).

2. Если проблема не найдена (а так обычно бывает в 99% случаев), то идешь в канал для обсуждения общих проблем при разработке, задаешь вопрос и ждешь.

3. Если повезет, оперативно могут подсказать ответственных за сервис и ты идешь уже к ним.

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

4. Запрашиваем помощи ответственных за тест - обычно апрув, чтобы была возможность пропустить упавшие тесты и задеплоить свои изменения.

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

Выводы:

1. Особенно, если вы QA, следите за пирамидой. Не допускайте в своем проекте антипаттерна "рожок мороженого" и следите, чтобы e2e было адекватное количество и они относительно стабильно работали или была четкая документация на случай проблем.
2. Если часто становитесь борцом с такими тестами, как я, то старайтесь выработать универсальный навык траблшутинга и поиска ответственных.

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

@time2code

🚀 Про Big Tech, инженерную культуру, людей и продукты, которые они создают.

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

Меня зовут Александр Новиков, и я инженер, который прошел путь от обыкновенного специалиста до продуктового бекенд-разработчика в настоящем Big Tech.

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

Этот канал - отражение моего профессионального развития и трудностей, с которыми я сталкивался, а также решений, которые помогли их преодолеть.

Несмотря на текущую позицию, мой путь продолжается.

Здесь я делюсь практическим опытом и поднимаю серьезные темы о современной разработке.

Если то, о чем пишу, откликается, буду рад вашим комментариям или реакциям к постам — это мотивирует меня писать больше и помогает понять, что материал полезен.

Путь в Big Tech:

- С какого языка программирования начинать и как решиться на первые шаги (читать)
- Как не потерять мотивацию (читать)
- Где брать идеи для пет-проектов (читать)
- Смена языка программирования (читать)
- Как попасть в компанию уровня Avito (читать)

Избранные посты:

- You are gonna need it (YAGNI v2.0) (читать)
- Как все успевать? (читать)
- Как научиться проектировать систему? И кому это нужно? (читать)
- Подчиняем performance review (читать)
- Мышление письмом (читать)
- Иллюзия простого языка (читать)
- Как расти в Big Tech (читать) и моя рефлексия за два года работы в нем (читать)
- Как я сделал блог на Hugo (читать)
- Возможно ли сохранить отношения после код-ревью? (читать)

-> Сайт
-> GitHub
-> LinkedIn

@time2code — не только про мой опыт, но и про общение. Делитесь своими историями в комментариях или предлагайте идеи для поста в личные сообщения. Давайте обсуждать сложные темы, расширять сеть контактов и учиться друг у друга.

Пул-реквест как отражение инженерной культуры

Как отбить желание смотреть ваш пул-реквест? - Вот отличный пример из опен-сор проекта PocketBase: непосредственно ПР.

Конечно, это гипербола, но через крайности объяснять суть всегда нагляднее.

Что мы имеем: изменено 147 файлов, сделан 1 коммит.

Думаю, никто не удивится ответу автора проекта:
"Thank you for spending your time on this but this type of changes are not really welcomed as I don't really see much point of reviewing 140+ files."

Занавес...

Я не раз говорил о важности маленьких шагов: как они помогают достигать целей и побеждать прокрастинацию.

Но сейчас речь пойдет про то, какие изменения за один раз мы деплоим на прод.

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

Никто не спорит: удобно выбрать все изменения и в одном коммите под знаменем "рефактор" отправить на удаленный репозиторий, но это очень темная дорожка и вам не нужно по ней идти.

Если с коммитами все понятно, то с ПР все гораздо интереснее, тут возможны варианты.

Поменялось ли что-нибудь, если изменения в 147 файлах шли не одним, а десятком коммитов в одном ПР-е? - Не думаю.

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

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

И тут вам прилетает уведомление: у вас 3 новых пул-реквеста:

ПР 1:
- "Добавляю новые правила валидации, изменяю логику для стораджа и делаю небольшой рефактор"
- 16 коммитов (атомарные, понятные)
- изменено 5 файлов, добавлено 2 (1 для тестов на правила валидации)

ПР 2:
- "Прокидываю клиент для метрик и начинаю писать технические метрики для фичи Отображение на карте"
- 5 коммитов (атомарные, понятные)
- изменено 3 файла, добавлен 1 для тестов

ПР 3:
- "В соответствии с задачей VRT-2231 добавляю новую логику"
- 3 коммита (неатомарные)
- изменено 2 файла, добавлен 1 (без тестов)

Какой из этих вариантов посмотрите в первую очередь? Я бы смотрел так:
2 -> 1 -> 3

Объясню:

1. Сперва описание. Если оно есть и понятное - уже очень хорошо. Но, если на первой же строке вас за дополнительным контекстом отсылают в Джиру, то это тревожный звонок - вероятно, ревью затянется.
2. Если изменения составляют инкремент, как история с метриками во втором ПР, то это явный кандидат на приоритетное ревью. С ним можно быстро разобраться и пойти дальше, позволив понятным изменения быстрее оказаться в проде.
3. С ПР 1 и ПР 3 - интереснее. Начну с первого, так как есть большой шанс, что здесь потребуются доработки и я быстрее смогу дать фидбек ребятам на исправление, так как нужны серьезные причины, чтобы столько всего предлагать в одном ПР-е (почему не разбить на 3?).
4. ПР 3 уходит напоследок, так для погружения в контекст потребуется гораздо больше ресурсов (из описания вообще ничего не понятно).

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

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

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

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

@time2code

Продай мне эту ручку систему. Неожиданные инсайты System Design

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

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

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

И в этом главная техника продаж: сперва вы должны понять нужды и ценности клиента, а затем спроецировать предлагаемое решение и продукт на них.

Здесь можно увидеть, как автор популярной фразы - Джордан Белфорт - "продает" ручку, подробно объясняя всю суть упражнения.

Основная ошибка - пытаться продать любой ценой, не понимая цели.

То же самое касается System Design на интервью: не нужно сразу бросаться рисовать систему и защищать свое решение, которое пришло вам в голову, любой ценой. Секция проектирование не про это.

На днях я завершил книгу автора Алекс Сюй System Design "Подготовка к сложному интервью".

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

Предлагается следующий алгоритм:

Шаг 1: Понять задачу и определить масштаб решения
Шаг 2: Предложить общее решение и получить согласие
Шаг 3: Подробное проектирование
Шаг 4: Подведение итогов

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

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

Интересно, но параллельно с моим чтением книги этой осенью Алексей Рыбак с экспертами разбирали некоторые главы из этой книги. Вот ссылка на обзор главы "Проектирование хранилища типа “ключ-значение” - рекомендую ознакомиться, если хотите углубиться в тему.

Запомнить: секция «проектирование» на собеседовании - это про диалог.

Воспринимайте это как продажу ручки: поймите потребности клиента и предложите решение, которое их может закрыть.

@time2code

Ноябрь 2024:

развитие

✔️ Завершил внутренний курс по обучению инженерной культуре. Изучил темы: паттерны проектирования (observability, асинхронный обмен, проектирование стабильного API и другие), продуктовая аналитика (включая архитектуру корпоративного Data Warehouse) и модуль по эффективной фасилитации встреч.
✔️ Приступил к изучению
F# в рамках обучения ФП.
✔️ Прочитал книгу по System Design «Подготовка к сложному интервью».
✔️ Разобрал паттерн “Декоратор” на Go.
✔️ Стал ментором нового инженера из соседней команды на период его онбординга.

прочее

✔️ Написал 5-ый пост в LinkedIn.
✔️ Обновил закреп канала.
✔️ Запустил для себя челлендж, в котором на каждой из недель (оставшихся до НГ) делаю рывок в направлении закрытия годовых целей.

посты

🔖 Возможно ли сохранить отношения после код-ревью (читать)
🔖 Готовимся к фичафризу и закрываем цели (читать)
🔖 Как не уронить свою пирамиду тестирования (читать)
🔖 Пул-реквест как отражение инженерной культуры (читать)
🔖 Неожиданные инсайты System Design (читать)

#результаты

Кто такой Senior?

Когда еще не занимался программированием, а лишь наблюдал со стороны, то популярные IT-градации: junior, middle, senior - воспринимались совершенно иначе, чем сейчас.

И если с начальными грейдами относительно просто, то определить в какой момент человек становится синьором достаточно сложно.

Для визуализации сравнил грейды международных Big Tech-компаний.

Фиолетовой полоской обозначил диапазон минимального и максимального уровня «синьорности» (источник).

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

Вообще это все условности, чтобы усреднить роли на рынке и соискателям с рекрутерами было бы проще находить пересечения.

Далее посмотрим на то, по каким компетенциям реально можно определить грейд.

А пока - предлагаю каждому ответить на вопрос: как вы определяете, кто такой senior?

@time2code

Хочешь стать Senior инженером? Начни с мышления.

Я много думал на эту тему.

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

Конечно, это преувеличение, но такое было направление мысли.

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

И это абсолютно нормально.

Во-первых, производительность в IT нельзя определять исключительно скоростью работы, то есть количеством строк кода в единицу времени.

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

❓Так в чем же все-таки их отличие?

Синьор разработчик оперирует гораздо большим контекстом.

Приведу пример: нужно добавить зависимость от нового признака - другими словами, просто еще один if, не больше, ни меньше.

Мышление не синьора:
- где написать код
- проверить работоспособность
- написать юнит-тест на новую логику (в лучшем случае)
- обновить документацию (в идеальном случае)

💪 Мышление синьора:
- за что отвечает новый if: в какие продуктовые метрики целимся
- насколько это важный функционал, нужно ли предусматривать graceful degradation в нештатных ситуациях
- правильно ли это делать на уровне потенциально рассматриваемого сервиса
- уведомлены ли владельцы сервиса или домена, где происходят изменения, о новом функционале (если нет - сначала согласовать)
- увеличится ли нагрузка на сервис или связанные с ним системы (если да - сначала согласовать)
- какие есть ограничения мобильных клиентов (есть ли завязка на версию приложения и пр.)
- какими техническими метриками нужно покрыть код
- какие логи нужно собирать
- нужна ли аналитика
- (. . .)
- и только затем 4 пункта: где написать код и т.д.

Конечно, по факту решение может быть абсолютно таким же (код в каких-то местах может быть даже хуже).

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

Про разницу грейдов легко думать в следующем ключе: обычный разработчик декомпозирует задачи, синьор - декомпозирует проблемы.

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

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

@time2code

Цена невнимательности в высоконагруженной системе

Биг Тех - это не только сильная инженерная культура и хорошо выстроенные процессы, но и высокие нагрузки - так называемый high load.

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

В Авито есть Metadata management system или как ее называют внутри - "Инфомодель" (далее буду называть ИМ). Подробнее можно послушать в докладе.

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

Пару недель назад произошел интересный случай. В ходе решения одной из задач мне потребовалось сделать изменения в ИМ - добавить скрытый и необязательный атрибут. Делается это довольно быстро, есть удобная админка для таких сценариев.

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

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

Вдруг - прилетает новое обращение от пользователя связанное с ошибкой при подаче объявления.

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

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

Чтобы не делать серию постов про еще одно расследование бага, перейду сразу к сути.

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

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

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

Какой итог?

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

Таким образом, одно неаккуратное действие, на которое я затратил менее 15 минут времени, стоило мне проблем, на разрешение которых я потратил ощутимый ресурс.

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

@time2code

Мощная привычка, которая отличает опытных разработчиков

Самый ценный совет, который я получил в начале карьеры программиста: пишите юнит-тесты.

У многих неопытных разработчиков требование написать их вызывает прокрастинацию или скуку.

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

✍️ Почему важно писать юнит-тесты:

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

2. С вероятностью 90% после написания тестов вы так или иначе сделаете фикс в свою бизнес-логику: где-то пропустили проверку на нулевой указатель, где-то забыли обработать ошибку, где-то вышли за предел массива при случайном наборе данных, а может элементарно вы что-то не учли или после тестов поняли, что лучше будет добавить еще один слой абстракции.

3. Это сильно поможет в поддержке большой кодовой базы. Например, когда над проектом работает множество команд, то нет ничего проще, чем случайно задеть чье-то незадокументированное поведение. Если будут написаны юнит-тесты, то вы это сразу заметите при очередном прогоне линтера (он должен быть настроен и каждый раз прогоняться на CI/CD).

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

На код-ревью я всегда обращаю внимание на наличие юнит-тестов. Если их нет, то я не понимаю протестировал ли автор свой код.

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

Пункт #2 у меня появился неспроста - это фактически отражение моей практики.

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

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

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

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

💪 Как можно выработать эту привычку?

В IDE можно настроить code coverage. Но он может раздражать.

У меня нередко были ситуации, когда я не мог пройти линтер в сервисе, получая предостережение:
Low code coverage: 90.0 < 90.0

Возможно, порог в 90% покрытия тестами избыточен, но 70% - это адекватный минимум, который должен быть.

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

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

@time2code

Продуктовая разработка одним слайдом

Почти 2 недели (начиная с 1 марта) у меня ушло на встречи.

Для меня это много, и я бы точно не хотел это количество увеличивать.

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

Важно учитывать, что любая встреча (даже 15 минут) занимает больше времени, чем непосредственно ее длительность:

- это подготовка ко встрече;
- дорогое переключение контекста на нее;
- и возвращение в рабочий режим.

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

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

📝 А еще: используйте асинхронное общение, где это возможно.

А сколько времени у вас занимают рабочие встречи? Для вас это много или мало?

@time2code

Декабрь 2024:

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

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

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

ключевые события

✔️ Со своей продуктовой командой запустили крупную фичу для пользователей, к запуску которой мы шли весь квартал и очень плотно трудились, чтобы это стало возможным. Уже за первую неделю показали крутой результат и закрыли ОКР.

✔️ Стал ментором младшего инженера из соседней команды на период его онбординга. Поставил встречи 1-1 и уже провел несколько, по результатам которых получил положительных фидбек.

✔️ Много практики на F#. Решил десятки задач с рекурсией, через которые знакомлюсь с языком. Удобно изучать ЯП через подобные задачки + хорошая тренировка ума.

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

посты

⭐️ Хочешь стать Senior инженером? Начни с мышления. (читать)

🔖 Цена невнимательности в высоконагруженной системе (читать)

🔖 Мощная привычка, которая отличает опытных разработчиков (читать)

🔖 Кто такой Senior? (читать)

🔖 Продуктовая разработка одним слайдом (читать)

#результаты -> #дайджест

@time2code

5 шагов для крепкого селф-ревью (секретный рецепт)

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

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

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

А если же вы можете проставить ✔️ возле каждого из следующего пункта, то все, что вам нужно будет - это собрать все воедино, следуя определенной формуле.

Итак, надеюсь, вы:

1. Хорошо поработали в прошлом периоде :)
2. Фиксировали результаты своей работы и базово то, над чем работали (мелочи важны - потом лишнее можно будет убрать).
3. Успели насобирать продуктовых метрик о том, как вы улучшили мир. Без этого, к сожалению, будет проблематично доказать свою ценность. Проще всего за цифрами сходить к продакту, но можно и к тимлиду, и даже к аналитику (но это совсем на крайний случай).

Когда все ингредиенты собраны, остается только выбрать рецепт, по которому это можно вкусно подать.

Спустя пять периодов перформанс ревью я нашел такой:

3ORV (Objective Output Outcome Role Volume => three O R V).

Три ОРВи звучит не очень благозвучно, поэтому мне больше нравится произносить как "thrive" - что означает "процветать" и, вероятно, поэтому и работает.

Рассмотрим по шагам.

Цель (Objective)

Шаг 1 - Копируем и вставляем название ОКР'а или ключевого результата.

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

Что сделано (Output)

Шаг 2 - Копируем и вставляем артефакты нашей работы, которые собирали за весь период (если же не собирали, то предстоит увлекательное путешествия в недра Джиры, Гита и мессенджера, чтобы поднять всю свою работу; тут может пригодиться удобная формула для выполненных задач в Джире).

Здесь идет перечисление вашей работы: разработал сервис, проресечил проблему и декомпозировал задачи - все в таком духе. Обязательно указывать ссылки на ПР-ы, issues и треды в мессенджерах для подтверждения своих слов.

Какой результат принесло (Outcome)

Шаг 3 - Копируем и вставляем цифры, полученные от продакта / тимлида / аналитика.

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

Роль (Role)

Шаг 4 - Указываем зону ответственности, например: Разработчик Backend.

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

Объем (Volume)

Шаг 5 - Указываем цифру, например: 3 спринта.

Цифра в спринтах / кварталах. Может потребоваться подсчет, но можно и приблизительно.

Если работаете с матрицей компетенций и остается место, то можно еще добавить блок с ссылками на проявленные компетенции в ходе своей работы (имеется в виду, что вы проявляете компетенции инженера более высокого грейда).

И все!

Пример селф-ревью по методике прикреплю в треде.

Такой подход помог мне качественно оформить 7 целей на 800 знаков каждая (лимит на цель), возможно, будет полезен и вам.

@time2code

Форс-апдейт без негатива: это реально?

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

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

Любое дополнительное действие для пользователя - это стресс.

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

Конечно, обычно не все так пасмурно и обновление приложения происходит проще.

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

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

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

🛴 от онлайн-магазина Самокат

+ Сочная обложка со свежими фруктами.

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

🌻 от сети магазинов Лента

+ Вас вежливо просят.
+ Вам дарят скидку на заказ! Фактически меня это и вдохновило на этот пост. Нигде не видел при форс-апдейте, чтобы негатив сумели преобразовать в позитив и в желание скорее воспользоваться предложением. Сразу видно, где подумали о пользователе.

- Стандартное системное окно. Можно было бы что-то красивое придумать, но для меня важнее, что подумали про содержание, нежели чем про обертку.

Конечно, если у вас миллионы пользователей, то раздавать регулярно по 200 рублей на человека может выйти немного накладно, отсюда несколько мыслей:

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

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

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

4. Пока готовил этот пост, зашел на форум ios-разработчиков и почитал Reddit. Там было предложение ограничивать доступ к новым функциям вместо форс-апдейта. То есть вы просто уведомляете, что какие-то фичи доступны только в новой версии, а старый функционал не пострадал и доступен без обновления.

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

@time2code

Мои карьерные ОКР на 2025 год

Планирование занимает много времени, а хорошее планирование может занять все, поэтому важно вовремя остановиться.

У меня получилось 4 основных приоритета на год, в каждом до 4-х ключевых результатов.

0️⃣ > Взятие следующего грейда

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

Ключевые результаты:
- KR 0.50 - Перевод трафика на проект, разрабатываемый в рамках рабочего тех. OKR
- KR 0.30 - Разработать механизм масштабирования для инициативы X
- KR 0.20 - Вынос специфичной логики из сервиса Y в домен Z

1️⃣ > Развитие сильного мышления

Эта цель более абстрактная и состоит из разных векторов развития, нежели каноничных ключевых результатов. Планирую сделать упор на SRE, Практики DevOps, архитектуру фронтенда и микросервисов.

Ключевые результаты:
- KR 0.40 - Пройти школу SRE от LinkedIn
- KR 0.25 - Пройти курс по архитектуре FE
- KR 0.25 - Прочесть 2 книги по микросервисной архитектуре
- KR 0.10 - Пройти курс по лучшим практикам в DevOps

2️⃣ > Усиление бренда

Основной фокус на развитие блога и LinkedIn.

Ключевые результаты:
- KR 0.50 - Аудитория @time2code выросла до 300 человек
- KR 0.30 - LinkedIn Challenge -> каждый месяц по 1 посту
- KR 0.10 - Перевести блог с github pages на свой домен
- KR 0.10 - Статья на Habr или VC

3️⃣ > Математика

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

Ключевые результаты:
- KR 1.00 - Курс по основам математики

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

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

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

#цели

Лямбда-исчисление: зачем оно вам?

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

Так ли это?

На выходных развлекался с лямбда-исчислением (в дальнейшем буду называть "лямбда") и бета-редукцией.

Казалось бы, для чего и как это поможет в работе?

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

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

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

Влияние на разработку

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

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

В реальном коде

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

func LoggingMiddlewareWithHandler(logFn func(format string, v ...interface{})) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            logFn("Request: %s %s", r.Method, r.URL.Path)
            next.ServeHTTP(w, r)
        })
    }
}

LoggingMiddlewareWithHandler – функция, принимающая http.Handler и возвращающая новый обработчик. Это классический пример функции высшего порядка, которая модифицирует поведение переданной функции.

А при помощи logFn мы передаем произвольный обработчик логов.

Использование в коде:

logMiddleware := LoggingMiddlewareWithHandler(log.Printf)
http.Handle("/hello", logMiddleware(http.HandlerFunc(helloHandler)))

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

Что почитать по теме?

Есть полезные материалы на английском языке прямиком из Стэнфорда:

- Подробная публикация с примерами
- Интересная статья с онлайн-калькулятором бета-редукции

Если знакомы с лямбда-исчислением, то пишите в комментариях, что получится в результате бета-редукции 🤓

(λx. λy. x y) (λz. z) a

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

@time2code

Январь 2025:

ключевые события

✔️ Завершился очередной перформанс ревью. Предварительно все хорошо, конкретные результаты менеджеры, как обычно, держат в тайне до момента X. Пора выдохнуть начать готовиться к летнему (см. п.1). Очередной раз убеждаюсь, что, если начать подготовку заранее, то это значительно облегчит этот процесс вам в будущем.

✔️ Начал изучать материалы по SRE. LinkedIn по этим материалам онбордит новичков в SRE. Актуальная документация - отличный инструмент, который следует использовать всем компаниям для обучения сотрудников - это экономия многих сотен часов.

✔️ Погрузился в идеологию VIM и понял, как можно повысить свою эффективность, отказавшись от мыши. Пока продолжаю работать на VS Code, но со временем планирую отказаться и от нее (как уходил от Goland рассказывал в посте). Изучать VIM, когда вы привыкли к удобной IDE, выглядит очень странно и больно. Но есть инструменты, способные сгладить кривую обучения, например: vim-adventures - прошел бесплатные уровни, поэтому могу смело рекомендовать.

✔️ За пару вечеров при помощи AI написал простенький шахматный тренажер на JS (всего 200 строк). "Только я вам его не отдам", так как он не идеален, а сырой проект не хочется показывать. Интереснее здесь не сам проект, а инсайты, которые получил, работая с AI (спойлер: работу у программистов пока не отнимают).

✔️ Завершил курс по F# и освоил базу по лямбда-исчислению. Рекомендую погрузиться в тему, у кого есть проблемы с пониманием рекурсии и лямбда-выражений. Сильно облегчает жизнь при работе с незнакомыми кодовыми базами.

посты

⭐️ Мои карьерные ОКР на 2025 год -> читать

🔖 Лямбда-исчисление: зачем оно вам? -> читать

🔖 Форс-апдейт без негатива: это реально? -> читать

🔖 5 шагов для крепкого селф-ревью (секретный рецепт) -> читать

🔖 Итоги 2024. Целый год по методике ОКР, выводы -> читать

#дайджест

@time2code

30 минут, которые могут изменить ваш продукт

Речь пойдет про мощный инструмент в исследованиях UX: User Day (UD).

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

Вчера поучаствовал как интервьюер на одном из таких дней. За 30 минут удалось задать порядка 40 вопросов о продукте, который мы с командой запустили в декабре.

Большинство вопросов направлено на проверку гипотез, которые формулирует Дискавери команда.

Примеры гипотез:

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

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

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

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

За подробными примерами из практики рекомендую сходить на популярные ресурсы: habr, vc. Так, например, ребята из Selectel пару лет назад делились кейсами, как такие дни помогли им улучшить свой продукт.

Для чего это разработчику?

1. Это интересно

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

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

2. Это расширяет твой кругозор

Когда слышишь реальный рассказ про опыт взаимодействия с твоей фичей, то начинаешь думать иначе. К техническому мозгу добавляется продуктовый и теперь, когда появляется задача от бизнеса, тебя не только заботит реализовать ее "as is" (лишь бы она была рабочая и отказоустойчивая), но невольно начинаешь думать про UX и по возможности стараешься влиять на это.

Тема раскрывается в книге "Психбольница в руках пациентов" Алана Купера. Планирую в этом году ее дочитать, хоть и говорят, что она немного устарела.

3. От тебя это ожидают

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

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

Вывод

Это мой второй юзер-дей за 2,5 года в компании. И хоть он требует от тебя некоторой подготовки и отнимает время у других задач, это определенно того стоит. Особенно, если вы хотите усилить свои софты.

А вам как кажется: стоит ли инженеру интересоваться подобной практикой? Может, пусть команда UX вместе с Продактами этим занимаются, а мы лучше сфокусируемся на хардах?

@time2code

Выжимаем из performance-review максимум

Недавно я делился собственным фреймворком для написания селф-ревью - 3ORV.

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

Фреймворк работает

Объявили результаты прошедшего периода, и мне удалось получить "сверхрезультат"!

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

Но кроме самого результата есть также и отзывы коллег, с которыми я взаимодействовал за прошедший период.

И для того, чтобы выжать из перф-ревью максимум, мы переходим к завершающему пункту нашей дорожной карты => Анализируем

Обозначаем точки роста

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

Как их найти? - Пропускаем отзывы, которые приятно читать, и фокусируемся на оставшихся.

Я их выписал отдельно по следующему шаблону (см. скриншот):

- Грейд
- Фамилия
- Отзыв

Внимательно изучаем отзыв и стараемся емко сформулировать его суть (основные мысли). Фиксируем рядом с хэштегом.

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

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

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

* * *

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

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

Подумайте, а могли ли вы в тот момент поступить иначе и какие результаты бы это принесло?

@time2code