Как проводить ревью кода и давать содержательную обратную связь

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

Вступление

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

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

1. Не бойтесь проверять код более опытных инженеров-программистов.

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

2. Спланируйте, когда вы хотите начать проверку кода.

Проверка кода - это та часть работы, когда вы не хотите, чтобы вас отвлекали. Когда каждые 10–15 минут отвлекаешься, с большей вероятностью не заметишь каких-то изъянов в коде. Постарайтесь посвятить один час полному фокусу времени (или больше, в зависимости от размера кода, который нужно проверить). Я стараюсь делать это в основном по утрам. Также помните о перерывах - дайте мозгу немного отдохнуть.

3. Если вам есть что проверять - делайте это по частям.

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

4. Не бойтесь задавать вопросы, когда не уверены.

Не стесняйтесь обращаться за разъяснениями, если вам что-то не нравится. Когда что-то настолько сложное, что ваши коллеги не могут понять, что происходит в коде, может быть, пора подумать о некотором рефакторинге? Проверка кода - тоже отличный шанс чему-то научиться. Ведь глупых вопросов нет. 🙂

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

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

А теперь вам понравится читать книгу с множеством опечаток и ошибочно выбранных слов? Я так не думаю. Если вы заметили что-то, что плохо звучит или может быть улучшено - укажите на это. Имена функций, возвращающих логическое значение, должны быть вопросами; имена объектов должны отражать их назначение (Строитель должен создавать, Модель должен быть моделью без каких-либо других обязанностей). Вам не нужно быть перфекционистом, просто постарайтесь поддерживать свою кодовую базу в порядке - у вас не будет времени на это позже. Поверьте мне.

6. Не забывайте хвалить своих сверстников.

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

7. Задать вопрос или предложить что-то лучше, чем жаловаться.

При написании комментариев к коду я стараюсь использовать такие фразы, как «Что вы думаете?», «Что, если…?», «Как насчет …? »,« Учитывать…. ». Эти фразы побудят ваших коллег подумать о других решениях и станут отличной отправной точкой для обсуждения. Жалобы блокируют активное мышление и обсуждение в целом.

Как в этом простом случае:

let transactions = ... //array with lots of items
for transaction in transactions {...}

отзыв типа «Рассмотрите возможность использования map вместо for-in для повышения производительности» звучит лучше, чем «Вам следовало использовать map».

8. Не откладывайте слишком много времени на проверку кода.

Конечно, у всех нас есть много интересных новых функций, которые нужно реализовать. Но важнее работать в команде, а не по отдельности. Не заставляйте коллег ждать вашего отзыва. В противном случае вы получите 4–5 запросов на слияние на человека в списке «На рассмотрение» (что много для относительно небольшой команды).

Я пытаюсь организовать свой рабочий процесс проверки следующим образом:

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

Кроме того, неплохо определить какой-то «внутренний крайний срок» для проверки в вашей команде. Мол, если ваш код не проверяли последние две недели - можете объединить без проверки.

Заключение

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

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

На пути к финансовым услугам, доступным для всех

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