Вероятно, вам всё еще нужно вызволить вашего кота из заложников деврела, раз вы читаете эту статью. Или у вас нашлась новая причина, так тоже бывает. Это третья часть квадрологии от Романа Поборчего, независимого эксперта — с 2015 он консультирует докладчиков наших конференций, как выступать на технические темы.
В первой мы искали темы в задачах разработчиков, а во второй - в инструментах разработки. Сегодня мы будем искать темы для выступлений в процессах разработки. Они там есть, мы проверяли.
Даже у разработчиков, кроме технической части работы, есть и организационная сторона, но что можно о ней рассказать?
Собеседование
Как вы придумываете задачи для технического собеседования? Вроде полезно давать задачу, похожую на то, чем человек будет заниматься в своей реальной работе, но откуда эту задачу взять?
В одной компании ребята из технической команды конкретно заморочились и разработали задачи, проанализировав падения своего прода. Одна из задач звучала так: у нас есть многопоточное джавовское приложение, и есть критический файл. Наша программа падает, если к этому файлу случится конкурентный доступ. Давайте придумаем, как внутри нашей кодовой базы инкапсулировать обращение к файлу, чтобы у нас продакшен не слишком часто падал.
Человек получает в руки редактор и начинает писать код. С первой попытки у него получается что-то вроде:
Здесь есть ошибка: кто-то может создать ещё один объект, типа файл со ссылкой на тот же физический файл на диске:
Кандидат, когда ему на это укажут, начинает создавать счётчики, очереди обращений, хэш-таблицы для хранения всех пользователей, которым нужен доступ у файлу. В каждом случае есть какой-то подвох, и команда его уже знает: ведь они уже роняли продакшн похожим образом! В процессе разное может случиться, но суть в том, что весь сценарий взят из реального кода. Если найти в коде такие места, которые были сложны для команды, то из них можно сделать великолепную задачу для собеседования. Та команда нашла три таких задачи.
На собеседовании мгновенно можно показать кандидату все его возможные ошибки: «Дружище, ты за этот час уронил наш продакшен 6 раз! Ты сделал это точно также, как в своем время это делали мы. Ты — наш друг и единомышленник… и нам с тобой не по пути!».
Из этого можно сделать настоящее шоу. Например, выступать вдвоём. Один из докладчиков будет изображать собеседующего, а другой — кандидата. Тех ребят не удалось убедить сделать доклад, но, возможно, вы как-то интересно придумываете задачи на собеседование?
Код-ревью
Помимо собеседований многие разработчики регулярно проводят код-ревью. Известно, что при этом есть риск перессорить людей в команде напрочь и очень быстро. И это прекрасная тема для рассказа, как осуществить проверку и избежать конфликтов. Например, с этим справился Владимир Романько:
В докладе много разных хаков, связанных с код-ревью, но здесь мы приведем лишь тот, который касается конфликтов. Чтобы разработчики меньше ссорились, иногда бывает достаточно запретить письменно отвечать на комментарии. Потому что в письменной форме проще скатиться к сарказму и переходу на личности, а потом еще и третьих лиц добавить к переписке: «Смотрите, какая чушь!».
Нет, если мы не согласны с комментариями — нам нужно либо дойти до этого человека ногами, либо созвониться с ним и обсудить всё голосом. Так можно нормально всё обсудить, обо всем договориться и не поссориться.
Без примеров не обойтись
Сложность процессов в том, что чем более гуманитарная тема, тем труднее синхронизировать терминологию, понимать всем всё одинаково. Однажды на тренинге про выступления я спросил группу из примерно двадцати человек, какую сумму они представляют, когда слышат, что кто-то должен крупную сумму денег. В ответах оказался разброс на два порядка: от пятисот тысяч до пятидесяти миллионов рублей. Точно такой же разброс возникает в головах зрителей, когда мы говорим, что комментарии к коду должны быть конструктивными и вежливыми. Кажется, что все однозначно понимают, что это значит. Но это не так.
Поэтому в выступлении на такие темы обязательно нужны примеры и антипримеры. Они обычно занимают больше половины времени и объема доклада, но не надо этого бояться. Это нормально, примеры делают рассказ понятным. Если у вас есть 2-3 неочевидных мысли, связанных с процессами — проиллюстрируйте их интересными примерами и у вас получится 30-40 минут выступления.
Снова шуруп молотком
Бывают случаи, когда в процессах тоже забивают шурупы молотком. Павел Михновец сделал доклад про то, как делают приборы, способные проанализировать еду или напиток и сказать, какие элементы таблицы Менделеева в этих образцах есть. Причём здесь DevOps? Например, когда такие приборы работают у клиентов, на них тоже нужно накатывать обновления. В целом, Павел нашёл в своей работе много интересных аналогий с процессами в разработке и сопровождении софта.
Другой пример — доклад Владимира Красильщика о том, чем похожи музыкальная индустрия и разработка софта. Оказывается, они действительно похожи, но музыкальная индустрия на 100 с лишним лет старше, и многие практики там уже придуманы.
Управление командой очень похоже на управление музыкальной группой или оркестром (с точки зрения Владимира). Заканчивает он провокационной мыслью, что профессиональные музыканты сами не сводят треки, не рисуют обложки к пластинкам и еще много чего сами не делают. Они занимаются только музыкой, и поэтому, скорее всего, весь ваш DevOps — это странная штука, которая не приживется.
Резюме
Находки, лайфхаки, которые вы используете в ваших процессах.
Шуруп молотком. Необычное применение процессов или использование их в другой индустрии.
Возможно, те находки и лайфхаки, к которым вы давно привыкли, могут быть полезны не только в вашей специфической ситуации, а далеко за ее пределами. Ищите интересные совпадения между отраслями. Это может быть хорошим источником тем для докладов. Особенно если не идти проторенной дорожкой, копнуть поглубже или посмотреть под другим углом.
До 12 августа открыт прием заявок на доклады на Highload++ 2022 (24 и 25 ноября 2022 в Москве). Ждем ваши заявки. Все подробности на сайте https://cfp.highload.ru/moscow
