Как справиться с проверкой кода на моем новом месте, когда я пришел из этой практики?

Команда в моей новой компании не имеет процесса проверки кода.

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

Я твердо верю в то, что проверка кода - это способ улучшить качество и сэкономить время, потому что он улавливает потенциальные проблемы ранее (хотя я не говорю о парном программировании).

• Как я могу показать, что проверка кода - это не трата времени, а экономия времени?
• Можно ли пропустить проверку кода, если у вас есть модульные тесты?

Можно ли пропустить проверку кода, если у вас есть модульные тесты?

Но почему?

Основная роль рецензирования заключается не в выявлении ошибок.

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

Однако проверка кода обеспечивает поддержку кода . Я потребую, чтобы код был чистым и понятным (не только для его автора), прежде чем он будет запущен в производство.

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

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

В более широком плане человек также учится и развивается как разработчик, читая чужой код.

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

Существуют ли какие-либо исследования и статистика, показывающая, что проверка кода - не трата времени, а экономия времени?

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

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

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

Можно ли пропустить проверку кода, если у вас есть модульные тесты?

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

Взятые из некоторых случайных слайдов, которые я нашел , но точные данные взяты из книги Стив Макконнелла Code Complete:

Полезны ли обзоры кода?

«Я считаю, что рецензирование кода - это самая большая вещь, которую вы можете сделать, чтобы улучшить свой код»

Джефф Этвуд из «Кодирующего ужаса» на http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html

---

«Индивидуальные проверки обычно выявляют около 60 процентов дефектов, что выше, чем у других методов, кроме прототипирования и бета-тестирования большого объема».

Стив Макконнелл, Code Complete 2-е издание, стр. 485

Эта цифра 60% взята из статьи IEEE Шулла и др. 2002 г. « Что мы узнали о борьбе с дефектами», которая содержит раздел под названием:

«Экспертные оценки улавливают 60% дефектов»

Отказ от ответственности: Этот ответ мой личный опыт :)

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

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

Так что я бы сказал, что это сильно зависит от того, что вы делаете, сколько людей вы и т.д.

Кроме того, риск того, что ваши пересмотры кода закончатся войной, не стоит недооценивать.

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

Убедитесь, что ваш код хорошо написан и проверен перед проверкой.

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

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

Обзоры кода имеют несколько целей:

• Нахождение дефектов в коде
• Передача знаний между членами команды

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

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

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

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

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

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

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

Это также позволяет избежать ужасных ситуаций, когда проверки кода приводят к столкновениям эго - ситуации, когда программист A будет использовать метод X, а B будет использовать метод Y, поэтому, если A пишет код, который использует метод X, рецензент B настаивает на методе Y, поэтому A переписывает код с использованием метода Y, в то время как если бы B написал код, а A проверил его, произошла бы полная противоположность.

Если вы сторонник рецензирования кода, я боюсь, что нет реальной замены. Неудачный и стереотипный случай - это рабочее место, которое не выполняет проверки кода, потому что (A) они не знакомы с практикой и / или (B) они не хотят тратить время и усилия на получение обзора кода Система на месте.

В основном, чтобы получить то, что вы хотите здесь, вам нужно изменить культуру на рабочем месте - и это никогда не бывает простым или легким. Не забывайте, что даже если ваше рабочее место на 100% убеждено, что обзоры кода превосходны, и они хотят их принять, то для перехода на новый способ работы все равно потребуются значительные затраты времени, энергии и производительности. Эти инвестиции должны окупиться - но вы должны иметь бай-ин для инвестиций, а не только для окупаемости. Посмотрите видео Роя Ошерова «Модульное тестирование и TDD - как это сделать» - проблемы принятия обзоров кода очень похожи на проблемы, связанные с применением модульного тестирования.

А пока делай, что можешь, чтобы получить как можно больше:

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

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

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

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

Затем проверьте все, прежде чем проверить его. Самое главное, что он работает правильно.

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