Программирование проверка кода

Я занимаюсь ежедневными обзорами кода уже более десяти лет. Преимущества анализа кода огромны: кто-то проверяет вашу работу на наличие ошибок, он учится на вашем решении. А совместная работа помогает улучшить общий подход организации к инструментам и автоматизации. Если в настоящее время вы не занимаетесь анализом кода в своей организации, начните прямо сейчас. Многие люди и организации поделились своими лучшими практиками анализа кода и тем. Что для них означает определение хороших обзоров кода. Руководства от Google, команды SmartBearи других компаний. инженер Филипп Хауэр отлично читает. Ниже приведен мой личный взгляд на то. Как выглядят хорошие обзоры кода и как сделать их еще лучше на командном и организационном уровне.

Это происходит в контексте технической среды, в которой я работаю – в настоящее время в Uber. А до этого в Skype/Microsoft и Skyscanner.

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

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

Эти обзоры корректируют свой подход в зависимости от контекста и ситуации. Цель состоит не только в том, чтобы получить качественный обзор, но и в том, чтобы помочь разработчикам и командам. Запрашивающим обзор. Быть более продуктивными.

Области, охватываемые Обзором Кодекса

Хорошие обзоры кода смотрят на само изменение и на то. Как оно вписывается в кодовую базу. Они будут смотреть через ясность названия и описания и “почему” изменения Они охватывают правильность кода. Тестовое покрытие. Функциональные изменения и подтверждают. Что они следуют руководствам по кодированию и лучшим практикам.

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

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

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

Тон рецензии

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

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

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

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

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

Утверждение и Запрос изменений

Как только рецензент завершает свою рецензию, он может либо отметить ее одобренной. Либо заблокировать рецензию запросами на изменения. Либо не устанавливать конкретный статус. Оставив ее в состоянии “еще не одобрена”.

То, как рецензенты используют статусы

Однако они дают понять. Какие вопросы или комментарии не являются блокирующими или несущественными. Четко выделяя их. Они явно выражены при одобрении изменений – например. Добавление комментария с поднятым большим пальцем типа “выглядит хорошо!”. В некоторых местах используются такие аббревиатуры как LGTM—они тоже работают, но имейте в виду. Что новички могут неправильно истолковать эти инсайдерские аббревиатуры для чего-то другого. Хорошие обзоры кода столь же явно выражены, когда они запрашивают последующую работу. Используя инструмент обзора кода или соглашение команды для передачи этой информации.

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

От Обзоров кода до Разговоров друг с другом

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

Но когда пришло время прекратить использовать инструмент—каким бы хорошим он ни был—и начать говорить лицом к лицу о коде?

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

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

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

Придирки

Придирки-это несущественные комментарии, где код можно было бы объединить, даже не обращаясь к ним. Это могут быть такие вещи, как объявления переменных в алфавитном порядке, модульные тесты, следующие определенной структуре, или скобки. Расположенные в одной строке.

Хорошие обзоры кода дают понять. Когда изменения несущественны. Обычно они четко помечают подобные комментарии. Добавляя к ним префикс “nit:”. Слишком многие из них могут привести к разочарованию и отвлечь внимание от более важных частей обзора. Поэтому рецензенты стараются не переусердствовать с ними.

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

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

Обзоры кодов для новых Столяров

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

Хорошие обзоры кода используйте одну и ту же планку качества и подход для всех, независимо от их должности. Уровня или времени прихода в компанию. Следуя вышесказанному. Обзоры кода имеют добрый тон. Запрашивают изменения там. Где это необходимо. И будут обращаться к рецензентам. Когда у них будет много комментариев.

Лучшие обзоры кода уделите дополнительное внимание тому. Чтобы сделать первые несколько отзывов для новых столяров отличным опытом. Рецензенты с пониманием относятся к тому факту. Что недавний столяр может быть не знаком со всеми руководящими принципами кодирования и может быть незнаком с некоторыми частями кода.

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

Кросс-Офис, Кросс-Часовой пояс Отзывы

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

в то время как базировался в Европе. Рецензенты стремятся пересмотреть кодекс в перекрывающиеся рабочие часы между офисами. Для отзывов с большим количеством комментариев рецензенты предложат пообщаться напрямую или сделать видеозвонок. Чтобы обсудить изменения.

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

Вопрос системного уровня заключается в том. Почему эти изменения происходят так часто. Изменения сделаны в правильной кодовой базе или должна быть изменена другая система? Будет ли частота изменений одинаковой или со временем снизится? Если предположить. Что изменения сделаны в правильной кодовой базе и частота не снизится. Можно ли каким-то образом нарушить межведомственную зависимость? Решения такого рода проблем часто не просты и могут включать в себя рефакторинг. Создание новых сервисов/интерфейсов или усовершенствование инструментария. Но решение подобных зависимостей облегчит жизнь обеих команд и сделает их прогресс более эффективным в долгосрочной перспективе. А это означает. Что отдача от инвестиций часто бывает весьма впечатляющей.

Организационная Поддержка

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

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

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

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

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

Начните С Хорошего. Сделайте его Лучше

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

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

——-

Гергели в настоящее время является ведущим инженером в Амстердаме. Эта запись в блоге первоначально появилась в блоге ГергелиПрагматичный инженерЕсли вы хотите узнать больше от Гергели. Вы можете подписаться на его ежемесячный информационный бюллетень для получения его статей по инженерии. Технологическому лидерству и распределенным системам. Если вы хотите внести свой вклад в блог Stack Overflow. Отправьте электронное письмо по адресу pitches@stackoverflow.com…

Теги: , , ,