저는 항상 혼자 프로그래밍 해 왔고, 아직 학생이기 때문에 다른 사람과 프로그래밍 한 적이 없으며 이전에 버전 관리 시스템도 사용해 본 적이 없습니다.
저는 프로그래머가 회사의 소프트웨어에 대해 어떻게 협력하는지에 대한 지식이 필요한 프로젝트를 진행하고 있습니다.
소프트웨어는 어떻게 컴파일됩니까? 버전 관리 시스템에서 나온 것입니까? 개별 프로그래머에 의한 것입니까? 주기적입니까? 누군가가 무언가를 짓기로 결정할 때인가? "작동"하는지 확인하기 위해 수행되는 테스트가 있습니까?
무엇이든 할 수 있습니다.
답변:
실제로 이러한 프로세스에는 많은 회사가있는만큼 많은 변형이 있습니다. 의미 : 모든 회사에는 다른 회사와 약간 다른 규칙이 있지만 대부분의 장소에서 일반적으로 사용되는 몇 가지 일반적인 모범 사례가 있습니다.
이 간단한 것들은 프로젝트가 통제를 벗어나지 않고 모든 사람이 동일한 버전의 코드로 작업하도록 보장합니다. 연속 통합 프로세스는 상황이 심각하게 악화 될 때 도움이됩니다.
또한 사람들이 기본 저장소에 빌드하지 않는 항목을 커밋하는 것을 방지합니다.
구현하는 데 며칠이 걸리는 새 기능을 포함하고 다른 사람이 프로젝트를 빌드 (및 테스트)하는 것을 차단하려면 버전 제어 의 분기 기능을 사용하십시오.
충분하지 않은 경우 해당 프로젝트에서 가능한 경우 자동화 된 테스트를 수행하도록 설정할 수 있습니다.
위 목록은 언뜻보기에 매우 무거울 수 있습니다. 필요 에 따라 수행하는 것이 좋습니다 . 버전 제어 및 버그 추적기로 시작한 다음 나중에 필요할 경우 지속적 통합 서버를 설정합니다. (대규모 프로젝트라면 곧 필요할 것입니다.) 가장 중요한 부분에 대한 단위 테스트 작성을 시작합니다. 충분하지 않다면 더 많이 쓰십시오.
유용한 링크 :
지속적인 통합 , 일일 빌드는 친구입니다 , 버전 관리 , 단위 테스트
버전 제어를 위해 요즘에는 개인 프로젝트에 Git 을 사용하는 경향이 있습니다. Subversion 도 인기가 있으며, 예를 들어 Windows 서버를 사용하는 경우 VisualSVN 을 설정하기가 매우 쉽습니다. 클라이언트의 경우 TortoiseSVN 은 많은 사람들에게 가장 잘 작동합니다. 다음은 Git과 SVN의 비교입니다.
버그 추적 소프트웨어의 경우 Jira 와 Bugzilla 가 매우 유명합니다. 이전 직장 에서도 Mantis 를 사용 했습니다.
지속적인 통합 소프트웨어의 경우 Teamcity 가 있습니다 ( CruiseControl 및 .NET 대응 소프트웨어 도 주목할 만합니다).
물론 그것은 리드 개발자가 될 것입니다.
회사에서 리드 개발자는 프로젝트의 재무 / 마케팅 담당자와 대화하는 사람으로, 회사의 재무 능력, 계획된 기능, 사용자의 요구 사항 및 사용 가능한 시간에 따라 아키텍처를 결정합니다.
이것은 복잡한 작업이며 일반적으로 한 명 이상의 사람이 관여합니다. 때때로 팀 구성원은 전체 프로젝트 또는 특정 부분의 디자인에 대해 참여하거나 브레인 스토밍하도록 요청받습니다.
저도 최근에 한 학기 전체가 거대한 그룹 프로젝트로 구성된 소프트웨어 공학 과정을 마친 학생입니다. 한 학기 내내 12 명이 걸린 일을 3 명과 함께 할 수 있었다고 말하면서 시작하겠습니다. 사람들과 함께 일하는 것은 힘든 일입니다. 의사 소통이 핵심입니다.
저장소를 확실히 활용하십시오. 각 사람은 모든 코드에 원격으로 액세스하고 무엇이든 추가 / 삭제 / 변경할 수 있습니다. 그러나 Subversion의 가장 좋은 점은 누군가가 코드를 깰 경우 이전 버전으로 되돌리고 거기에서 무엇이 잘못되었는지 평가할 수 있다는 것입니다. 의사 소통은 여전히 중요합니다. 팀원이 무엇을하는지 알고 충돌이 없도록하십시오. 코드에 앉아 있지 말고 저장소에 빠르고 의미있는 커밋을 수행하여 가장 효과적입니다.
** Redmine과 같은 버그 추적기를 권장합니다. 모든 사람에 대한 계정을 설정하고, 우선 순위가 다른 사람들에게 작업을 할당하고, 사람들이 특정 문제를 처리했는지 또는 더 많은 문제가 발생했는지 추적하고 확인할 수 있습니다.
그리고 앞서 말했듯이 단위 테스트는 큰 도움이 될 것입니다. 행운을 빕니다! 이것이 도움이 되었기를 바랍니다 :-)
중요한 것은 다음과 같습니다.
마지막으로, 계획을 수행하기 위해 함께 일할 의지가 필요합니다. 그것은 너무나 자주 힘든 부분입니다.
일반적으로 저장소에 빌드 아티팩트를 확인하지 않는 것이 좋습니다. 저장소에는 소스 트리, 빌드 구성 등-사람이 작성한 모든 것이 포함됩니다. 소프트웨어 엔지니어는 코드 사본을 로컬 파일 시스템에 체크 아웃하고 로컬에서 빌드합니다.
빌드 프로세스의 일부로 실행되는 단위 테스트를하는 것도 좋은 방법입니다. 이렇게하면 개발자는 변경 사항으로 인해 단위 테스트가 무효화되었는지 즉시 알 수 있으며 변경 사항을 확인하기 전에 수정할 수 있습니다.
버전 제어 시스템 (Subversion, CVS, Git 등 중 하나) 및 빌드 시스템 (예 : Java에는 Ant 및 Maven이 있음)에 대한 문서를 살펴볼 수 있습니다.
당신이 요구하는 것에 대한 기준은 없습니다. 오히려 관습이 있으며 이는 조직의 규모와 성숙도에 크게 좌우됩니다. 소규모 조직에있는 경우, 프로그래머 몇 명과 같이 코딩, 빌드 및 테스트를 수행하는 개별 개발자에게 다소 비공식적 일 것입니다.
대규모 조직에는 전담 빌드 엔지니어 및 프로세스가있을 수 있습니다. 이러한 종류의 조직은 일반적으로 체크인 된 소스 코드를 사용하여 하루에 한 번과 같이 정기적으로 공식 빌드를 수행합니다.이 프로세스에는 일반적으로 BVT (빌드 유효성 검사 테스트)와 일부 회귀 테스트도 포함됩니다. 개발자는 리포지토리에서 코드를 확인하고 자신의 부분을 로컬에서 작업 한 다음 체크인합니다.
Microsoft 또는 Google과 같은 가장 큰 조직에서는 완전히 전담 그룹과 전체 랩을 갖게되며, 이는 어느 정도 지속적으로 구축되어 각 실행의 결과를 제공합니다. 이러한 조직은 무엇을 체크인하고 언제, 코드 검토 프로세스가 무엇인지 등에 대해 매우 공식적인 프로세스와 절차를 갖추고 있습니다.
소프트웨어 개발 작업을위한 요리 책은 없지만 일반적으로 개발자가 유일한 프로젝트에서 작업하는 경우에도 버전 제어 시스템이 빌드 시스템의 핵심이되어야합니다. 이 경우에도 버전을 되돌리고 버전 로그를 읽을 수 있다는 것은 버그 수정에 매우 반가운 일입니다. 이것은 버전 제어 시스템의 유일한 기능은 아니지만 이것만으로도 버전 제어 시스템을 설치, 구성 및 유지 관리 할 수 있습니다.
빌드는 새 코드를 추가 할 때 각 개발자가 수행하거나 "빌드 서버"에서 주기적으로 수행 할 수 있습니다. 마지막 접근 방식은 더 많은 설정이 필요하지만 빌드 오류를 더 빨리 찾는 데 도움이됩니다.
짧은 대답- "상황에 따라 다릅니다".
현재 저는 혼자서 프로젝트를 진행 중이므로 VCS를 구축 / 사용하는 사람입니다. 나는 당신이 shudder로 프로젝트를 함께 작업하는 팀이있는 다른 곳을 알고 있습니다. 이메일로 . 또는 VCS를 사용하는 큰 (+5) 팀.
그 점에서 저는 적어도 VCS를 배우는 것이 좋습니다. 그리고 Joel Spolsky는 훌륭한 입문 튜토리얼을 가지고 있습니다. Mercurial에 대한 을 있습니다. Bazaar (내 개인적인 선택)는 비슷하고 Git은 유사성 측면에서 다음으로 가장 가까운 곳이지만 아마도 ATM보다 더 인기가있을 것입니다. 그 후 당신은 SVN에 비해 상당히 약합니다.
사실, Joel 은 대부분의 질문에 대해 이야기 합니다. 저는 그가 보유한 10 년 간의 아카이브를 읽는 것이 좋습니다. 모든 것이 매우 유용한 정보이며, 대부분은 현재 및 가까운 미래의 상황과 관련이 있습니다.
적절한 프로그래밍은 경험에서 큰 이익을 얻는 깊은 것입니다. 쌍 프로그래밍은 인식의 여러 프로세서를 실행하는 것과 같습니다. 하나는 다른 사람이 보는 것을 간과 할 수 있으며 통신하는 한 큰 진전을 가져올 수 있습니다.
우선, 팀은 리포지토리를 사용하여 작업합니다 (전문적인 버전 제어 또는 '라이브'디렉토리로 간주 될 수 있지만 수정 제어 시스템이 사실상의 표준 일 수 있음). 또한 프로젝트 관리 전략은 작업 방식 (폭포, 민첩성 등)에 따라 다릅니다. 반복 작업을하는 경우 자체적으로 유지되는 구성 요소 / 플러그인 / 모듈 / 라이브러리를 빌드하고 완료로 사인 오프 될 때까지 단위 테스트를 수행합니다. 팀으로서 여러분은 팀에서 일합니다. 즉, 모든 곳에서 동시에 전체 프로젝트를 수행하지 않습니다. 대신 프로젝트 영역 내에서 수행 할 작업을받습니다. 경우에 따라 자신의 것이 아닌 코드를 수정해야하지만 일반적으로 이상한 동작이 발생할 때 발생합니다. 기본적으로 개발 한 부품을 테스트하고 있습니다.
예를 들어 보겠습니다. 당신은 건설 노동자 팀 안에 있습니다. 건축가는 건물에 대한 계획을 가지고 왔고, 감독은 건설에 필요한 것이 무엇인지 확인한 다음 건설자를 고용합니다. 석공은 벽을 만들고 강도를 확인하고 잘 붙입니다. 전기 기사가 건물 내부의 모든 배선을 수행하여 전기가 흐를 수 있도록합니다. 사람마다 각자의 직업이 있습니다. 때로는 전기 기사가 특정 벽을 조각 할 수 있는지 여부를 석공과 논의하기를 원할 수 있지만 항상 감독과 함께합니다.
도움이 되었기를 바랍니다.
소스 제어를 사용하는 방법에 대한 좋은 소개는 Eric Sink의 Source Control HOWTO http://www.ericsink.com/scm/source_control.html입니다.
그의 예에서 그는 SourceGear Vault를 작성했기 때문에 사용하지만 다른 버전 제어 시스템에도 적용 할 수 있습니다.
이것은 오픈 소스 프로젝트를 살펴 봐야하는 좋은 이유 중 하나입니다.
대규모 오픈 소스 프로젝트 (Chromium, Mozilla Firefox, MySQL, Popular Gnu Software 등)에서 작업하는 수석 개발자는 전문가입니다. 그들은 많은 경험을 가지고 있으며 이러한 프로젝트는 수백 명의 전문가의 아이디어로 수년에 걸쳐 발전해 왔습니다.
답변에 언급 된 다른 모든 항목 (Plan, Version control system, Issue tracker, Notification system, Build system, Test suite,)은이 OpenSource 프로젝트에서 찾을 수 있습니다.
실제로 경험을 원한다면 인기 있고 큰 오픈 소스 프로젝트를 살펴본 다음 어떤 프로젝트 (버전 제어 사용)에서 소스를 가져 와서 직접 빌드 할 것을 강력히 제안합니다.
추신 : 저도 학생이고 OpenSource 프로젝트에 참여하는 것이 제 인생에서 한 최고의 일입니다. 날 믿어! 당신도 똑같이 느낄 것입니다.
