Каждый разработчик знает боль от банальных ошибок. Здесь неправильный атрибут, неправильное свойство, случайно дублированная строка кода, которую вы пропустили из-за заправленного кофе 16-часового хакатона, на котором вы были. Даже простой $ перед открывающим тегом PHP, который вы случайно поместили туда, потому что вы начали печатать до того, как адская среда IDE нагрелась и переместил курсор, может заставить вас часами чесать голову, если вы устали и отвлечены , Если бы только у вас была свежая пара глаз, чтобы посмотреть на то, что вы сделали — наверняка этих ошибок можно легко избежать?
Википедия определяет обзор кода следующим образом:
Проверка кода — это систематическая проверка (часто называемая экспертной проверкой) компьютерного исходного кода. Он предназначен для поиска и исправления ошибок, пропущенных на начальном этапе разработки, улучшая как общее качество программного обеспечения, так и навыки разработчиков. Обзоры выполняются в различных формах, таких как парное программирование, неофициальные прохождения и формальные проверки.
Это определение является настолько точным, насколько это возможно — в еще более непрофессионале, проверка кода — это просто действие, когда кто-то еще просматривает ваш код, чтобы найти ошибки, которые вы пропустили.
Типы проверки кода
Как намекает определение из Википедии, существует много разных способов проверки кода на наличие дефектов. Вот краткий обзор некоторых из них:
- OTS (Over the Shoulder) Review — это то, как небольшие команды обычно обрабатывают обзоры кода. Разработчик напишет приличный объем кода и пригласит другого разработчика взглянуть на него. Другой разработчик сидит там, в то время как первый объясняет, что он сделал, построчно. Посредством этого повествования первоначальный разработчик замечает некоторые свои ошибки и исправляет их, а разработчик OTS замечает другие, указывая на них первым. Они также делятся мнениями о решениях определенных проблем, которые первоначальный разработчик иногда переделывает после завершения процесса проверки, требуя повторной проверки. Это также легко сделать с помощью программного обеспечения для разделения экрана и голосового чата, если разработчики находятся на расстоянии.
- Проверка с помощью инструментов — существуют различные инструменты как онлайн, так и офлайн, чтобы помочь с проверкой кода. Хотя подробное рассмотрение различных предлагаемых инструментов выходит за рамки этой статьи, мы можем обобщить и сказать, что есть платные версии ( Atlassian Crucible , CodeCollaborator ), бесплатные версии ( Review Board ) или, если вы являетесь индивидуальным разработчиком, версия сообщества ( Stack Exchange Code Review ). Независимо от используемого инструмента каждый из них выполняет практически одну и ту же цель — он извлекает самые последние изменения в исходном коде и помечает их как требующие проверки. Одноранговый узел — это означает, что разработчик обладает такими же или более высокими навыками, — затем просматривает код, отмечает его как проверенный или отмечает все обнаруженные ошибки и вносит предложения, а также завершает или повторно инициирует процесс, отправляя его обратно исходному разработчику. Также важно отметить, что многие популярные IDE имеют плагины для проверки кода.
- Парное программирование — очень динамичный тип анализа кода, парное программирование — это «игра» для двух разработчиков, в которой один разработчик кодирует, а другой следит за его прогрессом, сидя рядом с ним. После нескольких сотен строк кода или после того, как они достигли заранее определенного этапа, они делают небольшой перерыв и меняются местами. Тот, кто кодировал сейчас, наблюдает, а тот, кто раньше наблюдал, теперь кодирует. Это чрезвычайно эффективно для предотвращения ошибок и улучшения общего качества кода, но стоит вдвое больше рабочей силы. Многие компании не готовы к такому риску и, к сожалению, не могут мыслить иначе, как «два человека на двух машинах выполняют больше работы, чем два человека на одной машине». Именно такой тип обзора дает наилучшие результаты: не только ошибки устраняются, но и два разработчика напрямую сотрудничают и обмениваются идеями по решению проблем, с которыми они сталкиваются по мере их продвижения. Также ничего не стоит, что этот тип обзора невероятно трудно реализовать в командах, которые к этому не привыкли — он в основном работает на более молодых командах.
Кроме того, существует также формальный тип обзора, впервые введенный и исследованный Майклом Фаганом в 1970-х годах (этот метод также известен как Fagan Inspection), который в настоящее время несколько архаичен и не пользуется популярностью в отрасли. Формальная проверка редко используется в небольших командах и в основном относится к продуктам стоимостью в несколько миллионов долларов, поскольку она очень напряженная и дорогая. В него входят несколько человек (до шести), которые сидят с проектором и вместе просматривают код. Каждому участнику назначается роль (например, «Читатель», «Модератор» или «Рецензент»), и когда команда замечает какие-либо ошибки или дефекты, все подробно описывается — от серьезности до фактической строки кода, причины и эффект, даже прогнозируемая стоимость этой ошибки достигает клиентов. Это, безусловно, самый профессиональный вид анализа кода, но также и самый обескураживающий для разработчиков, и поэтому он не получил широкого распространения. Исследования показали, что другие методы проверки кода также эффективны при правильном использовании, без необходимости связывать столько людей так долго.
Лучшие практики для проверки кода
Как только будет решено внедрить проверку кода, вероятно, придется преодолеть некоторые препятствия. Руководство может не видеть оправдания для дополнительных проверок времени, или некоторые программисты могут подумать, что проверка — это личная атака на код, над которым они работали. Вот несколько советов, которые вы хорошо сделаете, чтобы иметь в виду, когда будет реализован обзор кода.
- Знайте свои распространенные ошибки и активно сражайтесь с ними. При работе каждый разработчик имеет ошибки, которые он обычно делает независимо от того, насколько глубоко он «в зоне». У каждого из нас есть этот маленький глюк, который просто глуп и замечен другими. Обратите внимание на эти ошибки. Забыл отфильтровать ввод … снова? Забыл прокомментировать метод … снова? Имея такой список, разработчик может активно выследить эти ошибки, прежде чем запрашивать рецензию. Это называется эффектом эго — вы знаете, что ваш код собирается быть пересмотренным, и вы не хотите, чтобы рецензент говорил: «О, чувак, ты забыл снова фильтровать ввод!». Ты хочешь быть рок-звездой, ниндзя, человек, который заставляет других говорить «Вау, это действительно отличное решение». Эго-эффект — это то, что заставит вас улучшить свой код, прежде чем другие смогут даже взглянуть на него.
- Рецензирование кода на сверстников означает, что его проверяет кто-то с равным или большим уровнем квалификации Как следует из здравого смысла, проверка кода не может работать, когда младший просматривает код старшего. Младший может заметить некоторые обычные несоответствия, нарушения стандарта, опечатки или даже ошибки, такие как фильтрация ввода, но обычно он не может определить более серьезную проблему. Это часто требует определения иерархии по навыкам в команде, если она еще не присутствует.
- Меньше кода с четкими этапами означает лучшие отзывы. Кодекс следует пересматривать только после того, как будет достигнут личный этап, и эти этапы должны быть небольшими и происходить часто. В объектно-ориентированном программировании это особенно важно, но также и особенно выполнимо. Закончили новый компонент, который расширяет интерфейс, который связан с адаптером, который уже был рассмотрен? Наконец-то исправлена проблема с конкретным методом, который не давал покоя отделу в течение недели? Большой! Компонент за компонентом, и поддержание его не более 700-800 строк кода за раз (включая комментарии) — это то, что обеспечивает абсолютный наиболее эффективный процесс проверки. Сделайте код, который вам нужен, кратким, кратким и независимым, и сделайте обзор как можно скорее после завершения, пока идеи еще свежи в вашем уме. Просто помните — время дорого, так что не забирайте его слишком много! Часа должно быть более чем достаточно, чтобы выполнить этот «обзор раздела».
- Соберите метрики. Это проще, если вы используете более структурированный тип проверки кода, такой как вспомогательный или формальный инструмент, но это можно сделать и в OTS. Постарайтесь отметить количество и типы ошибок и ошибок, которые вы обнаружите в заданном количестве строк кода и единиц времени. Объедините эти данные между разработчиками и с легкостью узнайте, кто нуждается в наибольшей помощи, кто нарушает большинство стандартов и сколько денег вы фактически сэкономили своей компании, выполнив анализ кода. Вскоре вы сможете реально оценить полезность анализа кода, и только тогда все в компании будут заинтригованы этим. Обычно это самая сложная часть обзора, которую нужно реализовать, поскольку немногие разработчики имеют терпение к ручной статистике, но она может быть полезной в случае ее принятия.
- Помните о социальном аспекте — поиск ошибок — это хорошо, а не плохо! Необходимо помнить, что поиск ошибок — это хорошо, а не плохо. Никогда не позорьте и не выделяйте разработчика, который допустил ошибку, сделайте это неформальным. Пусть люди адаптируются к проверке кода — помогите своим коллегам принять это, не бойтесь этого. Code Review может быть не только полезным, но и веселым. Помните, что больше времени и более сложные задачи равны большему количеству ошибок — количество ошибок не указывает на умение разработчика! Если вы менеджер или руководитель группы, убедитесь, что никто не считает пересмотр кода отрицательным или пустой тратой времени. Убедитесь, что они не считают это правилом, предписанным компанией, а улучшением их повседневного рабочего процесса, который они должны соблюдать независимо от компании, в которой они работают. По возможности, стремитесь к персональному подходу к анализу кода. Если вы используете инструменты, используйте их и в OTS. Персональный подход к обоюдному мозговому штурму и неформальному обсуждению потенциальных решений проблем неоценим в процессе принятия рецензирования кода в качестве вашего друга.
В заключение
Анализ кода может быть невероятно трудным для реализации, особенно в команде старожилов, которые к этому не привыкли. Но как только это будет сделано, это не только уменьшит количество дефектов в вашем коде, но также увеличит сотрудничество и поможет создать команду, улучшит «братство» среди разработчиков и будет распространять лучшие практики и повышение квалификации всей команды или отдела. Любой тип проверки кода лучше, чем никакой, поэтому, если ваша команда не использует его сегодня, предложите его. Это может только помочь. Если вы являетесь индивидуальным разработчиком, найдите единомышленника, с которым вы можете просматривать код — выходите в интернет, общайтесь, расширяйте свои круги разработки, объединяйтесь. Не смотрите на других разработчиков как на соперников, а на проверку кода как на своего врага, смотрите на других, как на братьев по оружию, а просмотр кода — это ваше оружие на передовой к совершенству.
Изображение через Fotolia