개발자가 자신의 워크 스테이션에서 작업하는 방법에 대한 표준

우리는 프로젝트 도중 며칠 동안 개발자가 아플 때 때때로 나타나는 상황 중 하나를 발견했습니다.

그가 최신 버전의 코드를 커밋했는지 또는 로컬 컴퓨터에 최신 코드가 있는지 여부에 대해 몇 가지 질문이 있었으며 고객에게 대기 중이 어서 기다릴 수 없었습니다. 그에게 돌아온다.

다른 개발자 중 한 명이 같은 프로젝트의 겉보기에 작업 공간의 혼란을 발견하고 발견 한 타임 스탬프를 사용하여 어느 것이 "현재"인지 확실하지 않은 타임 스탬프를 발견했습니다. 그의 "핵심"하나).

분명히 이것은 목에 통증이지만, 대안 ( 다른 개발자가 최소한의 노력으로 물건을 집어들 수 있도록 각 개발자가 자신의 컴퓨터 에서 작업하는 방법에 대한 엄격한 표준 인 것처럼 보일 것 입니다 )은 많은 것을 깨뜨릴 수 있습니다 개발자 개인의 업무 흐름과 개인 수준의 비효율로 이어집니다.

나는 체크인 코드의 표준이나 일반적인 개발 표준에 대해 이야기하지 않고 개발자가 로컬에서 작동하는 방식, 일반적으로 (내 경험상) 거의 완전히 개발자 자신의 통제하에 있다고 간주되는 도메인에 대해 이야기하고 있습니다.

이런 상황을 어떻게 처리합니까? 방금 발생하는 문제 중 하나 인 개발자에 대해 지불하는 가격이 개발자에게 가장 적합한 방식으로 작업 할 수 있습니까?

또는 특정 디렉토리 사용, 표준 이름 지정, 위키에 대한 노트 등이 영역의 표준을 개발자에게 따르도록 요청합니까? 그렇다면 귀하의 표준이 무엇을 다루는가, 얼마나 엄격하고, 어떻게 경찰 등을 감시합니까?

아니면 다른 해결책이 있습니까?

[메모리에서 어떤 작업 공간이 단순하고 결함이 없으며 때로는 사람들이 진정으로 할 수 있는지를 알고 설명 할 수 있더라도 개발자가 여기에서 무엇을하고 있는지 이야기하기 위해 연락 할 수 없다는 주장을 가정하십시오. 연락하지 않고 모든 상황을 다루는 솔루션을 원합니다.]

편집 : 나는 누군가의 워크 스테이션을 통과하는 것이 나쁜 형태라고 생각합니다 ( 왜 그런지에 대한 흥미롭고 주제가 아닌 다른 질문이지만) 나는 무제한 액세스를 보지 않을 것입니다. 코드 디렉토리가 읽기 전용 공유로 설정된 표준 라인을 따라 더 많은 것을 생각하십시오. 아무것도 변경할 수 없으며 다른 것도 볼 수 없습니다.

" 소스 제어에없는 경우 존재하지 않습니다. "

이것은 내가 교리 적으로 경계하는 우리 직업에서 몇 가지 중 하나입니다. 다음과 같은 이유로 :

1. 워크 스테이션은 회사의 자산이지만 직면 해 봅시다. 프로그래머 자신의 워크 스테이션이 자신의 성이라는 기록되지 않은 규칙이 있습니다. 누구나 일상적으로 로그온하여 사용할 수있는 직장 문화가 불안합니다.
2. 모두가 자신의 흐름을 가지고 있습니다 (당신이 말했듯이). 모든 개발자가 자신의 로컬 작업 공간을 특정 방식으로 구성하도록 강요하면 특정 작업 방식에 위배되고 흐름이 깨져 효율성이 떨어질 수 있습니다.
3. 소스 컨트롤에없는 것은 반-베이크 코드입니다. 출시 준비가 된 코드가 완전히 구워지면 소스 제어 상태에 있어야합니다. 다시 요점으로 돌아옵니다 ....
4. "소스 제어에없는 경우 존재하지 않습니다."

사람들의 워크 스테이션에서 코드를보고자하는 문제를 완화 할 수있는 한 가지 방법은 정기적 인 체크인 문화를 조성하는 것입니다. 나는 공식적인 명령이 없었음에도 불구하고 회사에서 한 번 근무했는데, 주말 동안 모든 것이 항상 체크인되는 것이 자랑 스러웠습니다. 유지 보수 및 릴리스 후보 단계에서 CR 항목은 작고 깨끗하게 눈에 띄는 변경 사항과 정기적 인 체크인을 통해 추적 할 수 있도록 의도적으로 매우 세분화되었습니다.

또한 휴가를 가기 전에 모든 것을 체크인 해야 합니다.

TL; DR 버전 : 사람들의 워크 스테이션을 통한 리프팅은 잘못된 형태입니다. 사람들의 워크 스테이션을 통해 원하는 것을 쉽게 찾을 수있는 문화를 조성하기보다는 합리적인 소스 제어 사용과 정기적 인 체크인 문화를 육성하는 것이 좋습니다. 프로젝트의 중요한 단계에있을 때 규칙적인 체크인과 세밀한 작업까지도 가능합니다.

개발자가 워크 스테이션을 구성하는 방법에 대한 표준을 시행하기보다는 매일 모든 작업이 체크인되는 표준을 시행하십시오 . 체크인이 아직 완료되지 않은 경우 지점에 도착할 수 있습니다.

이렇게하면 아무도 다른 개발자의 워크 스테이션에 액세스 할 필요가 없습니다.

나는이 정책이 반대에 부딪 힐 것이라고 생각하지만, 워크 스테이션 구성에 대한 규칙을 시행 할 때 기대하는 것과 비교할 수있는 것은 없다.

누군가가 내 컴퓨터에 로그인하여 내 정보를 탐색 할 것이라는 생각에 대해 불안하다고 느끼는 진실을 말씀 드리겠습니다. 물론, 그것은 회사의 장비와 재산이지만, 단순히 나쁜 일입니다.

지난 주말에 사람들은 데이터베이스와 소스 제어를 사용하여 서버를 재구성했으며 어떤 이유로 든 내 컴퓨터에 로그인하고 새로운 설정을 위해 시스템을 재구성해야한다고 생각했습니다.

너무 안타깝게도 그들이 무엇을하고 있는지 전혀 몰랐으며 지난 2 개월 동안 작업했던 프로토 타입을 지 웠습니다.

적절한 의사 소통이 이루어 졌다면 일어나지 않았을 것입니다. 그게 당신이 필요로하는 것입니다. 해당 개발자에게 문의하여 상태를 확인하십시오. 더 좋은 방법은 휴가를 떠나기 전에 사람들에게 보고서를 요청하여 필요한 정보가 있는지 여부에 대한 정보를 바탕으로 결정을 내릴 수 있도록하는 것입니다.

그러나 사람들의 워크 스테이션을 엉망으로 만들지 마십시오.

추신 : 우리는 디렉토리 구조에 대한 관습을 가지고 있지만 주된 이유는 역사 / 구성이 혼합되어 있기 때문에 다른 곳에두면 컴파일되지 않습니다.

몇 달 전에 나는 다소 큰 프로젝트를 진행하고 있었고 병원에 입원 한 것을 알면서 갑자기 직장을 떠나야했습니다. 프로젝트의 최신 코드를 확인할 시간이 없었습니다.

운 좋게도, /var/www/ourdomain.com프로덕션을 모방하기 위해 코드를 저장하는 것이 (필수는 아니지만) 관습 입니다. 이러한 논리적이고 따르기 쉬운 규칙을 통해 동료는 내 컴퓨터에 로그인하여 최신 변경 사항을 쉽게 검색 할 수있었습니다.

나는 몇 가지 규칙이 좋다고 생각합니다. 그가 말할 때 Bobby에 동의하지만

"소스 제어에없는 경우 존재하지 않습니다."

또한 프로그래머 작업 공간에 유용한 추가 기능은 모든 소스 및 개발 프로젝트를 저장하는 전면 베이 핫 스왑 SATA 드라이브 일 수 있습니다. 이러한 방식으로 이러한 문제점이 발생하면 직원은 개발자 워크 스테이션에 로그인 할 필요없이 프로젝트의 새로운 소스 변경 사항을 쉽게 검색 할 수 있습니다.

질문의 첫 부분은 팀 내 의사 소통 문제를 명확하게 식별합니다. 매일 스탠드 업 을 시도 했습니까 ?

표준이 너무 엄격한 경우 비 효율성을 초래할 수 있다고 말하면 동의합니다. 표준은 모두가 참여 하는 팀에 의해 정의되어야합니다 .

귀하의 경우, 관련 개발자가 직장에 돌아온 후 며칠을 기다릴 것입니다. 그런 다음 해당 표준에 대해 이야기 할 회의를 조직하십시오.

심리적 차단과 저항을 피하기 위해 본 사람이나 특정한 것을 지명하지 마십시오. 일반적으로 여기에서 목표는 작업 방식을 개선해야한다고 생각하는 개발자를 포함하여 모든 사람으로부터 의견을 얻는 것입니다. 그 사람은 당신의 조직도 엉망으로 생각할 수 있습니다.

회의 중에 문제를 제시하고 팀 이 어떻게 상황을 개선 할 수 있는지 명확하게 묻습니다 .

(전체) 팀 이해야 할 일을 결정합니다.

해당 사용자는 적절한 도구가 부족할 수 있습니다. 특히, 분산 버전 제어 시스템을 사용하면 다른 상태의 다른 코드 디렉토리를 가질 필요가 없어졌습니다. 그는 모든 것을 가지에두고 훨씬 더 행복했을 수있었습니다.

그러나 요점으로, 나는 내 자신의 워크 스테이션을 구성하는 방법에 대한 표준을 시행하고 싶지 않다. 저는 현재 IDE에서 표준화하는 부서에 대해 추진하고 있습니다 (내 상사 REALLY는 IMO가 내 작업에 가장 적합한 도구는 아니지만 사용하고 잘 알고 있기 때문에 Eclipse에서 우리 모두를 원합니다 ).

개발자가 편안하게 할 수있는 모든 작업을 수행하십시오. 편안한 개발자는 불편한 개발자보다 생산적입니다. 누군가 생산적이지 않고 도구를 사용하여 현지에서 어려움을 겪고 있다고 생각되면 새로운 규칙을 세우기에 좋은 시간이 아니라 훈련의 기회입니다.

예전 작업장에는 버그 추적의 각 작업에 소스 제어의 자체 분기가있는 시스템이있었습니다. 대부분의 경우 하나의 버그 / 태스크가 한 명의 개발자에 의해 찌그러져 서 깨진 코드를 소스 제어에 체크인 할 수있는 것으로 이해되었습니다.

코드가 개발 브랜치에서 안정적인 상태가되면 통합하려는 브랜치에서 코드를 드래그하여 리베이스를 수행했습니다. 해당 병합을 테스트 한 후에는 코드를 통합 브랜치에 커밋하는 경우 일뿐입니다. 브랜치에서 이미 병합을 수행 했으므로 병합 할 필요가 없습니다.

이런 식으로, 당신은 깨진 코드를 커밋하는 것에 대해 걱정하는 개발자의 문제를 피할 수 있습니다-그리고 당신은 밤에 사무실을 떠나기 전에 코드를 체크인하는 것이 허용되는 사회 정책을 적용하기 시작할 수 있습니다-멋지고 안전합니다.

에서 이 특정 상황 호출 집에서 사람, 당신은 그가 병이 있음을 의심하지 않는 것을 매우 명확하게하지만 당신은 다른 사람이 자신의 일을 계속하고 최신 물건이 어떤 상태에 어디에 문의해야합니다.

그런 다음 여기에서 수행 할 작업을 고려해야합니다. 사람들이 너무 체크인하지 않는 것이 문제라면 사람들이 서로 방해하지 않고 지점에서 일할 수있는 분산 소스 제어 시스템을 사용하는 것이 좋습니다.

문제는 개발자가 자신의 컴퓨터에 여러 개의 작업 공간을 가지고있는 것을 좋아하지 않는다면 극복하십시오. 작업 스타일은 개인마다 다르며 소스 리포지토리의 규칙에 따라 제대로 작동하는 한 기본적으로 시스템에서 멀리 떨어져 있어야합니다. 개인적으로 다른 프로젝트에 대해 새 사본을 매우 자주 확인하고 한 번에 한 번 씩만 정리합니다.

문제가 개발자가 무엇을하는지 모르는 경우 문제는 정치적이지 않은 정치적 문제이므로 관리 스타일을 변경해야합니다. 개발자는 소량 관리를 거의 좋아하지 않으며 위임 해야하는 숙련 된 개인입니다 . 그렇지 않으면 가장 숙련 된 사람들을 밀어 내게됩니다.

따라서 공통 소스 리포지토리를 사용하는 더 나은 방법을 장려하는 것이 좋습니다. 사람들이 브랜치에서 작업하는 것이 좋으며 매일 로컬 리포지토리를 마스터 리포지토리에 동기화하는 한 자주 커밋 할 수 있도록합니다. 항상 다른 부서에 영향을 미치지 않는 지점에서 개발 작업을 수행합니다).

이런 상황을 어떻게 처리합니까?

불안정한 개인 브랜치를 지원하는 소스 제어 시스템과 빈번한 커밋을 유지하여이 문제를 해결할 수 있습니다. 전체 문제가 해결 될 때 커밋이 필요하지 않습니다. 소스 제어의 혜택을 누릴 때마다 제공되어야합니다. 하루의 끝은 커밋이 발생해야 할 시점 중 하나이므로 변경 사항이 발생한 위치를 확인하고 백업하고 미래의 자기 자신 또는 다른 사람에게 설명 할 수 있습니다.

또는 특정 디렉토리 사용, 표준 이름 지정, 위키에 대한 노트 등이 영역의 표준을 개발자에게 따르도록 요청합니까?

규약을 나타내는 거대한 환경 구성 문서가 있지만 표준은 아닙니다. 표준은 프로덕션 코드 및 환경에 대한 것입니다. 그러나 많은 개발 도구는 컨벤션을 지원하도록 설정되어 있으며 대부분의 개발자는 이러한 추세를 극복하기 위해 노력하지 않습니다.