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

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

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

Тогда какие тесты?
Если ожидается переписывание кода бека, когда мы меняем реализацию полезной бизнес-логики без изменения 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, поджег аудиторию.
#байки

Заканчиваем с юнит-тестами.
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