Команда не воспринимает всерьез мои комментарии по обзору кода

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

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

Мне кажется, это культурное несоответствие.

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

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

Если бы вы были в моей ситуации, что бы вы сделали?

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

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

Вы бы изменили свое отношение, чтобы больше не заботиться?

Точно нет.

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

Подводя итог вопросу, как он читается сейчас:

1. Я хочу добиться согласованности в коде и избежать глупых ошибок в продакшене.
2. Частью моей работы является код-ревьюер.
3. Мне приходится постоянно напоминать им о необходимости следовать согласованным стандартам кодекса.
4. Я не могу просто игнорировать основные ошибки
5. Мой менеджер не контролирует команду

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

Как проходит код-ревью? Это commit->review->comment/accept? Тогда сделайте именно это. Передавайте все горе от команды своему менеджеру. Они поручили вам выполнить важное задание, у вас, кажется, есть соответствующий опыт. Их работа состоит в том, чтобы помочь вам выполнить эти задачи.

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

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

Так что вам придется завоевывать сердца и умы.

Как старший специалист по код-ревью, у меня есть твердое мнение о том, что правильно, а что нет, когда речь идет о коде. («Ад — это чужой код», если неверно цитировать Сартра).

ТЕМ НЕ МЕНЕЕ:

Я очень тщательно различаю «вы должны исправить это, потому что код не работает» от «я бы предпочел другой стиль» (каждое из которых имеет разную степень настойчивости). Сосредоточьтесь на том, что сломано. Со временем люди добровольно принимают мои предпочтения — потому что они хороши, а не потому, что я так говорю (я не всезнающий, я просто натерпелся достаточно дерьма, чтобы иметь предложения, как этого избежать).

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

Я не могу просто игнорировать основные ошибки, допущенные в обзорах, и пустить этот код в производство.

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

Я не в состоянии просить их сделать это явно

Тогда вы не делаете код-ревью.

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

Однако, если я упускаю какие-то детали, и вы уверены, что подверглись дискриминации по вашему полу, то они не имеют права напрягать вас из-за вашего пола, и вот шаблон, которому вы должны следовать:

1. Создайте тикет или документацию по обнаруженному вами дефекту и задокументируйте, что он был проигнорирован другими.
2. Затем задокументируйте дефект, обнаруженный разработчиком-мужчиной, и отметьте, что он был исправлен в соответствии с запросом. (Если, как вы сказали, рецензентов несколько, то лучше - собрать решенные и проигнорированные тикеты.)
3. Поговорите со своим менеджером с распечаткой этих двух доказательств и спросите, почему ваш дефект был проигнорирован, а вы вели себя по-другому.

Гендерная дискриминация является серьезной проблемой, к которой нельзя относиться легкомысленно. Вы сказали, что у вас «стресс», а это значит, что что-то не так — и не стесняйтесь обострять проблему, пока не будете полностью удовлетворены.

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

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

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

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

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

Поднимите код на одну или две буквы, а не с F на A

Люди, которые создают код F-качества, делают это не специально. Либо они неопытны, либо просто не умеют. Вы не можете взять младшего разработчика (или старшего разработчика с вредными привычками всю жизнь) и ожидать, что он изменит все свои привычки за один день. Более того, это необоснованный стандарт, поскольку ни один код не может быть по-настоящему идеальным: даже вы делаете ошибки и что-то упускаете. Сосредоточьтесь на двух-трех основных недостатках и устраните их в обзоре кода, чтобы код перешел от F к C. Поверьте, что со временем ваши разработчики станут лучше, и как только они начнут создавать код уровня C, вы можете беспокоиться о них. перейти на B или A.

Привязывайте обратную связь к принципам, а не к мнениям

У людей разные мнения о том, как создавать код — это нормально. Если вы настаиваете на том, что что-то изменилось только потому, что вы бы сделали что-то по-другому, то ваши отзывы будут считаться произвольными и бессмысленными. Вместо этого привяжите обратную связь к конкретным принципам: «это не масштабируется», «это не модульно», «слишком много происходит в этом одном классе или функции», «руководство по стилю говорит, что нужно делать это так».

Оформляйте обратную связь как запросы, а не команды

Вы бы не сказали своему коллеге принести вам кофе. Используйте инклюзивный язык: «Мы должны добавить сюда проверку ошибок».

Разделите большие обзоры на маленькие обзоры

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

Не задерживайте одобрение тривиальных изменений

Ваши коллеги - профессионалы. Доверьтесь их профессионализму. Если у вас есть только несколько комментариев, скажите: «X, Y и Z — это незначительные изменения, которые улучшат ситуацию, но пока я одобряю это изменение».

Искренне хвалите, где это возможно

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

Вы пытаетесь изменить встроенный способ ведения дел, который, вероятно, возник из-за системы стимулов в компании.

В моей компании технически есть стандарты кодирования, проверки кода, планы документации и т. д. Будет ли кто-то им следовать, зависит от того, насколько мы близки к концу спринта. До конца первых 5 дней в их билетах будут организованы модульные тесты, проверка кода и SQL. Оставшееся время спринта становится сомнительным. Ошибки во внешнем интерфейсе, как правило, вызывают больше беспокойства, чем ошибки в бэкэнде.

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

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

Осознает это руководство вашей компании или нет, скорее всего именно они поощряют такое поведение тем, что вознаграждают, на что жалуются и что расставляют по приоритетам.

Вы мало что можете с этим поделать, поскольку здесь вы, по сути, идете против руководства.

Мне очень нравится ответ Джо, но я расскажу о нескольких очень тревожных для меня признаках.

Мне приходится постоянно напоминать им следовать согласованным стандартам кода, документировать вещи и просто брать на себя ответственность.

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

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

Обзоры кода в командах — это не семинары, на которых один человек рассказывает другому, как что-то делать. Это сотрудничество для достижения лучшего качества путем открытого обсуждения между людьми, работающими над проектом. Если вы ведете себя как ворчливая мамаша, вместо того чтобы тратить время на объяснения и поиски консенсуса с другими разработчиками, почему вы удивляетесь, что они просто начнут игнорировать ваши отзывы?

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

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

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

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

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

Качество кода не имеет значения. Продажи делают. Создание нового продукта помогает, потому что это увеличивает продажи. Перепишите код сто раз, и ваши продажи не вырастут.

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

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

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

Но до тех пор, пока кодовая база относительно невелика, качество кода добавляет лишь незначительную ценность. Итак, чтобы аргументировать качество кода, вы можете рассмотреть, какие бизнес-цели/ошибки являются наиболее актуальными сейчас и в следующем году, и привести аргументы в пользу определенного качества кода (повторное использование, именование, ясность и т. д.) в этих областях. области. Затем вы можете представить это своему менеджеру: «Эй, компонент xyz рассматривается как важная вещь для нашего продукта, мы должны быть активными сейчас, чтобы содержать его в чистоте, чтобы он не вызывал проблем позже».

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

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