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

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

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

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 не тратит времени на поиск и отслеживание. Еще один кусок кода, который не добавляет постепенно сложности в поддержки программного обеспечения. Разработчики и менеджеры могут спать немного спокойнее по ночам каждый раз, когда будет обнаружен новый дефект.

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

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

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

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

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