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

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

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

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

  • Как я могу показать, что просмотр кода - это не трата времени, а временная заставка?
  • Можно ли пропустить проверку кода, если у вас есть модульные тесты?
31 голос | спросил jparkcool 5 32014vEurope/Moscow11bEurope/MoscowWed, 05 Nov 2014 10:31:32 +0300 2014, 10:31:32

10 ответов


30
  

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

Но почему?

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

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

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

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

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

В более широкой схеме вещей человек также учится и развивается как разработчик от чтения кода других людей.

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

ответил Konrad Morawski 5 32014vEurope/Moscow11bEurope/MoscowWed, 05 Nov 2014 13:42:16 +0300 2014, 13:42:16
24
  

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

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

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

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

  

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

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

ответил back2dos 5 32014vEurope/Moscow11bEurope/MoscowWed, 05 Nov 2014 10:57:11 +0300 2014, 10:57:11
5

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

  

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

     

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

     

Джефф Этвуд из фильма «Ужас в кодировании»    http://www.codinghorror.com/blog/2006/01/код-обзоры-только-ду-it.html

     

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

     

Стив Макконнелл, Code Complete 2nd Edition, стр. 485

Эта цифра в 60% взята из статьи IEEE от Shull et al 2002 Что мы узнали о борьбе Дефекты , которые содержат раздел под названием:

  

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

ответил icc97 5 32014vEurope/Moscow11bEurope/MoscowWed, 05 Nov 2014 23:10:54 +0300 2014, 23:10:54
3

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

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

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

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

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

ответил Knerd 5 32014vEurope/Moscow11bEurope/MoscowWed, 05 Nov 2014 14:18:08 +0300 2014, 14:18:08
3

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

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

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

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

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

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

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

ответил ChrisW 5 32014vEurope/Moscow11bEurope/MoscowWed, 05 Nov 2014 20:56:51 +0300 2014, 20:56:51
2

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

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

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

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

ответил Venkat 5 32014vEurope/Moscow11bEurope/MoscowWed, 05 Nov 2014 13:00:36 +0300 2014, 13:00:36
1

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

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

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

ответил gnasher729 5 32014vEurope/Moscow11bEurope/MoscowWed, 05 Nov 2014 20:40:12 +0300 2014, 20:40:12
0

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

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

Тем временем сделайте все возможное, чтобы получить столько, сколько сможете:

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

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

ответил Standback 12 32014vEurope/Moscow11bEurope/MoscowWed, 12 Nov 2014 11:40:57 +0300 2014, 11:40:57
-2

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

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

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

ответил Simon B 5 32014vEurope/Moscow11bEurope/MoscowWed, 05 Nov 2014 17:33:02 +0300 2014, 17:33:02
-2

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

ответил Jules 5 32014vEurope/Moscow11bEurope/MoscowWed, 05 Nov 2014 17:51:21 +0300 2014, 17:51:21

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132