OO 프로젝트에서 팀 작업은 어떻게 이루어 집니까? [닫은]

나는 스스로 OO 스타일로 Java로 프로그래밍하고 있습니다. 다른 프로그래머와 함께 일할 기회가 없었습니다 (최소한 아직 전문가는 아닙니다).

호기심으로, 나는 묻고 싶었습니다. 특히 OO 프로젝트를 수행 할 때 팀과 함께 프로젝트를 수행하는 방법은 무엇입니까?

분할 작업은 어떻게 작동합니까? 다른 프로그래머가 개발 한 것과 성공적으로 작동하는 것을 어떻게 개발합니까? 프로그래머는 언제 어떻게 의사 소통을합니까?

감사

잘만되면 나는 당신을 조금 도울 수 있거나 적어도 올바른 방향으로 당신을 가리킬 수 있습니다!

약간의 면책 조항이지만, 그것은 큰 주제입니다. 그리고 나는 정말로 깊이 이해하기 위해 " 던지기 " 가 필요하다고 생각합니다 . 즉, 두 가지 주요 문제에 대해 간략히 설명하겠습니다.

1. 코드와 소스 컨트롤
2. 커뮤니케이션과 팁.

OOP 프로젝트와 관련하여-다른 곳에서는 존재하지 않는 OOP 관련 문제를 솔직히 볼 수 없습니다.

실제로 OOP 스타일 프로그래밍은 팀 개발에 매우 ​​적합하다고 생각합니다. OOP의 한 가지 핵심 개념은 내가 상호 작용하는 모든 개체에 대한 모든 세부 사항을 알아야 한다는 것입니다. 수행 할 수있는 작업과 수행 방법 을 알아야 합니다.

OOP가 제공 할 수있는 추상화는 팀에서 훌륭합니다.

소스 컨트롤

프로젝트를 저장하려면 중앙 위치가 있어야하며 여러 개발자가 한 번에 코드베이스에 액세스 할 수있는 곳이 있어야합니다. 여기서 Git (또는 SVN)과 같은 시스템이 작동합니다.

SVN을 사용한 적이 없기 때문에 Git에 대해서만 구체적으로 말할 수 있습니다. 그러나 그것들은 비슷하지만 용어가 다릅니다.

Git을 사용하여 주어진 프로젝트에 대한 모든 소스 코드로 저장소를 만든 다음 팀이 저장소에 액세스 할 수 있습니다. 그런 다음 모든 기능 또는 버그 수정에 대해 개별 개발자는 자체 "분기" 를 만들 수 있으며 이는 병렬 트랙에서 개발이 발생할 수 있음을 의미합니다.

기능이나 수정이 완료되면 다시 기본 프로젝트의 코드베이스에 " 병합 " 될 수 있습니다 . 그런 다음 Git은 모든 " 충돌 "을 감지하고 책임이있는 개발자가 소스 수준에서 해결할 수 있습니다.

이전에 Git을 사용했는지는 확실하지 않지만 처음에는 상당히 복잡해 보일 수 있지만 최근 인기 ( Github ) 덕분에 많은 자습서와 리소스가 있습니다.

이전에 사용하지 않은 경우 GitHub에 가입하여 그런 식으로 느끼는 것이 좋습니다. (또는 Bitbucket 도 비슷한 대안이지만 개인 저장소를 무료로 사용할 수 있습니다.)

Git Flow 는 훌륭한 Git 기반 작업 흐름으로, 팀에게 매우 유용합니다. 일반적으로 Git과 마찬가지로 잠시 동안 작업하면 팀이 없으면 팀에서 일하는 것을 상상하기가 어렵습니다!

연락

모든 기술적 장벽을 넘어 서면 대부분의 프로젝트 (기술적이든 아니든)를 괴롭히는 근본적인 문제로 귀결됩니다. 이것이 바로 의사 소통입니다.

전체 팀은 누가 무엇을하고 있는지, 언제 무엇을하고 있는지, 그리고 어떤 영향을 미치는지 알고 있어야합니다.

책임을 명확하게 정의해야합니다

이것은 명백하지만 대부분의 프로젝트는 특정 형태의 티켓팅 시스템을 사용합니다. 여기서 기능 요청이나 버그가 기록 된 다음 특정 직원에게 할당됩니다. ( JIRA , Unfuddle 등) 종종 소스 컨트롤 시스템에 내장되어있어 삶을 조금 더 단순하게 만듭니다. (BitBucket과 GitHub는 둘 다 호스팅되는 Git 리포지토리에 대한 문제 추적을 제공합니다.)

이렇게하면 개발자가 실수로 동일한 문제에 대해 작업을 중지하거나 방지 할 수 있습니다.

이것은 완전한 수정이 아닙니다. 개발자가 다른 개발자의 책임에 대해 알고 있는지 확인해야합니다. 나는 과거에 특정 버그를 수정하는 과정에서 우연히 발견 된 다른 문제를 해결했다는 것을 알고 있습니다. 순전히 말이됩니다. ( " 음, 나는 이미 여기 있습니다. 이것은 리 팩터와 관련이있을 수 있으며 아마도 다른 문제를 확인할 수 있습니다. ") 그런 다음 다른 개발자가 내가했던 다른 문제에 대해 작업 할 때 사과해야했습니다. 고정-우리 시간을 낭비.

일반적으로 이러한 문제는 다음과 같이 해결할 수 있습니다.

정기 회의

일부 프로젝트 관리 / 개발 방법론은 특정 의사 소통 방법 또는 회의 간격을 나타냅니다. 일반적으로 내가 본 가장 생산적인 시스템은 팀의 모든 사람이 자신이하는 일을 빠르게 정리할 수있는 모닝 스탠딩 미팅이었습니다. 개발 팀 멤버에게만 제한하고 무엇에 대한 명확한 지침이있는 경우 의사 소통하기 위해 이것들은 엄청나게 효과적 일 수 있습니다. 나는 항상 고집하려고 노력했다.

저는 X에서 일하고 있습니다.

Y를 달성 / 수정하려면

Z 수정 / 수정이 필요합니다.

다른 팀원들은 " Fergus는 다른 날에 기록 된 버그를 고치기 위해 노력하고 있습니다. 그러나 그는 그가 살펴 봐야하는 코드를 작성하고 있다는 것을 의미합니다. 변경하기 전에 그와 함께 확인하겠습니다." ".

건축 회의

나는 최근 에 더 큰 / 건축 적 문제가 논의 될 이틀간 " 기술 채팅 " 을하는 훌륭한 팀과 함께 일했습니다 . 팀의 모든 구성원은 프로젝트가 직면 한 더 큰 문제를 이해하고 잠재적 인 해결책을 논의 할 시간을 가졌습니다.

나는 개인적으로 이것을 좋아했고, 프로젝트를 처음 접했을 때 많이 기여하지는 않았지만 토론을들을 수 있으면 많은 통찰력을 얻었습니다. 곧 프로젝트와 개인의 사고 스타일을 이해할 수있었습니다.

커뮤니케이션은 모든 팀을 무너 뜨릴 수있는 문제입니다 . 기술적이든 아니든 사람들이 더 큰 그림을 알지 못하면 실패 할 가능성이 더 큽니다.

다른 문제

팀에서 작업 할 때 모든 사람이 동일한 구성 또는 스타일을 갖도록하는 것이 좋습니다. 무슨 뜻이야?

구성

Java 프로젝트에서 작업하는 경우 (개발 환경의 경우 적어도 테스트 환경이 아닌지) 확인하십시오. 팀에서 JVM 버전이 일반적이라고 생각하는 것이 좋을까요? 그런 다음 IDE. 전체 팀이 Eclipse 또는 NetBeans 또는 선택한 IDE를 사용하는 경우 주로 도움이됩니다 .

웹 프로젝트에서는 모든 개발자에게 특정 스택이 필요할 수 있습니다. 특정 아파치 또는 PHP 버전.

이와 같은 요소를 생각하면 팀이 제 생각에 좀 더 빨리 "젤"을 쓸 수 있습니다.

스타일

탭 대 공백? CamelCase 또는 spacing_with_underscores? 혼자서 일할 때, 더 큰 팀과 함께 일할 때, 공통된 스타일을 향해 노력하고 싶을 때 이러한 질문은 아주 작습니다.

당신은 알고 있어야합니다 - 사실, 당신은 정말 코드의 특정 섹션을 쓴 말할 수 안 자신이 속한 .

그렇기 때문에 많은 오픈 소스 프로젝트가 소스 코드 형식 가이드 라인 / 스타일 가이드를 공개적으로 게시하는 이유가 여기에 포함 됩니다. 오픈 소스 프로젝트에 대한 Google StyleGuides 를 살펴보십시오 .

작업 및 단위 테스트

팀에만 국한되지는 않지만 특히 한 가지 이유 때문에이 문제에 빠르게 다룰 것입니다. 팀 생활을 훨씬 쉽게 만들어줍니다.

종속성이 많거나 빌드 프로세스가 긴 복잡한 워크 플로가있는 경우 작업 러너를 사용하여이를 자동화하는 것이 유용한 경우가 많습니다. 웹 프로젝트의 경우 Java에서 제공되지만 GruntJS 는 훌륭 합니다 .Apache Ant 는 매우 비슷할 것입니다.

FTP 서버에 사이트를 배포하기 전에 GruntJS 를 사용 하여 사이트를 구축 하는 개인으로서 하나의 Grunt 명령 만으로 CSS / Sass 를 컴파일하고 축소 하고 자산을 압축 한 다음 파일을 업로드 할 수 있습니다.

팀원으로서 GruntJS를 사용하여 테스트를 중단하지 않았는지 확인하고 프로젝트의 다른 부분에 대해 완전히 알지 못하여 버그를 도입하지 않았는지 확인할 수 있습니다. 물론 이것은 개별 개발자로서의 이점에 추가됩니다.

멋진 소스 제어 패키지 (Git)를 사용하여 프로젝트를 복제하고 하나의 명령을 실행하여 모든 종속성을 설치하기 위해 사용할 수도 있습니다. 익숙하지 않은 코드베이스에 익숙해지기까지 걸리는 시간을 고려하지 않고도 실제로 개발자가 실제로 개발을 시작할 수있는 위치로 새로운 개발자를 데려가는 데 소요되는 시간이 길어지기 때문에 이는 큰 이점입니다.

선적 서류 비치

내가 본 최고의 프로젝트는 개발자를 겨냥한 문서화 (그리고 종종 과도한)를 가지고 있습니다. 이러한 종류의 문서는 다음과 같은 것을 설명 할 수 있습니다.

1. 개발 환경 :

"우리는 현재 LAMP 스택을 실행하는 서버에 배포하고 있습니다. 개발자는 여기에 설명 된 버전을 대상으로해야합니다."

2. 작업 흐름

"모든 기능은 'feature / *'지점에서 개발되고 릴리스 준비된 것으로 간주되기 전에 'testing'지점으로 병합됩니다."

3. 팀의 책임 :

"데이터베이스 문제는 Steve와, 플랫폼 문제는 David와 대화하십시오."

4. 미래를위한 " 파이프 라인 "

"새로운 코드를 개발할 때 2014 년 6 월 현재 x 를 구현하려고 합니다.이 문제가 발생하기 전에 레거시 코드를 검토해야 할 수도 있습니다."

예

오픈 소스 프로젝트의 워크 플로우를 살펴보고 자신의 워크 플로우가있는 확립 된 워크 플로우인지 (많은 문서화되어 있는지) GitHub의 많은 예제 중 하나인지 여부에 대한 느낌을 얻으십시오.

마지막 경고

이 모든 일을 제대로 수행하는 팀에서 일하고 있다면 다른 곳을 싫어하는 것입니다 ..! 좋은 팀을 경험하고 나면 갑자기 다른 곳에서 문제 가 발생하여 실제로 당신을 끌 수 있습니다. (그러나 그것은 다른 게시물에 대한 이야기입니다!)