Чудес не бывает или я ошибаюсь?

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

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

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

В блог стал меньше писать, потому что он в моей голове предполагает сейчас какую-то долгую предварительную работу со статьей. Черновики у меня годами лежат. Поэтому, встречайте телеграмм-канал, лайт-версию блога: появилась мысль - отправляется в канал. Тематика та же самая, Подключайтесь . Из мариновавшегося годами тут, но уже появившееся в телеге: Team- vs TechLead Ошибки приводящие к проблемам в IT Про календари менеджера и инженера

Побеседовали с Мишей про эту "магическую" сущность, а он смог классно переработать содержимое нашей беседы и кучи других материалов. Я теперь даже не уверен, какие именно мысли мои :) Но там все по делу. Ну и самое главное про легаси: 1. это про то, что нужно (иначе бы выкинули) 2. это то, что с вами всегда* ** *если вы не меняете работу каждые полгода после написания нового кода **но уровень боли от легаси можно уменьшить - статья как раз про это

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

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