저는 항상 혼자 프로그래밍 해 왔고, 아직 학생이기 때문에 다른 사람과 프로그래밍 한 적이 없으며 이전에 버전 관리 시스템도 사용해 본 적이 없습니다.
저는 프로그래머가 회사의 소프트웨어에 대해 어떻게 협력하는지에 대한 지식이 필요한 프로젝트를 진행하고 있습니다.
소프트웨어는 어떻게 컴파일됩니까? 버전 관리 시스템에서 나온 것입니까? 개별 프로그래머에 의한 것입니까? 주기적입니까? 누군가가 무언가를 짓기로 결정할 때인가? “작동”하는지 확인하기 위해 수행되는 테스트가 있습니까?
무엇이든 할 수 있습니다.
답변
실제로 이러한 프로세스에는 많은 회사가있는만큼 많은 변형이 있습니다. 의미 : 모든 회사에는 다른 회사와 약간 다른 규칙이 있지만 대부분의 장소에서 일반적으로 사용되는 몇 가지 일반적인 모범 사례가 있습니다.
항상 유용한 모범 사례
- 프로젝트의 모든 소스 코드와이를 빌드하는 데 필요한 모든 것은 버전 제어 (소스 제어라고도 함 )하에 있습니다. 누구나 클릭 한 번으로 전체 프로젝트를 빌드 할 수 있어야합니다.
또한 불필요한 파일 (오브젝트 파일 또는 컴파일 된 바이너리)은 매우 쉽게 재생성 될 수 있고 저장소의 공간을 낭비 할 수 있으므로 저장소에 추가 해서는 안됩니다 . - 모든 개발자는 하루에 몇 번 버전 제어를 업데이트 하고 커밋 해야합니다. 대부분 작업을 완료하면 작업하고 테스트하여 사소한 버그가 포함되어 있지 않음을 알 수 있습니다.
- 다시 말하지만 누구나 클릭 한 번으로 프로젝트를 빌드 할 수 있어야합니다. 이것은 중요하며 누구나 쉽게 테스트 할 수 있습니다. 프로그래머가 아닌 사람 (예 : 상사)도 그렇게 할 수 있다면 큰 이점이 있습니다. (팀이 작업중인 내용을 정확히 볼 수 있다는 느낌을줍니다.)
- 모든 개발자 는 추가하는 새로운 기능 또는 버그 수정을 저장소에 커밋 하기 전에 테스트해야 합니다.
- 정기적으로 (미리 결정된 간격으로) 리포지토리에서 자체 업데이트 하고 전체 프로젝트의 모든 것을 빌드하려고 시도하는 서버를 설정합니다 . 실패하면 문제를 디버깅하는 데 도움이되도록 버전 제어에 대한 최신 커밋과 함께 팀에 이메일을 보냅니다 (어떤 커밋이 빌드에 실패했는지).
이 방식을 지속적 통합 이라고 하며 빌드를 야간 빌드 라고도 합니다 . (이것은 개발자가 자신의 컴퓨터에서 코드를 빌드하고 테스트하지 않아야 함을 의미하지 않습니다. 위에서 언급했듯이 그렇게해야합니다.)
- 분명히 모든 사람 이 프로젝트의 기본 디자인 / 아키텍처에 익숙해야하므로 필요한 것이 있으면 팀의 다른 구성원이 바퀴를 다시 만들 필요가 없습니다. 재사용 가능한 코드를 작성하는 것은 좋은 일입니다.
- 팀 구성원간에 일종의 의사 소통 이 필요합니다. 모두는 다른 사람들이하고있는 일을 최소한 조금이라도 알고 있어야합니다. 많을수록 좋습니다. 이것이 SCRUM 팀에서 일일 스탠드 업 이 유용한 이유 입니다.
- 단위 테스트 는 코드의 기본 기능을 자동으로 테스트하는 매우 좋은 방법입니다.
- 버그 추적 소프트웨어 (라고도 시간 추적 소프트웨어는 ) 다른 팀 구성원이가 어떤 작업을 어떤 버그를 추적하는 아주 좋은 방법이다. 테스트에도 좋습니다. 프로젝트의 알파 / 베타 테스터는 이러한 방식으로 개발 팀과 통신 할 수 있습니다.
이 간단한 것들은 프로젝트가 통제를 벗어나지 않고 모든 사람이 동일한 버전의 코드로 작업하도록 보장합니다. 연속 통합 프로세스는 상황이 심각하게 악화 될 때 도움이됩니다.
또한 사람들이 기본 저장소에 빌드하지 않는 항목을 커밋하는 것을 방지합니다.
구현하는 데 며칠이 걸리는 새 기능을 포함하고 다른 사람이 프로젝트를 빌드 (및 테스트)하는 것을 차단하려면 버전 제어 의 분기 기능을 사용하십시오.
충분하지 않은 경우 해당 프로젝트에서 가능한 경우 자동화 된 테스트를 수행하도록 설정할 수 있습니다.
좀 더 생각
위 목록은 언뜻보기에 매우 무거울 수 있습니다. 필요 에 따라 수행하는 것이 좋습니다 . 버전 제어 및 버그 추적기로 시작한 다음 나중에 필요할 경우 지속적 통합 서버를 설정합니다. (대규모 프로젝트라면 곧 필요할 것입니다.) 가장 중요한 부분에 대한 단위 테스트 작성을 시작합니다. 충분하지 않다면 더 많이 쓰십시오.
유용한 링크 :
지속적인 통합 , 일일 빌드는 친구입니다 , 버전 관리 , 단위 테스트
예 :
버전 제어를 위해 요즘에는 개인 프로젝트에 Git 을 사용하는 경향이 있습니다. Subversion 도 인기가 있으며, 예를 들어 Windows 서버를 사용하는 경우 VisualSVN 을 설정하기가 매우 쉽습니다. 클라이언트의 경우 TortoiseSVN 은 많은 사람들에게 가장 잘 작동합니다. 다음은 Git과 SVN의 비교입니다.
버그 추적 소프트웨어의 경우 Jira 와 Bugzilla 가 매우 유명합니다. 이전 직장 에서도 Mantis 를 사용 했습니다.
지속적인 통합 소프트웨어의 경우 Teamcity 가 있습니다 ( CruiseControl 및 .NET 대응 소프트웨어 도 주목할 만합니다).
“프로젝트의 주요 디자인은 누가 결정합니까?”라는 질문에 답하십시오.
물론 그것은 리드 개발자가 될 것입니다.
회사에서 리드 개발자는 프로젝트의 재무 / 마케팅 담당자와 대화하는 사람으로, 회사의 재무 능력, 계획된 기능, 사용자의 요구 사항 및 사용 가능한 시간에 따라 아키텍처를 결정합니다.
이것은 복잡한 작업이며 일반적으로 한 명 이상의 사람이 관여합니다. 때때로 팀 구성원은 전체 프로젝트 또는 특정 부분의 디자인에 대해 참여하거나 브레인 스토밍하도록 요청받습니다.
답변
저도 최근에 한 학기 전체가 거대한 그룹 프로젝트로 구성된 소프트웨어 공학 과정을 마친 학생입니다. 한 학기 내내 12 명이 걸린 일을 3 명과 함께 할 수 있었다고 말하면서 시작하겠습니다. 사람들과 함께 일하는 것은 힘든 일입니다. 의사 소통이 핵심입니다.
저장소를 확실히 활용하십시오. 각 사람은 모든 코드에 원격으로 액세스하고 무엇이든 추가 / 삭제 / 변경할 수 있습니다. 그러나 Subversion의 가장 좋은 점은 누군가가 코드를 깰 경우 이전 버전으로 되돌리고 거기에서 무엇이 잘못되었는지 평가할 수 있다는 것입니다. 의사 소통은 여전히 중요합니다. 팀원이 무엇을하는지 알고 충돌이 없도록하십시오. 코드에 앉아 있지 말고 저장소에 빠르고 의미있는 커밋을 수행하여 가장 효과적입니다.
** Redmine과 같은 버그 추적기를 권장합니다. 모든 사람에 대한 계정을 설정하고, 우선 순위가 다른 사람들에게 작업을 할당하고, 사람들이 특정 문제를 처리했는지 또는 더 많은 문제가 발생했는지 추적하고 확인할 수 있습니다.
그리고 앞서 말했듯이 단위 테스트는 큰 도움이 될 것입니다. 행운을 빕니다! 이것이 도움이 되었기를 바랍니다 🙂
답변
중요한 것은 다음과 같습니다.
- 계획 — 사람들이 어디로 가는지 모른다면 아무데도 가지 않을 것입니다. 따라서 모든 프로젝트를 시작하려면 몇 사람 (종종 프로젝트 회색 수염)이 필요합니다. 계획은 매우 상세 할 필요는 없지만 여전히 필요합니다.
- 버전 관리 시스템 — 이것이 없으면 함께 작업 할 수 없습니다. 또한 일이 약속되지 않으면 중요하지 않다는 확고한 약속이 필요합니다. “오, 내 샌드 박스 중 하나에있다”는 말도 안되는 변명 일뿐입니다.
- 이슈 트래커 — 이메일 폴더로는 이러한 것들을 추적 할 수 없습니다. 확실히 데이터베이스 기반이어야합니다.
- 알림 시스템 — 사람들은 자신이 관리하는 코드에 어떤 일이 투입되거나 자신이 책임지는 버그에 대해 주석을 달았는지 알아야합니다. 이메일 은 캔의 IRC (제공 모두가 물론, 그것을 사용),이 작동.
- 시스템 구축 — 한 번의 작업으로 개발 샌드 박스와 주 저장소 모두의 현재 상태를 완벽하게 구축 할 수 있다면 어떻게되는지 는 중요하지 않습니다 . 이를위한 최상의 옵션은 사용중인 언어에 따라 다릅니다.
- 테스트 스위트 — 테스트 스위트는 사람들이 어리석은 오류를 피하는 데 도움이됩니다. 빌드만큼 쉽게 실행할 수 있어야합니다 (빌드의 일부가되는 것이 좋습니다. ). 테스트는 정확성에 대한 조잡한 대체물 일 뿐이지 만없는 것보다 훨씬 낫습니다.
마지막으로, 계획을 수행하기 위해 함께 일할 의지가 필요합니다. 그것은 너무나 자주 힘든 부분입니다.
답변
프로그래머가 회사에서 소프트웨어를 함께 작업하는 방법
개발자는 팀으로 일하지 않습니다. 팀은 형편 없다. Dilbert 는 그가 Goofy와 같은 코믹한 캐릭터이기 때문에 재미가 없습니다. 그는 진짜이고 사람들이 그가 처한 상황을 인식하기 때문에 재미 있습니다.
답변
일반적으로 저장소에 빌드 아티팩트를 확인하지 않는 것이 좋습니다. 저장소에는 소스 트리, 빌드 구성 등-사람이 작성한 모든 것이 포함됩니다. 소프트웨어 엔지니어는 코드 사본을 로컬 파일 시스템에 체크 아웃하고 로컬에서 빌드합니다.
빌드 프로세스의 일부로 실행되는 단위 테스트를하는 것도 좋은 방법입니다. 이렇게하면 개발자는 변경 사항으로 인해 단위 테스트가 무효화되었는지 즉시 알 수 있으며 변경 사항을 확인하기 전에 수정할 수 있습니다.
버전 제어 시스템 (Subversion, CVS, Git 등 중 하나) 및 빌드 시스템 (예 : Java에는 Ant 및 Maven이 있음)에 대한 문서를 살펴볼 수 있습니다.
답변
당신이 요구하는 것에 대한 기준은 없습니다. 오히려 관습이 있으며 이는 조직의 규모와 성숙도에 크게 좌우됩니다. 소규모 조직에있는 경우, 프로그래머 몇 명과 같이 코딩, 빌드 및 테스트를 수행하는 개별 개발자에게 다소 비공식적 일 것입니다.
대규모 조직에는 전담 빌드 엔지니어 및 프로세스가있을 수 있습니다. 이러한 종류의 조직은 일반적으로 체크인 된 소스 코드를 사용하여 하루에 한 번과 같이 정기적으로 공식 빌드를 수행합니다.이 프로세스에는 일반적으로 BVT (빌드 유효성 검사 테스트)와 일부 회귀 테스트도 포함됩니다. 개발자는 리포지토리에서 코드를 확인하고 자신의 부분을 로컬에서 작업 한 다음 체크인합니다.
Microsoft 또는 Google과 같은 가장 큰 조직에서는 완전히 전담 그룹과 전체 랩을 갖게되며, 이는 어느 정도 지속적으로 구축되어 각 실행의 결과를 제공합니다. 이러한 조직은 무엇을 체크인하고 언제, 코드 검토 프로세스가 무엇인지 등에 대해 매우 공식적인 프로세스와 절차를 갖추고 있습니다.
답변
소프트웨어 개발 작업을위한 요리 책은 없지만 일반적으로 개발자가 유일한 프로젝트에서 작업하는 경우에도 버전 제어 시스템이 빌드 시스템의 핵심이되어야합니다. 이 경우에도 버전을 되돌리고 버전 로그를 읽을 수 있다는 것은 버그 수정에 매우 반가운 일입니다. 이것은 버전 제어 시스템의 유일한 기능은 아니지만 이것만으로도 버전 제어 시스템을 설치, 구성 및 유지 관리 할 수 있습니다.
빌드는 새 코드를 추가 할 때 각 개발자가 수행하거나 “빌드 서버”에서 주기적으로 수행 할 수 있습니다. 마지막 접근 방식은 더 많은 설정이 필요하지만 빌드 오류를 더 빨리 찾는 데 도움이됩니다.
