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

#management

Очень интересно сейчас выглядит продуктовая разработка в какой-то части отечественных продуктовых компаний: нужно сделать продукт, который повторяет некоторый многим привычный, но иноземный, совокупного возраста лет 10-25. И нужно не просто частями наращивать, а чтобы сразу и полностью копия.
Все вот эти вопросы “а какую проблему решаем?” в традиционной продуктовой (да любой) разработке втыкаются в “вот оно вчера так все работало, и мы хотим, чтобы все так же работало, но с вами”. Огромное поле задач для людей, которые умеют в приоритизацию и переговоры, пока разрабы судорожно повторяют фичи возраста 10+ лет, потому что пользователю нужно именно это. Вот такая вот вроде продуктовая, а как бы и нет, разработка. Некоторые бэклоги забиты на годы вперед. Порешает ли пользователь свои проблемы без новых продуктов? Я думаю, что, в какой-то степени, да (просто пример одного из вариантов решения). Понадобятся ли эти забитые бэклоги после этого, хороший вопрос…
Но это шансы и их надо использовать. И в этой ситуации важны качественные принятые решения со стороны разработки, как на, условно, тактическом, так и стратегическом уровне, позволяющие закрыть вопросы того, что нужно было "вчера" и того, что понадобиться "послезавтра". А это не всегда совпадающие истории...
#байки

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

Молодые родители отмечают каждый новый месяц ребенка в течение года. У владельцев собак то же самое со щенками. Я уже немолодой родитель, да и собаки у меня уже взрослые.
Но вот каналу - 1 месяц 🎉
Спасибо, что подписались и, если верить статистике, даже его читаете (знаю-знаю, не все). С одной стороны, хочется у вас попросить обратной связи: чего добавить, чего убрать (больше/меньше баек, больше просто ссылок без моих комментов, долой засилье мемов). А с другой 🫣, лично меня текущий формат пока устраивает. Но с удовольствием подумаю над вашими предложениями, если кому-то захочется поделиться своими мыслями/вопросами/идеями.
Из удивившего в телеге: в тлг-канале не видно, кто именно ставит реакции под сообщениями (в комментариях видно, а в основных постах - нет). Поэтому не стесняйтесь ставить свои 💩 и ❤️- я все равно не вижу кто именно отреагировал, но зато вашу реакцию на пост можно оценить.
Очень признателен тем, что находит время комментировать, спасибо вам большое, вы помогаете.
Задающие вопросы - для вас в моем ❤️ отдельный уголок.
Погнали дальше…
#байки

Все хэштеги и группа для обсуждения
#байки - истории из жизни
#it_memes - веселые картинки по теме канала
#quality
#testing
#test_automation
#unit_testing
#management
#процессы
#tech_read - полезные статьи
#ваши_вопросы - ответы на ваши вопросы, можно задавать любым удобным вам способом
#holywar - посты, которые могут вызывать горение
#мысли_вслух - короткие, но умные мысли, чаще мои :)
#metrics - про метрики (технические, процессные)
#развитие - посты про развитие, свое и команды
#it_философия - посты-наблюдения про отрасль
#codereview
#observability
#собеседования
#вопросы_с_собесов
#про_резюме
#оценка
#тесты_в_проде
#стратегия чтобы это не значило

Все кому заходит контент, но телега мешает его обсуждать, велком в группу https://t.me/+eVSMX4QvqvxlNjcy

Карьерные лестницы 1.
Так или иначе вопросы развития мозга, в идеале, одновременно с ЗП встают перед каждым из нас.
Многие при этом надеются на то, что этот план развития им предоставит их менеджер. Я бы даже сказал "уверены, что только менеджер может их составить".
И хотя в задачи менеджера или лида действительно может входить “развитие сотрудников”, мой опыт показывает, что лучше получается, когда менеджер дает направления, текущие места приложения возможных усилий, а непосредственно план развития самостоятельно составляется сотрудником. И уже потом этот план совместно обсуждается, полируется и берется в работу.
Понятно, что условный джун не составит себе хорошего плана и тут требуется больше участия лида или опытного сеньора. Но даже в этом случае самостоятельной работы не нужно исключать.
Наличие в компании инженерных “лестниц” серьезно помогает и в составлении планов индивидуального развития, и в обсуждениях пересмотров ЗП*, и в формированиях ожиданий от кандидатов и списков вопроса на собесах.
*Тема увязки уровней компетенций лестницы с уровнем ЗП кажется ожидаемой, понятной и логичной, но не все так просто обычно. Поговорим про это попозже.

Немного полезных ссылок с описаниями возможных уровней лестниц:
1. Карты развития, в целом без привязки к лестницам, но много интересного по разным ролям/языкам и тп. Что важно, упор сделан именно про технику, потому что обычно сами лестницы очень абстрактные. Подобные ресурсы с последующим наложением на потребности команды, как раз и помогают в самостоятельном составлении плана.
2. Один из возможных вариантов лестницы.
3. Ну и еще одна, в качестве примера
4. Инструмент для составления своей лестницы
#развитие #процессы #holywar

Годовые планы и бюджеты
Каждый год, уже много лет, убеждаюсь, что годовые планирования - это что-то такое... необычное.
Это как раз то, что доказывает, что в планировании важен сам процесс познания и осознания желаний, а не конечные артефакты.
Потому что каждый раз, очередное планирование года тонко (а иногда и толсто) показывает, что в этом году все делали не то, что планировали. То черные лебеди прилетят, то сами, что чаще, накосячим, то “опять власть видение меняется”, а то выстреливает то, что делали не планируя.
И хотя порефлексировать о причинах конечно стоит: возможно что-то все же стоит менять, но относитесь к этому действу проще и гибче, без надрыва.

#байки

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

Сегодня философский #it_memes

Забавный инсайт после просмотра доклада: наверное в каждой компании есть команда Core (самые важные и самые озвиздюленные ребята обычно).
Сейчас правда появилось более стильное название: Platform team (степень важности и озвиздюливания сохраняется, местами даже увеличивается)
#процессы #quality

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

Лирическое отступление: где-то одновременно с этим, тестеров переименовали в QA (не поменяв сути их деятельности и не поняв, что же значат эти 2 буквы), спустя какое-то время админов переименовали в DevOps (хороший получился трик с повышением ЗП, хотя и задачи чуток поменялись, да).

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

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

ЗЫ кстати, в архитектурных решениях свои спирали (а может “маятники”), типа “монолит -> микросервисы -> монолит”
#байки #процессы #quality

Postmortem за $135млн
"Наиболее вероятной причиной аварии "Луны-25" стало нештатное функционирование бортового комплекса управления, связанное с невключением блока акселерометров в приборе БИУС-Л (блок измерения угловых скоростей) из-за возможного попадания в один массив данных команд с различными приоритетами их исполнения прибором", - говорится в сообщении.
Отмечается, что распределение команд в таких массивах данных имеет случайный, то есть вероятностный характер.
"В связи с этим в бортовой комплекс управления приходили нулевые сигналы с акселерометров прибора БИУС-Л. Это не позволило при выдаче корректирующего импульса зафиксировать момент набора требуемой скорости и произвести своевременное выключение двигательной установки космического аппарата, в результате чего ее отключение произошло по временной установке".

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

Начнем с самого простого:
Кто должен писать автотесты - кто-то из команды, зависит от того, кто (специалисты с какой квалификацией) у нее есть сейчас и того, что мы понимаем под "автотестами".
Я знаю разработчиков, которые автотестами называют все тесты, которые у них пишут автоматизаторы (а то, что пишут разработчики это или модульные, или интеграционные). Вот такая вот “логичная” классификация🙂

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

Тогда какие тесты?
Если ожидается переписывание кода бека, когда мы меняем реализацию полезной бизнес-логики без изменения API (клиент остается тем же), то перед началом работ важно зафиксировать текущее поведение функциональными тестами на API + контрактными тестами (детальная серия статей про их теорию и практику). Это могут сделать или разрабы, или автоматизаторы (если они знают что-то, кроме написания e2e тестов через UI). Можно и через UI конечно, но я не сторонник такого подхода (такие тесты медленно работают, подвержены влиянию вспышек на солнце и в принципе случайно успешные).
Короче, в этом случае, тесты вам только в помощь и стоит не кого-то переубеждать, а выделить время на их написание.
Можно чуток схалявить и зафиксировать API вызовы с клиента и их результаты через какой-нибудь инструмент записи запросов во время ручного тестирования клиента. Удобного и правильного примера инструмента не подскажу, давно не лазил в эту сторону, но такое точно есть (вангую, что тот же Postman подойдет).
Если планируем менять и клиентскую часть, и API, или у вас моно-приложение типа десктопа или мобилки, то я бы сказал, что написание любых автотестов перед тем, как все будет переписываться, бесполезно. Время будет потрачено впустую и все тесты потом придется выкинуть. Проще их уже делать одновременно с написанием нового кода.

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

Но и это еще не все...
Есть другой аспект этой истории, уже не совсем про автотесты. Он кроется в самой постановке вопроса. Завтра продолжим.

#testing #ваши_вопросы

Продолжаем про вчерашний вопрос про покрытие автотестами.
Естественно, вчерашний ответ без уточнения вопроса - это как диагноз по фотографии.
Давайте поразмышляем.
Что может смущать в этом вопросе?
1. Сам факт его задания
Если возникает вопрос “кто должен писать?”, значит, скорее всего, сейчас это делает “никто” 🫠 (это мы потом с автором обсудили, похоже на правду)
Автотесты в реальной жизни пишут или те разработчики, кто уже постиг дзен и понимает всю ценность этого действа (или у их менеджеров сильные колени). Или специально обученные люди, которые пишут программы, для тестирования других программ (aka “автоматизаторы”). Обе этих категории таких вопросов не задают (одни и так знают ответ, другие за это деньги получают по умолчанию).
Тут немного моего давнего максимализма про то, почему разработчики не пишут тесты ( 😒сейчас я уже тот менеджер, которого в посте ругаю)
2. Откуда мог возникнуть такой вопрос с покрытием у обычного разработчика и кому он хочет что-то объяснять?
Вангую, что лиду. А откуда у лида может возникнуть такой запрос, если предположить, что раньше он его не волновал, ибо тестов то, как мы знаем из п1, нет.
Вопрос с покрытием тестами часто приходит снаружи от менеджера (“почему у вас клиенты находят проблемы, как вы продукт тестируете?”) или возникает, как требование в рамках процессов сертификации (🥲 свежак из моей реальности).

С менеджером проще - берем планируем и пишем, тесты сами себя не напишут.

Давайте представим, что пришли секьюры и спросили за покрытие тестами, а его у нас нет.
Что можно тогда делать?
0. Рассказать лиду, что это тоже надо планировать 🙃
1. Понять, что это не щелчок пальцами
2. Уточнить, какие в первую очередь пользовательские сценарии интересны секьюрам (поверьте, их чаще всего интересует реализация функций безопасности) и как они ожидают увидеть покрытие
3. Запланировать работы по реализации и вперед
Без этих шагов, велик шанс, что вы просто потратите время, но сделаете не то, что нужно секьюрам. Хотя какое-то покрытие у вас появится 🙂

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

PS2 Все события вымышлены, любые совпадения случайны и являются лишь плодом моего воображения

#testing #quality #ваши_вопросы

На следующей неделе буду мимикрировать под эксперта на докладе Виталия Шароватова. Приходите послушать Виталия.
Если я правильно понимаю, то это как раз попадает на Community Day (free, зарегистрироваться можно тут).

Если составить рейтинг используемых слов в моем словаре за последние полгода, то там с огромным отрывом победит слово
DevOps

Весь прод в труху, но потом...

#it_memes #тесты_в_проде

Неделя про модульные тесты (aka unit tests).
Мне последние несколько лет нравится концепция сю-ха-ри, основная мысль которой заключается в том, что ты не можешь нарушать правила пока не изучил базу, идеи и мысли других, придумал свои правила, а только потом можешь освобождаться от любых правил.
Если спроецировать этот подход на автоматизацию проверок, то получается, что сначала ты должен научиться писать тесты, как их видят в отрасли, а только потом точить подходы под себя.
Но фишка в том, что подходов очень много.
Например, кто-то считает, что модульные тесты мешают (недавние рассуждения Кирилла Мокевнина), кто-то считает, что интеграционные тесты - фигня, а модульные тесты рулят (JB Rainsberger Integrated Tests Are A Scam HD).
Каждый подход и мнение имеет в своей основе мысли, с которыми можно согласиться, с какими-то поспорить, но потом все равно прийти к философскому "зависит от".
На этой неделе попробую собрать в кучку основные приколы связанные с модульными тестами.
Посмотрим, что получится.
Продолжение
#test_automation #unit_testing

Продолжаем про юнит-тесты (я понял, что “юнит-тест” у меня с языка слетает автоматом, тогда как “модульные” - это что-то “академическое на старославянском”).
Начнем с того, что многие в принципе не считают такие тесты классическими тестами. Оно и правда, если юнит-тесты написаны по канонам*: “проверяется лишь одна функция одного юнита”, “все строго изолированно” и тп, то это лишь скорее просто инструмент разработчика.
Что он дает?
1. возможность запускать части кода без запуска всей системы, что обеспечивает:
• быструю обратную связь от вносимых изменений
• уверенность в вносимых изменениях
2. документация к коду
3. помощь в проектировании

Разберем коротенько по пунктам (заметки Капитана Очевидность, но я как-то не хочу их проскакивать)
1. Быстрый запуск кода - тут речь как про возможность “засунуть датчик” непосредственно в кишочки кода, так и про скорость выполнения самой проверки.
Когда у тебя есть возможность здесь и сейчас, без дополнительного окружения и ресурсов проверить, как выполняет свои задачи свеженаписанный код - это то, что нужно. К примеру, если функция по бинарному блобу определяет тип данных в нем, то не нужно проверять эту функцию запуская и дергая API сервиса, который где-то внутри себя использует эту функцию. Банальность и очевидность, но сплошь и рядом наблюдается (о причинах не сегодня). А если функция вызывается внутри десктоп приложения? Там с проверкой функции ”через приложение” вообще будет веселый аттракцион.
2. Документация. Есть интересная особенность памяти среднестатистического разработчика - она обнуляется по отношению к коду буквально через месяц (+/-). Некоторые только по истории гита определяют, что какое-то конкретное изменение кода было сделано именно ими. А уж про то, что именно код делает и для чего, так и подавно не помнят. Так вот тесты расположенные близко к коду (чаще всего те самые юнит-тесты), как раз помогают быстрее восстановить понимание предназначения кода и логики его работы. И да, конечно, это можно сделать и просто читая код. Но читая юнит-тесты, тем более хорошо написанные тесты с правильными названиями, сделать это намного быстрее. Тем более, что обычную документацию то редко кто пишет, а еще реже обновляет.
3. Проектирование. Использование юнит-тестов способствует (но не гарантирует) тому, что проверяемый ими код будет написан удобно, понятно, расширяемо. Потому что способность кода быть удобно тестируемым (тестируемость) напрямую связана с такими характеристиками качества кода, как изменяемость и поддерживаемость.
В этом месте можно было бы ввернуть про TDD (и я ввернул), но забавно, что сейчас это буквосочетание куда-то исчезло (только из моей инфоленты?). А то ли дело ра-а-аньше, трава зеленее, "TDD помогает" vs "TDD есть опиум для народа" и такие батлы в комментариях (тут тоже есть, если вы любитель попкорна).

Короче, юнит-тесты - это лишь инструмент разработчика: написал код так, чтобы потом его протестировать, проверил локально, остались какие-то артефакты имитирующие документацию. Работает в моменте здесь и сейчас.
Если юнит-тесты написаны канонично*, то с вероятностью 99% их надо выкинуть (=сильно переписать) при изменении того кода, который они проверяют. И именно от последнего всех и бомбит.

*по канонам завтра, потому что я не верю, что в телеге кто-то такие простыни читает. А вообще я так разошелся, что может и пятница будет без мемов, но это неточно.
#unit_testing #test_automation

Продолжаем про юниты-тесты и каноны.
Давайте немного вернемся к началу и поразмышляем на тему собственно юнита (модуля). Что это такое? Какие тесты еще можно называть модульным, а какие уже не являются таковыми, потому что уже тестируют несколько юнитов?
Обратимся к классику (Мартин Фаулер) :
“Объектно-ориентированный подход рассматривает класс как юнит, процедурные или функциональные подходы могут рассматривать одну функцию как юнит. Но на самом деле команда решает, что такое юнит исходя из их понимания системы и ее тестирования" (вольный перевод, а статья кстати хорошая, почитайте)
Хмм, получается, что нет строгого определения, что считать юнитом?
Да, но есть нюансы.
Вы знали, что существует 2 школы боевого кунг-фу юнит-тестов?
Лондонская и Детройтская (она же Чикагская).
Что самое забавное, когда говорят про недостатки юнит-тестов, то чаще всего указывают на проблемы, которые возникают при лондонском подходе.
Чем же они отличаются?
Одно из отличий - это как раз определение размеров юнита.
Лондонская школа определяет юнит, как класс/функцию и предполагает изоляцию SUT (system under test) от всего того, с чем он взаимодействует через test doubles (тест-дублеры, на старославянском - моки, что неправильно, но все привыкли). То есть, мы проверяем строго то, как работает SUT ориентируясь на его публичный интерфейс и поведение нужное нам для реализации пользовательского сценария. А все его внешние зависимости замокированы. Это как раз и и приводит к тому самому “цементированию” кода тестами, затрудняющего его модификацию.

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

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

Полезные ссылки
• Are You Chicago Or London When It Comes To TDD?
• London vs Chicago
• London and Detroit schools of unit tests (похоже недоступно из РФ, есть копия из кэша)

Заключение
#unit_testing #test_automation

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