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

Заканчиваем с юнит-тестами.
TLDR: “Бей вперед - игра придет”
(просто начните, если еще нет, хоть с какими-то автотестами)

Вредные советы:
• пишите юнит-тесты на чужой код после того, как код написан, просто для покрытия (мероприятие искажающее ценность таких тестов)
• не пишите юнит-тесты на чужой код (если тестов нет) перед тем, как меняешь код (зависит от объема изменений, возможно нужно писать другого уровня тесты)
• активно используйте привычные и традиционные программерские приемы типа удаления дублирования (приводит к ухудшению читаемости тестов, хотя пункт ооочень холиварный)
• продолжайте игнорировать книги по юнит-тестам и тестированию вообще
• открывайте вакансию “Unit Test Writer” (клянусь - реальность, погуглите, я рыдал, особенно над требованиями)

Полезные советы:
• почитать про мутационное тестирование
• всегда думать, какие тесты для чего лучше* подходят
• всегда думать (всех обнимаю)
*Критерии “лучшести”: скорость написания, скорость обратной связи (запуск, скорость выполнения и диагностика проблем)

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

Поэтому сильно плюсую к этому автору:
“Вообще мне кажется, что разделение на юнит, интеграционные, е2е и т.п. тесты устарело. Сейчас стоит придерживаться другой таксономии: тесты, которые можно прогонять при каждом пулл реквесте, и тесты, которые можно прогонять только собрав релиз.
И тестконтейнерс - один из способов перетащить часть тестов из второй категории в первую.”

Ну и уже от меня, само по себе разделение на “слои” провоцирует на разделение зон ответственности и появление вопроса “кто пишет”: типа разрабы это только юнит-тесты, а e2e - автоматизаторы. Еще один из примеров закона Конвея.

Полезные ссылки:
• Литература по тестированию (с акцентом на разработку).
• Если кому-то нужно про юнит-тесты на C++ (ну вдруг), то вот эта норм, я ее в свое время даже переводить собирался, так понравилась.

#unit_testing #test_automation

PS Ура, таки пятница осталась для мема. А то не все из подписчиков выдержали этот 4-х дневный "марафон". Да и в целом интерес к чтению у вас поугас 😃.
Но мне прям зашло: собрать все в кучку из чертогов памяти, приятная теплота в мозгах.

Хорошего всем завершения трудовой недели.
И старый-добрый мемчик про #unit_testing
#it_memes

Вчера был на первом дне оффлайн-версии Heisenbug.
Года 4 не был уже в оффлайне. Ностальгия 🙂

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

Что поменялось: практически полностью сменился состав спикеров, про пару компаний-спонсоров даже не слышал раньше, ПК стал добрее к процессным и менее хардкорным докладам😉 (и это неплохо для слушателей, а у меня есть возможность побыть “экспертом” 😃 ), да и сам ПК сильно расширился и омолодился.

Наблюдения:
- судя по ответам слушателей на открытии, минимум 3/4 были на Гейзене в первый раз. Интересно, как часто люди приходят 2й, 3й раз (думаю, что 3й уже мало).
- отличные доклады от Ozon Fintech
- конференция живая и развивается
- моя ряха пока еще влезает в фоторамку
#байки

Если не подписаны на ByteByteGo, а работа связана с разработкой, тестированием и тп, то рекомендую. Ребята очень полезные штуки делают в сторону популяризации подходов системного дизайна.
А для собесов вообще хорошо зайдет (в реале то мало кто применяет 🙂, потому что все "знают" как правильно, но никто так не делает).
У них и книги по этой теме есть.
Из свежего, их подборка System Design 101 как раз для разогревочных бесед на собесах и тех, кому хочется одной картинкой понять для чего пригодится Redis, что такое CI/CD или чем REST отличается от GraphQL.
#tech_read

Пусть эта неделя будет немного про резюме/собесы и тп
Сейчас снова подключился к анализу резюме кандидатов и собесам (как ни странно, DevOps-в).
Что можно сказать? А то, что люди, как и раньше, как не “умели” писать резюме, так и не “умеют”.
Просто набор ключевых слов обрамленный глаголами “применял”, “настраивал”, “мониторил” и тп.

А что такое “уметь” писать резюме? Важный ли это навык?
Имхо, влияние качества резюме на итог поиска работы* сильно переоценено.
В 80% случаев на собесе ты будешь его пересказывать и половина собеседующих его даже не прочитают. Важно пройти фильтр, тут помогут ключевые слова и, иногда, имена предыдущих компаний. Фсе.
*если речь про первую работу (джун), то не все так “просто”. Там придется потрудится сначала над тем, что ты сможешь описать (приобрести знания/умения), а потом, как это подать.

Тут вот статья "Resumes suck. Here's the data" (автор ее недавно подкорректировал, раньше она была жестче и категоричней) с описанием эксперимента по качеству отбора по резюме предвещала чуть ли не “смерть” резюме еще 9 лет назад. Но они все еще живее всех живых.
И это логично - это самый популярный и простой способ* себя проиндексировать, классифицировать и отобраться в качестве кандидата на собес.
*я знаю только 3 способа: резюме, личный бренд, “по блату”

Резюме сейчас - это просто набор метаданных к тебе, как соискателю. А дальше получается, что важен навык структуризации этих данных в удобочитаемом формате без синтаксических ошибок.
Само “умение писать резюме” в целом - это умение описать свои задачи и их результаты (это важнее) интересно, зацепить. Но на фоне дефицита опытных IT-шников спокойно приглашаешь даже просто по “ранжированию ключевых слов” из технологий, задач и прошлых компаний.

Завтра про то, как я читаю резюме.

#про_резюме

Дисклеймер: знать, как правильно писать резюме, как быстро его читать и потом им пользоваться на собесе, не равно иметь правильное написанное свое резюме 🫠

Давай сегодня “почитаем” резюме традиционного HH формата (у LI тоже есть свои приколы) Иногда складывается ощущение, что HH целенаправленно делает (ничего личного, бизнес: “дольше ищешь-дольше платишь”) критикуемый многими формат резюме, где раздел “обо мне” (который как раз можно сделать чуть ли не единственным), находится глубоко внизу. В итоге до него мало кто и доходит, если вспомнить с какой частотой сегодня IT-шники меняют работу, а значит все застревают на перечислении компаний с одинаковыми задачами. Обычно я быстро пролистываю до конца и смотрю, есть ли там в “обо мне” что-то обобщенное о кандидате, его задачах и предпочтениях. Это то, от чего отталкиваюсь.
Дальше смотрим последние пару мест работы: выполняемые задачи и какими инструментами (речь не только про инженеров, у менеджера тоже есть свои инструменты, и это не Jira 😃). Про достижения мало кто пишет, но если есть, дополнительный “+” к вопросу приглашения. Из остального формируются будущие вопросы на собесе.

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

Что очень редко смотрю в резюме: образование. Обычно на него смотрю, когда специалист начального уровня, дальше уже все равно. Были случаи, когда уже после выхода на работу и пары месяцев работы, я узнавал, что у новенького нет высшего образования. Знаю менеджеров, которые, наоборот, уделяют этому разделу большое внимание и ищут там любимые ВУЗы, которые по их мнению отражают квалификацию кандидата. И если нет таких вузов, значит кандидат не годится.
В Питере раньше была фишка, выпускники “ФМЛ 239” (очень продвинутая, но школа) всегда его писали в резюме. Есть подозрение, что это такая метка для своих 😉Потому что я чаще всего триггерился в обратную сторону.

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

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

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

Полезные ссылки:
Стрим про резюме и подготовку к интервью
#про_резюме

Сегодня не традиционный пятничный мем, но старая добрая картинка по теме этой недели про резюме, которая висела в коридорах одной из лучших компаний, где я работал, в рамках "информационно-просветительской акции" 🙂
#it_memes #про_резюме

Про тестирование и разрабов (это музыка будет вечной)
На неделе про юнит-тесты я писал, что само по себе разделение ролей и провоцирует вопросы про то, кто пишет тесты.
И вот аналогичное мнение:
“Наличие выделенных SDET (ака Software Development Engineer in Test) сделало для разработчиков доступной заманчивую возможность передать написание модульных тестов на аутсорсинг. Без команды SDET вопрос о том, кто пишет модульные тесты, не стал бы предметом обсуждения: нам, разработчикам, пришлось бы их писать”... “Формально команда состояла из 6 SDE (ака Software Development Engineer) и 3 SDET. На самом деле нас было 9 SDE, благодаря инженерному менеджеру и руководителю тестирования, которые незаметно решили, что нет смысла выделять специальную роль тестировщика, когда мы каждый день выпускаем новые функции.”

И тут другой инсайт: релизный процесс (его частота, вид продукта: SaaS с деплоями раз в минуту или коробка наружу обмазанная сертификацией) тоже драйвит убирать узкие горлышки, мешающие скорости разработки не теряя при этом в качестве, с учетом тестовой стратегии, где скорость отката сбойнувшего изменения важнее “отполированного” ручными тестировщиками продукта.
Картинка там тоже интересная (закинул в комменты, про соотношение типов тестов в зависимости от того, кто их пишет).
Ну и чтобы вы не думали, что такое мнение редкость, вот уважаемый мной Алан Пейдж
“Мне говорят, что «у разработчиков нет времени на тестирование» или что лучше потратить время на разработку программного обеспечения, чтобы его могли тестировать эксперты. (😂 мне тоже так постоянно все говорят)
Странно.
...Тестирование не является отдельной деятельностью от разработки — тестирование является частью разработки. Сказать, что у разработчиков нет «времени» на тестирование, — это все равно, что шеф-повар говорит, что у него нет времени пробовать свои творения. Его также часто называют безработным поваром."

Итого: пока (надо еще поварить это в голове) я согласен с выделением "нагрузочников" в отдельную роль, но "автоматизаторы" - это рудимент. Автоматизировать проверки должны разработчики.

#unit_testing #test_automation #testing

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

В комментах иногда цепляем больные (для меня) темы холивара🔥, которые потом хочется отдельно помусолить. Вчера, вспомнил про фулстек, но там был циничный юморок и в реальности я топлю за T-shape и надо будет подумать об вас на эту тему подробнее.
Сегодня будет про code review.
Если совсем коротко, то, на мой скромный взгляд, одна из самых переоцененных, но часто используемая практика, которой пытаются чего-то достичь. Почти никто не думает о реальных целях, форматах проведения, реальном ее влиянии на итоговое качество продукта и кода, скорость доведения фичи до прода, но все проводят. (Потом правда на каждом ретро обсуждают "почему у нас MR висят на ревью целыми днями")
Хотя на самом деле в большинстве своем, у многих, она сейчас больше мешает, чем помогает.
Имхо, популярность практики связана не с ее ценностью, а человеческой психологией: всегда удобно просто покритиковать кого-то.
С другой стороны, ревью кода в виде обозначения "экспертиза исходного кода программы" входит в ГОСТ по безопасной разработке, что как минимум требует формальной галки проведенного ревью, как максимум ожидает настроенного процесса. То есть вроде полезная штука, в чем же подстава?

Подстава в последовательности шагов ревью и квалификации команды. Остальное вторично.
Интуитивно: если мы делаем ревью чего-то, то мы предполагаем существование этого чего-то. То есть сначала пишем код, потом его анализируем. Потом, по комментам, код меняется и снова ревью. Кто-нибудь анализирует основные причины комментариев? Что заставляет сильно менять код? Как часто находятся проблемы? Могли бы эти проблемы найдены статическими анализаторами, линтерами и тестами (рядом с кодом)?
По моему опыту (давнему разработческому и текущему наблюдающему), если настроен автоматический анализ кода + пишутся тесты, то это намного эффективнее находит проблемы, чем глаз коллеги, особенно, если его экспертиза в разработке или доменной области решаемой кодом сильно разнятся от вашей.
Что нельзя отловить анализаторами и тестами? Ошибки проектирования (хотя считается, что юнит-тесты как-то помогают). Значит добавляем промежуточный шаг, когда разработчик предлагает сделать ревью не готового кода в 100500 изменений, а драфта возможного решения: набросок кода, схемы предполагаемого взаимодействия (data flow, межкомпонентного и тдтп). Это смотрится, обсуждается, дальше реализация, а потом уже или быстрое ревью, или только автоматизация.
Вот кажется, это единственно разумный вид процесса code review. Все остальное - бесполезная трата времени.

Полезные ссылки:
• Stop doing code reviews and try these alternatives (там хороший анализ с примерами исследований и возможных альтернатив)
• И снова про code review или новая единица измерения качества (WTF/minute) (самопис в мою бытность ревьювера)
#holywar #codereview

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

Самый быстрый код - это код, который никогда не выполняется.
Найди сегодня что-нибудь для удаления.
#мысли_вслух

Признаюсь, долго думал, ок/не ок картинка за пределами твиттера.
Но, честно, формат, в котором часто проходит code review, навевает эту аналогию.
Всем хорошего завершения рабочей недели.
#it_memes #codereview

Мысли про observability.
Как правильно на русском, не знаю: наблюдаемость(?), но так я еще ни разу не слышал. PS в комментах подсказали "Обозреваемость"
Очередная модная штука (ну последние лет 5-6), которую мало кто понимает (я признаться тоже скорее интуитивно), но базвордят ею активно.
Реперные точки, базис:
1. С помощью мониторинга мы узнаем, что проблема произошла, тогда как observability дает нам возможность узнать причину проблемы и точнее локализовать сбойнувшее место в системе.
2. Мониторим мы обычно то, про что знаем. Observability позволяет узнать то, что неизвестно (unknown unknowns).
3. Важнейшая характеристика наблюдаемости - это возможность понять поведение системы по артефактам ее функционирования.
4. И хотя логи сервисов являются одним из ценных артефактов, бездумное их расширение вносит проблемы в сам код и его эксплуатацию, не добавляя при этом им полезности.
5. Думайте про контекст. Именно контекст того, как пользователь взаимодействует с системой и что нас привело в конкретную точку и является тем, на чем базируется наблюдаемость.
Полезные ссылки:
• Observability: The 5-Year Retrospective
• Don't attempt to "monitor everything". You can't. Engineers often waste so much time doing this that they lose track of the critical path, and their important alerts drown in fluff and cruft"
• Framework for an Observability Maturity Model
• Monitoring vs Observability with Example
#observability

Я уже признавался в симпатиях к DORA-метрикам.
Добрался наконец-то до отчета 2023 года.
Какие-то интересные штуки буду сюда закидывать.
Начнем с традиционного, с самих метрик для оценки скорости поставки изменений. Первые 2 отвечают за пропускную способность, следующие 2 за стабильность поставки:
• Change lead time - время от комита до завершения его поставки
• Deployment frequency - как часто изменения попадают в прод (задача со * в “коробочных” продуктах с релизами раз в квартал)
• Change failure rate - как часто деплой в прод требует вмешательства, когда что-то пошло не так
• Failed deployment recovery time - какое время требуется для восстановления после неудачного деплоя
И тут уже видим первое изменение: теперь "Mean Time to Recover" обзывается "Failed deployment recovery time" для более точной привязки проблем именно к деплою. Обновите чек-листы для собесов 🙂
Ну а какими, по мнению экспертов, должны быть цифры для этих метрик, смотрите картинку в комментах.

Полезные ссылки:
• Сам отчет Accelerate State of DevOps Report 2023 (ссылка на него традиционно доступна в открытом виде на форме, где тебя просят ввести свои контакты, чтобы ее скачать, надо лишь просто посмотреть ее исходники)
• Про метрики инцидентов (в том числе про то, зачем переименовали MTTR)
#metrics #tech_read

ахаха, смотрю, дора тяжело идет ))
Ну вот вам внеплановых мемчиков в честь вечера нечисти
#it_memes #test_automation

А про удаление ненужного думают не только в этой тележке.
Вчера кучно прилетело про проекты, которые разрабатываются в больших корпорациях для того, чтобы автоматически находить и удалять ненужный код и связанные с удаленными сервисами данные: SCARF (оригинальные ссылки есть внутри этой транскрипции) и Sensenmann (кстати, в гугле таким образом удалили уже 5% старого С++ кода).
Так как реализация обоих механизмов завязана на внутряшку текущей реализации проектов в FB и Google, то вряд ли мы дождемся чего-то открытого и доступного остальным. Но подходы интересные.
#tech_read

Нумерология для менеджеров:
0 - сколько раз вам можно соврать
1 - сколько раз вы можете делать контр-оффер одному человеку (я вообще их не люблю)
2 – минимальное количество прямых подчиненных, которое должно быть у менеджера
3 – минимальное количество кандидатов, с которыми вам следует провести собеседование перед принятием решения
4 - сколько минут можно потратить на болтовню в начале встречи
5 - количество комментариев к документу, после которого вам нужно попросить рассказать о проблеме
6 - число, которое вам говорят люди при вопросе оценить свое удовлетворение работой в шкале от 1 до 10, когда они не удовлетворены ей
7 - дней для первого MR после выхода на работу
8 - процент людей, которых следует оценивать как неэффективных в быстрорастущей компании
10 – максимальный процент, который вам следует рассчитывать при обсуждении оффера
30 – количество дней, прежде чем небольшая проблема из саппорта станет большой проблемой
50 - количество MR, которые хороший инженер должен смержить за 6 месяцев
90 - количество дней, за которое открытая вакансия должна закрыться
100 - раз ты должен прочитать все эти цифры
200 - максимальное количество записей для small data
500 - количество сотрудников компании до того, как ваш генеральный директор станет политической фигурой
1000 - размер компании, при котором вы рискуете прийти в состояние, когда сотрудники начнут думать, что от них ничего не зависит в успехе компании
#management

Крафтотесты... я тоже так раньше называл, потом как-то затерялось.
А звучит ведь волшебно...
#it_memes #testing

Про ясность ваших мыслей и отсутствие вранья

“Одна из наиболее распространенных ошибок управления — отсутствие ясности в случае, когда люди ошибаются в отношении важных, вложенных усилий.”
…
“многие проблемы управления возникают из-за ,попытки быть «хорошим» там, где вам следует ясно выражать свои мысли”
…
“Вы не должны говорить людям, что они неправы, каждый раз, когда они совершают небольшую ошибку. Однако чем больше времени было потрачено, то есть, чем больше ошибка - тем яснее вам нужно быть.”
#management

Как-то потерял Ивана Селиховкина в своей ленте, а он хорошие вещи пишет.
Когда-то занимался у него на курсе PMP, благодаря чему понял, что PrjM-ство не мое (кто-то бы знал, кто-то бы знал, чем придется заниматься спустя 10 лет…)
Рекомендую посмотреть его статью “Как измерять эффективность в ИТ-компании?” про три группы метрик:
• Метрики работы (TTM, CT, FE, Through Output, milestone deviation, etc)
• Метрики комфорта (NPS, текучка)
• Метрики продукта (MAU, DAU, retention, chun, LTV, ARPU)
#management