Как защитить багажник от несчастных новичков?

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

Команда из 5-10 работает над проектом, который управляется проблемами. То есть, типичный поток выглядит следующим образом:

фрагмент работы (ошибка, улучшение и т.д.) создается как проблема в отслеживании проблем.
Проблема назначается разработчику
Разработчик решает проблему и фиксирует свои изменения кода в trunk
В момент выпуска замороженная и сильно протестированная соединительная линия или релизная ветка или что-то еще встроенное в режиме выпуска и выпущенный

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

Одна идея, с которой мы играем:

Отменить фиксацию доступа к соединительной линии для новичков и заставить их развиваться в ветке для каждого разработчика (мы используем SVN):

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

Обновление: Спасибо, всем, за ценный вклад.

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

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

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

С этими двумя исправлениями я не думаю, что что-то жесткое или драконовское, как то, что я предложил выше, необходимо. Спасибо!

Ответ 1

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

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

Я собираюсь выйти на конечность и сказать, что есть DEFINETLY "новые" (новые для вашей компании) кодеры, которые с меньшей вероятностью ошибаются, чем некоторые из ваших "опытных" разработчиков.

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

Есть несколько других вещей, которые вы могли бы сделать:

Управление проектами. Объясните проблему с командой, подчеркнув ответственность, связанную с фиксацией соединительной линии.
Структура команды. Назначьте наставника новичков, которые будут выполнять проверку кода перед фиксацией. Это также хорошая возможность для новичков узнать проект, стандарты кодирования и ознакомиться с культурой команды.
Тесты устройств:. Требовать от всех, чтобы они также записывали unit test для своего кода.
Регулярные сборки и тесты. Установите сервер сборки и создайте ночные сборки (в том числе unit test), чтобы обнаружить проблемы на раннем этапе.
Обзор кода Установите крюк после фиксации на вашем сервере SVN, чтобы отправить уведомление по электронной почте о новых коммитах, и кто-то из вас быстро сделал быстрый обзор.

Ответ 8

Вы можете поставить поэтапную систему обзора, например ReviewBoard. См. Также разговор google на Mondrian. Мы начинаем использовать обзор здесь, но в режиме post-commit, для которого он не предназначен напрямую.

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

Добавьте автоматическое тестирование модулей и/или автоматическое функциональное тестирование, и у вас есть еще больше уверенности. (Мы это делали в прошлом, но это поддавалось некоторой бит-гнили.)

Вы даже можете дойти до непрерывного интеграционного сборщика (как это упомянуто несколькими другими).

С одной стороны, процесс фиксации может быть:

опубликовать патч (или адрес ветки) на ReviewBoard; если не это, то попросите одного или нескольких сверстников для обзора
рассмотрели ли он и приняли
CI buildsystem построит его и запустит модульные и функциональные тесты
система сборки CI обязуется для вас только в том случае, если она выполнена успешно
(тогда, возможно, запустите анализ статического кода - например, Gimpel PC-Lint - до или после фиксации).

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

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

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

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

Ответ 9

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

Что касается прослеживаемости, то как это происходит в багажнике, кого это волнует? Если код нарушен, рецензент, который его пропустил, сильно виноват, если не БОЛЬШЕ не по вине, чем разработчик (поскольку они ЗНАЮТ, что разработчик является "несчастным новичком" и "не нужно доверять", они должны знать смотреть внимательно).

Ответ 10

Код просмотрит изменения в соединительной линии и попросит их применить исправления (если они есть). В конце концов они поправятся, и все будут счастливы.

Ответ 11

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

Ответ 12

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

Ответ 13

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

"цепочка неудачных событий";). Честно говоря, это звучит как ваш Q & A не настолько жесткий, как ваше предложение. Лучшее тестовое покрытие и, возможно, сервер CI помогут. Мне лично нравятся сообщения svn commit. Это позволяет мне легко обновляться. Я получаю электронное письмо с diff, которое кто-то совершил. Легко сделать, и непрочитанные сообщения об отправке тоже являются списком задач.

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

Ответ 14

Я могу просто повторять то, что говорили другие люди, но...

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

Другим решением было бы иметь программу Mentoring/Sponsoring-type для стажеров/кооперативов/новичков, где политика и процедуры компании не просто рассматриваются в принципе, а на практике. Так, например, новичок будет работать бок о бок со Спонсором в течение определенного периода времени, чтобы он или она могли ознакомиться с тем, как бизнес работает изо дня в день. Таким образом, помимо приобретения опыта, он или она могут стать удобными и использовать для выполнения своей работы так, как это должно быть сделано.