Став частью команды QuintoAndar, я приобщилась ко многим процессам, о которых раньше не знала. В их число входили обязательные ревью кода.
Если кратко, то в рамках этой процедуры ревьюер читает код автора, высказывается по поводу более оптимальных способов решения задачи, предлагает рекомендации и даже одобряет используемые приемы.
Перед тем как объединить код с производственной средой, в нашей компании необходимо получить, по крайней мере, одно одобрение инженера, ответственного за ревью. И руководство активно побуждает нас содействовать укреплению этой традиции. Но возникал ряд вопросов: “С чего начать?” и “Как быть с тем, что некоторые команды используют абсолютно другие инструменты?” У нас не было единых стандартов, кроме того мы говорили на разных языках.
Выслушав мои соображения, ведущий инженер предложил мне провести небольшое исследование с последующей разработкой рекомендаций для улучшения процесса ревью кода в компании.
Разработка самостоятельного проекта
Получив полный карт-бланш, я дала выход своей творческой энергии и согласно замыслу разработала мини-проект, состоящий из 4 этапов:
- Провести опрос. Цель: определить текущее положение вещей и узнать, что по этому поводу думают инженеры.
- Поделиться результатами. Цель: создать инфографику, отражающую общее мнение инженеров компании по данному вопросу и значимые результаты исследования.
- Приступить к написанию новых рекомендаций и получить обратную связь. Цель: создать временный канал связи для общения заинтересованных людей, готовых поучаствовать в обсуждениях.
- Ознакомить всех сотрудников компании с окончательным документом.
Благодаря ведущему инженеру, его вере в меня и честным критическим замечаниям по ходу работы, проект был успешно воплощен в жизнь. Наблюдая подобное отношение, я еще раз убедилась, что чем демократичнее руководство, тем оно эффективнее. Очевидно, что он рассуждал схожим образом, поскольку искренне хотел, чтобы я добилась успеха и погрузилась в атмосферу сотрудничества, царящую внутри компании.
Запуск проекта
Итак, у меня была задача, решение и четкий план реализации. Осталось только воплотить задуманное в реальность. На первом этапе были сформулированы 3 основных вопроса, которые помогли обобщить: 1) как работается нашим инженерам; 2) всё ли их устраивает; 3) что можно было бы улучшить.
В общий канал разработки Slack всем было отправлено сообщение с просьбой поучаствовать в опросе, о чем я периодически дополнительно напоминала. Многие искренне заинтересовались происходящим: за сутки к моменту окончания опроса откликнулось 73 человека. Учитывая имеющийся на тот момент штат в 200 инженеров, процент участия составил 36.5% — высокий результат для такой крупной компании.
Первый этап пройден! Теперь предстояло обобщить ответы и сделать выводы.
Доказательство концепции
На тот момент моим увлечением была одна книга о том, как гендерное неравенство негативно влияет на развитие технологической индустрии. Также стоит упомянуть, что попасть в компанию мне помогла организованная ею программа найма исключительно женского персонала. Поэтому я понимала, что мне придется доказать свою гипотезу, согласно которой женщины остерегались высказывать мнение о коде своих коллег. Несмотря на анонимность опроса, я осторожно узнавала пол респондентов и интересовалась, чувствуют ли они себя уверенно в процессе ревью. Моей первоначальной целью было доказать взаимосвязь этих двух аспектов. Во избежание неловких ситуаций опрос предполагал наличие вариантов: “мужчина”, “женщина”, “небинарный”, поле для ответа в свободной форме “другое” или “предпочитаю не отвечать”.
В число респондентов входило 49 мужчин, 21 женщина и 3 предпочли не отвечать. Результат соответствовал моим ожиданиям. В целом 54.8% специалистов ответили, что уверенно себя чувствуют, проверяя код коллег. Однако обработка результатов с учетом гендерной принадлежности показала, что 81% женщин ответили на вопрос отрицательно.
Мы воспитывались в обществе, в котором женщин убеждали не рисковать, помалкивать и не оспаривать мужское мнение. Тогда с какой стати, вдруг ни с того ни с сего женщины-программисты начнут “тыкать пальцем” в код, написанный преимущественно мужчинами? Недостаточно лишь предоставить женщинам рабочие места, намного важнее помочь им стать частью компании и остаться на должности по прошествии месяца. Кто-то должен взять на себя ответственность и начать незамедлительно действовать. Именно это мне хотелось доказать с помощью простого опроса о ревью.
Такие разные люди
Обсуждая тему ревью, мы так или иначе затрагиваем тему межличностного общения. У каждого человека за спиной огромный багаж жизненного опыта, о котором мы абсолютно ничего не знаем.
Что вы почувствуете, потратив часы или дни в попытках найти лучший подход к решению задачи, когда из ниоткуда появится некто и укажет вам, насколько всё просто и решается с помощью одной строки кода?
И ревьюер, и автор кода должны понимать, что оба они делают все возможное для создания качественного продукта. Автору следует спокойно относится к своему творению и понимать, что всегда найдется специалист, пусть и с меньшим опытом работы, который лучше разбирается в определенной теме. На самом деле, лучше уподобиться Сократу и признать: “Я знаю, что ничего не знаю”. А ревьюеру необходимо четко высказывать свое мнение о коде и вносить деловые предложения. Никогда не знаешь, как будут восприняты твои замечания. Комментарии на Github можно оживить за счет смайликов Markdown, чего не сделаешь при личном общении.
Кроме того, как уже ранее упоминалось, у каждого свой жизненный опыт. Например, у аутистов возникают сложности с восприятием сарказма, поэтому всегда следует довольно серьезно относиться к их комментариям, ведь, в сущности, это вид документации. Все, что размещается на Github или в других предпочитаемых системах контроля версий, представляет собой историю приложения и требует к себе должного отношения.
Обратная связь на долгие года: любовь с первого взгляда
На протяжении моей карьеры, переходя из одной компании в другую, я замечала, что по большей части сотрудники довольно редко получают отзывы о своей работе — по себе знаю. Однако теперь всё изменилось по 2 главным причинам. Во-первых, наконец-то ко мне пришло понимание, что вдохновляться на новые “подвиги” мне помогают комментарии людей по поводу моей работы и советы о том, как ее улучшить. Во-вторых, это же осознал и мой работодатель.
После оглашения результатов многие сотрудники поделились своим мнением по поводу цифровых показателей и ответов. Происходили процессы, о которых они и не догадывались. Казалось бы, важные вопросы, но никто их раньше не задавал. До этого момента. Меня переполняла гордость — видимо, на это и рассчитывал наш ведущий инженер.
На следующем этапе я собрала всех участников опроса и создала временный канал Slack для всеобщего обсуждения первой версии документа. В течение месяца набралось немало комментариев — от грамматических правок до глубоких размышлений о чистом коде. С помощью коллег цель была достигнута.
Я выросла и как писатель, и как разработчик, и как ревьюер кода! И мне бы хотелось, чтобы благодаря этим рекомендациям другие инженеры компании также совершенствовались в этих областях, хотя, возможно, кроме писательской.
Основные выводы
На создание документа ушло около 4 месяцев, и я очень надеюсь, что он улучшит обмен профессиональными знаниями внутри компании. Сам процесс разработки рекомендаций был очень увлекательным. Я убедилась, насколько важно не ограничиваться словами в стремлении дать своей команде почувствовать себя частью целого, а подкреплять их действиями. Женщины-ведущие инженеры также организовывали встречи со всеми представительницами технических команд и проводили мероприятия по уменьшению гендерного неравенства, по сей день существующего в компании.
Позволяя коллегам проявлять творческую инициативу, вы демонстрируете доверие к их мнению. Вы признаете их значимость и создаете самостоятельную команду, с энтузиазмом преодолевающую препятствия.
Ревью кода неотрывно связано с приобретением новых знаний, обучением, общением и обратной связью. Все мы люди, и в конце рабочего дня не прочь потешить свое самолюбие и услышать несколько одобрительных слов о своей работе, а иногда нам просто нужна помощь. Процесс ревью кода гораздо сложнее, чем может сначала показаться. Важно понять, как наши неосознанные предубеждения сказываются на выполнении мелких ежедневных обязанностей и как мы можем содействовать формированию психологически комфортной среды.
Помню, как в колледже на занятиях по грамматике некоторые мои одногруппники доказывали, что они им не пригодятся в разработке систем. Тогда бы я с ними согласилась, но поскольку я всегда любила писать и хотела стать журналистом, до того как увлеклась технологиями, меня это особо не волновало. Но все изменилось, и такие социальные навыки, как общение и эмпатия, становятся такими же важными для программистов, как и хорошее владение любимым языком программирования.
Читайте также:
- Code Review - Полное руководство
- Проблема эйджизма в IT-сфере
- 8 советов, как стать лучше во фронтенд-разработке
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Stephany Nusch: Everything non-code-related I learned while writing guidelines about Code Reviews
