Стандарты работы разработчиков на своих рабочих станциях


18

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

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

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

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

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

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

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

Или есть другое решение, которое мне не хватает?

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

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


8
-1 за переход гестапо в командный центр программиста.
системович

17
Подождите, как второй разработчик узнал пароль первого разработчика?
TheLQ

12
+1 за отличный вопрос. По моему мнению, «уход в гестапо» не имеет отношения к корпоративной среде, поскольку разработчики работают на корпорацию и поэтому отказываются от прав доступа к своим локальным компьютерам. Вы хотите конфиденциальности, используйте свое собственное оборудование.
Гэри Роу

4
Если с разработчиком можно связаться по паролю, почему бы вам просто не спросить его, какая версия является текущей?
Бен Л

2
@ Гэри: что? нет, это полная (и очень опасная) ерунда. Это непростой (как логически, так и юридически) переход от работы в компании к отказу от личных прав на неприкосновенность частной жизни. Я бы не назвал действия Джона «происходит гестапо» (еще до того, он пояснил , что больше) , но компании действительно идут Гестапо иногда и это то , что должно быть предотвращено и воевали на всех уровнях. Я могу говорить только для Германии , но здесь вы делаете иметь определенные права на частную жизнь , даже при работе на принадлежащих компании оборудования.
Конрад Рудольф

Ответы:


64

« Если он не находится в управлении источниками, он не существует ».

Это одна из немногих вещей в нашей профессии, о которой я догматична. По следующим причинам:

  1. Несмотря на то, что рабочая станция является собственностью компании, давайте посмотрим правде в глаза - есть неписаное правило, согласно которому собственная рабочая станция программиста является его / ее замком. Мне просто неловко с культурой рабочего места, где любой может регулярно заходить в нее и проходить через нее.
  2. У каждого свой поток (как вы и сказали). Попытка заставить всех разработчиков организовать свои собственные локальные рабочие пространства определенным образом может пойти вразрез с их особым образом работы, нарушить их поток и сделать их менее эффективными.
  3. Вещи, которые не находятся в контроле исходного кода, являются недоделанным кодом Если это полностью запеченный код, готовый к выпуску, он должен находиться в системе контроля версий. Который возвращается снова к главному пункту ....
  4. «Если он не находится в управлении источниками, он не существует».

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

Кроме того, проверка всех перед отъездом была обязательной .

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


10
+1: Кто-то болен, возиться на его рабочей станции, вероятно, будет дороже, чем стоимость. Один человек уже ушел. Теперь другой тратит время, пытаясь выяснить, что происходит. Огромный управленческий кошмар для бесполезных. Пока он не находится в управлении источниками, он никогда не существовал.
S.Lott

1
Если он на выходной? Да, для остальной части недели? Может быть, на месяц? Без шансов. Это одна из тех неприятных проблем «оттенков серого» ... мы снова вернулись к тому, чтобы фиксировать рано, часто делать коммиты - поэтому шаблоны не обязательно должны быть рабочими станциями, а использовать контроль версий, но, безусловно, это что-то стоит подумать
Murph

Когда вы говорите, релиз, вы имеете в виду релиз для сборки или релиз для пользователей?
JeffO

2
@Murph: Если изменения фиксируются где-то каждые X дней, максимальный объем работы, который может быть неуместен, стоит X дней, и это верно независимо от того, как долго разработчик неизбежно уходит. Правильно сделать так, чтобы у вас была достаточно частая политика регистрации, чтобы количество потерянной работы находилось в допустимых пределах.
Дэвид Торнли

1
@ Дэвид мой комментарий был ответом на @ S.Lott - с точки зрения аргумента о «потерянном». Ну вроде. Я хочу, чтобы коммиты были атомарными в смысле полного набора изменений (я начинаю понимать, почему rebase является настолько привлекательным понятием) - поэтому я вижу «коммит для сохранения» как проблемный (в общем случае и при отсутствии). из перебазированного эквивалента). И в любом случае должны быть ежедневные автоматические резервные копии рабочих станций, совершенно отличные от контроля версий.
Murph

22

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

Таким образом, никто не должен получать доступ к рабочей станции другого разработчика.

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


1
Как часто вы будете объединять филиал? Каждый раз, когда вы чувствовали, что это было стабильно?
Джон Хопкинс

2
@Jon Hopkins: «Releasable» легче управлять, чем «Stable». Releasable включает в себя стабильный, а также владелец продукта готов к этому. И вы сделаете много обработки от ветки к релизу. От ветки к конюшне слишком большой потенциал для субъективизма и обсуждения «сработало для меня».
S.Lott

2
-1 Я не согласен с этим без огромного количества квалификации, проверки должны происходить в логической точке, а не произвольно в конце дня. (Да, мы должны стремиться не оставлять, пока мы не дойдем до разумной точки останова, но жизнь не всегда сотрудничает.) Резервные копии должны быть разными. И все мы должны быть немного менее ценными в отношении доступа к нашим ящикам (не изменений в доступе )
Murph

1
-1 потому что это не относится к сценариям типа «Я чувствую себя действительно больным, я иду домой прямо сейчас. Хм, лучше просто сделайте еще 30 минут подготовки, чтобы не нарушать сборку, когда я фиксирую».
Гари Роу

2
@ Murph Checkins в 'trunk' или mainline (как бы вы это ни называли) должны происходить только так, как вы описываете. Тем не менее, нет ничего плохого в том, что разработчики «сохраняют свою работу в конце дня», передавая данные в личную ветку (хотя с git или mercurial это намного проще, чем с SVN). И по сравнению с приведением в исполнение рекомендаций по настройке рабочих станций разработчиков (что и послужило нашей отправной точкой), это совершенно нормальное решение.
Крис

6

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

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

Жаль, что они понятия не имели, что делают, и стерли прототип, над которым я работал последние два месяца.

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

Но не связывайтесь с рабочими станциями людей.

PS У нас есть соглашение по структуре каталогов, но основная причина его существования - это сочетание истории и конфигурации - поместите его куда-нибудь еще, и оно не будет компилироваться.


3
@Murph: «Заболеть», сопровождаемое срочной необходимостью получить что-то из его системы, - действительно редкая ситуация. Может не стоить усилий по стандартизации.

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

3
Нет резервной копии на этом прототипе?
JeffO

2
@ Разработчик искусства, почему вы не работали в ветке системы управления версиями?

1
@DeveoperArt, что вы имеете в виду "не используя эту опцию"? Вы имеете в виду, что у вас просто не было возможности создать ветку самостоятельно? Они как-то отключили разветвление? Я никогда не слышал об этой возможности. Тем не менее, вы могли бы создать свой собственный репозиторий «git» (или даже «svn») на своем локальном компьютере (возможно, для резервного копирования на Dropbox или сетевой диск) без участия кого-либо еще. Я просто не могу относиться лично к работе над чем-то в течение 2 месяцев (или даже 2 часов , действительно), «важно» или нет, и иметь только 1 копию этого.
JoelFan

6

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

К счастью, здесь принято (хотя и не «необходимо») хранить код /var/www/ourdomain.comдля имитации производства. Благодаря такому логическому и простому соглашению, коллеге было легко войти на мою машину и получить мои последние изменения.

Я думаю, что некоторые соглашения хороши. Хотя я согласен с Бобби, когда он говорит

«Если он не находится в управлении источниками, он не существует».

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


«... его не существует». Для других это так.

4

Первая часть вашего вопроса четко определяет проблемы общения в вашей команде. Вы пробовали ежедневные приемы ?

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

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

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

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

(Вся) команда решает, что делать.


2

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

Но главное - нет, я не хочу, чтобы на меня навязывали стандарты того, как я организовываю свою собственную рабочую станцию. В настоящее время я настаиваю на том, что мой отдел стандартизирует IDE (мой босс ДЕЙСТВИТЕЛЬНО хочет, чтобы мы все были в Eclipse, потому что это то, что он использует и хорошо знает, хотя IMO это не лучший инструмент для моей работы).

Пусть разработчики делают все, что им удобно. Удобный разработчик более продуктивен, чем неудобный. И если кто-то НЕ продуктивен, и вы подозреваете, что они используют инструменты локально, это возможность для обучения, а не время для разработки новых правил.


1
Как это поможет? Вопрос все еще будет существовать, мы будем просто говорить о том, какая ветвь в его локальном репозитории DVCS, а не какая рабочая область.
Джон Хопкинс

Не думайте, что это инструменты, а также понимание того, как лучше всего использовать инструменты, которых может не хватать. То, что очевидно для одних, нужно показать другим. Анти-шаблон множества копий исходного дерева я видел несколько раз. Да, DVCS может помочь - но в этом контексте у нас все еще будет проблема с определением правильной ветви и - если мы хотим пойти дальше - с доступностью этих ветвей Work In Progress. @ Локальная DVCS должна автоматически передать «резервную копию» этого хранилища этому пользователю. По крайней мере, если перенесет проблему из коробки.
Мерф

@Jon - Я думаю, дело в том, что его разнообразные ветви были бы в чем-то, что имело бы встроенную функциональность слияния, а не просто разбросанные каталоги расходящихся файлов. Кроме того, получить его и пойти на DVCS было бы возможностью для обучения.
Дэн Рэй

1
@Dan - Но некоторые из этих веток - тупики - доказательства концепции, вещи с различным отладочным кодом, которые вы не хотите объединять, старые версии. Тот факт, что у вас есть функция слияния, не помогает, когда вы не знаете, что вам нужно слить.
Джон Хопкинс

@ Джон - я думаю, это правда. Может быть, просто не оправиться от кого-то, кто действительно стремится устроить беспорядок.
Дэн Рэй

2

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

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

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


2

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

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

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

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

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


1
Я специально сказал в вопросе, чтобы предположить, что человек не может связаться.
Джон Хопкинс

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

Там есть логическое несоответствие - «вы не знаете, что делает ваш разработчик» против «вы должны делегировать», что означает, что вы знаете, что он делает, но, возможно, не как - что, в свою очередь, является причиной того, почему вам нужно разобраться в коде ... (да, общение может помочь разобраться в этом, но если вы доверяете своим разработчикам решить проблему и ее небольшую проблему - для данного разработчика - тогда «иди исправьте это, пока!» может быть столько же управления, сколько и требуется).
Murph

@ Murph, затем соблюдайте правило «частая фиксация - в ветке» и переходите в центральное положение хотя бы ежедневно.

1

Так как вы справляетесь с такими ситуациями?

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

Или вы просите разработчиков придерживаться стандартов в этой области - использования определенных каталогов, стандартов именования, заметок в вики или чего-то еще?

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.