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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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