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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Advertisements

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

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