Заметки консультанта

Шамрай Александр Владимирович

Archive for the ‘Рецензирование’ Category

Лучшие секреты рецензирования кода. Социальные эффекты коллегиальной оценки

Posted by Шамрай Александр на Июль 12, 2013

Неожиданные позитивные социальные аспекты; Управление негативным влиянием и «Эффект большого брата».

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

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

«Эффект Эго»

Первый эффект имеет место даже до того, как произойдет первое рецензирование кода. Оно привнесет и положительные, и негативные эмоции в рецензирование кода; рассмотрим хорошие.

«Джерри всегда забывает проверить на исключение NULL-указателя». Никто не хочет быть известным парнем, который всегда поступает глупо, делает ошибки на уровне молодого разработчика. Так что представьте себя перед компилятором, с поставленной задачей исправить небольшую ошибку, но понимая, что как только вы говорите «Я закончил», ваши коллеги – или еще хуже ваш босс – будут критически рассматривать ваши результаты.

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

Другими словами, вы немедленно станете разработчиком лучше. Вы будете делать работу отлично, потому что вы хотите получить идеальную оценку на рецензировании. «Ого», ваш босс напишет в заметках о встрече, «я никогда не рецензировал код, который был бы настолько продуманным! Я могу только одно сказать! Отлично!»

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

Хорошей характеристикой эффекта эго является то, что он работает одинаково хорошо в случаях, когда рецензии обязательны для всех изменений кода или просто используются как «точечные проверки». Если у вас есть шанс 1 из 3 быть вызванным на рецензирование, это уже достаточный стимул, чтобы убедиться, что вы делаете работу хорошо. Однако, существует переломный момент. Например, если шансы рецензирования только 1 из 10, вы может быть неаккуратным, потому что теперь у вас есть повод. «Да, я обычно помню, что это нужно делать. А то что вы только что поймали меня, ну это просто день не сложился.»

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

Старые привычки легко умирают

Это был наш второй обзор кода в SmartBear Software с использованием альфа-версии нашего нового инструмента рецензирования кода. Я просматривал небольшое изменение, которое сделал Брэндон в Java-код. Он добавил следующую строку кода:

if («integrate».equals (str)) {…}

Я остановился здесь на мгновение. Он сравнивал равна ли строка str константной строке integrate. Но я написал бы это по-другому – перевернув integrate и str. Я понял, что оба метода работают, но возможно была причина, по которой он выбрал именно этот?

Я написал ему быстро сообщение. Он объяснил, что если str имеет значение null, его выражение вернет false в то время как мой вариант получил бы исключение указателя на null. Поэтому он взял в привычку использование константных строк в левой части выражения equals(), как в этом примере.

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

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

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

Во-вторых, я был оппонентом, но я был единственным, кто научился чему-то. Обычно вы думаете, что процесс рецензирования однонаправленный – проверяющий указывает проблемы автора, и автор может узнать что-то в этом процессе. Но здесь я был оппонентом и все же я был тем, кто учится!

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

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

Систематический личный рост

Он получается даже лучше.

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

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

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

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

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

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

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

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

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

Задетое самолюбие & Эффект «Большого брата»

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

Во-первых: Задетое самолюбие.

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

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

Второе: Эффект «Большого брата».

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

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

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

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

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

Эти пункты являются методами, которые объясняют, что (a) дефекты являются позитивом, а не негативом и (b) плотность дефектов не коррелирует с способностями разработчиков и что поэтому (c) дефектов не стоит избегать и они никогда не будут использоваться для оценки работы.

1. Сложный код имеет больше дефектов

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

Можно посмотреть на это с другой стороны: если бы вы знали, что фрагмент кода был сложным, и рецензент сказал, он не нашел недостатков в нем, вы не заподозрили бы, что рецензент не был прилежным? Если я представил это эссе редактору, даже после нескольких самостоятельных проверок, и редактор не представил замечаний, я должен подозревать, что редактор не прочитал текст?

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

2. Больше времени вызывает больше дефектов

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

Группа в различных вариантах пыталась определить необходимое количество времени на страницу кода, тестируя разницу в длительности 5, 15, 30 или даже 60 минут на страницу. Большинство результатов показали увеличение плотности дефектов вплоть до 30 минут на страницу, некоторые даже видели увеличение при 60 минутах на страницу. После определенного момента количество дефектов будет останавливаться в некоторой точке, в которой вы действительно учли все о чем вы могли подумать и дальнейшее время, затраченное на код, не обеспечит дополнительных дефектов. Но 60 или даже 30 минут на страницу гораздо больше времени, чем могло бы предположить большинство людей.

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

3. Это все о коде

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

В 1986 году космический шаттл Челленджер взорвался на 110,3 секунде после взлета, погибли все семь членов экипажа. Последующее президентское расследование пыталось ответить на два вопроса: что вызвало взрыв и почему мы этому не помешали?

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

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

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

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

Поэтому инженеры были виноваты в искажении данных? Нет, потому что данные были составлены правильно. Никто не думал упорядочивать их так, чтобы они показали тенденцию. Ни один из них не был обучен методам визуализации и презентации данных.

Основной вывод такой: даже с большим количеством очень умных и опытных людей, будут допускаться ошибки. НАСА решили эту проблему девятью шагами, большинство из которых различные формы рецензирования. Идея рецензирования программного кода является той же – устранить как можно больше дефектов, независимо от того, кто «является причиной» ошибки, независимо от того, кто нашел ее. Это не личное отношение.

Действительно как менеджер, вы знаете, что если «количество дефектов» было использовано для оценки качества работы, у разработчиков будет стимул не находить дефекты, даже когда они знают, что они там. Что является противоположностью цели процесса рецензирования, так что вы знаете, что дефекты должны быть обязательно не фактором для любой персоны – или персонала –, а отчетом.

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

4. Чем больше дефектов тем лучше

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

Этот вывод является по сути правильным! Подумайте об этом так: каждый дефект найденный и исправленный в коллегиальной оценке – это ошибка, которую клиент никогда не увидит. Еще одна проблема, QA не тратит времени на поиск и отслеживание. Еще один кусок кода, который не добавляет постепенно сложности в поддержки программного обеспечения. Разработчики и менеджеры могут спать немного спокойнее по ночам каждый раз, когда будет обнаружен новый дефект.

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

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

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

Posted in Рецензирование, Стандарты и методологии | Отмечено: , | Leave a Comment »

Лучшие секреты рецензирования кода. Новые исследования

Posted by Шамрай Александр на Июнь 24, 2013

Какая современная литература может рассказать о Рецензировании кода; c какими исследованиями мы согласны, а с какими нет.

Поиск в Amazon книг по фразе «рецензирование кода» покажет только один книгу: 29-страничная статья Майкла Фаган из IBM 1974 года. В том году IBM продал модель диска 3330-11 за $111,600. Мегабайт ОЗУ мог обойтись вам в $75000. До сих пор наиболее продаваемым миникомпьютером является PDP-11.

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

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

Инспекции кода для сборок в OS/360 не имеет ничего общего с тем, как сказываются последствия изменений кода в объектно-ориентированных интерпретируемых языках 3-го уровня. Сбор встречи по инспекции с 5 участниками не работает при распределенной разработке и гибких методологиях.

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

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

Вотта 1993, Конради 2003, Келли 2003: Встречи по рецензированию необходимы?

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

Во-первых, самый известный выпад на такое мнение, традиционно связанное с совещаниями, сделал Лоуренс Вотта из AT&T Bell Labs в 1993 году. Он выделил пять причин наиболее цитируемых менеджерами и разработчиками программного обеспечения в поддержку встреч по инспекциям:

  1. Синергия. Команда найдет недостатки, которые отдельных рецензент может не найти.
  2. Образование. Менее опытные разработчики и рецензенты учатся у своих более опытных коллег.
  3. Срок. Встречи создают график, в котором люди должны работать.
  4. Конкуренция. Эго приводит к личному стимулированию содействия и улучшения.
  5. Процесс. Инспекции просто требуют встреч. Это формальный процесс.

Однако в его оригинальных документах в 1993 на основе его собственных исследований, а также исследованиях других Вотта утверждал, что:

  1. Синергия. Встречи, как правило, выявляют ложные дефекты вместо новых дефектов. (Подробнее ниже).
  2. Образование. Образование путем наблюдения обычно недостаточно; Некоторые исследователи его сильно осуждают.
  3. Сроки. Процесс установки сроков является важным, но может быть обеспечен без встреч сам собой или, по крайней мере, без тяжеловесных встреч.
  4. Конкуренция. Конкуренция по-прежнему достигается при любой коллегиальной оценке. Некоторая конкуренция разрушительно влияет на совместную работу, например, между проектировщиками и тестировщиками.
  5. Процесс. Процесс имеет важное значение, но факты, а не «традиция», должны использоваться для определения процесса.

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

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

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

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

Как выяснилось совещания способствовали лишь 4% от всех дефектов, найденных в ходе инспекций в целом. Статистически больше нуля, но Вотта задался вопросом «стоит ли цена времени потраченного на собрание по сбору Tсбора [напрасно потраченное время] и дополнительное время рецензента этому 4% увеличению проблем, найденных на этой встрече (по любой причине)? Ответ на этот вопрос Нет».

Сильные слова! Но существуют ли другие преимущества для совещаний инспекции помимо просто выявления дефектов?

В 2003 году Дайан Келли и Терри Шепард Королевского Военного Колледжа Канады выполнили эксперимент, сравнили рецензентов в изоляции и на групповом совещании. Результаты поддерживают или противоречат результатам Вотта? И помимо количества дефектов, там будет небольшая разница в других важных факторах, таких как скорость, с которой дефекты были обнаружены или уменьшение ложных дефектов, на которые тратили свое время авторы?

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

В общей сложности 147 дефектов было обнаружено во время фазы чтения. Из них 39 (26%) были удалены во время встречи. Хотя некоторые из них были как ложные (т.е. рецензент неправильно определил дефектом), в большинстве случаев плохая документация или стиль кода привели оппонента к мнению, что существует проблема. Келли выразил мнение о том, что эти «дефекты» следует вероятно рассматривать после всех остальных.

Таким образом совещания по фильтрации ложных дефектов довольно полезная вещь, но что по поводу выявления новых дефектов? Вотта предположил бы, что будет найдено очень мало новых дефектов. У Келли этап совещания добавил к уже существующим 147 только 20 новых дефектов. Кроме того, из этих 20 две трети были относительно тривиального характера. Поэтому этап совещания не только не способствует значительному росту общего количества дефектов, этот вклад в целом имеет поверхностный уровень, а не на уровне логики или алгоритмов.

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

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

Келли установил, что на чтение было потрачено около две трети от общего объема человеко-часов и одну треть на совещание. Это приводит к скорость обнаружения дефекта 1,7 дефектов в час для чтения и 1,2 для совещания. Чтение на 50% более эффективно в поиске дефектов, чем встречи.

Еще один прямой тест исследований Вотта совместных усилий под другим углом прошел в 2003 году и был проведен Рейдаром Конради между Ericsson в Норвегии и двумя норвежскими колледжами, NTNU и Университетом Агдер. Целью экспериментов было измерение воздействия некоторых методов чтения для проверки модели UML. Вотта экспериментировал с рецензированием проектирования, Келли с исходным кодом, и теперь Конради изучит рецензирование архитектуры.

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

В частности, в 38 контролируемых инспекциями сценариях они обнаружили, что 25% времени было потрачено на чтение, 75% времени на совещания, и тем не менее 80% дефектов были обнаружены во время чтения! Они были в 12 раз более эффективным в поиске дефектов с использованием чтения чем на совещании. Кроме того, в их случае они приглашали 5-7 человек на каждое совещание, что немного больше, чем Келли или Вотта, или даже Фаган рекомендует, поэтому количество обнаруженных дефектов в соответствии с трудозатратами было очень малым.

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

Блакели 1991: Hewlett Packard

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

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

Это предварительное исследование включало один проект с 30 часами разработки и 20 часами рецензирования – 13 часов на предварительной встрече контроля и 7 часов на совещании. Они ограничили свои инспекционные размеры 200 строками кода в час согласно инструкциям. Был найден 21 дефект, обеспечивая проекту скорость дефектообразования 0.7 в час и плотность дефектов 100 на тысячу строк кода.

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

Поскольку они знали, что эта проблема была важна с самого начала, они собирали достаточно информации относительно каждого дефекта, чтобы определить возможно ли, чтоб каждый из них был обнаружен, улучшив процесс тестирования/QA. В частности, для каждого дефекта они отвечали на вопрос: «Есть ли какой-либо тест, который бы выполнил тестировщик и нашел бы этот дефект?» Возможно, было бы более эффективно выстроить процесс тестирования вместо того, чтобы смотреть код.

Результат был следующий: Только 4 из 21 дефекта могли быть однозначно обнаружены во время фазы тестирования/QA. Они также увидели, что потребовалось бы больше общих рабочих часов, чтобы найти и исправить те 4 дефекта в QA чем потрачено на инспекцию.

Дансморе 2000: Объектно-ориентированные инспекции

Какие методы инспектирования должны использоваться при рассмотрении объектно-ориентированного кода? Объектно-ориентированный код (ОО) имеет различные структурные и исполнительные шаблоны в отличии от процедурного кода; подразумевает ли также это изменение методов рецензирования кода и как, если да?

Алистер Дансморе, Марк Ропер и Мюррей Вуд попробовали ответить на этот вопрос в серии экспериментов.

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

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

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

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

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

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

Сравнение результатов трех типов рецензирования. Уровень дефектов в час.

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

Результаты показаны на рисунке ниже.

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

Уровень дефектов является постоянным до 60 минуты инспекции, далее он выравнивается на уровень без дефектов, которые не обнаруживались уже вообще после 90 минут.

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

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

Увано 2006: Анализ движения глаз в процессе рецензирования

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

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

Исследователи использовали систему по плану, отображаемому в короткой программе на языке C на экране, пока сканер глаз записывал все «фиксации» – время, когда глаз оставался в радиусе 30 пикселей более чем на 1/20 секунды. Кроме того, т.к. они контролировали отображение исходного кода, фиксации были сопоставлены с номерами строк. Результатом является участки, в которых строка кода просматривались с течением времени.

Были использованы шесть различных фрагментов кода C, каждый от 12 до 23 линий, каждый как целая функция или небольшой набор функций для просмотра без прокрутки. Пять предположений были применены для каждого фрагмента, выполняя 27 испытаний (от трех из 30 пришлось отказаться, потому что субъект отвлекался во время опыта).

Общий шаблон – это рецензент, который читает линии сверху вниз в «ухабистом склоне». Это, как правило сквозное, но с короткими, краткими «обратными дорожками» по пути. Они назвали это «первичным сканированием». Обычно 80% из линий только «касаемы» в ходе этого первого сканирования. Затем рецензент концентрируется на определенной части кода – 4 или 5 линий – предположительно где рецензент считает, что может быть проблема.

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

Дальнейшая инспекция движения глаз показывает интересные идеи о том, как кто-то читает исходный код для понимания. К примеру, глаза отдыхают на объявлениях инициализации переменных на протяжении сессии. Мозг требует постоянного обновления о том, что означают эти переменные. Даже тогда, когда есть только две или три локальные переменные, все целые числа, которые не представляет ничего специального или трудно для запоминания, шаблон остается таким же. Исследователи назвали это движение глаз «проследить объявление». Это для кода означает, что объявления локальных переменных также должны быть видимы на том же экране что и код, который использует их. В противном случае читатель вынужден будет прокручивать туда и обратно. Распространенным способом обеспечения этого является ограничение количества строк кода в функции. Мы все слышали аргументы для ограничения длины функции для общего чтения; Вот доказательства, которые являются фундаментом этих аргументов.

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

Но вернемся к рецензированию. Исследователи первоначально искали ответ на вопрос: есть ли что-нибудь в движениях глаз, что может быть отнесено к эффективности рецензирования? Ответ оказался Да.

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

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

Этот результат имеет несколько последствий. Во-первых, замедлить! Как мы говорили в разделе как вывод – чем дольше вы уделяете обзору, тем больше дефектов вы найдете. Поспешность добавляет затраты.

Во-вторых, первичное сканирование является полезным методом при проверке кода. Этот эксперимент показывает, что достаточно тщательное «первичное сканирование» фактически увеличивает уровень обнаружения дефекта.

Лайтенбергер 1999: Факторы, влияющие на количество дефектов

При каких обстоятельствах мы ожидали бы найти больше или меньше дефектов в ходе рецензирования? Размер кода является вопросом инспекции? Как насчет количества времени рецензирования потраченного, глядя на код? Что насчет языка исходного кода или типа программы? Все эти вещи являются «факторами», но мы можем установить что-то более влиятельное, чем эти? Возможно некоторые вещи значат больше, чем другие. В 1999 году трое исследователей провели анализ 300 рецензий от Lucent в Центре Реализации Продуктов для Оптических Сетей (PRC-ON) в Нюрнберге, Германия. Эта группа тратит 15% от их общей разработки на рецензии, но используют ли они свое время мудро? Они обнаруживают настолько много дефектов в час насколько возможно? Если нет, что конкретно они должны делать, чтобы максимизировать уровень обнаружения дефекта? Это были вопросы Лайтенбергера.

Рассмотрение других исследований предложило два наиболее вероятных фактора в количестве дефектов, обнаруженных во время рецензирования: (a) время, затраченное на подготовку и (b) размер кода для инспекции. Так они пришли к причинно-следственной модели – то есть, теоретическая модель, в которой, как они ожидали, эти два фактора могут повлиять на количество дефектов.

Эта модель показана на рисунке ниже. Но создание схемы не доказывает ничего!

Как мы можем проверить является ли эта модель точной и как можно измерить насколько важны каждые из этих причинных связей?

Рисунок 8: Причинно-следственная модель для двух крупнейших факторов, которые определяют количество дефектов, обнаруженных во время рецензирования.

Стрелки указывают причинно-следственные связи. «Е» значения представляют собой внешние факторы, которые не учитываются в модели.

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

Результаты Пути Анализа Лайтенбергера для рецензирования кода. Цифры представляют процент от общего влияния.

Результаты одинаковы для проведения рецензирования проектирования и спецификаций.

Результаты показаны на рисунке выше. Следует отметить две важные вещи.

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

Во-вторых, «внешние факторы» гораздо более важны, чем любой из названных. Размер кода только показывает лишь 8% колебаний в количестве найденных дефектов; время чтения показывает 35%, но большая часть вариации поступает из других источников. Рецензирование нового кода, отличается от поддерживаемого кода. Сложные алгоритмы отличаются от связей сложных объектов, которые отличаются от простого процедурного кода. Языки отличаются. Уровень опыта автора и рецензента имеет значение. Эти внешние эффекты составляют наиболее важные факторы того сколько дефектов вы можете ожидать при проведении рецензии.

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

Во-вторых, вы не можете усреднить все ваши показатели и сказать «мы должны найти X дефектов на 1000 строк кода». Каждый проект, язык, модуль, даже классы могут быть разными. Это может нарушить ваши метрики на этих уровнях при попытке найти некоторые реальные модели.

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

Заключение

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

Рецензирование максимум один час.

Хотя не каждое исследование рассматривало этот вопрос, общий результат говорит, что эффективность рецензентов по поиску дефектов падает резко после 1 часа. Это справедливо независимо от того, сколько материалов пересматривается одновременно. Некоторые исследования тестировали специально для того, чтобы увидеть насколько много дефектов обнаруживается после 15, 30, 45, 60, 75, 90 и 120 минут на задаче. Во всех случаях существует примерно линейное увеличение количества дефектов, найденных до одного часа, затем значительное выравнивания после этого. Этот результат был отражен и в других исследованиях, которые мы рассматривали.

Точка останова, в которой дальнейшее рецензирование не приносит пользы

Существует по крайней мере два объяснения этого эффекта. Во-первых, каждый рецензент способен найти определенный набор дефектов. Независимо от того, как долго вы таращитесь на код, есть некоторые проблемы, которые вы просто не знаете как найти. Что особенно справедливо, если рецензирование управляется контрольным списком – рецензент часто фокусируется на контрольном списке и все значительное вне этого списка не находится в области его действий.

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

Чтобы обнаружить больше дефектов, нужно замедлить чтение кода.

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

Что также справедливо, будет или не будет ваш приватный код читаться впоследствии на совещании инспекции.

Встречи для инспекций не обязательно должны быть очными.

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

За последние пятнадцать лет этот эффект был проверен во многих исследованиях и со многих углов зрения. Несколько выводов по этому вопросу показаны во всех исследованиях данного обзора и во многих других.

Во-первых, подавляющее количество дефектов находится на этапе предварительного частного «чтения». К тому времени, когда совещание начинается, все сомнительные аспекты кода уже определены. Это имеет смысл: было бы трудно определить был ли правильно реализован сложный алгоритм с использованием обсуждения, а не сосредоточенными усилиями.

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

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

Показатели количества дефектов на строку кода ненадежны.

Это мечта предсказателя. Сколько дефектов скрываются в этих 5000 строк кода? Нет проблем, просто взять наше стандартное количество дефектов на количество строк во время обзора и умножить. 12 дефектов на количество строк кода? Ожидаете, что найдете 60 дефектов. Если вы пока нашли только 30, смотрите дальше.

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

Упущения усложняют поиск дефектов.

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

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

Например, в нашем собственном опыте утилита контрольного списка имеет пункт «убедитесь, что все ошибки обрабатываются», что имеет ограниченную пользу – это очевидная вещь для проверки всего кода. Но мы забыли передать номер сборки, прежде чем сеанс QA прошел уже на 30%. После установки контрольного списка выпуска мы больше не забывали об этом.

Исследования слишком малы.

Несчастным общим элементом этих исследований является то, что они почти все слишком малыми, чтобы иметь статистическую значимость. Сложно найти более чем 100 рецензий или 100 дефектов в любом из них. Большинство из них говорят «В наших 21 рецензиях, мы обнаружили, что…» двадцать одна рецензия не является статистически значимой, независимо от того, какие данные вы собираете!

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

Различия между каждыми исследованиями.

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

Так что теперь перейдем от небольших экспериментов к крупным когда-либо опубликованной отраслевым исследованиям легкой коллегиальной оценки.

Posted in Рецензирование, Стандарты и методологии | Отмечено: , | Leave a Comment »

Лучшие секреты рецензирования кода. Пять типов рецензирования

Posted by Шамрай Александр на Июнь 13, 2013

За и против формальных проверок, через-плечо, через-почту, парного программирования и инструментального рецензирования.

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

Формальные инспекции

Исторически «формальные» рецензии обычно вызывают «инспекциями». Это пережиток исследования Майкла Фагана 1976 года в IBM относительно эффективности коллегиальных оценок. Он попробовал много комбинаций переменных и придумал процедуру для рецензирования до 250 строк прозы или исходного кода. После 800 итераций он придумал формализованную инспекционную стратегию, и по сей день Вы можете заплатить ему, чтобы он Вам рассказал об этом (название компании: Fagan Associates). Его методы были позже другими изучены и подробно расширены, прежде всего Томом Джилбом и Карлом Виджерсом.

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

Каждому участнику будет присвоена определенная «роль». Для «рецензента» можно определить задачу критического анализа, в то время как «наблюдатель» может бы быть призван как консультант проблемной области или изучить, как правильно делать рецензирование. На инспекции Фагана «читатель» просматривает исходный код только для понимания – не для критического анализа – и представляет его группе. Это разделяет то, что автор предполагал, от того, что фактически представлено; часто сам автор в состоянии выбрать дефекты, получив такое описание со стороны.

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

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

Типичный поток операций для «формальной» инспекции. Не показаны артефакты, создаваемые анализом: журнал дефектов, заметки по встрече и журнал метрик. Некоторые в инспекции также используют закрывающую анкету-опросник на заключительной встрече.

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

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

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

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

Поэтому давайте посмотрим другие методы.

Рецензирование через-плечо

Это наиболее распространенное и неофициальное из рецензирований кода. Рецензирование «через-плечо» простое – разработчик стоит над рабочим местом автора, в то время как автор проводит рецензента по изменениям кода.

Обычно автор «ведет» рецензирование, находясь за клавиатурой и мышью, открывая различные файлы, указывая на изменения и объясняя, почему был выбран такой путь. Автор может представить изменения, используя различные инструменты, и даже переходя назад и вперед между изменениями и другими файлами в проекте. Если рецензент видит что-то неправильное, они могут поучаствовать в небольшом «парном программировании на месте», когда автор пишет исправление, а рецензент наблюдает. Большие изменения, где рецензент не обязателен, выполняются отдельно.

С современным программным обеспечением использующим общий рабочий стол так называемый анализ «через-плечо» может иметь место и для удаленных ситуаций. Это усложняет процесс, потому что вы должны запланировать эти встречи совместного использования и связаться по телефону. Положение через-плечо позволяет людям указывать, писать примеры или даже переходить к электронной доске для обсуждения, что сложнее сделать по Интернету.

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

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

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

Во-вторых, для автора просто неумышленно пропустить изменение. Бесчисленное количество раз мы наблюдали анализ, который завершался, автор регистрировал свои изменения, и когда он видит, что список файлов уже загружен, он говорит, «О, я изменял этот? «. Слишком поздно!

Процесс рецензирования через-плечо

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

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

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

«Почему Вы делаете так,» спросит рецензент, «ведь API GUI Windows сделает это за Вас?»

«Да, я думал так также,» ответит автор, «но оказывается, что в этом случае обрабатывается не правильно. Поэтому я должен был вызвать его по-другому здесь.»

Для рецензента будет просто принять изменения. Но следующий разработчик, который прочтет этот код, будет иметь такой же вопрос и может даже удалит обходное решение в процессе чистки кода. «В конце концов», скажет следующий разработчик, «API Windows делает это для нас, поэтому никакой потребности в этом дополнительном коде нет!»

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

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

Рецензирование через-почту

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

Самая сложная часть почтовой рецензии состоит в поиске и сборе рецензентов для файлов. На конец автор должен выяснить, как собрать файлы. Например, если это рецензирование изменений, предлагаемых для регистрации в управлении версиями, пользователь должен идентифицировать все файлы, добавленные, удаленные и измененные и скопировать их куда-нибудь, затем загрузить предыдущие версии этих файлов (так чтобы рецензенты видели, что было изменено), и организовать файлы так, чтоб рецензенты знали, какие с какими файлами сравнивать. Далее рецензенты должны извлечь эти файлы из электронной почты и сгенерировать различия для них.

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

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

Рисунок 3: Типичный процесс для почтового рецензирования кода уже зарегистрированного в системе управления версиями. Эти фазы не отличимые в действительности, потому что нет никакого материального объекта «рецензирование».

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

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

Еще одно преимущество рецензирования через-почту – они не выбивают рецензентов из «зоны». Хорошо известно, что разработчику требуется 15 минут, чтобы войти «в зону», где они погружены в свою работу и очень производительны. Даже простая просьба рецензирования у разработчика выбивает его из зоны – даже если будет ответ «я слишком занят». С электронными письмами рецензенты могут работать во время самостоятельно выбранного перерыва, поэтому они могут оставаться в своей зоне в течение многих часов.

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

Рисунок 4: Типовой процесс для рецензирования кода через-почту уже зарегистрированного в системе управления версиями. Эти фазы не отличимые в действительности, потому что нет никакого материального объекта «рецензирование».

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

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

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

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

Инструментальное рецензирование

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

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

Автоматизированный сбор файлов

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

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

Объединенное отображение: Различия, комментарии, дефекты

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

Автоматизированный набор метрик

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

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

Выполнение рецензирования

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

Клиенты и интеграция

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

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

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

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

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

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

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

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

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

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

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

Полное обсуждение за и против парного программирования в целом вне нашей темы.

Заключение

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

И любой вид рецензирования кода лучше, чем ничего.

Posted in Рецензирование | Отмечено: , | Leave a Comment »

Лучшие секреты рецензирования кода. Сопротивление рецензированию кода

Posted by Шамрай Александр на Июнь 5, 2013

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

Автор Эрик Браун.

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

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

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

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

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

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

А это косвенные выгоды, которые являются побочными продуктами Рецензирования кода:

  • Более короткие циклы разработки/тестирования
  • Уменьшение влияния на техническую поддержку
  • Больше удовлетворенность клиентов
  • Более простой в сопровождении код

И тем не менее, некоторые группы разработки до сих пор не используют рецензирование кода как регулярную часть их процесса. Почему так? Существует две основных простых причины:

  1. Эго программиста
  2. Проблемы передачи исходного кода для рецензирования и планирование встреч для рецензирования

Давайте поговорим сначала об эго. Когда кто-то еще смотрит на твою работу, любой программист естественно будет оценивать то, что человек думает о нем. Это может быть истолковано как конструктивный или критически настроенный процесс, и это толкование может создать 2 разных класса программистов. Первым классом являются коллективные программисты, когда они сталкиваются с проблемой, будут делать все что необходимо для ее понимания (или по крайней мере прийти к временному решению), что часто включает в себя спросить коллегу, который уже знает ответ или готов поделиться разными идеями. Они видят и используют коллегиальную оценку как полезный процесс. Вторым классом являются изоляционисты – те программисты, которые когда сталкиваются с проблемой, которую они не в состоянии решить, будут продолжать непродуктивно грузиться на ней, вместо того, чтобы выявить их коллег, которые им помогут. Стоит отметить, эта дихотомия подходов безусловно не является уникальной для программистов и существует в более широких масштабах личности в целом.

Почему эти классы имеют тенденцию быть настолько различными среди программистов? Основная причина последнего класса программиста, как правило, короткая карьера в разработке программного обеспечения. Их багаж знаний становится ограниченным в том, что они могут сами понять, что даже ярких личностей (в поле ярких личностей) ограничивает.

В 2002 году было озвучено, что средняя карьера в высоких технологиях длится около 8 лет. Это слишком много времени потраченного впустую на свое совершенствование. Положение может быть также важно, как способность. Программист должен иметь способность работать в команде, слушать внимательно, идти на риск и учиться на своих ошибках, для того чтобы выжить в обычно быстро меняющейся среде высоких технологий. Постоянный интерес к обучению последовательно усиливает и обостряет навыки и позволяет программистам продолжать быть продуктивными (и рыночными!) в постоянно меняющейся области.

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

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

Когда я работал в качестве разработчика драйверов устройства для большой корпорации разработки программного обеспечения и оборудования, наш менеджер первой линии был очень нетехническим. У него всегда было одно и тоже понимание ошибок, которые мы пытались изолировать: «Вы просто должны установить флаг». Большинство программистов имеют первичный страх необходимости объяснять что-то или страдать от бессмысленных вопросов таких как этот. Так что, когда вы спросите программиста извлечь последние несколько изменений чужого кода из системы управления версиями, распечатать их и выделить изменения, и затем принести их на встречу для обсуждения с другими людьми, включая моего старого менеджера, вы ощутите, как уходит из вас жизненная сила.

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

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

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

Больше нет оправданий не использовать рецензирование кода.

Posted in Рецензирование | Отмечено: , | Leave a Comment »

Лучшие секреты рецензирования кода. Примеры для коллегиальной оценки

Posted by Шамрай Александр на Июнь 4, 2013

Ошибка на 1 млрд $ и почему никто не говорит о коллегиальной оценке кода.

Это должно было занять только час.

Плохая новость была в том, что мы имели стек жалоб от клиентов. Последний релиз имел неприятную ошибку, которая проскользнула через контроль качества (QA). Хорошая новость в том, что некоторые из этих жалоб включали описание проблемы – диалоговое окно с непредвиденной ошибкой – и к одной жалобе был прикреплен файл с журналом. Нам только нужно было воспроизвести проблему с помощью журнала и добавить этот случай в модульные тесты. Быстро выпустить сборку из стабильной ветви и мы в ажуре.

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

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

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

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

Пример для рецензирования: Поиск ошибок в начале и часто

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

Результат: Рецензирование кода сохранило бы половину стоимости исправления ошибок. Кроме того, они нашли бы 162 дополнительных ошибок.

Почему столь драматичен эффект рецензирования кода? Виновником может быть отсутствие сотрудничества на этапе разработки.

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

Сохранить 150 000$: Урок из реального мира

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

Рецензирование кода добавляет обратный элемент сотрудничества к этой фазе процесса разработки программного обеспечения.

Рассмотрим это: ничего коммерческого не публикуется без корректировок от нескольких профессиональных редакторов. Посмотрите подтверждение этого в любой книге и вы сможете найти отзывы, кто помог «удалить дефекты». Независимо от того, насколько умен или прилежен автор, процесс рецензирования необходим для производства высококачественной работы. (И даже тогда, когда автор не нашел еще пять ошибок после просмотра первой версии?)

Почему мы считаем, что в разработке программного обеспечения по-другому? Почему должны мы ожидать от наших разработчиков написания страниц детального кода (и прозы) без ошибок?

Мы не должны. Если рецензирование работает с романами, то и в проектировании программного обеспечения это может также работать при написании кода. Рецензирование кода добавляет элемент столь необходимого сотрудничества к этапу разработки процесса разработки программного обеспечения.

Ошибка на 1 миллиард $

В 2005 году Adobe приписали $1 млрд доходов к формату PDF. Почему PDF стоит 1 млрд $? Потому что это один формат, который каждый может просматривать и печатать. Он работает просто. Если он потеряет этот статус, Adobe потеряет состояние построенное на этом формате, которому 2005 финансовом году присвоили прибыль в 1 млрд $.

Теперь представьте, что вы менеджер по разработке Acrobat Reader версии для Windows. Следующая основная версия должна быть сделана за 9 месяцев, и вы несете ответственность за добавление пяти новых функций. Вы знаете, как много читают с Reader-ом и сколько дохода – и рабочих мест – зависит от его дальнейшего успеха.

Так что теперь вопрос: какая из тех пяти функции настолько убедительна, что было бы возможно введение критической ошибки в Reader только, чтобы иметь эту функцию?

Ответ: Ни одна!

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

Ответ: Все. Включая рецензирование кода.

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

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

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

Но вам не нужно иметь 1 млрд $ на кону, чтобы быть заинтересованными в качестве кода и возможности поддержки. Поставка ошибок QA стоит денег; поставка ошибок клиентам стоит много денег и потерю доброго отношения.

Но если рецензирование кода работает и это хорошо, почему мало людей говорят об этом? Кто-то действительно делает это?

Почему рецензирование кода является секретом

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

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

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

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

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

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

Мне интересно. Что дальше?

Итак, рецензирование кода работает, но что делать, если разработчики тратят слишком много времени на это? Что делать, если социальные последствия личностных критик нарушают моральные принципы? Как можно выполнять рецензирование измеряемо, так чтобы вы могли определить проблемы процесса?

Мы покроем исследования рецензирования в реальном мире и покажем, какие выводы можно извлечь из них (и какие нет). Мы дадим результаты наших собственных исследований по 2500 отзывам. Мы дадим профессиональные советы и руководства для пяти наиболее распространенных типов рецензирования. Мы объясним, как воспользоваться преимуществами позитивных социальных и личных аспектов рецензирования, также какими путями менеджеры могут смягчить негативные эмоции, которые могут возникнуть. Мы объясним, как осуществить обзор в контексте CMMI/PSP/TSP. Мы дадим конкретные советы по как построить процесс коллегиальной оценки, которая удовлетворит конкретные цели. Наконец мы опишем инструмент, который наши клиенты использовали для различных видов рецензирования как возможно безболезненно и как возможно более эффективно.

Рецензирование кода может быть практичным, эффективным и даже веселым.

Posted in Рецензирование | Отмечено: , | Leave a Comment »

 
%d такие блоггеры, как: