В завершающем посте расскажу про нашу внутреннюю кухню: как мы пофиксили коммуникацию, сделав ее комфортной и понятной для всех участников процесса.
Коммуникация в интернете - это, на мой взгляд, самостоятельный навык, которому надо учиться, как правописанию или ораторскому мастерству. В реальной жизни, помимо слов, мы также используем невербалику: интонации, жесты, мимику, образы. В сети же у нас ограниченный набор инструментов для донесения своих мыслей. Мы можем использовать скобочки, эмодзи, изображения или даже описывать, какой интонацией наше сообщение надо “прочитать”. Но все это оказывается тщетно, когда сообщения доходят до получателя: сколько бы усилий и красок в текст вы не вложили, интерпретация зависит от контекста и привычек оппонента. Так случилось и у нас.
После той самой сотни комментариев под своей работой я пришел к коллегам и сказал, что мне было не очень приятно читать токсичные и неконструктивные комментарии. Один из них удивился, сказал, что вообще не вкладывал негатив в комментарии, и что он всегда так общается.
Посудите сами, что было тогда:
🔝 “Это не должно работать”
🔝 “А вот это вообще можно было лучше сделать”
🔝 “Уже есть функция, которая делает ровно тоже самое”
🔝 “У нас так не принято, переделай”
Несмотря на то, что комментарии действительно неконструктивны, я допустил, что мой коллега, может быть, и не закладывал все те негативные эмоции, с которыми я читал его сообщения. Стало понятно, что мы по-разному воспринимаем текст, и надо приходить к общему знаменателю.
Что мы сделали, чтобы это исправить:
🔝 Поделили комментарии к коду на несколько типов и сформировали формат сообщения
🔝 Ревьювер объясняет, почему он оставил этот комментарий
🔝 Если ревьювер видит необходимость переписать решение, то к комментарию прилагаются указания / инструкция / вариант решения / ссылка на источники с пояснениями (используй код-ревью как еще один канал для обучения и менторства)
🔝 Поощряем использование эмодзи в комментариях
🔝 Хорошие решения стоит подмечать и давать позитивную обратную связь
🔝 Ввели анекдоты к пулл реквестам (по желанию)
До этих правил мы дошли не сами, а подсмотрели у других команд: в Яндекс Практикуме, у Гугла, Гитлаба. Привожу слегка перефразированные, но реальные комментарии из нашего репозитория, чтобы понимать, к чему мы пришли:
❗️Обрати внимание:
В проекте это значение используется ещё несколько раз. Думаю, ее можно вынести в константы, чтобы повысить читаемость.
❓ Есть вопрос:
Почему ты решил остановиться именно на этой библиотеке? Смотрел ли в сторону *Library_name*? Судя по описанию, она работает быстрее и весит меньше.
🚀 Возможность для улучшения:
Кажется, здесь компонент будет перерисовываться много раз на странице из-за изменения состояния. Попробуй вынести его отдельно и кешировать, чтобы избежать замедления работы. *Пример кода по возможности*
В итоге общее впечатление команды от ревью от спринта к спринту стало сглаживаться даже по мнению того самого коллеги. Сейчас, спустя год, мы не всегда придерживаемся такого формата - это остается по желанию ревьювера. Но в самом начале такие упражнения помогли участникам процесса осознаннее подходить к код-ревью.