Команда в моей новой компании не имеет процесса проверки кода.
Я приехал из компаний, где пересмотр кода является обязательной культурой, и поэтому я чувствую себя некомфортно, когда комментирую свой код, когда его никто не просматривает.
Я твердо верю в то, что проверка кода - это способ улучшить качество и сэкономить время, потому что он улавливает потенциальные проблемы ранее (хотя я не говорю о парном программировании).
- Как я могу показать, что проверка кода - это не трата времени, а экономия времени?
- Можно ли пропустить проверку кода, если у вас есть модульные тесты?
code-reviews
jparkcool
источник
источник
Ответы:
Но почему?
Основная роль рецензирования заключается не в выявлении ошибок.
Да, вы можете выявить некоторые потенциальные ошибки и сомнительный, склонный к ошибкам код, это часто случается, но иногда обнаружение некоторых грубых ошибок не означает, что рецензирование является надежным способом исключить наличие ошибок. Это далеко не так. Это не правильный инструмент для проверки функциональной правильности реализации.
Однако проверка кода обеспечивает поддержку кода . Я потребую, чтобы код был чистым и понятным (не только для его автора), прежде чем он будет запущен в производство.
Наличие модульных тестов полностью ортогонально этому. Вы можете иметь 100% покрытие кода и все тесты, проходящие для абсолютно непонятного кода.
Обзор кода также служит для ознакомления других разработчиков с вашей работой, чтобы они знали, что к чему, и могли оттуда забирать, или обрабатывать отчеты об ошибках, когда вы в отпуске и т. Д. Знание того, что вы сделали сразу, может помочь хорошо выполняйте свою работу - сохраняйте согласованность кодовой базы (придерживайтесь аналогичных шаблонов и соглашений во всем приложении) или избегайте дублирования кода.
В более широком плане человек также учится и развивается как разработчик, читая чужой код.
Модульные тесты вряд ли могут заменить любую из них. Да, если они хорошо написаны, они читают как документацию, и мы должны стремиться к этому. Но, опять же, это не является взаимоисключающим с проведением рецензирования, скорее наоборот - все преимущества рецензирования остаются в силе, тот факт, что ваши коллеги имеют несколько хороших модульных тестов, на которые можно посмотреть, только сделает процесс рецензирования более простым и еще более полезным а не излишним.
источник
Peer review doesn't even attempt to tackle this important aspect- ну, это так. По мере. Я часто нахожу себя указывающим, например. «партнер, вы фактически повторяете ту же логику здесь, и это бомба замедленного действия. Однажды она изменится в другом месте, и мы забудем обновить ее здесь ...»Я не знаю ни одного. Также трудно проводить такие исследования, потому что вам понадобятся две команды, у которых есть задача равной и реалистичной сложности, где одна использует обзоры кода, а другая - нет. Вам, вероятно, нужно, чтобы они решили ту же проблему, что означает выбрасывание большого количества денег в окно. И вам нужно было бы повторять эксперимент достаточно часто, чтобы получить статистическую значимость, что увеличило бы количество брошенных денег на порядки.
Если вы просто измеряете эффективность компаний, использующих проверки кода, по сравнению с компаниями, которые этого не делают, не только неясно, как измерить эффективность, но и какова реальная причина. Обзоры кода являются частью большой культуры. Трудно сказать, какая часть этого факта делает команду более эффективной (и может очень зависеть от характера команды или проекта). Или наличие этой культуры может просто означать, что компания меньше или моложе, каждый из которых имеет множество эффектов. Или вполне может быть, что готовность подчиниться кодовым обзорам исключает или способствует здоровой дистанции с вашим эго;)
Но не забывайте: у вас есть собственный опыт. Это часть того, почему они наняли тебя. Так что, если вы действительно верите, что можете повысить эффективность (а ваша команда действительно страдает от ее нехватки), сообщите об этом четко.
Нет. Если вы верите в важность тестов, то ваши тесты должны быть в первую очередь рассмотрены. Что если это чепуха? Или если покрытие паршивое? Или если они проверяют реализацию, а не поведение?
источник
return true;.Взятые из некоторых случайных слайдов, которые я нашел , но точные данные взяты из книги Стив Макконнелла Code Complete:
Эта цифра 60% взята из статьи IEEE Шулла и др. 2002 г. « Что мы узнали о борьбе с дефектами», которая содержит раздел под названием:
источник
Отказ от ответственности: Этот ответ мой личный опыт :)
Я сделал очень плохой опыт с обзорами кода в коде, который мы поддерживаем. Потому что у нас обычно только один лайнер или около того, и нам не о чем пересматривать.
Но в реальных проектах я получил хороший опыт, во время экзамена мой тренер проверял мои правила работы с кодом, и это очень помогло мне найти некоторые ошибки, которые я делал очень часто, которых я больше не делаю.
Так что я бы сказал, что это сильно зависит от того, что вы делаете, сколько людей вы и т.д.
Кроме того, риск того, что ваши пересмотры кода закончатся войной, не стоит недооценивать.
источник
Вы можете попросить руководителя вашей группы и / или коллеги провести рецензирование вашего кода, даже если проверки кода не выполняются нормально, возможно, как часть вашего обучения.
Убедитесь, что ваш код хорошо написан и проверен перед проверкой.
Когда я был руководителем группы, я сам проверял код новых сотрудников до тех пор, пока (через некоторое время) я не перестал бы находить ошибки или что-либо еще, что можно было бы критиковать в их коде, и с этого момента я перестал бы делать обзоры кода с ними; это произойдет, когда:
Обзоры кода имеют несколько целей:
Я думаю, что хорошо делать обзоры кода для новых сотрудников, даже если команда решила пропустить проверки кода среди опытных членов команды.
источник
Для любого программного обеспечения, разработанного для программного кода, не существует правила большого пальца, все зависит от области применения, размера клиента и размера компании. Например, если вы создаете приложение, в котором в будущем будет реализовано простое приложение, в котором, возможно, не будет никаких других версий, там достаточно модульного тестирования. Но опять же, проверка кода происходит, когда вы говорите о производительности приложения, где вам нужно проверять код на предмет кратковременного падения кода, которое можно было бы сделать лучше, чтобы повысить быстродействие.
Обзоры кода обычно выполняются там, где есть команда из более чем 2 разработчиков и технический руководитель, где технический руководитель хочет обеспечить качество приложения и обеспечить соблюдение стандартов кода, чтобы масштабировать приложение для будущих улучшений и обновлять его для различных приложений. будущие версии.
Например, у нас сейчас есть много платформ с открытым исходным кодом CMS, и эти платформы время от времени выпускают обновления для улучшения функций платформы, воображают разработчика, использующего одну из этих платформ, и не следуют стандартам кода, таким как жесткое кодирование в основных файлах, написание приложений код в файлах шаблонов, и если этот код поступает в производство и позже, когда клиент хочет обновить платформу до новой версии, он никогда не будет обновлен, если кодирование не будет переделано в соответствии со стандартами кода для этой платформы. Здесь это становится серьезной проблемой для выпуска кода в производство без проверки кода.
Поэтому я бы сказал, что обзоры кода, выполняемые перед выпуском, являются необходимостью для любых профессиональных софтверных компаний, и исключения могут быть только для личных / очень небольших приложений, где разработчик является опытным программистом и имеет опыт работы с ним.
источник
Обзоры кода имеют преимущества, которые не проистекают из самого процесса рецензирования: всегда есть дилемма, чтобы получить код высокого качества, но созданный за короткое время. Без проверки кода вы сами по себе, так что вы можете пожертвовать качеством для выполнения кода в короткие сроки. В обзорах кода есть рецензент, который не позволяет вам избежать низкого качества кода - именно этого вы хотите, будучи вынужденным тратить время на получение качественного кода, чего вы в первую очередь хотели, и который вы знаете, что в итоге вы сэкономите время, потому что каждый час, потраченный на написание лучшего кода, - это два часа, сэкономленные на отладке (или больше).
Без проверки кода вы сами по себе, так что вы должны поддерживать высокое качество кода. Простым решением является проверка каждого изменения, которое вы делаете самостоятельно, и исправление вещей, которые не соответствуют вашим стандартам качества.
Это также позволяет избежать ужасных ситуаций, когда проверки кода приводят к столкновениям эго - ситуации, когда программист A будет использовать метод X, а B будет использовать метод Y, поэтому, если A пишет код, который использует метод X, рецензент B настаивает на методе Y, поэтому A переписывает код с использованием метода Y, в то время как если бы B написал код, а A проверил его, произошла бы полная противоположность.
источник
Если вы сторонник рецензирования кода, я боюсь, что нет реальной замены. Неудачный и стереотипный случай - это рабочее место, которое не выполняет проверки кода, потому что (A) они не знакомы с практикой и / или (B) они не хотят тратить время и усилия на получение обзора кода Система на месте.
В основном, чтобы получить то, что вы хотите здесь, вам нужно изменить культуру на рабочем месте - и это никогда не бывает простым или легким. Не забывайте, что даже если ваше рабочее место на 100% убеждено, что обзоры кода превосходны, и они хотят их принять, то для перехода на новый способ работы все равно потребуются значительные затраты времени, энергии и производительности. Эти инвестиции должны окупиться - но вы должны иметь бай-ин для инвестиций, а не только для окупаемости. Посмотрите видео Роя Ошерова «Модульное тестирование и TDD - как это сделать» - проблемы принятия обзоров кода очень похожи на проблемы, связанные с применением модульного тестирования.
А пока делай, что можешь, чтобы получить как можно больше:
Основным преимуществом любого из них является то, что если вы сможете поддерживать их с течением времени, разработчики вокруг вас начнут замечать обзоры кода. Вы эффективно продемонстрируете, как проверки кода могут быть интегрированы в существующую культуру, и это открывает путь для изменения культуры. Обзоры кода помогают , поэтому, если вы сможете продемонстрировать это в небольшом масштабе, это откроет путь для других - и культуры в целом - последовать вашему примеру.
источник
Перестаньте беспокоиться об этом - ваш новый работодатель просто не заботится об обзорах кода. Научитесь быть уверенными в своих силах, и никто не скажет вам, что можно проверить код, который вы написали. Вскоре вы научитесь жить без утомительно утомительного процесса, который просматривает код других людей.
Следуйте рекомендациям по стилю (или просто стилю), которые используют все остальные. Используйте свой опыт, чтобы решить, что нужно комментировать, какие соглашения об именах использовать и так далее.
Затем проверьте все, прежде чем проверить его. Самое главное, что он работает правильно.
источник
Если вашему новому работодателю не нравится идея проверки кода, возможно, это связано с тем, что у него отрицательная связь со старомодными методологиями командных и управляющих типов, и они стремятся к более современному, гибкому набору практик. В этом случае они могут быть более открытыми для идеи парного программирования, которая обеспечивает многие из тех же преимуществ и широко рассматривается как более динамичная современная практика.
источник