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

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

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

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. Мы дадим конкретные советы по как построить процесс коллегиальной оценки, которая удовлетворит конкретные цели. Наконец мы опишем инструмент, который наши клиенты использовали для различных видов рецензирования как возможно безболезненно и как возможно более эффективно.

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

Advertisements

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

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