私はJavaで、非常にオブジェクト指向のスタイルで、自分でプログラミングしています。他のプログラマーと仕事をする機会がなかった（少なくとも私はプロではない）。
好奇心から、私は尋ねたいと思いました：プロジェクトでチームと働くことは、特にオブジェクト指向プロジェクトで働くとき、どのように働きますか？
分割タスクはどのように機能しますか？他のプログラマーが開発したものとうまく機能するものをどのように開発しますか？ プログラマはいつ、どのように通信しますか？
ありがとう
回答:
少しでもお役に立てれば幸いです。あるいは、少なくとも正しい方向に向けていただければ幸いです。
ちょっとした免責事項として、それは大きなトピックです-そして、私は本当に深く理解するために「投げられる」ことをとると思うものです。とはいえ、2つの主要な問題について簡単に説明します。
特にOOPプロジェクトについて-正直に言って、他の場所には存在しないOOP固有の問題はあまり見られません。
実際、OOPスタイルのプログラミングはチーム開発に非常に適していると思います。OOPの重要な精神の1つは、やり取りするすべてのオブジェクトの詳細をすべて知ってはならないということです。何ができるのか、どうすればそれを実現できるのかを知る必要があるだけです。
OOPが提供できる抽象化は、チームでは素晴らしいです。
プロジェクトを保存する中心的な場所が必要であり、複数の開発者が一度にコードベースにアクセスできる場所が必要です。これは、Git（またはSVN）などのシステムが登場する場所です。
SVNを使用したことがないため、Gitについてのみ具体的に話すことができますが、Gitは似ていますが、用語が異なります。
Gitを使用して、特定のプロジェクトのすべてのソースコードを含むリポジトリを作成し、チームがリポジトリにアクセスできるようにします。その後に行われるすべての機能またはバグ修正について、個々の開発者は独自の「ブランチ」を作成できます。これは、開発が並行して実行されることを意味します。
機能または修正が完了すると、それをメインプロジェクトのコードベースに「マージ」することができます。「競合」は、Gitによって検出され、責任のある開発者がソースレベルで解決できます。
以前にGitを使用したことがあるかどうかはわかりませんが、最初は非常に複雑に見えるかもしれません-しかし、最近の人気（Githubの一部）のおかげで、チュートリアルとリソースが豊富にあります。
以前に使用したことがない場合は、GitHubにサインアップして、そのように感じてみることをお勧めします。（または、Bitbucketも同様の代替手段ですが、無料でプライベートリポジトリを使用できます。）
Git Flowは優れたGitベースのワークフローであり、チームにとって非常に便利です。一般的なGitのように、しばらくGitで作業すると、それなしでチームで作業することを想像するのは難しくなります。
すべての技術的な障壁を乗り越えると、ほとんどのプロジェクト（技術的であるかどうかに関係なく）を悩ませている根本的な問題にたどり着きます。それがコミュニケーションです。
チーム全体が、誰が何をしているのか、いつそれを行っているのか、そしてそれが何に影響するのかを認識する必要があります。
これは明らかですが、ほとんどのプロジェクトは何らかの機能のチケットやバグを記録した後、特定のスタッフに割り当てられるチケットシステムを使用します。（JIRA、Unfuddleなど）多くの場合、これらはソース管理システムに組み込まれているため、生活が少し簡単になります。（BitBucketとGitHubは両方とも、ホストされているGitリポジトリの問題追跡を提供します。）
これにより、開発者が誤って同じ問題に取り組んでいるのを止めるか、少なくとも防ぐのに役立ちます。
ただし、これは完全な修正ではありません。開発者が他の開発者の責任について認識していることを確認する必要があります。私は過去に、特定のバグを修正する過程で偶然見つけた他の問題を修正したことを知っています。（「まあ、私はすでにここにいます。これはリファクタリングで行うことができ、おそらく他の問題をチェックすることができます。」）修正済み-両方の時間を無駄にしています。
一般的に、これらの問題は次の方法で修正できます...
一部のプロジェクト管理/開発方法論では、特定の通信方法または会議の間隔が規定されています。一般的に、私が見た最も生産的なシステムは、チームの全員が彼らがしていることのクイックランダウンを与える朝のスタンドアップミーティングです-これを開発チームのメンバーのみに制限し、何についての明確なガイドラインがある場合通信するには、これらは非常に効果的です。私は常に固執しようとしました：
私はXに取り組んでいます、
Yを達成/修正するには、
Zの変更/修正が含まれます。
他のチームメンバーはすぐにそれを取り入れることができます。Fergusは先日ログに記録されたバグの修正に取り組んでいますが、それは彼が私が見る必要のあるコードに取り組んでいるということです。「。
私は最近、2週間に1度「技術チャット」を行う素晴らしいチームと仕事をしました。そこでは、より大きな/建築上の問題が議論されます。チームのすべてのメンバーは、プロジェクトが直面している大きな問題を理解する時間があり、潜在的な修正について話し合うことができました。
私は個人的にはこれが大好きで、プロジェクトにかなり慣れていないのであまり貢献しませんでしたが、議論を聞くことができたので多くの洞察が得られました。すぐにプロジェクトと個人の思考スタイルを理解できました。
コミュニケーションは、あらゆるチームをダウンさせる可能性がある1つの問題です。技術的であろうとなかろうと、人々が全体像を認識していない場合、失敗する可能性が高くなります。
チームで作業するときは、全員が同じ構成またはスタイルを持つようにすることをお勧めします。どういう意味ですか？
Javaプロジェクトで作業している場合、おそらく（少なくとも開発環境では、テスト用ではありません）JVMバージョンがチーム間で共通であることを確認することをお勧めしますか？次にIDE。チーム全体がEclipse、NetBeans、または選択したIDEを使用している場合、主に役立ちます。
Webプロジェクトでは、すべての開発者が特定のスタックを必要とする場合があります。特定のApacheまたはPHPバージョン。
このような要因を考えると、チームは私の頭の中を少し早く「ゲル化」することができます。
タブとスペース？キャメルケースまたはspacing_with_underscores？これらの質問と同じくらい小さいのは、あなたが一人で仕事をしているとき、あなたがより大きなチームで仕事をしているとき、あなたは本当に共通のスタイルに向かって努力したいかもしれません。
実際、コードの特定のセクションを誰が書いたのかを実際に伝えることはできません- それが属していることを知っている必要があります。
これが、多くのオープンソースプロジェクトがオープンソースコード形式のガイドライン/スタイルガイドを公開している理由です。これらの内容については、独自のオープンソースプロジェクトのGoogle StyleGuidesをご覧ください。
これはチームに限定されるものではありませんが、特に1つの理由により、チームライフをより簡単にするために、これにすばやく触れます。
多数の依存関係がある複雑なワークフロー、または長いビルドプロセスがある場合、多くの場合、タスクランナーを使用してこれを自動化すると便利です。Webプロジェクトの場合、GruntJSは素晴らしいですが、Javaから来たのですが、Apache Antもかなり似ていると思います。
個人として、私はGruntJSを使用してFTPサーバーにデプロイする前にサイトを構築します.CSS / Sassをコンパイルして縮小し、アセットを圧縮してからファイルをアップロードするために必要なのは、1つのGruntコマンドだけです。
しかし、チームメンバーとして、GruntJSを使用して、テストに違反していないこと、およびプロジェクトの他の部分を完全に認識していないためにバグが発生していないことを確認できます。これはもちろん、個々の開発者として私に与えられる利点に追加されるものです。
それを使用して、ファンシーなソース管理パッケージ（Git）を使用してプロジェクトを複製し、1つのコマンドを実行してすべての依存関係をインストールすることもできます。新しいデベロッパーを実際に開発を開始できる位置に置くのにかかる時間は非常に長くなる可能性があるため、これは大きなプラスになります-なじみのないコードベースに慣れるのにかかる時間を考慮することさえありません。
私が見た最高のプロジェクトには、開発者向けのドキュメントがあります（多くの場合、非常に過剰です）。これらの種類のドキュメントは、次のようなことを説明します。
1.開発環境：
「現在、LAMPスタックを実行しているサーバーにデプロイしています。開発者は、概説されているバージョンをターゲットにする必要があります。」
2.ワークフロー
「すべての機能は「feature / *」ブランチで開発され、リリース準備完了と見なされる前に「testing」ブランチにマージされます。」
3.チームの責任：
「データベースの問題については、Steveに相談してください。プラットフォームの問題については、Davidに相談してください。」
4. 未来への「パイプライン」
「新しいコードを開発するとき、2014年6月の時点でxを実装することを忘れないでください。これが発生する前にレガシーコードを確認する必要がある場合があります。」
オープンソースプロジェクトのワークフローを見て、それがどのように動作するのかを感じてみる価値があります-それが独自のワークフローを備えた確立されたものであるか（頻繁に文書化されている）、GitHubの多くの例の1つです。
あなたが自分自身がこの権利のすべてを成し遂げることができているチームで働いていることに気づいたら..あなたは他のどこかにいることを嫌うでしょう..！良いチームを経験したら、他の場所で突然問題が発生する可能性があります。（しかし、それは別の投稿の話です！）