Я подозреваю, что фокусируюсь не на той проблеме, поэтому сначала я опишу, что я думаю о проблеме, прежде чем представлять, возможно, неоптимальное решение, которое я представляю.
Текущая ситуация:
В настоящее время мои коллеги фиксируют изменения в своем коде только после огромных периодов времени с изменениями, распространяющимися по всему проекту (-ам). Это прогресс, я думаю, потому что не так давно они просто поместили .zip архивы на какой-то сетевой ресурс Тем не менее, слияние - это кошмар - и, честно говоря, с меня хватит. И я тоже устал говорить, объяснять и просить. Это просто должно прекратиться - без меня постоянно быть "плохим парнем".
Мое решение:
поскольку кажется, что нет никакого понимания и / или отсутствия интереса к проблемам, и я не могу ожидать, что какие-либо усилия будут длиться дольше, чем несколько дней ... поражаю, что, часы, я бы хотел, чтобы сервер Subversion выполнил нытье.
Мой вопрос:
я здесь далеко от базы или я смотрю не на ту проблему? Кажется, что я что-то упускаю, и я думаю, что спрашиваю не то, что смотрю на инструменты, чтобы решить мою проблему.
Должен ли я искать инструмент для решения этой проблемы или что я должен сделать, чтобы это исправить?
источник
Ответы:
Вы ищете техническое решение человеческой проблемы. Это редко работает.
Причина этого в том, что если члены команды что-то не принимают (и не понимают последствий), вместо того, чтобы следовать правилам, они попытаются их обойти. Именно поэтому, например, разработчики должны принимать и понимать правила стиля, а не просто принуждать их к выполнению проверкой.
Вот несколько подходов, которые я или использовал в прошлом, или имел в виду, фактически не имея возможности использовать их на практике. Некоторые могут не относиться к вашему делу, в зависимости от занимаемой вами должности в команде (если вы возглавляете команду с отличной репутацией, скорее всего, у вас будет лучшая возможность отстаивать свою точку зрения, чем если вы студент, который только что присоединился к команде на время вашей стажировки).
Обсудите эту проблему со своими коллегами и объясните последствия крупных коммитов. Может быть, они просто не понимают, что сложные слияния являются прямым следствием редких коммитов, а небольшие частые коммиты сделают слияния (относительно) легкими.
Я знал многих программистов, которые были просто убеждены, что слияния всегда сложны. Они выполняли не более одного коммита в день, избегая использования мощных инструментов, таких как diff и auto-merge в Visual Studio, и имели плохую практику ручного слияния (если только «Take mine» без дальнейшей проверки diff на самом деле является хорошей практикой). Для них это не имеет ничего общего с ними , и был присущ характер слияния.
Приведите конкретные примеры того, что происходит в других компаниях (особенно тех, к которым ваши коллеги относятся с большим уважением). Они могут просто не знать, что это проблема, и быть уверенными, что каждая команда делает максимум один коммит в день.
Некоторые люди не знают, что есть команды из 5-10 участников, которые производят до 50 толчков в производство, что в среднем составляет 5-10 коммитов в день на человека. Они могут не понять ни как это возможно, ни почему кто-то это сделает.
Подавать пример. Делай достаточно мало, возьми себя в руки. Если возможно, сделайте короткую презентацию, показывающую их и ваши слияния бок о бок в течение недели (я не уверен, легко ли извлечь такую информацию из системы контроля версий). Подчеркните возможные ошибки, которые они совершили во время слияния, и сравните их с количеством ошибок, которые вы сделали (которые должны быть близки к нулю).
Используйте «Я сказал вам» технику, когда это необходимо . Когда вы видите, что ваши коллеги страдают от болезненного слияния, громко комментируйте, что небольшие частые коммиты могут сделать слияния (относительно) безболезненными.
Объясните, что для совершения коммита не существует минимальной продолжительности. Коммит может даже соответствовать незначительным изменениям, сделанным за несколько секунд. Переименование файла, удаление устаревшего комментария, исправление опечатки - все это задачи, которые можно выполнить немедленно.
Программисты не должны бояться делать крошечные коммиты, а скорее объединять множество изменений в один огромный коммит.
При необходимости работайте с людьми, а не с командой. Если есть человек, который особенно отказывается делать частые, небольшие коммиты, поговорите с этим человеком индивидуально, чтобы понять, почему он отказывается от него.
Они могут дать совершенно веские причины, которые могут дать вам подсказку о том, что происходит с командой. Несколько причин, которые я слышал сам:
«Мой учитель / наставник сказал мне, что лучше всего делать один коммит в день». Меня это не удивляет, учитывая то , что я слышал от своих учителей в колледже .
«Мои коллеги сказали мне, что я должен делать меньше коммитов». Мне тоже говорили об этом в некоторых командах, и я понимаю их точку зрения. У нас был журнал, который был практически заполнен моими коммитами (это не сложно сделать, когда четыре товарища по команде даже не делают один коммит в день), что расстроило моих коллег.
«Я думал, что небольшие коммиты затрудняют нахождение ревизии». Как-то верный момент, даже когда команда прилагает усилия для написания описательных сообщений журнала.
«Я не хочу тратить слишком много места на нашем сервере контроля версий». Человек, очевидно, не понимает, как хранятся коммиты (и как дешево это место для хранения).
«Я думаю, что коммит должен соответствовать конкретной задаче». Учитывая, что часто задача соответствует некоторой работе, выполняемой за один день (например, на досках задач визуального управления), это не совпадение. Затем человек должен научиться определять разницу между заданием в отставании (от 2 до 8 часов работы) и логически изолированным изменением, которое должно быть совершено (от нескольких секунд до нескольких часов работы). Это также связано с пунктом 5.
Ищите причину, по которой команда не выполняет коммиты чаще. Вы можете быть удивлены результатами.
Недавно в другом ответе я упомянул, что скорость фиксации имеет значение, и даже сотни миллисекунд могут подтолкнуть разработчиков к фиксации с меньшей частотой.
Другие причины могут включать в себя:
Слишком сложные правила для написания сообщения коммита.
Правило, которое заставляет разработчика связывать коммит с задачей из системы отслеживания ошибок.
Страх сломать сборку.
Нежелание иметь дело с риском сломать сборку прямо сейчас: если вы делаете коммит вечером в пятницу перед самым отъездом, вы можете отложить работу со сломанной сборкой до понедельника.
Страх перед слиянием.
Определите, понимают ли разработчики, что есть и другие преимущества для частого принятия . Например, платформа Continuous Integration является огромным стимулом для частых коммитов , поскольку она позволяет точно определить, где была введена регрессия .
Я предпочел бы, чтобы платформа CI говорила мне, что я сломал сборку в ревизии 5023, которая состоит из изменения двух методов в одном файле, который я сделал пятнадцать минут назад, а не в ревизии 5023, состоящей из изменений, которые охватывают четыре дюжины файлов и представляют 13 часов работы.
источник
Организация, с которой я заключил контракт в прошлом, хотела решить эту же проблему и предложила довольно хорошее социальное решение: у разработчиков нет своих компьютеров. У команды разработчиков есть компьютеры, но любого человека можно попросить работать с любым компьютером разработчика в любой день. Таким образом, регистрация - единственный способ убедиться, что вы можете продолжать работать над тем, что вы делали вчера!
Затем руководство обошлось и тайно отменило изменения на компьютерах после нескольких часов, так что все, что не было зарегистрировано, было потеряно. Эти «симулированные сбои компьютера» должны были произойти только несколько раз, прежде чем разработчики попали на борт.
Конечно, важно объяснить «почему» правил, а также «что». Если «почему» не выяснено, они могут просто хранить свой источник на USB-накопителях или что-то в этом роде.
источник