앞으로 한 사람 프로젝트에서 팀 프로젝트로 이동. 지금 무엇을 준비하고 있으며 무엇을 기다릴 수 있습니까?

좀 더 정교하게 설명하기 위해 사람들이 여전히 한 사람 프로젝트 (팀 소스 제어, 문서, 빌드 등)를 통해 배치해야한다고 생각하는 것과 두 번째 사람이 올 때까지 수행 할 필요가없는 것을 알고 싶습니다. 프로젝트에.

이 시나리오를 경험 한 사람이라면 누구나 통찰력을 얻을 수 있습니다.

내가 배운 것. (다른 순서를 시도했습니다. 틀 렸습니다. 이것은 관련성이있는 순서입니다.)

1. 모든 것을 소스 코드 제어에 넣으십시오. 모든 사람이 액세스하고 바로 시작할 수있는 것을 사용하십시오 . 예외 없음. 지연이 없습니다. 변명하지.

2. 개인 "작업"또는 "개발"환경과 완전히 다른 QA / 테스트 영역을 만듭니다. 최소한 별도의 사용자 ID. 별도의 VM에 이상적입니다.
   완전히 분리됩니다. 현재 작업 환경과 겹칠 수 없습니다.

3. 자신의 작업 환경에서 단위 테스트 이상의 테스트를 중지하십시오. 코드 및 단위 테스트는 "직접"수행합니다. 별도의 VM에서 수행하는 다른 모든 테스트 (통합, 성능 등) 스스로 테스트하지 마십시오. 항상 별도의 QA 사용자로 테스트하십시오. 별도의 VM에 이상적입니다.

   "저를 위해 일하십시오"는 당신의 팀원에게 말해야 할 나쁜 일입니다. 아주 나쁜. 그들이 뭘 잘못하고 있는지 알아 내야합니다. 하루에 여러 번.

4. 모든 것을 적어 두십시오. 모든 문서가 버전 제어 저장소에 일반 텍스트가되도록 일반 텍스트 마크 업 도구 (RST 또는 Markdown 또는 기타)를 사용하십시오. 도구를 사용하면 HTML 페이지 (예 : RST 용 Docutils) 또는 PDF 또는 가장 적합한 것을 만들 수 있습니다. 독점 문서 형식 (예 : MS-Word)을 사용하지 마십시오. 일부 소스 코드 제어 시스템에서는 제대로 작동하지 않을 수 있습니다.

5. 가장 먼저 기록해야 할 것은 다음과 같습니다.

   • 작업 개발 환경을 만드는 방법 확실하지 않은 경우 가상 머신을 작성하고 해당 가상 머신에서 전체 조작을 수행하십시오. 단계가 실제로 작동하고 설명서가 명확해야 합니다. 실제 줄은 실제 명령 줄에서 명확하게 입력했습니다.

   • 단위 테스트 스위트를 실행하는 방법 다시. 지침이 작동하고 생각할 필요가 없는지 확인하십시오. "이것을 입력하십시오 :" "확인하십시오 :"종류의 물건. 팀원이 바보가 아닙니다. 당신이 그것을 모두 쓰지 않으면 가정하는 것을 기억하지 못합니다.

   • 통합 테스트 스위트를 실행하는 방법

   아키텍처 또는 디자인 원칙을 설명하는 데 많은 시간을 낭비하지 마십시오. 먼저 누군가를 가동시켜야합니다. 나중에 설명 할 수 있습니다.

6. 다음으로 문서화 할 내용은 사용자 스토리입니다. 그리고 그 이야기를 뒷받침하는 테스트 사례. 그리고 사용자 사례를 지원하는 테스트 사례에 필요한 데이터 픽스처.

   이것을 공유 할 것입니다. 소스 코드 제어하에 있습니다.

7. 결국 다른 4 가지 뷰를 문서화 할 수 있습니다.

   • 논리적 관점은 문서화에 도움이됩니다. 여기에 그림이 허용됩니다. 이는 빠르게 발전하는 경향이 있으므로 기존 정보를 캡처하는 데 시간을 소비하지 마십시오. 팀원과 협력 할 수있는 방법을 찾으십시오.

   • 프로세스 뷰는 종종 도움이됩니다. 전체 응용 프로그램에 따라 이것이 얼마나 중요한지에 따라 다릅니다.

   • 개발 뷰 (모듈, 라이브러리, 프레임 워크 등)는 종종 비공식적으로 설명됩니다. 그림이 도움이 될 수 있지만 누군가가 문서를 집어 들고 머리 나 꼬리를 만들 수있을 정도로 충분히 완성하기는 어렵습니다. 오랫동안 설립 된 매우 공개적인 프로젝트에도 단순히 무시되는 라이브러리 문서가 있습니다. (많은 스택 오버플로 질문으로 이어지고 있습니다.)

     비공식적으로 받아 들일 수있는 것 외에도 이것은 빠르게 변하는 경향이 있습니다.

   • 배포 정보. 서버. IP 주소. 데이터베이스 자격 증명. 그 모든 것들을 기록 해야합니다 . 결국.

도구 및 방법론

성공적으로 협업하고 생산적이 되려면 무엇이 필요합니까?

• 프로젝트의 부품 / 구성 요소 식별 : 서로 다른 부품 (데이터베이스, 데이터 액세스 계층, 웹 사이트, 서비스, API, 테스트 프로젝트, 빌드 스크립트 등)과 환경 (개발, 스테이징, 프로덕션)을 명확하게 구분하고 이름을 지정합니다. 구두 및 서면 의사 소통 (문서, 프로젝트 이름 등)에 지속적으로 영향을 미칩니다.
• 아직 그렇지 않은 경우를 대비 하여 소스 코드 관리 시스템을 사용하십시오 . 프로젝트 및 설정에서 분기를 사용하는 방법에 대해 생각하십시오.
• 빌드 자동화 -소스 리포지토리에서 환경을 가능한 한 쉽게 설정할 수 있습니다.
• 테스트 프로젝트 는 적어도 더 복잡한 프로젝트의 경우 큰 프로젝트에서 필수입니다.
• 프로젝트를 사용할 준비가 된 준비 환경을 사용하십시오 . 또한 자동 스테이징 설정을위한 샘플 데이터를 작성하고 유지 보수하십시오.
• 개발 우선 순위를 정하고 계획을 세우는 데 도움이되는 버그 추적 시스템 을 사용하고 과거 버그 및 해결 방법에 대한 메모리 역할도합니다.
• 프로젝트의 각 부분을 문서화 하십시오. 나는 개인적으로 좋아한다 : 개요-아키텍처-종속성-구성-일반적인 문제 ( 여기에서 ). 문서가 오래되지 않도록 간결하게 작성하고 문서가 일상 활동의 일부가되도록하는 것이 좋습니다.

관리 / 팀워크

... 또는 대인 관계 수준의 다른 것

• 다른 개발자에 대한 기대치 를 정의하십시오 . 적어도 처음부터 옳지 않은 것처럼 아무도 당신과 같은 참여와 열정을 가져 오지 않을 것입니다. 당신이 기대하는 것과 그렇지 않은 것을 전달하고 당신과 다른 사람의 책임을 정의하십시오. 모든 사람이 엔지니어, 건축가, 개발자, dba 및 sysadmin 인 것은 아니지만 원하는 것이 맞는 사람을 선택하면 실망 할 것입니다.
• 처음에 , 정확하게 작업을 정의 하고, 검토를하고 결과를 논의한다. 점차적으로 마이크로 관리를 시작하십시오. 아이디어는 신뢰를 쌓고 책임을 높이는 것입니다.
• 프로젝트 계획 , 프로젝트 및 다음 해에 팀을위한 목표를 설정합니다. 적어두고 나중에 확인하면 관점 이 나타납니다 . 그 목표는 또는 (가 목표입니다만큼 다른 사람에게 전달되지 않을 수 있습니다 당신이 아니라 다른 사람을 달성하는 데 필요한)는, 단순히 자신의 체크리스트가 될 수 있습니다.
• 새로운 개발자 의 첫 달 (또는 2/3 개월) 을 준비하고 계획 하는 데 하루가 걸립니다 . 나는 잘 준비된 사람들과 일할 때 그것이 매우 동기 부여가된다는 것을 안다. 아무도 자신의 시간이 낭비되었다는 인상을받지 않아야합니다.
• 가자 . 그것은 당신의 아기입니다. 다른 사람도되어야합니다. 적어도 프로젝트의 일부에서는 다른 사람이 당신보다 더 나은 전문가가되도록하십시오. 이것은 실제로 당신이 성공했다는 것을 의미합니다.
• 듣기 - 당신이 그녀를 고용하는 경우, 그녀는 할 말이 있어요. 배울 준비를하십시오.
• 지식과 경험 을 공유 할 준비를하십시오 (따라서 시간이 오래 참 아야합니다).
• 실수 가있을 것입니다. 그것이 어떻게 처리되고 모든 사람들이 그들에 대해 배우는 것이 중요합니다.
• 배우고 실험 할 시간을 준다

도서 참조

필자는 실제로 읽은 일반적으로 언급되는 책 중 일부를 나열 하고 더 자세한 설명이나 더 많은 책을 위해 읽을만한 가치가 있다고 생각합니다. 이것 또는 이 질문.

이 책은 팀, 조직 및 프로그래밍 프로젝트와 관련하여 실제로 읽을 가치가 있습니다.

• 피플웨어
• 신화적인 남자 달
• 소프트웨어 예측, 블랙 아트의 미스터리

이 중 어느 것도 방법론 X를 구현하는 방법에 대한 실질적인 안내서는 아닙니다 (소프트웨어 추정을 제외하고이 책은 적절한 추정 프로세스를 선택하는 데 도움이됩니다). 물론 Code Complete와 같은 프로그래밍 자체에 중점을 둔 책들도 매우 풍부합니다.

나는 경험에서 이야기하지만 모든 사람이 다르다는 것을 명심하십시오. 이것들은 보편적이지 않습니다.

한 가지는 개인적으로 보내도록하는 것입니다. 이 프로젝트는 당신이 18 개월 동안 함께 살았으며, 모든 변화가 자연스럽게 이루어 지길 원할 것입니다. 동료가 실수하고 배우도록 버퍼를 제공하십시오. 그들에게 유용한 공간을 만드십시오. 그리고 바로 일어날 수 없다는 것을 명심하십시오. 또한 개선 또는 생성에 성공할 수있는 코드의 일부인 단기간에 성공한 것처럼 느껴지는 것이 있다면 좋을 것입니다. 인내와 관용은 여기서 좋은 대가를받습니다. 미시적 관리를 시도하지 말고 비판하고 싶을 때 "너는 틀렸다"고 말하고 장점이 있는지 확인하고 증명할 수 있으며 "종교적"싸움이 아니다.

또 다른 중요한 문제는 당신에게 맞는 사람을 찾는 것입니다. 자신보다 똑똑한 사람을 찾는 것이 가장 좋습니다. 그것은 주관적이고 친근하지만, 당신이 가지고 있지 않은 지식과 기술을 가진 사람이 있다고 생각한다면, 그것은 최선입니다. 상호 보람있는 협력이 될 것입니다.

두 가지 방법이 있습니다-동료는 드래그가 될 것이고, 당신은 그 사람이 한 일을 다시하게 될 것입니다. 그렇지 않으면 두 사람의 기술이 더해질뿐만 아니라 더해질 것입니다.

"깨끗하고 빠르며 재사용 가능한 코드"에 관한 주제-인터뷰에서 작은 마이크로 커널 / 서비스 관리자 및 / 또는 직무 집행자를 작성하도록 요청하십시오. 플러그 가능 구성 요소를 지정하고 구성하는 방법을 참조하십시오. 끝낼 필요는 없습니다. 중요한 생각입니다. 그리고 당신은 그것을 잘 알고있는 사람들을 빨리 배우고 괜찮은 돈을 원할 것입니다 ;-) 행운을 빌어 요!

나의 견해 : 그것을 알지 못하는 누군가를 위해 내부 프로젝트의 아키텍처를 문서화하십시오. 어떤 가정이 있고 언제 / 어떻게 일반적인 관행에서 벗어나는지 설명하고 이유를 설명하십시오.

빌드 자동화 : 좋은 생각입니다. 개발자 머신에 대한 구성 자동화를 추가 할 수 있습니다. 더 많은 것을 구축하는 것이 가장 쉬운 방법입니다 (테스트 배포가 많을수록 빠름).

또 다른 아이디어 (한 번 나에게 도움이 됨) : 새로운 개발자에게 코드베이스의 다른 영역에서 소규모 작업을 정리하여 레이아웃 도구 등에 익숙해 지도록 요청하십시오. 좋은 아이디어는 제거하는 것입니다. 나중에 혼란을 야기 할 수있는 영역을 모호하게합니다 (예 : 어딘가에 쉘 스크립트의 두 줄에 emmm python을 사용하고 프로젝트가 java를 기반으로하는 경우, 개발자 # 3이 수행해야 할 두 줄을 java로 다시 작성하도록 요청하십시오. 일하기 위해 덜 알으십시오)

나는 것 때문에 미숙 한 사람에 의해 엉망이 될 수있다, 수동 작업을 필요로 모든 것을 자동화에 초점 . 위의 간단한 의견을 바탕으로 다음이 포함됩니다.

• 버전 관리를 설치하고 수동 백업을 자동 백업으로 교체
• 가능한 한 자동 배치를 설정하십시오 (최소한, 직접 작성하는 대신 FTP를 통해 배치 할 스크립트를 작성하십시오).

만약 당신이 이것들을하지 않는다면, 당신은이 일들을 영원히하게 될 것입니다.

다른 중요한 작업은 @dimitris가 언급했듯이 문서화입니다. @에스. 로트는 이것에 대해 더 많은 세부 사항을 추가 했으므로 반복하지 않고 +1하십시오.

다음은 개인적인 경험을 바탕으로 한 몇 가지 생각입니다.

• 프로젝트를 문서화 하십시오. 설계 사양, 다이어그램, 매뉴얼 및 의견은 신입 사원의 속도를 높이는 데 도움이됩니다. 복잡한 시스템을 구두 로만 설명하면 느리고 실망 스러울 수 있습니다. 한 사람의 프로젝트에서는 종종 문서가 무시됩니다. 당신이 예외인지 확인하십시오.

• 처음에는 API / 코어 레벨 코드에 집중하면서 새로운 직원에게 "애플리케이션 계층"작업 또는 버그 수정을 제공하여 점차 코드에 익숙해 지도록 하십시오. 일반적 으로 시작 쉽게 , 아직 의미 하고, 따라서 보상 작업 .

• 의사 소통 이 중요합니다. 신입 사원의 질문, 의견 및 아이디어에 응답하십시오. 생각이 좋지 않다고 생각하는 이유를 설명하십시오. 신선한 눈 쌍은 놀랍게도 개선의 여지를 찾을 수 있습니다. 신입 사원이 괜찮은 사람이라면 코드를 동료 검토하고 결국 건축 결정에 참여할 수 있습니다. 토론하고 아이디어를 서로 바운스하십시오. 이는 프로젝트에 동료가있는 것의 가장 큰 이점 중 하나입니다.

• 새로운 팀원이 어떤 종류의 작업을 수행하는지 알면 책임을 명확하게 정의하십시오 . 수립 문서 관행 과 규칙을 코딩하는 일이 원활하게 유지합니다.

• 개정 관리 시스템을 사용하십시오 . 유지 논리적 소스 파일 레이아웃 및 빌드 규율을 .

인터뷰와 관련하여-응시자의 스트레스 지속 능력을 시도하지 않는 한 인공 코딩 테스트 또는 트릭 질문을 좋아하지 않습니다. 가장 현명한 문제 해결사조차도 그러한 상황에서 잠길 수 있습니다. 당신이 찾고자하는 자질은 정직 , 전문 능력 , 기술 지식 / 통찰 , 열정 및 상호 호환성 입니다. 업무 분위기는 많은 것을 의미 할 수 있습니다. 마음에 들지 않는 팀원을 선택하는 것은 바람직하지 않습니다. 질문을 올바르게하고 비공식 토론을 통해 응시자의 좋은 그림을 얻으십시오. 행운을 빕니다!

과학 기술

다른 사람을 개발자로 데려오고 있다면 시작하기 전에 시작하고 실행하는 것이 좋습니다.

1. 소스 컨트롤
2. 이슈 트래킹
3. 지속적인 통합

이 세 가지가 제대로 작동하면 새로운 팀원을 유치 할 때 발생하는 일반적인 문제의 약 75 %가 제거됩니다. 이 기술의 요점은 단지 당신의 머리에서만 일어나고있는 일을 많이 가져 와서 팀원이 상호 작용할 수있는 곳에서 꺼내는 것입니다.

소스 제어를 통해 동일한 작업을 수행 할 수 있습니다. 이슈 추적을 통해 수행해야 할 작업을 추적 할 수 있으며 작업중인 작업과 수행중인 작업을보다 쉽게 ​​알 수 있습니다. 지속적인 통합 및 테스트는 반복 가능한 빌드 프로세스를 유지하고 새로운 개선 사항으로 인해 코드의 다른 부분을 위반하지 않도록합니다.

실용 프로그래머는 이것에 대해 꽤 좋은 책을 가지고 있습니다. 추천 할만한 몇 가지가 있습니다. 사용중인 프로그래밍 언어 또는 사용하려는 버전 제어에 따라 다른 유사한 제목이 있습니다.

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http : //www.pragprog. com / titles / auto / pragmatic-project-automation

개인적인

종종 당신이 겪게 될 어려움은 기술적 인 측면이 적고, 더 많은 것을 배우기위한 학습에 더 가깝습니다. 다른 사람이 프로젝트의 측면을 제어하도록하는 것은 어려울 수 있습니다. 특히 자신이 모든 일을하고 모든 단일 결정을 내리는 데 익숙한 경우에는 더욱 그렇습니다. 처음에 새로운 사람이 합리적인 자유로 일할 수있는 영역을 찾을 수 있다면 신뢰의 기반을 개발할 수 있다면 슬픔을 덜 수 있습니다. 당신이 좋은 사람을 고용한다면, 아마도 당신이 배우게 될 가장 중요한 것은 자신의 모든 결정이 당신이 한 것과 동일하지 않더라도 다른 사람이 좋은 일을하도록 신뢰하는 방법입니다.

신입 사원이 문제를 조기에 포착 할 수 있도록 보호 장치를 제자리에 유지하면서 문제를 해결할 수있는 자유를 부여하고 싶습니다.

이 요점은 내 의견으로는 가장 중요합니다.

1. 코드의 중요한 부분을 읽고 이해하기 쉽도록하십시오. 주석 또는 직관적 인 기능 및 변수 이름을 사용하십시오.
2. 새로운 사람이 쉽게 코드를 제출할 수 있도록하십시오.
3. 사소한 것이 아니라면 개발 환경을 설정하는 방법에 대한 새로운 개발자에게 필요한 모든 단계를 설명하는 README 파일을 만드십시오. 또는이 환경 설정을 면밀히 지원하십시오.
4. 이 새 프로젝트를 수행 할 때 새 개발자에게 매우 명확하게 정의 된 작업을 제공하십시오. 제 생각에는 이러한 작업에는 새롭지 만 간단한 기능이 포함되어야합니다. 새로운 개발자가 먼저 코딩 스타일과 그 습관에 익숙해지기 때문에 정리 작업은 이해가되지 않습니다. 정리 또는 리팩토링은 코드를 알고있는 사람들이 수행해야하는 작업입니다.
5. 코드 제출 프로세스가 무엇인지 명확히하십시오. (예를 들어, 컴파일하는 것만 제출하십시오.) 너무 엄격하지는 않습니다. 처음에는 좌절 할 수 있습니다.
6. 코딩 규칙이있는 문서를 준비하십시오. 다른 코딩 규칙이 무엇인지 추측하는 것은 정말 실망 스러울 수 있습니다.
7. 앱이 복잡한 경우 아키텍처를 설명하는 문서를 준비하십시오. 또는 순서도 또는 이와 유사한 것을 사용하여 새로운 사람에게 아키텍처를 설명하십시오. 새로운 개발자가 프로젝트 리버스 엔지니어링에 너무 많은 시간을 낭비하고 싶지는 않습니다.
8. 새 개발자가 직접 배포를 수행해야하는 경우 배포 하는 데 필요한 모든 단계를 설명하는 준비된 체크리스트를 준비하십시오.

마지막으로 버전 관리 시스템을 구입하십시오. Subversion은 괜찮습니다. 그러나 사용자 특정적이고 끊임없이 노래하는 Eclipse 파일 (또는 기타 파일)을 추가하지 마십시오. 그들은 시간을 낭비하게 만듭니다. Stackoverflow에 문제가 있으면 언제든지 문의하십시오.