프로그래머는 프로젝트에서 어떻게 협력합니까?

프로그래머는 프로젝트에서 어떻게 협력합니까?

---

저는 항상 혼자 프로그래밍 해 왔고, 아직 학생이기 때문에 다른 사람과 프로그래밍 한 적이 없으며 이전에 버전 관리 시스템도 사용해 본 적이 없습니다.

저는 프로그래머가 회사에서 소프트웨어를 함께 작업하는 방법에 대한 지식이 필요한 프로젝트를 진행하고 있습니다.

소프트웨어는 어떻게 컴파일됩니까? 버전 관리 시스템에서 나온 것입니까? 개별 프로그래머에 의한 것입니까? 주기적입니까? 누군가가 무언가를 짓기로 결정할 때인가? "작동"을 확인하기 위해 수행되는 테스트가 있습니까?

무엇이든 할 수 있습니다.

---

실제로 이러한 프로세스에는 많은 회사가있는만큼 많은 변형이 있습니다. 의미 : 모든 회사에는 다른 회사와 약간 다른 규칙이 있지만 대부분의 장소에서 일반적으로 사용되는 몇 가지 일반적인 모범 사례가 있습니다.

항상 유용한 모범 사례

• 프로젝트의 모든 소스 코드와이를 빌드하는 데 필요한 모든 것은 버전 제어 (소스 제어라고도 함 )하에 있습니다. 누구나 클릭 한 번으로 전체 프로젝트를 빌드 할 수 있어야합니다.
  또한 불필요한 파일 (오브젝트 파일 또는 컴파일 된 바이너리)은 매우 쉽게 재생성 될 수 있고 저장소의 공간을 낭비 할 수 있으므로 저장소에 추가 해서는 안됩니다 .
• 모든 개발자는 하루에 몇 번 버전 제어를 업데이트 하고 커밋 해야합니다. 대부분 작업을 마쳤을 때 작업을 수행하고 충분히 테스트하여 사소한 버그가 포함되어 있지 않음을 알 수 있습니다.
• 다시 말하지만 누구나 클릭 한 번으로 프로젝트를 빌드 할 수 있어야합니다. 이것은 중요하며 누구나 쉽게 테스트 할 수 있습니다. 프로그래머가 아닌 사람 (예 : 상사)도 그렇게 할 수 있다면 큰 이점이 있습니다. (팀이 작업중인 내용을 정확히 볼 수 있다는 느낌을줍니다.)
• 모든 개발자 는 새로운 기능이나 버그 수정을 저장소에 커밋 하기 전에 테스트해야 합니다.
• 정기적으로 (미리 결정된 간격으로) 리포지토리에서 자체 업데이트 하고 전체 프로젝트의 모든 것을 빌드하려고 시도하는 서버를 설정합니다 . 실패하면 문제를 디버그하는 데 도움이되도록 버전 제어에 대한 최신 커밋과 함께 팀에 이메일을 보냅니다 (어떤 커밋이 빌드에 실패했는지). 이 방식을 지속적 통합 이라고 하며 빌드를 야간 빌드 라고도 합니다 . (이것은 개발자가 자신의 컴퓨터에서 코드를 빌드하고 테스트하지 않아야 함을 의미하지 않습니다. 위에서 언급했듯이 그렇게해야합니다.)
  
  
• 분명히 모든 사람 이 프로젝트의 기본 설계 / 아키텍처에 익숙해야하므로 필요한 것이 있으면 팀의 다른 구성원이 바퀴를 다시 만들 필요가 없습니다. 재사용 가능한 코드를 작성하는 것은 좋은 일입니다.
• 팀 구성원간에 일종의 의사 소통 이 필요합니다. 모두는 다른 사람들이하고있는 일을 최소한 조금이라도 알고 있어야합니다. 많을수록 좋습니다. 이것이 SCRUM 팀에서 일일 스탠드 업 이 유용한 이유 입니다.
• 단위 테스트 는 코드의 기본 기능을 자동으로 테스트하는 매우 좋은 방법입니다.
• 버그 추적 소프트웨어 (라고도 시간 추적 소프트웨어는 ) 다른 팀 구성원이가 어떤 작업을 어떤 버그를 추적하는 아주 좋은 방법이다. 또한 테스트에도 좋습니다. 프로젝트의 알파 / 베타 테스터는 이러한 방식으로 개발 팀과 통신 할 수 있습니다.

이 간단한 것들은 프로젝트가 통제를 벗어나지 않고 모든 사람이 동일한 버전의 코드에서 작업하도록 보장합니다. 연속 통합 프로세스는 상황이 심각하게 악화 될 때 도움이됩니다.

또한 사람들이 기본 저장소에 빌드하지 않는 항목을 커밋하는 것을 방지합니다.
구현하는 데 며칠이 걸리는 새 기능을 포함하고 다른 사람이 프로젝트를 빌드 (및 테스트)하는 것을 차단하려면 버전 제어 의 분기 기능을 사용하십시오.

충분하지 않은 경우 해당 프로젝트에서 가능한 경우 자동화 된 테스트를 수행하도록 설정할 수 있습니다.

좀 더 생각

위 목록은 언뜻보기에 매우 무거울 수 있습니다. 필요 에 따라 수행하는 것이 좋습니다 . 버전 제어 및 버그 추적기로 시작한 다음 나중에 필요할 경우 지속적 통합 서버를 설정합니다. (대규모 프로젝트라면 곧 필요할 것입니다.) 가장 중요한 부분에 대한 단위 테스트 작성을 시작하십시오. 충분하지 않다면 더 많이 쓰십시오.

유용한 링크 :
지속적 통합 , 일일 빌드는 친구입니다 , 버전 관리 , 단위 테스트

예 :

버전 제어를 위해 요즘에는 개인 프로젝트에 Git 을 사용하는 경향이 있습니다. Subversion 도 인기가 있으며, 예를 들어 Windows 서버를 사용하는 경우 VisualSVN 을 설정하기가 매우 쉽습니다. 클라이언트의 경우 TortoiseSVN 은 많은 사람들에게 가장 잘 작동합니다. 다음은 Git과 SVN의 비교입니다.

버그 추적 소프트웨어의 경우 Jira 와 Bugzilla 가 매우 유명합니다. 이전 직장 에서도 Mantis 를 사용 했습니다.

지속적인 통합 소프트웨어의 경우 Teamcity 가 있습니다 ( CruiseControl 및 .NET 대응 소프트웨어 도 주목할 만합니다).

"프로젝트의 주요 디자인은 누가 결정합니까?"라는 질문에 답하십시오.

물론 그것은 리드 개발자가 될 것입니다.
회사에서 리드 개발자는 프로젝트의 재무 / 마케팅 담당자와 대화하는 사람으로, 회사의 재무 능력, 계획된 기능, 사용자의 요구 사항 및 사용 가능한 시간에 따라 아키텍처를 결정합니다.

이것은 복잡한 작업이며 일반적으로 한 명 이상의 사람이 관여합니다. 때때로 팀 구성원은 전체 프로젝트 또는 특정 부분의 디자인에 대해 참여하거나 브레인 스토밍하도록 요청받습니다.

---

저도 최근에 한 학기 전체가 거대한 그룹 프로젝트로 구성된 소프트웨어 공학 과정을 마친 학생입니다. 한 학기 동안 12 명이 걸린 일을 3 명과 함께 할 수 있었다고 말하면서 시작하겠습니다. 사람들과 함께 일하는 것은 힘든 일입니다. 의사 소통이 핵심입니다.

저장소를 확실히 활용하십시오. 각 사람은 모든 코드에 원격으로 액세스하고 무엇이든 추가 / 삭제 / 변경할 수 있습니다. 그러나 Subversion의 가장 좋은 점은 누군가가 코드를 깨 뜨리면 이전 버전으로 되돌리고 거기에서 무엇이 잘못되었는지 평가할 수 있다는 것입니다. 의사 소통은 여전히 ​​중요합니다. 충돌이 없도록 팀원이 무엇을하는지 알고 있어야합니다. 코드에 앉아 있지 말고 저장소에 빠르고 의미있는 커밋을 수행하여 가장 효과적입니다.

** Redmine과 같은 버그 추적기를 권장합니다. 모든 사람에 대한 계정을 설정하고, 우선 순위가 다른 사람들에게 작업을 할당하고, 사람들이 특정 문제를 처리했는지 또는 더 많은 문제가 발생했는지 추적하고 확인할 수 있습니다.

그리고 앞서 말했듯이 단위 테스트는 큰 도움이 될 것입니다. 행운을 빌어 요! 이것이 도움이 되었기를 바랍니다 :-)

---

중요한 것은 다음과 같습니다.

• 계획 — 사람들이 어디로 가는지 모른다면 아무데도 가지 않을 것입니다. 따라서 모든 프로젝트를 시작하려면 몇 사람 (종종 프로젝트 회색 수염)이 필요합니다. 계획은 매우 상세 할 필요는 없지만 여전히 필요합니다.
• 버전 관리 시스템 — 이것이 없으면 함께 작업 할 수 없습니다. 또한 일이 약속되지 않으면 중요하지 않다는 확고한 약속이 필요합니다. "오, 내 샌드 박스 중 하나에 있습니다."는 단지 절름발이의 변명 일뿐입니다.
• 이슈 트래커 — 이메일 폴더로는 이러한 것들을 추적 할 수 없습니다. 확실히 데이터베이스 기반이어야합니다.
• 알림 시스템 — 사람들은 자신이 관리하는 코드에 어떤 일이 투입되거나 자신이 책임지는 버그에 대해 주석을 달았는지 알아야합니다. 이메일 수 캔의 IRC (제공 모두가 물론, 그것을 사용),이 작동.
• 시스템 구축 — 한 번의 작업으로 개발 샌드 박스와 기본 저장소 모두의 현재 상태를 완벽하게 구축 할 수 있다면 어떻게되는지 는 중요하지 않습니다 . 이를위한 최상의 옵션은 사용중인 언어에 따라 다릅니다.
• 테스트 스위트 — 테스트 스위트는 사람들이 어리석은 오류를 피하는 데 도움이됩니다. 빌드만큼 쉽게 실행할 수 있어야합니다 (빌드의 일부가되는 것이 좋습니다 ). 테스트는 정확성에 대한 조잡한 대체물 일 뿐이지 만없는 것보다 훨씬 낫습니다.

마지막으로, 계획을 수행하기 위해 함께 일할 의지가 필요합니다. 그것은 너무나 자주 힘든 부분입니다.

---

일반적으로 저장소에 빌드 아티팩트를 확인하지 않는 것이 좋습니다. 저장소에는 소스 트리, 빌드 구성 등 사람이 작성한 모든 것이 포함됩니다. 소프트웨어 엔지니어는 코드 사본을 로컬 파일 시스템에 체크 아웃하고 로컬에서 빌드합니다.

빌드 프로세스의 일부로 실행되는 단위 테스트를 사용하는 것도 좋은 방법입니다. 이렇게하면 개발자는 자신의 변경 사항으로 인해 단위 테스트가 무효화되었는지 즉시 알 수 있으며 변경 사항을 확인하기 전에 수정할 기회가 있습니다.

버전 제어 시스템 (Subversion, CVS, Git 등 중 하나) 및 빌드 시스템 (예 : Java에는 Ant와 Maven이 있음)에 대한 문서를 살펴볼 수 있습니다.

---

프로그래머가 회사의 소프트웨어에 대해 협력하는 방법

개발자는 팀으로 일하지 않습니다. 팀은 형편 없다. Dilbert 는 그가 Goofy와 같은 코믹한 캐릭터이기 때문에 재미가 없습니다. 그는 실제적이고 사람들이 그가 처한 상황을 인식하기 때문에 재미 있습니다.

---

There is no standard for the things you're asking about. Rather, there are conventions and these depend heavily on the size and maturity of the organization. If you're in a small organization, say a couple of programmers, then things will probably be somewhat informal with the individual developers doing coding, builds, and test.

In larger organizations, there may be a dedicated build engineer and process. This kind of organization will usually do a formal build on a regular basis, say once a day, using whatever source code is checked in. The process will also usually include BVT (Build Validation Tests) and perhaps some regression tests. Developers will check out the code from the repository, work on their own portion locally, then check it in.

In the largest organizations, like Microsoft or Google, they will have a completely dedicated group and full lab that will build on a more-or-less continual basis, making the results of each run available. These organizations have very formal processes and procedures in place about what gets checked in and when, what the code review processes are, etc.

---

The short answer - "It depends".

Currently, I'm working on a project by myself, so I'm the one who builds/uses VCS. I know of other places that you have teams working on the project together by shudder email. Or big (+5) teams using VCS.

On that note, I highly recommend learning at least some VCS, and Joel Spolsky has a great introductory tutorial for Mercurial. Bazaar (my personal choice) is similar, and then Git is the next nearest in terms of similarity, but probably more popular than either (at least ATM). After that you have SVN which is pretty weak in comparison.

Actually, Joel talks about most of your questions - I'd recommend reading the 10 years of archives he has - it's all highly useful information, and most of it pertinent to your current and near-future situation.

---

There is no cookbook for working with software development, but in general the version control system should be the heart of your build system, even if you are working in a project where you are the only developer. Even in this case, being able to revert versions and read the version log is very welcome help in fixing bugs. This is not the only feature of a version control system, but this alone justifies installing, configuring and maintaining a version control system.

The build can be done either by each developer when adding new code, or periodically by a "build server". The last approach requires more setup, but helps finding out build errors sooner.

---

Proper programming is a deep thing that benefits greatly from experience. Pair-programming is like running multiple processors of awareness... one can overlook something seen by the other and so long as they are communicating it can result in great progress.

---

First of all, teams work by using repositories (which can be professional version control, or just a bunch of directories that is considered the 'live' one, however a revision control system is the de facto standard). Also, how the project is managed strategy depends on how you work (waterfall, agile, etc.). If you work in iterations, you build components/plugins/modules/libraries which are self-sustained, and you perform unit testing, until its signed off as finished. As a team, you work in a team which means you do don't work on the entire project everywhere at the same time. Instead, you get a task to perform inside a realm of the project. On some occasions you have to fix code that isn't yours, but that comes usually when a strange behavior occurs. Basically, you are doing the testing of the parts you develop.

Let me examplify this for you. You are inside a team of construction workers. The architect comes with a plan for a building, the foreman looks what the necessities are to construct and then hires the constructors. The mason does the walls, checks them for strength and glues them up nicely. The electrician does all the wiring inside the building so electricity can flow. Each man has their own job. Sometimes, the electrician might want to discuss with the mason if certain walls can be carved, but always in conjunction with the foreman.

I hope this is some help for you!

---

Typically, the source control system contains the source code and usually does not have the binaries. If you want to build it and run it, you would check the code out and build it on your local machine.

Some places run nightly builds to make sure everything works. There may even be some automated tests that are ran server-side. If the build or anything else fails, someone is notified automatically.

---

A good introduction to a method of using source control is Eric Sink's Source Control HOWTO http://www.ericsink.com/scm/source_control.html

In his examples he uses SourceGear Vault since he wrote it and all, but the methods can be applied to other version control systems.

---

This is again one good reason why one should look into Open Source projects.

The lead developers who work in big OpenSource projects (like Chromium , Mozilla Firefox, MySQL , Popular Gnu Software) are professionals. They have lot of experience and these projects have evolved over years with ideas from hundreds of such professionals.

답변에 언급 된 다른 모든 항목 (Plan, Version control system, Issue tracker, Notification system, Build system, Test suite,)은이 OpenSource 프로젝트에서 찾을 수 있습니다.

실제로 경험을 원한다면 인기 있고 큰 오픈 소스 프로젝트를 살펴본 다음 어떤 프로젝트 (버전 제어 사용)에서 소스를 가져 와서 직접 빌드 할 것을 강력히 제안합니다.

추신 : 저도 학생이고 OpenSource 프로젝트에 참여하는 것이 제 인생에서 한 최고의 일입니다. 날 믿어! 당신도 똑같이 느낄 것입니다.

참고 URL : https://stackoverflow.com/questions/3000190/how-do-programmers-work-together-on-a-project