2_Цели, задачи, этапы и объекты ревьюирования. Планирование ревь. Цели, задачи, этапы и объекты ревьюирования. Планирование ревьюирования. Определение и цель ревьюирования

• Название: Цели, задачи, этапы и объекты ревьюирования. Планирование ревьюирования. Определение и цель ревьюирования
• Дата: 05.09.2022
• Размер: 22.33 Kb.
• Имя файла: 2_Цели, задачи, этапы и объекты ревьюирования. Планирование ревь.docx
• Тип: Документы; #663451

Цели, задачи, этапы и объекты ревьюирования.

Планирование ревьюирования.

1.Определение и цель ревьюирования

В энциклопедии мы можем встретить следующее определение: «Рецензия (англ. review— обзор) — анализ, разбор, некоторая оценка публикации, произведения или продукта, жанр газетножурнальной публицистики и литературной критики. Рецензия может относиться к материальным вещам (приборы, аксессуары, бытовая техника), компьютерным технологиям, художественной литературе, музыке, фильмам, компьютерным играм.

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

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

Code Review (данный термин переводят как ревьюирование, рецензирование, обзор, инспектирование кода) — один из стандартных методов программной инженерии, направленный на проверку кода, его анализ и составление рецензии о проверенном коде, основной целью которого является повышение качества программного кода.

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

2. Методы ревьюирования кода

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

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

При ревьюировании оцениваются различные аспекты разработанного кода, в частности:

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

Могут подвергаться оценке и другие аспекты работы.
Рассмотрим Методы проведения ревьюирования:
Самостоятельное ревьюирование работы. Разработчик самостоятельно проверяет свой код.

Достоинство: экономия времени, так как для проверки кода не привлекаются другие сотрудники.

Недостатки:

• 
  нет экспертной оценки кода;
  
• 
  разработчик может не заметить ошибки или возможности для лучшего проектирования.
  

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

Достоинства:

• 
  метод оценки более объективен в отличие от ревьюироания автором работы;
  
• 
  могут быть даны советы стороннего разработчика по доработке кода и исправлению ошибок;
  

• 
  не требует большого количества времени и дополнительных формальных процедур.
  

Недостатки:

• 
  проверяющий поверхностно знаком с кодом, следовательно,
  

проверка может быть неэффективной;

• 
  для проверки один из разработчиков отвлекается от своей основной работы.
  

2. Разработчик отдает код на проверку. Код изучается сторонним программистом без присутствия автора.

Достоинства:

• 
  простота;
  
• 
  рецензент может проверить код в любое удобное для него время.
  

Недостатки:

• 
  могут потребоваться дополнительные комментарии к коду автора, которые не всегда просто получить;
  
• 
  длительность процесса больше, чем при использовании варианта проверки, описанного в подразд. 2.1.
  

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

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

Достоинство: осуществление контроля и исправление ошибок на этапе разработки.

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

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

Достоинства:

• 
  привлечение группы программистов, каждый член которой выражает свой взгляд на сделанную работу;
  
• 
  обмен опытом:
  
• 
  глубокий анализ кода.
  

Недостатки:

• 
  трудоемкая процедура, требующая времени;
  
• 
  отвлечение сотрудников от основной работы;
  
• 
  психологически сложный процесс для автора кода .
  

Рассмотрим подробнее процедуру ревьюирования.
1.2.3. Этапы и планирование ревьюирования

Процедура ревьюирования содержит слелдующие этапы:

1) автор сообщает, что код готов к ревьюрованию;

2) определяется группа разработчиков для ревьюирования кода.

Среди членов группы должны присутствовать:

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

3) определяются дата и время работы группы для совместного ревьюирования, о чем оповещаются все члены группы;

4) решается вопрос, в какой форме будет происходить ревьюирование. Например, совещание с присутствием всех участников либо онлайн-совещание с использованием программы Skype или иного ПО;

5) определяется повестка совещания;

6) подлготавливаются необходимые ресурсы (компьютер, проектор, ПО, распечатки и т.д.);

7) автор кода предоставляет его заранее всем членам группы.После этого внесение изменений в код нежелательно. (Разработчик компании Eiffel Software отмечает, что код желательно предоставлять за неделю до общего собрания);

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

В результате ревьюирования могут быть приняты следующие решения:

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

Помимо основной цели ревьюирование позволяет решить следующие задачи:

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