#19: Выдал базу: три важнейших вещи в разработке

[00:20] Здарова! Меня зовут Саша Пахомов, и я инженер, который любит своё дело. Это девятнадцатый выпуск подкаста «Тысяча фичей». Сегодня мы поразмышляем над размерами команд, разберёмся, что такое карго-культ, и определим три необходимые практики, которые должны присутствовать в абсолютно любом процессе производства и работы над софтверным продуктом. А в конце — полторы полезняшки. Поехали!

[00:53] Почти наверняка, если вы меня слушаете, то работаете в команде. Какого размера ваша команда? Часто ли вы вообще задумывались над этим вопросом — над размером своей команды или той, что сидит рядом? Какого размера команда должна быть в принципе? Два человека — это уже команда или как? Или пять-шесть, а может, пятнадцать? Авторы книги «Программист-прагматик» считают, что оптимальный размер команды — чуть меньше десяти человек. Если больше, это перестаёт быть тем самым юнитом, который может что-то делать, и превращается просто в набор людей, которые как-то существуют вместе, объединённые разве что общим названием или процессом, но реально командой не являются.

[01:39] Я, в принципе, с авторами согласен — мне нравится работать в небольших командах. Не совсем в крошечных, по два-три-четыре человека, хотя и это в целом окей, но когда людей уже шесть-семь-восемь — вот это, на мой взгляд, более-менее оптимально. Почему? Во-первых, если мы команда, то должны хотя бы примерно понимать, кто чем занимается, держать в голове контекст каждого человека — чтобы понимать, нужна ли ему помощь и можем ли мы к нему за помощью обратиться. Есть такая теория — нам её ещё в университете рассказывали, — что человек в среднем, статистически, может держать в голове до семи вещей одновременно, а лучше пять. То есть примерно 5–7 человек — это тот оптимальный размер команды, который позволяет держать в голове, кто чем занят. Если больше — мы, как мне кажется, начинаем терять контекст, он размывается, и смысл существования команды пропадает. Уж лучше тогда разбиться на две команды и быть каким-то объединением, департаментом. А зачем держать в одной команде пятнадцать человек — непонятно.

[02:56] Ещё одна интересная мысль, которую я почерпнул из «Программиста-прагматика», — что команды наиболее эффективны, когда могут произвести end-to-end решение. Помните, в одном из выпусков я рассказывал про трассирующие выстрелы, про трассирующий код — когда мы делаем от начала до конца какую-то неполноценную, но работающую фичу: написали код, написали какой-то тест, задеплоили и увидели, как это использует пользователь — на фронтенде, в мобилке. Мы это пощупали, мы видим работающий код end-to-end. Ровно то же самое применимо и к команде. Когда команда может что-то произвести end-to-end — пусть неполноценное, но быстро, — это намного эффективнее и качественнее. Мы начинаем деливерить, делать эти самые трассирующие выстрелы и наблюдать: нравится ли нам то, что мы делаем, нужно ли где-то свернуть, поменять требования. Когда мы видим результат, мы начинаем работать эффективнее.

[04:01] Я с этим тоже согласен — люблю, когда мы можем сделать что-то не до конца. Например, нам сказали реализовать огромную фичу, которую мы как команда будем делать месяца два. И что лучше: увидеть результат через два месяца и понять, что здесь всё не так и половину надо переделывать, — или увидеть результат через неделю, пусть неполный, без каких-то функциональных штук (невозможно за неделю сделать то, что займёт два месяца), но зато мы уже отдадим его кастомеру или продукту — человеку, который может принять решение, устраивает это нас или нет? Вот это и есть тот самый трассирующий выстрел.

[04:41] Мораль в том, что команда должна уметь это сделать. Ведь когда мы делим команды на бэкенд, фронтенд и мобильщиков, то для трассирующего выстрела нужна координация как минимум двух команд: бэкенд должен сделать API, чтобы оно как-то работало, мобилки — чтобы оно как-то отображалось и дёргало API. Начинаются зависимости между командами, и это вносит сложность. Сделать тот самый трассирующий выстрел намного тяжелее, и, скорее всего, его просто не будет — будет отдельно разработанный бэкенд, отдельно фронтенд, которые потом как-то склеятся: заработает — хорошо, нет — посидим ещё недельку. Это те самые функциональные команды, за которые топят авторы: чтобы и мобильщик, и фронтендер, и бэкендер были в одной команде и внутри одной итерации делали друг другу API, и всё это происходило незаметно, без проблем с коммуникацией. Если они в одной команде — проблем, скорее всего, не будет; а если в разных — так или иначе что-то начинается.

[05:45] Честно говоря, я не работал в командах по первой модели — когда отдельно фронтенд, отдельно бэкенд. Мы либо всё время работали вместе с фронтендом, либо сами писали фронтенд, если это какие-то внутренние админки или тулы для тестирования. Как правило, бэкендеры могут сами написать фронтенд, потому что там нет строгих требований к качеству, а наваять фронтенд на коленке, думаю, может каждый из нас. Так что да, авторы топят за функциональные команды, и я с ними согласен — по-моему, это самый оптимальный вариант. Но всё зависит от контекста, и авторы всю дорогу — про команды, проекты, процессы — говорят: смотрите на контекст. Кому-то функциональные команды действительно удобны, но иногда продукт настолько сложный, что целая команда (или много команд) работает исключительно над какой-то частью конкретного мобильного приложения. Ну зачем ты туда посадишь бэкендеров? Они опять начнут терять контекст. Сложно объединить, сложно ежа с ужом подружить — так действительно бывает, и смотреть всегда нужно на контекст.

[06:57] И основная мысль всего этого: ребята, не существует единственно верного «как надо». Не надо смотреть, как делает Netflix, как делает Spotify, как делает другая большая компания. Вы не Netflix, вы не Google, вы не Spotify. Делаем так, как удобно нам, как работает для нас. А как понять, что работает? Просто попробовать. Берём практику — можем даже её придумать, необязательно смотреть, как делает кто-то, и принимать на себя. Можно самому изобрести велосипед, но понять, что он для нас работает, что помогает, что улучшает процессы, — и что альтернативы будут работать хуже. Просто пробуем, внедряем — так и достигается нормальный процесс разработки. Не нужно делать себе трайбы, гильдии, про которые раньше все говорили в контексте Spotify. Если вы не Spotify, если у вас нет такого количества юзеров, такого стримингового сервиса, если вы просто разрабатываете мобильное приложение — ну зачем вам трайбы? Разделитесь так, как вам удобно, и проверьте, что это для вас работает.

[07:59] Ещё авторы говорят, что хорошо бы сделать какую-то айдентику команды — чтобы команда была заметна, представляла какой-то образ в головах у людей, которые о ней говорят. Конкретно они говорят про лейбл, про символ и про имя. Кстати, вы как-то именуете свою команду? Бывают странные названия по проектам — какая-то аббревиатура, цифры, — и человек снаружи вообще никогда не поймёт, что это такое. Это шифр? Название команды? Или это госномер в какой-то стране? У меня были такие случаи: команды назывались просто по аббревиатуре проектов, и понять это было невозможно, запомнить тоже, и никакой ассоциации в голове, когда ты произносишь название вроде IPPO, не возникает.

[08:51] А ещё я работал в проектах, где у команд были нормальные названия. Назывались мы по-разному — вообще подойдёт любое рандомное забавное слово, — но у нас это часто были животные: слоны, мамонты. И это довольно забавно и прикольно, потому что у тебя сразу есть якорь, за который цепляются ассоциации с командой. Тебе говорят: «сходи к слонам, спроси у них», — и ты после митинга помнишь, куда тебе надо, потому что слон — понятная вещь, все мы его видели и хорошо себе представляем. За эту картинку в голове начинают цепляться экшены, которые нужно сделать, и это намного проще запомнить. Никакого тайного смысла, никакого поклонения, никакого лишнего креатива, которого якобы не должно быть на работе, тут нет. Дело вообще не в креативе — просто знакомыми словами намного проще оперировать и запоминать их. Хотя, если команд в компании мало, такие имена, может, и не нужны. Не знаю, но, по мне, это прикольно.

[10:00] На этом про команды, наверное, всё. Авторы, конечно, рассматривают ещё много чего, но вещи довольно банальные и очевидные — про них мне даже в подкасте говорить не хочется, не хочется тратить время дорогих слушателей, потому что время — самый важный ресурс.

[10:21] Следующее, о чём хотелось бы поговорить, — карго-культ. Изъезженное слово, его используют очень часто и по отношению к очень многим вещам; возможно, и я когда-то его использовал. Но, строго говоря, у термина «карго-культ» (или «культ карго») есть вполне нормальное определение и объяснение — это реальное явление, которое называется религией самолётопоклонников, или культом даров небесных. Если дать краткую выжимку: есть ребята, которые живут на острове (это реальная история, где-то в Меланезии — где именно, честно говоря, не знаю). Живут они, значит, островитяне, и верят, что все блага человечества — самолёты, оружие, телефоны, всё, чем мы привыкли пользоваться, — это дары небесные. У них как будто отключена способность понимать, как вещи производятся: они реально не осознают, как происходит производство, как вообще появляется в нашем мире телефон. Они думают, что это боги им дают. И чтобы получить, например, самолёты, они строят у себя настоящие аэродромы — ну, как настоящие: выглядят как настоящие, из сена, из кокосов, делают всякие будки, проводят марши, ведут себя абсолютно так же, как лётчики, которые к ним прилетают на настоящих самолётах. Но самолёта у них нет, и они не лётчики — а ведут себя точно как лётчики, понимаете? Вот откуда пошёл термин «карго-культ».

[12:00] И когда мы используем его по отношению к программированию, к скраму или ещё к каким-то штукам — вспоминайте это определение, историю, которая за ним стоит, и думайте, подходит оно конкретной ситуации или нет. Но справедливости ради, в нашей работе действительно бывает много ситуаций, которые выглядят как карго-культ. Самый популярный и банальный пример — какой-нибудь скрам, когда мы делаем дейли-созвоны, у нас есть скрам-мастер. В командах, где люди этот скрам, собственно, и определили, оно, вероятно, работало. Часто оно работает и у нас — но иногда не работает вообще, а мы просто думаем, что это результат ежедневных созвонов и наличия специального человека, который всё делает. Как будто оно помогает работать — а на самом деле это просто атрибут: мы построили из кокосовых опилок какую-то будку и думаем, что из-за неё прилетают самолёты. Но они прилетают не из-за неё, и так это просто не работает.

[13:14] Иногда всякие эти созвоны — особенно затягивающиеся, — слепое следование спринтам действительно выглядят как карго-культ, и нужно всегда проверять и мыслить критически: а правда ли этот процесс является причиной того, что у нас, например, уменьшился time-to-delivery, что мы быстрее шипим софтину — именно потому, что начали созваниваться каждый день? Это надо понимать, а возможно, даже как-то померить. С конкретным примером: время доставки фичи до прода можно померить в течение нескольких месяцев — сколько сейчас проходит от взятия фичи в работу до результата на проде, когда всё работает. Потом ввести какую-то практику — например, автоматизированное тестирование, если вдруг его нет, — и посмотреть, насколько это увеличит или, наоборот, уменьшит time-to-delivery. Пример я взял из головы и сам так не делал, но суть в том, что нужно смотреть, проверять, ставить эксперименты — понимать, что вот эти вещи работают, а вот эти нет, и только тогда их принимать. А карго-культ — теперь мы знаем, что это такое, — давайте ему не следовать и таких штук не делать.

[14:35] Следующая небольшая тема, о которой хотелось поговорить, — так называемый Pragmatic Starter Kit for Projects. Что я имею в виду? Есть в книге такой раздел: авторы говорят, что есть три вещи, три процесса, три аспекта разработки, которые должны присутствовать в каждом проекте. В любом — неважно, мобилки это, фронтенд, база данных, какая-то внутренняя система отчётности или тестовая система, — по барабану: эти три штуки должны быть всегда. Даю вам буквально пять секунд подумать: сможете угадать хотя бы одну? Вы по-любому этим пользуетесь, оно у вас так или иначе есть. Итак, первое — система контроля версий. Очевидно. Я не знаю ни одного проекта, который бы её не использовал. И необязательно, чтобы это был Git, — это может быть любая другая система контроля версий: SVN, Mercurial, что там ещё используют, какие-то самописные вещи. Главное — чтобы она была. Система контроля версий — это база, без которой я даже ни один личный проект уже давно не веду; без неё мне и жить-то сложно. Всё, что я пишу, лежит под системой контроля версий — естественно, я использую Git, всё пушу в GitHub, Git — наше всё.

[16:05] Останавливаться и размышлять, почему оно так, наверное, уже не стоит. Про Git мы разговаривали в одном из первых выпусков — то ли в четвёртом, то ли в пятом; можете посмотреть, там про это подробнее. Я как раз рассказывал про месседжи коммитов, которые я делаю, на что опираюсь, какие месседжи считаю правильными, а какие нет. Это уже было сказано, поэтому идём дальше.

[16:33] Вторая обязательная вещь — тестирование, а лучше даже сказать — регрессионное тестирование. То есть мы должны проверять, что не сломали программу. В процессе разработки мы можем её сломать — это очевидно, мы можем внести багу, — и чтобы нам били по рукам, у нас должно быть регрессионное тестирование. Оно складывается из огромного количества других тестов. Сколько их бывает? Из банальных — юнит-тестирование, интеграционное тестирование, системное, смоук-тестирование, то же регрессионное, UI-тестирование. Очень много терминов. Но важным мне кажется не знать и понимать каждый термин — я вот, например, прямо сейчас сходу не скажу, что такое смоук-тестирование, сложно. Главное — это делать: тестировать те вещи и компоненты, о которых эти нейминги говорят. Если у вас есть фронтенд — лучше всё-таки его тестировать. А как именно, с помощью каких сетов тестов — уже не так важно; главное, чтобы это было.

[17:33] Ещё авторы говорят, что нужно тестировать сами тесты. А вот теперь вопрос: как, по-вашему, можно протестировать тесты? Первое, что приходит в голову, — написать тесты на тесты. Но тогда получается проблема: как протестировать тесты на тесты? Это бесконечный луп, рекурсия, из которой мы никогда не выйдем. А что предлагают авторы? Давайте так: зачем мы вообще пишем тесты? Очевидно, чтобы находить баги — самый простой ответ. Значит, хороший, работающий тест должен что? Должен находить баги. Как проверить, что тест хороший? Внести багу и посмотреть, что тест её обнаружил. Мысль очень очевидная, банальная и простая, но иногда мы ей не пользуемся. Я вот в последнее время постоянно ломаю тесты: для меня, если я не увидел красный тест, а потом зелёный (это тема из TDD), — это вообще не тест, для меня это ничто. Если он не поймал багу, я считаю, что его нет, а лучше бы и не было: если он не ловит баги, он даёт ложное ощущение, что мы что-то тестируем, а на самом деле нет. Я всегда сначала пишу тест, а потом код, который ломается, — или сразу поломанный тест, а потом его фикшу и вижу, как тест из красного переходит в зелёный. Когда этот светофор начинает работать (я про это и в Телеграм-канале писал), у меня возникает спокойствие: тест качественный, и я, собственно, протестировал тест.

[19:01] Есть и разные другие практики — например, мутационное тестирование. Что это? Это когда мы берём наш source code — тот, что тестируется тестами, — и начинаем вносить в него изменения. Например, была строчка if i > 0, и внутри что-то делается — а мутационное тестирование может развернуть знак в обратную сторону, поменять «больше» на «меньше». И если после этого все тесты прошли, мутационное тестирование считается неуспешным, непройденным. Почему? Потому что тесты не заметили изменения этого if — значит, есть поведение, которое мы не тестируем, или мы внесли багу, которую тесты не поймали. А если эта строчка вообще ничего не значит и софтина работала как работала, этот if ни на что не влияет — значит, это лишний код, garbage, которого в source-коде тоже быть не должно. Таким образом, мутационное тестирование меняет все эти строчки кода и на каждое изменение, на каждую так называемую мутацию запускает все тесты и смотрит, поймали они что-то или нет.

[20:11] В промышленном плане про мутационное тестирование я знаю только, что этим занимается Netflix — по-моему, они и изобрели термин chaos monkey или что-то в этом роде, у них даже есть под это фреймворк. И Google, знаю, такое делает. То есть большие ребята, которые могут себе это позволить. Но вообще выглядит это как что-то очень долгое: вы только представьте — нужно изменить source-код, всё перекомпилировать, пересобрать, прогнать все чеки и запустить все тесты, и это ради одного изменения. Вы же не можете внести сразу сотню мутаций и прогнать разом — иначе не поймёте, какая именно мутация уронила тест; нужно делать по одной или как-то умно запускать. В общем, на это будто бы должна тратиться огромная вычислительная мощность, и не все могут себе это позволить. Да и человеческий ресурс — понять, почему так, анализировать эти тесты, всё исправлять — очень тяжёлый. Поэтому в реальной жизни, в своих проектах, я этого не видел, но сама идея довольно интересная и иногда может выручить. Думаю, в таких продуктах, как базы данных или какие-то критические сервисы, мутационное тестирование вполне может повысить качество. Итак, тестирование, которое отлавливает баги, качественные тесты — это вторая необходимая вещь в процессе разработки любого софта. Тут, наверное, сложно поспорить.

[21:39] Version control и тестирование — а что же третье? Вроде бы придумать нечего, но авторы говорят, что это автоматизация, причём полная — Full Automation. Что это значит, я до конца не понял, но они говорят, что процесс интеграции, CI/CD, деплоя должен быть автоматизирован. По сути, третье можно переформулировать как CI/CD-практики, которые должны присутствовать. Если мы не можем быстро и без больших усилий доставить код до конечных пользователей, значит, не можем их удовлетворить — не можем вовремя доставить им фичу. А если мы делаем всё руками, то, очевидно, можем внести ошибку, и разные люди делают это по-разному — все эти мануалы навряд ли работают. Инфраструктурные вещи — например, если у каждого пользователя должна быть виртуальная машина с определёнными версиями Java и всего окружения — тоже, очевидно, должны разворачиваться автоматизированно: с помощью Puppet, Ansible или чего вы там используете. Люди не должны сами ставить себе софт на виртуалку, потому что поставят разный, и потом из-за этого будут проблемы. Но и в автоматизации нужно знать меру: автоматизировать можно до посинения, до бесконечности, и надо понимать, когда остановиться — когда сам процесс поставки кода, его тестирования, проверки, что он работает, всякие хелс-чеки перестают доставлять боль, становятся достаточно быстрыми и не превращаются в бутылочное горлышко в доставке фич пользователям.

[23:34] Мне кажется, этого уже достаточно. У меня и пример есть, и не один. Я, естественно, всегда использую автоматизированные развёртывания и доставку кода и всегда делаю это в начале проекта — в моих проектах это буквально шаг номер ноль, настроить CI/CD. Почему? Потому что, когда всё настроено, процесс разработки и поставки становится кайфом. Вот, например, был у меня Telegram-бот. Да, я могу локально поднять тестового бота, на нём всё делать, писать код, смотреть, что он работает, потом пушить и тестировать. Но когда у меня есть CI/CD, а это мой личный проект и больше над ним никто не работает, я просто пушу фикс в main, иду завариваю себе чай, сажусь — и у меня уже реальный (ну или стейджинговый) бот с этой фичой, и я тестирую его на реальном окружении, с реальными сервисами и интеграциями. Мне не нужны приседания вокруг воспроизведения и поднятия окружения рядом, не нужно двойное тестирование — ведь когда я залью на прод, я всё равно буду тестировать: мне хочется посмотреть, что фича работает именно на том окружении, с которым взаимодействует пользователь. А с CI/CD я просто делаю Command-K — это commit, Command-Shift-K — это push, и через минуту всё уже там. И это офигеть какой кайф: ты об этом вообще не думаешь, и вот этот end-to-end feedback loop реально доставляет.

[25:02] Второй пример — это мой сайт, который хостится на GitHub. Я генерирую его с помощью Hugo и потихоньку выкладываю туда выпуски подкаста с плеером, чтобы можно было послушать, посмотреть материалы, — возможно, потом даже расшифровки буду добавлять. И делаю я это прямо на горячую: локально Hugo-сервер, чтобы он раздавал мне статику на localhost, я поднимаю редко. Я просто добавляю markdown-файлы, пишу номер выпуска — короче, подготавливаю сорцы — и пушу сразу в main, потому что это мой личный проект. Зачем мне какие-то pull request’ы, вот это всё? Опять же карго-культ: лично для меня pull request’ы работать не будут, потому что я сам себе их буду апрувить. Я просто пушу в main, у меня запускается pipeline, и через 30 секунд статика уже раздаётся на реальном сайте. Я смотрю на него: подгрузились ли стили, подгрузилась ли картинка, тот ли плеер — всё там проверяю. И это дико удобно. Но, опять же, это работает, потому что работает для меня. Когда мы будем работать в команде над общим проектом, я, естественно, не буду пушить в main — у нас будет какой-то процесс review или что-то похожее, чтобы проходили дополнительные проверки. Но лично мне это не нужно, поэтому я фигачу вперёд. А CI/CD, который автоматизирован, доставляет именно кайф. У всех он есть, это неотъемлемая вещь — но она ещё и доставляет удовольствие. Вот основная мысль, которую я хотел донести.

[26:33] И последние две мысли, которыми авторы завершают даже не главу, а уже и книгу. Да, я подошёл к концу чтения этой книги и дальше не знаю, что почитать. Если у вас есть на примете книги, которые могут побудить к размышлениям, на подумать, — не чтобы делать читательский клуб с разбором каждой главы, а вот для таких разговорных форматов, — закидывайте, буду очень рад.

[26:58] Так вот, первая мысль в том, что мы, программисты, инженеры — называйте как угодно, — по факту problem solvers: мы решаем проблемы. Сделать это мы можем с помощью кода, конфигурации, написания нового сервиса, kill -9 какого-нибудь процесса — инструментов у нас много, но самое важное понять, что мы решатели проблем. Интересная мысль, на которую я и сам когда-то набрёл, уже довольно давно. Я уже несколько лет не позиционирую себя как программист, как какой-то джава-кодер — я ассоциирую себя с тем, что решаю проблемы и деливерю value людям: пользователям или тем, кто мне платит, неважно. Я что-то произвожу, а как я это делаю — уже детали имплементации. Это прикольный способ думать о том, что мы делаем и нужны ли нам какие-то люди, чтобы донести конкретное value. Ведь некоторые команды состоят из скрам-мастеров, системных аналитиков и кучи других людей, которые по факту нужны для того, чтобы мы доставили value бизнесу. А иногда мне кажется, что я и сам могу его доставить — вот как есть: Саша может написать код, заресёрчить, разобраться, чтобы что-то предоставить или какую-то проблему решить. И вот эта индивидуальная самостоятельность — когда можешь и заресёрчить, и разобраться, и демку показать, и с бизнесом поговорить, и с другой командой связаться — такой универсальный боец, мне кажется, очень полезный навык. А когда тебе люди пишут какое-нибудь ТЗ… Я уже сто лет ТЗ не читал, и мне было бы сложно: а вдруг там что-то не так, а вдруг я думаю иначе и захочу разобраться. Ощущение себя кодером — это не про меня, оно мне не нравится. Так что problem solvers — довольно прикольное определение.

[29:13] И ещё авторы говорят: sign your work — подписывайте свою работу, не стыдитесь и не умалчивайте те заслуги, те штуки, которые вы сделали. Если вы разработали какую-то прикольную тулзу — говорите, что вы её разработали, показывайте всем, напишите в README, запостите у себя в твиттере. Ваша работа, ваши результаты — это то, что строит из вас профессионала. Интересно ведь говорить о том, что ты сделал, показывать, объяснять. Я, кстати, в подкасте этим и занимаюсь — думаю, вы плюс-минус понимаете, чем я занимаюсь, и можете найти результат моей работы, посмотреть на GitHub. Но суть в том, что, когда мы программисты, инженеры, problem solvers, — есть что посмотреть, что мы действительно делаем. А то ведь человек вроде умно говорит умные слова, читает книжки и что-то рассказывает — это может немного попахивать скамом. Если вам кто-то говорит, что он там что-то оптимизирует, — покажи: где твой GitHub? Я посмотрю — даже не на качество кода, это уже второстепенно, а на то, что ты делаешь. Разрабатываешь этот продукт — окей, я гляну, оценю его с технической точки зрения, посмотрю уровень контрибьюшена конкретного человека и пойму, отвечает ли он за слова: реально профессионал, который производит качественный код, или просто инфоцыган, который всем рассказывает, какой он крутой, а по факту ничего предоставить не может.

[30:43] И в этом плане все истории про «ой, у меня NDA», «ой, у меня нагруженный сервис, я не могу» — ну ребят, есть же open source. Я и под NDA разрабатывал кучу вещей, но есть штуки, в которые я просто контрибьютил, где делал фичи. Вот, например, Oracle Testcontainers — мой первый контрибьюшен: если вы используете Spring Boot и у вас в тестах поднимается Oracle Testcontainers, то это моя работа, можете зайти в git history и посмотреть. И таких вещей много — я могу показать. Сейчас-то вообще понятно, чем я занимаюсь. Мне кажется, это очень важно: когда мы не только говорим, но и делаем и можем показать, что делаем, — это очень круто. Поэтому да — sign your work; а если не можете подписать и показать всем свою работу, то делайте что-то другое. Например, просто контрибьютите библиотеки, которые вам нравятся. Я вот недавно законтрибьютил в библиотеку ProgressBar, которая рендерит прогресс-бар в терминале на Java. Автор включил это в следующий релиз — фича в том, что теперь можно менять цвета. Совсем маленькая, строчек 200 вместе с тестами, но мне приятно: я это сделал, я понимаю, что теперь библиотека стала более расширяемой и гибкой. Мне это просто нравится, и как профессионал я чувствую себя намного комфортнее, чем если бы просто использовал библиотеки, не внося в них никаких изменений.

[32:10] Да, что-то я уже совсем разогнался — вольное рассуждение. Если вы дослушали до этого момента, вы огромный молодец, вам от меня просто респект.

[32:19] А полезняшка в конце — это YouTube-канал. Да, я сейчас немножечко погружаюсь в YouTube, смотрю, что ребята производят, кто что делает, просто чтобы понимать, какой контент существует. И то, что мне понравилось, — YouTube-канал под названием Computerphile. Ссылки, естественно, оставлю в шоу-нотах. Это отличный пример канала, в котором нет суперспецэффектов, который снят на обычную простенькую камеру, но материал подан настолько талантливо и людьми, которые увлечены своим делом, что он очень доступный, и слушать и смотреть его — одно удовольствие. Короче, это прямо айтишный контент — про нейронные сети, про всякие программные, софтверные штуки, про стейт-машины; в общем, там всё есть, заходите, смотрите.

[32:58] Как я говорил, есть полторы полезняшки: вот эта была полноценная, а половинка — это мой первый видос на YouTube про то, какие бенефиты мне даёт подкаст. Я в целом старался, поэтому надеюсь, вам понравится. Заходите тоже по ссылке в шоу-нотах, поддержите видос лайком, оставьте комментарии, подписывайтесь на YouTube — будет много интересного. Ну и, как всегда, делитесь подкастом с близкими, друзьями, коллегами — давайте прокачивать себя и людей вокруг. Ну а на этом всё. Услышимся!