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

Это не личное

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

Однако великая ирония всей этой катастрофы заключается в том, что, пытаясь избежать разрыва социальной ткани группы, мы фактически выводим ее из строя. Мы останавливаем его продвижение. Члены группы, которые не могут быть честными друг с другом, а также позитивно настроены на честность, выражают удовлетворение существующим положением вещей. Улучшение требует вызовов, и мы как группа / команда обязаны постоянно и настойчиво бросать вызов себе и друг другу.

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

Познакомьтесь со своей командой

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

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

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

Я использую себя в качестве примера. До того, как я присоединился к моей нынешней компании Birdie, я никогда не занимался профессиональной бэкенд-работой. В частности, мои знания SQL были довольно плохими. Поскольку мы поощряем беседы 1–1 с коллегами, другие инженеры должны понимать мой опыт, а также мое стремление к совершенствованию в этой области. Это означало, что когда я отправлял PR на проверку, который включал запрос к базе данных, они не просто исправляли что-то вроде «Использовать соединение» или «Это должно быть проиндексировано», а скорее находили время, чтобы объяснить свой запрос. Это помогло мне стать лучше, а это означало, что проверка кода с использованием запросов включала меньше ошибок и упущений.

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

Задавать вопросы

При получении запросов на изменение может возникнуть определенная усталость. Фраза «Я просто хочу, чтобы это слилось» не редкость в командах инженеров. Однако в тот момент, когда мы рассматриваем запросы на изменение как просто барьер между нами и объединенной работой, у нас возникает проблема. Проблема в том, что мы превратили обзор из обсуждения в диктант.

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

  1. Предоставляет ли это ценность для пользователя
  2. Имеет ли это ценность для разработчика?

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

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

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

Обеспечьте контекст

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

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

  1. Что делает этот пиар?
  2. Предоставьте снимок экрана / скринкаст его функциональности (не всегда применимо)
  3. Как это можно проверить вручную
  4. Есть ли там тесты

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

Увидеть картину в целом

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

expect(array.length).toBe(0)

to

expect(array).toHaveLength(0)

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

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

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

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

Заключение

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

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

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

📝 Прочтите этот рассказ позже в Журнале.

👩‍💻 Просыпайтесь каждое воскресное утро и слушайте самые интересные истории недели в области технологий, которые ждут вас в вашем почтовом ящике. Прочтите информационный бюллетень« Примечательно в технологиях .