Должны ли ваши лучшие программисты проверять код чужого кода на исходный контроль?

Одно из различий между svn и git - это возможность контролировать доступ к репозиторию. Трудно сравнить эти два, потому что есть разница в перспективах о том, кому разрешено вообще совершать изменения!

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

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

29 голосов | спросил GlenPeterson 8 Jam1000000amTue, 08 Jan 2013 00:40:05 +040013 2013, 00:40:05

11 ответов


52

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

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

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

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

Кроме того, не забудьте изучить гибридные опции. С git очень легко настроить репозиторий, к которому каждый может нажать, а затем иметь привратника, такого как старший разработчик, тестер или даже автоматизированный сервер непрерывной интеграции, если и когда изменение превратит его во второй, более стабильный репозиторий. Таким образом, вы можете получить лучшее из обоих миров.

ответил Karl Bielefeldt 8 Jam1000000amTue, 08 Jan 2013 02:42:01 +040013 2013, 02:42:01
40

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

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

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

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

ответил Telastyn 8 Jam1000000amTue, 08 Jan 2013 01:09:10 +040013 2013, 01:09:10
28

Нет. Любой должен иметь возможность совершить.

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

Еще одна замечательная вещь называется unit tests;)

Есть альтернатива, хотя.

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

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

ответил jgauffin 8 Jam1000000amTue, 08 Jan 2013 01:24:02 +040013 2013, 01:24:02
8

Вам следует посмотреть проекты, такие как Gerrit который позволяет всем разработчикам подталкивать свой код в «обзорную» ветку, и как только вы старшие /ведущие разработчики довольны этими изменениями, они могут вставить их в master /release.

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

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

ответил rochal 8 Jam1000000amTue, 08 Jan 2013 05:04:17 +040013 2013, 05:04:17
8

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

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

  1. Нет. Я хочу видеть каждую строку кода, прежде чем вы ее проверите.
  2. Некоторые - дайте мне знать, что вы делаете, и я предоставлю отзыв
  3. Большинство - отправляйтесь на работу и только при необходимости обращайтесь за помощью.

Преимущества освобождения вашего таланта:

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

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

ответил JeffO 8 Jpm1000000pmTue, 08 Jan 2013 17:38:59 +040013 2013, 17:38:59
5
  

- обзор, заслуживающий успеха в производительности?

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

Если это сделано неправильно , производительность ударит, конечно, убьет любые преимущества обзора; ответ заключается в том, чтобы не отбрасывать идеи отзывов, а узнать, как это сделать правильно .

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


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

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

С другой стороны, когда команда разумно сбалансирована, обзоры кода интересны и воспитательны. В моем предыдущем проекте у нас было требование для 100% обзора кода, и он не занимал много времени и не отвлекал. Были обнаружены ошибки, обнаруженные через обзор, и были дебаты о стиле кодирования и вариантах дизайна, но это чувствовалось просто ... normal .


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

  • - Интеграция этого изменения сильно затянулась, потому что рецензент внезапно заболел, что-то несчастье.
    - Здравствуйте! Hell-lo-o-o, вы когда-нибудь думали о том, чтобы иметь backup для рассмотрения подобных случаев?
ответил gnat 8 Jam1000000amTue, 08 Jan 2013 02:38:46 +040013 2013, 02:38:46
4

Да. Но только если вы говорите о распределенном контроле источника. С централизованным - это зависит.

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

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

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

ответил Hubert Kario 8 Jam1000000amTue, 08 Jan 2013 01:06:40 +040013 2013, 01:06:40
2

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

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

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

ответил Erik Reppen 8 Jpm1000000pmTue, 08 Jan 2013 18:23:32 +040013 2013, 18:23:32
0

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

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

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

ответил James 8 Jam1000000amTue, 08 Jan 2013 00:51:11 +040013 2013, 00:51:11
0

Да, обзор стоит того. Я не уверен, что есть производительность, если процесс обзора пропорционален следующим причинам:

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

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

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

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

ответил Steve 8 Jam1000000amTue, 08 Jan 2013 01:07:39 +040013 2013, 01:07:39
-1
  

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

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

  

Если ваши лучшие программисты должны проверить код чужого кода на исходный элемент управления?

Абсолютно NO. Это наверняка трата времени, за исключением некоторой критической логики, которая должна быть в твердотельном состоянии .

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

ответил EL Yusubov 8 Jam1000000amTue, 08 Jan 2013 05:20:11 +040013 2013, 05:20:11

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

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

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