我自己用非常面向对象的风格用Java编程。从来没有机会与其他程序员合作（至少我还不是专业人士）。
出于好奇，我想问：与团队一起进行项目工作如何工作，尤其是在进行OO项目时？
拆分任务如何工作？您如何开发可以与其他程序员开发的产品一起成功使用的产品？ 程序员如何以及何时进行交流？
谢谢
Answers:
希望我能对您有所帮助，或者至少为您指明正确的方向！
但是，作为一个免责声明，这是一个巨大的话题-我真正认为这个话题需要“ 投入 ”以深入了解。也就是说，我将简要介绍两个主要问题：
关于OOP专案-老实说，我看不到OOP所没有的其他太多问题。
实际上，我认为OOP风格的编程非常适合团队开发。OOP的一个主要精神是我不应该了解与之交互的每个对象的所有细节：我只需要知道它可以做什么，以及我如何才能做到这一点。
OOP可以提供的抽象在团队中很棒。
需要将项目存储在一个中心位置，并且该位置允许多个开发人员随时访问代码库。这就是诸如Git（或SVN）之类的系统开始发挥作用的地方。
我只能专门讲讲Git，因为我从未使用过SVN-但是我发现它们很相似，只是术语有所不同。
使用Git，我可以使用给定项目的所有源代码创建存储库，然后允许我的团队访问该存储库。对于随后进行的每个功能或错误修复，单个开发人员都可以创建自己的“分支”，这意味着开发可以并行进行。
一旦功能或修复完成，就可以将其“ 合并 ”回主项目的代码库。然后，Git可以检测到任何“ 冲突 ”，并由负责的开发人员在源代码级别解决。
我不确定您之前是否会使用过Git，但乍一看它似乎很复杂-但由于它最近的流行（部分原因是Github的帮助），那里有大量的教程和资源。
如果您以前从未使用过它，那么我建议注册GitHub并以这种方式来体验一下！（或者，Bitbucket是一个类似的选择，但是它允许您免费拥有私有存储库。）
Git Flow是基于Git的出色工作流程，对团队而言非常有用。一般而言，就像Git一样，一旦使用了一段时间，就很难想象没有它就可以在团队中工作！
克服所有技术障碍后，您实际上就会陷入困扰大多数项目（无论是否是技术项目）的根本问题，那就是沟通。
整个团队都需要知道谁在做什么，什么时候在做什么以及它会影响什么。
这是显而易见的，但是大多数项目将使用某种形式的票务系统-记录所有功能请求或错误，然后将其分配给特定的职员。（JIRA，Unfuddle等）。这些通常内置于源代码控制系统中，这使工作变得更简单。（BitBucket和GitHub都提供了对其托管的Git存储库的问题跟踪。）
这可以停止或至少有助于防止开发人员意外处理相同的问题。
但是，这不是一个完整的解决方案。您仍然需要确保开发人员了解其他开发人员的职责。我知道过去，我已经修复了在修复特定错误过程中偶然发现的其他问题，纯粹是因为这样做是有道理的。（“ 好吧，我已经在这里了。这可能与重构有关，也许我可以检查其他问题。 ”）然后，我不得不向其他开发人员道歉，因为他们正在处理我已经解决的其他问题固定-浪费我们的时间。
通常，这些问题可以通过...解决
一些项目管理/开发方法规定了特定的沟通方法或会议间隔。总的来说，我见过的最有生产力的系统是上午的站立会议，团队中的每个人都将快速了解他们的工作-如果您仅将其限制为开发团队成员，并且对工作有明确的指导原则进行交流，那么它们会非常有效。我一直试图坚持：
我正在研究X，
要实现/修复Y，
其中涉及修改/修改Z。
其他团队成员可以立即接受“ Fergus正在修复前一天记录的错误，但是，这意味着他正在处理一些我需要查看的代码-在进行任何更改之前，我将与他联系。 ”。
我最近与一个很棒的团队合作，每两周进行一次“ 技术聊天 ”，讨论更大/体系结构的问题。团队中的每个成员都有时间了解项目面临的更大问题，并可以讨论潜在的解决方案。
我个人喜欢这个，因为我是很新的项目我没有太多贡献-但能够聆听讨论给了我很多见解; 很快我就能理解该项目以及个人的思维方式。
沟通是可能导致任何团队瘫痪的一个问题。无论技术水平与否，如果人们不了解大局，那么他们失败的可能性就更大。
最好在团队中确保每个人都具有相同的配置或样式。我什么意思
如果您正在研究Java项目，那么也许可以确保（至少对于开发环境而言，肯定不是为了测试）。在团队中使用JVM版本是一个好主意吗？然后是IDE。如果整个团队都在使用Eclipse或NetBeans或您选择的IDE，那么它将大有帮助。
在一个Web项目中，可能所有开发人员都需要特定的堆栈。与特定的Apache或PHP版本。
考虑这样的因素只会让团队在我脑海中更快地“凝结”。
制表符还是空格？CamelCase还是spaces_with_underscores？当您独自工作时，与更大的团队一起工作时，这些问题可能会如此之小，您真的想朝着共同的风格努力。
实际上，您实际上不应该知道是谁编写了特定的代码部分-您应该只知道它属于。
这就是为什么许多开放源代码项目公开发布源代码格式指南/样式指南的原因-为了了解其中包含的内容，请查看针对自己的开放源代码项目的Google StyleGuides。
这不仅限于团队，但我将特别快速地谈到这一点，原因有一个：它使团队生活变得更加轻松。
如果您的工作流程复杂且有很多依赖项，或者构建过程很漫长，那么使用任务运行器自动执行此操作通常会很有用。对于Web项目，GruntJS很棒，尽管我来自Java，但我猜Apache Ant可能非常相似。
作为个人我使用GruntJS打造我的网站之前，我把它部署到我的FTP服务器-一个步兵命令是将所有我需要为我的CSS / 萨斯进行编译和精缩，被压缩我的资产，然后我的文件上传。
但是，作为团队成员，我可以使用GruntJS来检查是否没有破坏任何测试-并且由于没有完全了解项目的其他部分而没有引入任何错误。当然，这是除作为个人开发人员提供给我的好处之外的其他好处。
我也可以使用它，以便可以使用高级源代码控制包（Git）克隆项目-并运行一个命令来安装我的所有依赖项。这是一个很大的优势，因为将新开发人员带到可以开始实际开发的位置的时间可能会非常长-甚至无需考虑习惯陌生代码库所花费的时间。
我所见过的最好的项目都有针对开发人员的文档（常常是过多的文档）。这些类型的文档可能会解释以下内容：
1.开发环境：
“我们目前正在部署到运行LAMP堆栈的服务器，因为此类开发人员应针对其中概述的版本。”
2.工作流程
“所有功能都将在'feature / *'分支上开发，并在考虑为发布准备就绪之前合并到'testing'分支中。”
3.团队职责：
“对于数据库问题，请与Steve交谈。对于平台问题，请与David交谈。”
4. 未来的“ 管道 ”
“在开发新代码时，请记住，自2014年6月起，我们希望实施x-可能需要先检查旧代码，然后再进行检查。”
值得一看开放源代码项目的工作流程，以了解它是如何工作的-无论是建立自己的工作流程并拥有自己的工作流程（通常都有大量记录），还是GitHub上的众多示例之一。
如果您发现自己在一个能够做到所有这些权利的团队中工作，您将不喜欢在其他任何地方工作。从我这里拿走，一旦您经历了一支优秀的团队，突然之间其他地方的问题会真的使您失望。（但是，这是另一个帖子的故事！）