От Songhua
Введение
В чем суть Code Review (CR)? Это для проверки ошибок? Или по КПИ? В этой статье представлены мнения старших технических экспертов Alibaba. CR — это долгосрочная практика и ориентация организационной культуры. Благодаря CR была сформирована благоприятная интерактивная техническая атмосфера, распространяющая и делящаяся знаниями и улучшающая качество кода. В этой статье также даются семь практических советов по повышению эффективности и качества CR.
Есть много статей о CR. CR — это стандартная практика многих организаций, но у многих команд возникают следующие вопросы, когда они пробуют CR:
- Достигла ли «политкорректная» КР желаемых результатов?
- Столкнувшись с большим количеством кода, с чего мне начать? Какие из них я должен рассмотреть? Какие из них я не должен рассматривать?
- Кто-нибудь внимательно просмотрел мой код? Как сделать так, чтобы другим было проще просматривать мой код?
Эти вопросы являются общими и поднимались в различных контекстах в течение многих лет. Чтобы ответить на эти вопросы, вам нужно сосредоточиться только на двух аспектах:
- Поймите основные цели CR и сформулируйте правильные ожидания в отношении CR
- Узнайте, почему CR может быть неэффективным, и примите целенаправленные меры для повышения его эффективности.
Зачем нам нужен КР?
Многие думают, что CR используется для проверки ошибок, и надеются использовать количество дефектов в коде для определения эффективности CR. Это недооценивает значение CR. Существенная роль CR заключается не в обнаружении проблем. Если мы стремимся обнаруживать проблемы, у нас есть больше и лучшие способы, чем CR. Роль CR в первую очередь связана с культурой и социологией организации и является долгосрочной практикой.
CR обеспечивает соответствие стандартам кодирования
Точка зрения программистов: мягкое социальное давление
Вы кодируете все, и ваш крайний срок вырисовывается. Кроме того, вашей организации требуется модульное тестирование кода: весь новый код должен пройти полное автоматизированное модульное тестирование. Однако под давлением вы можете немного снизить требования к написанию кода. Вы можете позже написать модульный тест для нового кода или написать немного менее полезный тест, чтобы соответствовать требованиям покрытия инструмента, например, тесты без утверждений.
Однако, когда вы знаете, что ваш код будет отправлен на проверку вашим коллегам, кажется ли эта идея менее заманчивой? Такого рода давление безвредно и может дать вам немедленные результаты, не давая вам выбрать «спекулятивное» поведение с краткосрочными прибылями и долгосрочными потерями. Если бы не было CR, у вас мог бы возникнуть соблазн «делать все, что вы хотите», но вам все равно пришлось бы платить за такого рода уловки.
Точка зрения специалиста по обслуживанию: гарантия читабельности кода
Есть много способов выполнить одни и те же требования к программному обеспечению. Заинтересованные читатели могут самостоятельно выполнить поиск по запросу Hello World’s N Ways of Writing. Хотя все дороги ведут в Рим, стоимость дорог разная. От именования переменных до структуры проекта, если вы примете менее распространенный метод, вы можете создать проблемы для более поздних сопровождающих кода. Это техническое обслуживание может выполняться через один месяц, через 1 год или дольше. В этот момент вы больше не являетесь автором кода в команде, и никто не может понять, почему программное обеспечение было разработано таким образом.
CR запускает этот цикл обратной связи раньше времени. Сразу после того, как код написан, есть один или несколько читателей, которые являются рецензентами кода. Поэтому этот код прошел проверку на читабельность сразу после написания. В идеале, если у организации уже есть спецификации кодирования и спецификации дизайна, она также может обеспечить соответствие кода этим спецификациям. Если в процессе CR будет обнаружено, что этот код не соответствует спецификациям, это также может дать преимущество. Это указывает на еще одну ключевую ценность КО: распространение знаний.
CR способствует распространению знаний и достижению консенсуса в области дизайна
Вы можете быть лидером команды, беспокоясь о том, как улучшить навыки программирования членов вашей команды. Вы хотите, чтобы они читали книги, поэтому приносите вводные книги, такие как «Чистый код». Вы также представляете классический режим проектирования и рекомендуете проектирование на основе предметной области. Вы можете периодически организовывать членов команды для обмена своими бизнес-знаниями в надежде, что члены команды смогут понять бизнес-логику продуктов.
Все эти усилия очень хороши, но также возможно, что вы будете поражены. Месяц спустя кажется, что члены команды установили концепцию соглашения об именовании, но нет единого мнения о том, как выполнять конкретное именование. Многие члены команды уже знают некоторые шаблоны проектирования. Однако некоторые используют избыточные шаблоны и делают код раздутым, в то время как другие знают только синглтон. Кроме того, члены команды спорят о том, что такое объект-сущность и что такое объект-значение, и никто не может четко сказать, что такое агрегация и к каким сценариям она применима.
Чего вам действительно не хватает, так это сцены. Трудно сформировать консенсус, если абстрактные концепции не реализуются на практике. Некоторые люди могут знать понятие «прецедент» в правовой системе общего права, что является очень хорошим способом сформировать консенсус на юридическом уровне. CR формирует прецедент: какой тип дизайна разумен и какой тип дизайна нецелесообразен? Анализируя конкретные проблемы, команда постепенно формирует консенсус по дизайну. При этом новые члены команды, не знакомые с консенсусом, также могут постепенно интегрироваться.
Проверка логической правильности
CR также можно использовать для проверки логической правильности.
Дизайнер несет ответственность за правильность логики кода.
Чтобы предотвратить злоупотребление CR и завышение ожиданий, мы должны сначала объявить одну вещь: Разработчик несет ответственность за обеспечение правильности логики кода. Если возникает ошибка нулевого указателя, как можно определяем плохая кодировка, плохой CR или тест плохой? Во-первых, автор кода должен был создать эту проблему. Справедливо ли обвинять в этой проблеме рецензента кода? Возможно, за обнаружение таких проблем отвечает рецензент кода, но что, если код содержит ошибки по своей сути? Что делать, если рецензент кода просмотрел 1000 строк кода за раз, но не может просмотреть весь код, чтобы найти эту проблему? Как рецензент кода, можно найти множество причин, по которым такая ошибка нулевого указателя пропускается.
Другие методы поиска логических ошибок
У вас есть много других методов поиска ошибок, и их стоимость часто невелика:
- Написание автоматизированных модульных тестов
- Использование инструментов статической проверки кода
Независимо от того, ведется ли деятельность по CR, предыдущие два пункта — это действия, которые профессиональный разработчик и организация, занимающаяся разработкой, должны активно поддерживать.
Ценность поиска ошибок
При условии, что предыдущие два пункта распознаны, для поиска ошибок следует использовать CR. По сути, он устанавливает механизм избыточности, когда несколько человек работают над одним и тем же фрагментом кода, чтобы обнаружить любую небрежность и когнитивные ошибки, которые могут существовать в коде, которые часто трудно найти одному разработчику.
Эффективный и качественный CR
Факторы, препятствующие эффективности КО
CR сам по себе не сложен, но если учесть следующие факторы, то может быть сложнее:
- Вы можете ничего не знать о контексте разработки кода, подлежащего проверке.
- Вы можете быть очень заняты.
- Вы неожиданно получили тысячи строк кода, которые необходимо проверить.
Практические предложения
Предложение 1: Небольшие партии — меньше кода для каждого обзора
Исследования показывают, что успешная деятельность в области устойчивого развития должна быть мелкомасштабной. Например, в документе "Modern Code Review: Case at Google" говорится, что в ходе CR-активностей Google был изменен только один файл на 35 % CR-активностей, было изменено менее десяти файлов. для 90% действий по CR, и только одна строка кода была изменена для 10% действий по CR.
Есть два основных преимущества одновременного просмотра небольших объемов кода: очень ясно, где вносятся изменения, и проблема будет ясна с первого взгляда. Если вы отправляете кому-то более 1000 строк кода за раз, крайне маловероятно, что вы получите ценный обзор.
Проверка должна выполняться для кода значимой и полной функции. Если код не предназначен для исправления дефектов, разработчики должны разрабатывать функции итеративно.
Предложение 2: несколько партий — частые обзоры
Небольшие партии неизбежно приведут к множеству партий. В статье Microsoft 2013 года iExpectations, Outcomes, and Challenges of Modern Code Review и вышеупомянутой статье Google упоминалась практика частых проверок. Среди них среднее еженедельное количество изменений кода Google на одного разработчика — три, а среднее недельное количество обзоров на одного рецензента — четыре.
Предложение 3: Найдите подходящего человека — подходящего рецензента
Кто подходит для проверки вашего кода? Неразумно выбирать кого-то, кто не имеет никакого отношения к анализируемому коду. Лучшие потенциальные кандидаты перечислены ниже:
- Если в вашей организации есть механизм владельцев, владелец — правильный человек.
- Коллеги, которые работают в том же контексте, что и вы
- Коллеги, которые недавно модифицировали тот же код
- Более опытные программисты, с которыми вы можете работать, чтобы получить профессиональную обратную связь
Уже есть некоторые инструменты, которые могут рекомендовать рецензентам в зависимости от контекста. Это облегчает выбор подходящих рецензентов.
Предложение 4: Быстрый ответ
Когда степень детализации каждой проверки невелика и необходимы частые проверки, возможен быстрый ответ, что также является неизбежным требованием. Среднее количество часов проверки Google на одного рецензента составляет четыре часа. Этот показатель может быть хорошим ориентиром.
Предложение 5: Используйте современные инструменты
Качественный обзор, дающий быстрый ответ, зависит от современных инструментов. Современные инструменты проверки могут автоматически интегрироваться в рабочие процессы, выделять изменения и автоматически суммировать изменения. Уже доступно множество современных инструментов, и читатели, которые еще не выбрали инструменты, могут искать их самостоятельно.
Предложение 6: парное программирование
Когда дело доходит до «небольших пакетов, нескольких пакетов и быстрой обратной связи», если у вас есть опыт парного программирования, вы сразу поймете, что парное программирование очень похоже на CR.
Парное программирование означает, что два человека, которые совместно программируют, имеют один и тот же контекст, поэтому нет проблем с переключением контекста, нет проблем с нехваткой времени и нет необходимости использовать дополнительные инструменты для обеспечения обратной связи друг с другом в любое время и в любом месте. На мой взгляд, парное программирование — лучший CR.
Предложение 7: онлайн-обзор и автономный обзор
Онлайн-обзоры должны быть нормальным поведением. Когда дело доходит до ценности CR для «распространения знаний», офлайн-обзоры являются полезным дополнением. Опытные команды периодически или нерегулярно организуют автономные обзоры, чтобы они могли получить более широкий спектр распространения знаний, чем онлайн-рецензии. Это также может привести к бурным дискуссиям и спорам, формируя консенсус более высокого качества.
Цифровые метрики
Полная оцифровка научно-исследовательских работ позволила получить некоторые ценные данные. Деятельность в области устойчивого развития можно постоянно продвигать посредством наблюдения за метриками, если инструменты могут это поддерживать. Мы суммировали следующие предлагаемые показатели и данные:
С точки зрения авторов кода:
- Количество строк кода за отзыв (основной показатель)
- Частота обзора (ссылка)
С точки зрения рецензента:
- Время отклика
- Количество комментариев и процент отказов
С точки зрения группы рецензентов вы также можете найти отношения сообщества между автором кода и рецензентом, что также является ценной информацией для понимания распространения знаний.
Мы рекомендуем следовать приведенным ниже инструкциям:
Избегайте использования цифровых показателей CR для оценки, даже если мотивация хорошая. Суть CR – культурное строительство. Мы настоятельно рекомендуем использовать метрики CR только в качестве рекомендаций по улучшению, а не для оценок, связанных с производительностью, независимо от того, являются ли метрики CR вышеупомянутыми или данными, относящимися к качеству проверки или дефектам, обнаруженным в проверках.
Лучшие практики
Каково качество кода вашей организации? Как насчет технической атмосферы вашей организации? Вы внедряете CR?
- Если вы еще не внедрили CR, планируете ли вы попробовать?
- Если она уже реализована, достигает ли существующая практика истинной цели КО?
Я надеюсь, что практические советы, которыми я поделился в этой статье, будут полезны. Если у вас есть предложения по CR, поделитесь ими с нами.
