Connect with us

Разработка

Что нужно и чего не нужно делать во время Code Review

Сандия Санкаррам из компании SurveyMonkey рассказала о том , как распознать токсичную коммуникацию среди программистов и как с ней бороться.

Анна Гуляева

Опубликовано

/

     
     

Code Review могут быть спорными. Недавно я впервые выступала на конференции с темой токсичного поведения в культуре просмотра кода. Я готовилась получить большое количество критики, но в итоге тему приняли добротой и поддержкой.

Меня попросили поделиться слайдами, но мне кажется, что сами по себе они не очень полезны, так как им не хватает контекста. Так как они распространились по интернету без этой нужной информации, я решила написать статью, чтобы более полно донести свое выступление.

Я перечислила несколько распространенных шаблонов поведения, которые случаются во время Code Review, а также несколько рекомендаций о том, как команды разработчиков могут создать более благоприятную атмосферу, если не будут делать токсичность нормой. Все описанное происходило со мной или я была этому свидетельницей. Я и сама вела так себя в прошлом.

1. Представление мнения в качестве факта

Не делайте заявлений, пока не сможете процитировать документацию, формальные требования или примеры кода, чтобы подтвердить их. Людям нужно знать, почему их просят внести изменение, и личные предпочтения — это недостаточно хороший аргумент.

Вместо того, чтобы говорить “В этом компоненте не должно быть состояний” предоставьте контекст этих рекомендаций:

“Так как в этом компоненте нет методов или состояний жизненного цикла, его можно сделать функциональным компонентом без состояний. Это улучшит производительность и читабельность. *Вот* документация.”

Это поведение распространено, когда разработчики обсуждают предпочтения в стиле и синтаксисе. Это важные обсуждения, но они не должны происходить во время просмотра кода, так как стиль и синтаксис не относятся к проблеме, которую разработчик изначально планировал решить.

Выделите эти дискуссии и решите, каких правил и стиля будет придерживаться группа. Используйте линтеры и автоматические фиксеры. Так вы сможете придерживаться правил по стилю, а не своих персональных предпочтений, во время обзора кода.

Это особенно важно, когда у вас более высокая должность или авторитет в команде. Если вы будете так себя вести, у разработчиков не останется другого выбора, и им придется подстраиваться под ваши требования.

2. Лавина комментариев

Когда человек совершает ошибку, вероятно, он или она сделали ту же ошибку в других местах. Я заметила, что часто те, кто просматривает код, указывают на каждый случай ошибки вместо того, чтобы оставить один детальный комментарий со ссылками на полезные ресурсы.

Объединение комментариев позволит вам донести свое сообщение и не ошеломить человека. Бесполезно и угнетает:

Более полезно:

Я могу понять, что это может быть полезно, так как комментарий исчезает, когда разработчик исправляет ошибку. Но если эта ошибка повторяется, значит, разработчик не знает об определенном правиле, и ему или ей нужно указать на корректные ресурсы.

3. Просить инженеров решить проблемы, которые возникли не из-за них

Не просите разработчиков решать проблемы, которые не относятся к их изменениям или к проблеме, которую они пытаются решить. Даже если разработчик работает с беспорядочной частью кода, не просите его или её исправлять код просто потому, что они работают с ним в данный момент.

Я не говорю, что разработчики не должны чувствовать ответственность за код, который начали писать не они. Я говорю, что более правильным решением будет создать отдельный тикет и решение для беспорядочного кода. Так вы не добавите кому-то работы, и плохой код будет исправлен.

Правила, которые я выработал по результатам тысяч code review

4. Задавать осуждающие вопросы

Не задавайте вопросов вроде: “Почему ты просто не сделаешь это здесь?”. Такие вопросы предполагают, что это очевидное решение. Это также заставляет разработчиков оправдываться.

Эти осуждающие вопросы часто являются замаскированными просьбами. Вместо этого напишите рекомендацию (с цитированием документации) и не используйте грубые слова.

“Ты можешь сделать это, и это будет полезно поэтому.”

5. Сарказм

Сарказм — это неправильное поведение, когда вы даете обратную связь. Саркастические комментарии ничего не объясняют. Вместо этого детально опишите проблему и напишите рекомендации, но оставьте шутки в стороне.

Бесполезно: “Ты вообще тестировал(а) этот код?”

Полезно: “Происходит сбой при вводе отрицательного числа. Можешь, пожалуйста, разобраться с проблемой?”

Вот ещё один пример комментария, который несмешной и бесполезный:

Я не говорю, что мы подлые. Мы просто беспощадные. Ты заметишь, что я оставил комментарий “Бип!” на импорте каждого файла, к которому ты притронулся. Я имел в виду, что твои импорты нарушают нашу стандартную процедуру, но это было слишком долго писать в каждом файле.

Комментарий “Бип!” бесполезен. Это просто педантичный юмор, который не помогает человеку, который писал код.

6. Использование эмодзи, чтобы указать на проблемы

Не нужно использовать эмодзи с пальцами вниз или человеком, которого тошнит. Это так же бесполезно, как и сарказм. Эмодзи можно понять неправильно. Эмодзи тратят время людей, которые пытаются понять, что вы имели в виду.

Вряд ли вас действительно будет тошнить от ошибок в коде. Вы можете использовать радостные эмодзи, чтобы показать, что код выглядит хорошо, но не используйте их, чтобы указать на проблему.

7. Ответ не на все комментарии

Люди, которые писали код, могут тоже вести себя некорректно. Если вы отправляете код без ответа на все комментарии, люди могут задуматься, зачем они вообще тратили время на помощь вам, а вы покажете, что некоторые мнения важнее других.

Если комментарий относится не к вашей работе или вы не будете действовать в соответствии с обратной связью, просто кратко объясните причины. Не занимайтесь гостингом.

8. Игнорирование токсичного поведения производительных людей

Токсичное поведение не нужно игнорировать только потому, что разработчик отлично работает. Хотя он или она может делать фантастическую работу, важно помнить, что их поведение делает работу других людей сложнее.

О работе с людьми, ведущими себя токсично:

Всем остальным работать с этим человеком будет сложно и неинтересно. Они будут избегать взаимодействия с ними, даже если это негативно повлияет на их способность выполнять задания. Коммуникация в вашей организации нарушится. Если все станет плохо, ваша команда начнет искать возможности в другом месте. Пока вы будете сталкиваться с утечкой людей и неудачными проектами, эти разработчики продолжат работать так, как будто все в порядке. — Джозеф Гефрох.

Бездействие может оказать серьезное влияние на команду, так как разработчики будут чувствовать себя демотивированными. Они начнут бояться процессов фидбэка, которые должны были помогать им расти. Лично я нервничаю каждый раз, когда получаю письмо о том, что бывший коллега (который оставлял токсичную и бесполезную обратную связь), прокомментировал мой запрос. Хотя такое поведение влияет на всех по-разному, мы все можем согласиться, что никто не получает от этого пользы.

Примечание: хочу отметить, что случайное проявление одной из описанных вещей не делает человека токсичным. А вот повторяющиеся оскорбления и язвительная обратная связь говорят о многом.

Как писать чистый и красивый код

Полезные вещи в обзоре кода

Это рекомендации, которые можно применить к любому человеку в дружелюбной среде, даже если здесь они даны в контексте просмотра кода.

1. Используйте вопросы или рекомендации, чтобы вести диалог

Никогда не требуйте от людей внести изменения и не задавайте осуждающих вопросов, потому что это не открывает диалог между вами. Резкие вопросы заставляют их оправдываться. Вместо этого спросите, что человек думает о предложенном решении:

“Можно поместить эти трансляции в файл констант, как думаешь? Их слишком много, имеет смысл создать для них отдельный файл.”

или предоставьте рекомендацию:

“У тебя в этом файле много запросов на трансляцию функции X. Имеет смысл создать отдельный файл под константы функции X.”

2. Не указывайте, а работайте вместе

Когда вы занимаетесь парным программированием, вы должны задавать вопросы, обсуждать и давать ссылки на ресурсы.

“Когда вы хотите работать с другим человеком, вы должны быть полностью вовлечены, а не просто появляться периодически”, — указания для пользователей Recurse Center.

3. Отвечайте на каждый комментарий

Если вы не планируете применять советы человека, оставьте заметку об этом. Не игнорируйте тех, кто уделил время на помощь вам.

Например:

“ — Что ты думаешь о создании хелпера для этого вызова API?

— Эта строка не входит в мой набор изменений. Я пока отправлю этот код, но я создам отдельную issue на GitHub для вызова API и отправлю это в бэклог группы.”

4. Иногда обсуждение нужно перенести в оффлайн

После десятков противоречивых комментариев и предложенных решений должно быть понятно, что онлайн-коммуникация стала непродуктивной для решения проблемы. Устройте встречу, чтобы обсудить вопрос вживую, так вы сможете прийти к решению быстрее.

5. Используйте возможности, чтобы научить чему-то, и не хвастайтесь

Перед тем, как участвовать в просмотре кода, спросите себя — ваш комментарий помогает другому разработчику учиться или вы просто любите придираться?

Подумайте, почему вы принимаете в этом участие. Помните, что цель просмотров кода — помочь другим разработчикам расти.

6. Не выказывайте удивление

Не нужно удивляться, если у кого-то нет тех же знаний, что есть у вас. Если люди могут понять нехватку опыта в какой-то теме и попросить о помощи —  это отлично. Не заставляйте их переживать из-за того, что они “уже должны были знать” эту информацию.

Григорий Петров: Код проекта: что хотел сказать разработчик

7. Автоматизируйте все возможное

Просмотр проблем, которые могут уловить линтеры, перехватчики в git или автоматизированные тесты, бесполезен. Люди не всегда видят эти проблемы, и поэтому существуют эти инструменты автоматизации.

Существуют инструменты, которые запускают тесты после проверки кода, и они показывают предупреждения, когда набор изменений нарушает какие-либо тесты. Эти функции есть у TeamCity и Jenkins CI. Используйте перехватчики в git. Они запускают тесты и линтеры, когда кто-то пытается отправить код, и перехватывают этот запрос, если в нем содержится код с ошибками.

8. Отказывайтесь от нормализации токсичного поведения

Не нужно поддерживать токсичные комментарии из-за их статуса кво. Ищите коллег, которые вас поддержат в этом. Если вы заметите, что кто-то оставляет бесполезные комментарии, дайте им знать об этом (если вы можете сделать это на вашей должности и в вашей компании) и будьте прямолинейны.

Григорий Петров: Как и зачем читать чужой код

9. Менеджеры, нанимайте внимательно, слушайте свою команду и применяйте меры

Менеджеры могут создать позитивную и дружелюбную культуру в своей команде.

  • Не нанимайте в команду токсичных разработчиков. Смотрите не только на технические навыки, оценивайте способности кандидатов к коллаборации и коммуникации. Критически анализируйте их работу и смотрите на их реакцию. Убедитесь, что каждый человек привносит что-то положительное в культуру компании.
  • Если у вас в команде есть токсичные разработчики, спросите у всех в отчетах о том, как им работается наедине с другими сотрудниками. Отчеты покажут, если у вас действительно есть токсичный разработчик.
  • Поговорите с этим человеком. Покажите ему примеры и правильную обратную связь.
  • Не изолируйте токсичного разработчика. Нужно побудить этого человека на здоровую коммуникацию с командой. Изоляция не поможет человеку исправиться.
  • Повторяйте, что ожидаете от команды коллаборации в дружелюбной обстановке.

10. Установите стандарт с самого начала существования команды

Если ваша команда небольшая, она может принять идеи и начать воплощать их сразу. Даже если вам это пока не нужно, помните, что вы хотите, чтобы ваша команда оставалась отличной с появлением новых сотрудников.

11. Поймите, что вы можете быть частью проблемы

Чтобы сделать обстановку лучше, важно быть честными с собой и подумать о том, не вели ли вы себя таким образом. Когда я была джуниор-разработчиком, у меня было несколько случаев, когда я видела баг в чьем-то коде и радовалась, потому что так я могла стать частью просмотра. Я теперь понимаю, что использовала эту возможность, чтобы похвастаться, а не помочь. Я пытаюсь помнить об этом и я думаю, что у каждого должен быть такой момент саморефлексии.

Одна последняя вещь…

Я не хочу регулировать содержимое фидбэка, я просто прошу людей следить за своим тоном.

Я знаю, что обратная связь важна, и я не объявляю ей войну. Я не прошу команды жертвовать качеством своего кода. Здоровая культура Code Review и высокое качество кода не исключают друг друга. Я надеюсь, что люди предпримут шаги, чтобы предоставлять конструктивную обратную связь и создать более благоприятную среду, где разработчики смогут учиться, расти и совершать ошибки.

Краткое содержание:

https://twitter.com/jalehafshar/status/939976095381598208?ref_src=twsrc%5Etfw&ref_url=https%3A%2F%2Fmedium.freecodecamp.org%2Fmedia%2F55aef60009c0286ae84637d6f51dcfff%3FpostId%3Db7c295452a3c

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Новости

Интересные материалы: 23.10

На ночь глядя разбираемся с Tensorflow, менторством джуниоров и магией бумаги.

AppTractor

Опубликовано

/

Автор:

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Обучение

От данных к действиям с Airbnb Plus

История Data Science-интерна, который провел лето в Airbnb.

AppTractor

Опубликовано

/

Автор:

Стажировки – это одна из самых сильных и важных вещей для студентов. Они позволяют вам за 3 коротких месяца многому научиться и кратно вырасти в опыте. Помимо этого, стажировки помогают налаживать связи, улучшают навыки работы в команде и позволяют научиться ориентироваться в организациях.

Этим летом Габриэль Сикуэйра прошел стажировку по Data Science в новой команде Airbnb Plus. В этой статье он отвечает на некоторые распространенные вопросы о Data Scientists в Airbnb и проливает некоторый свет на то, что действительно делает стажер в Больших Данных.

 

Комментарии
Продолжить чтение

Интервью

Евгений Кот (Wrike): Dart стал гораздо серьезнее!

Каково будущее Dart? Что нового в версии Dart 2.0 по сравнению с предыдущей? Евгений Кот ответил на наши вопросы про язык, на котором разрабатывается продукт в Wrike, а также рассказал про DartUp – первую русскоязычную конференцию пo Dart/Flutter, которая пройдет 1 декабря в Санкт-Петербурге.

AppTractor

Опубликовано

/

Автор:

Евгений Кот – фронтенд тимлид в компании Wrike. До этого чем только не занимался, был C++ и C#. В Dell начал заниматься фронтендом, так и завертелось. Также Евгений –  Dart GDE (Google Developer Expert).

Вы работаете в компании, которая использует Dart для разработки своего продукта. Что было до него? В какой момент пришло понимание, что нужно переходить именно на Dart?

Когда я только пришёл в Wrike ( это было четыре года назад) нас было гораздо меньше, а фронтенд за это время вырос аж в семь раз! Тогда мы писали всё на JavaScript. Также у нас был ExtJS третьей версии, включая части других фреймворков. Продукту всё-таки уже десять лет.  Эти технологии не так плохи сами по себе, но вдесятером поддерживать такой проект становилось всё сложнее. В тот момент стало понятно, что компания и команда будут расти вместе с продуктом. Нам была нужна типизация – чем строже, тем лучше. В те времена выбор был небольшой: Flow и TypeScript только начинали развиваться, но не давали должной уверенности. Стали искать альтернативы и наткнулись на Dart. Тогда, конечно, инструменты были “сырее” и сам язык был немного другой. Но мы не побоялись и поставили на “тёмную лошадку”. О том, почему мы перешли на Dart,  можно почитать в нашей статье.

Dart — язык программирования, созданный Google. Dart позиционируется в качестве замены/альтернативы JavaScript. Один из разработчиков языка Марк Миллер написал, что JavaScript «имеет фундаментальные изъяны», которые невозможно исправить. Поэтому и был создан Dart.

Первая общедоступная информация об этом языке программирования появилась 12 сентября 2011 года на конференции разработчиков Goto. 10 октября 2011 была проведена официальная презентация языка Google Dart.

Задачи, поставленные перед разработчиками языка:

  • Создать структурированный и в то же время гибкий язык для веб-программирования
  • Сделать язык похожим на существующие для упрощения обучения
  • Высокая производительность получаемых программ как в браузерах, так и в иных окружениях, начиная от смартфонов и заканчивая серверами.

Dart: как и где он используется?

Ну-с, немного ликбеза. Dart – язык, созданный Google уже больше шести лет назад. Он имеет строгую типизацию, SDK и свою экосистему и может исполняться на различных платформах. Сами разработчики позиционируют его как “язык, оптимизированный для клиентской разработки“. Таким образом, он лучше всего подходит для разработки именно клиентских приложений – Web и Mobile. На бекенде его тоже можно использовать, но там конкуренция инструментов гораздо выше.

Чтобы понять бенефиты Dart, надо просто попробовать написать большое приложение, например, на JavaScript – недостатки слабой системы типов рано или поздно всплывут. Тут конечно можно со мной поспорить, и я с радостью это сделаю, пишите в соцсети :-) Мы используем его для создания web-части нашего продукта. Также у нас есть несколько критических сервисов, написанных на Dart, и мы присматриваемся к мобильным возможностям языка.

Многие нам говорят – “так на нём никто не пишет, только Wrike, что же его использовать”. Это совсем не так. В русскоговорящем сообществе мы, пожалуй, самые большие его потребители –  это правда. Даже коллеги из Google признают, что у нас самое большое после них web-приложение. Но компаний много: например, Workiva. Сам Google перешёл на Dart в AdWords – это их основной сервис для зарабатывания денег. Малейшая бага – и всё, миллионов нет.

В русскоязычном сегменте появляются вакансии и компании, которым интересен данный язык программирования. Кстати, на конференции DartUP, которая пройдет в Петербурге уже 1 декабря, будут выступать разработчики из других “евангелистов” языка.

Вы организовали сообщество русскоязычных Dart-разработчиков, которое официально было признано Google. C чего все начиналось?  Как вы поддерживаете и развиваете сообщество?

Ну как это обычно бывает – используешь сам, а потом понимаешь, что только с коллегами обсуждать скучно и нужна “свежая кровь”. Началось всё с небольшого митапа три года назад – тогда Dart в России вообще никто не использовал. С тех пор это переросло в небольшое, но уютное комьюнити. Основным каналом общения остаётся чат в телеграмме, но также есть Slack. Периодически мы организуем митапы побольше, все видео доступны на YouTube канале:

Мне кажется сообщество – это как костер:  оно само себя поддерживает, если есть топливо. Мы отвечаем на вопросы в чате, организуем митапы, делимся своим опытом. Понятно, что с каждым инфоповодом в канал приходят новые люди, основной вопрос: “Ну что там, можно Dart для продакшена использовать?”. Ответ – “да” обычно не устраивает, так что бывают и холивары.

В чем основные преимущества Dart? Можно ли его использовать для создания мобильных приложений?

Это система типов + SDK + поддержка различных платформ. Я могу написать один блок кода и переиспользовать его везде. Сейчас никого этим не удивишь. JavaScript есть в каждом “утюге” и языки с типизацией уже не в новинку (TS, Kotlin и так далее). Но преимущество состоит как раз в сочетании всех этих факторов. В Dart 2.0 разработчики выкрутили типизацию на максимум. На Dart писать просто приятно. В целом, все разговоры X лучше Y всегда должны начинаться с вопроса: “Для каких  именно задач это можно применять?”. И тут уже можно что-то обсуждать.

Что касается мобильных приложений, теперь есть Flutter! Он позволяет писать код сразу под Android и iOS – эти приложения будут быстрыми и красивыми. Звучит как рекламный слоган, но это действительно так. Архитектура Flutter отличается от всех остальных мультиплатформенных фреймворков (ReactNative, Xamarin и прочих), поэтому это что-то совершенно иное.

Подкаст AppTractor: Flutter

Расскажите немного про Dart 2.0. Какие нововведения в нем произошли по сравнению с предыдущей версией языка?

Когда язык только проектировался, он должен был “убить” JavaScript, но “под капотом” он был достаточно слабо типизирован. И это, на мой взгляд, определило его провал в те годы. Ведь зачем нужен ещё один JS, который, по своей сути, не очень от него отличается? Во второй версии Dart стал гораздо серьезнее во многих вопросах. Это открыло дорогу многим оптимизациям (например, более агрессивному TreeShaking). Также была проделана большая работа по инструментам: появилось много пакетов, новый сборщик и так далее. Теперь это более production ready язык, чем был когда-либо.

Как родилась идея организовать конференцию DartUp, которая совсем скоро пройдёт в Спб? Что вы от нее ожидаете?

Конференция является идейным продолжением митапов, которые мы организовывали каждый год. Мы дозрели до масштабного мероприятия  – будет целый день докладов с крутыми спикерами, большинство из которых приедут из других городов и разных компаний.

Конференция DartUp полностью бесплатна, нужно только зарегистрироваться. И как и год назад, мы  наварили специального Dart-пива.

Мы ожидаем от конференции только позитивных эмоций!  Приятно видеть, что сообщество растет и взрослеет. А ещё ожидаем в гости всех и тем более тех, кто о Dart ничего не слышал – будет весело!

Комментарии
Продолжить чтение

Новости

Интересные материалы: 22.10

У нас лучшие идеи для приложений, архитектура и конкурс ВКонтакте.

AppTractor

Опубликовано

/

Автор:

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Реклама

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.