程序员如何在项目上一起工作？

Question

我总是单独编程，我还是学生，所以我从未与其他人编程，我以前甚至都没有使用版本控制系统。

我正在开展一个项目，现在需要了解程序员如何在公司的一个软件上协同工作。

软件是如何编译的？它来自版本控制系统吗？是个别程序员吗？这是周期性的吗？是有人决定建造什么的吗？是否有任何测试可以确保它“有效”？

一切都会。

Answer 1

Answer 2

我也是一名学生，他最近完成了一个软件工程课程，整个学期由一个巨大的小组项目组成。首先我要说的是，我们可以和3个人一起完成整个学期12个人的工作。与人合作是一件艰难的事情。沟通是关键。

绝对利用存储库。每个人都可以远程访问所有代码，并添加/删除/更改任何内容。但是关于颠覆的最好的部分是，如果有人破坏了代码，你可以恢复到早期版本并评估那里出了什么问题。沟通仍然是关键，知道你的队友在做什么，这样就没有冲突。不要坐在你的代码上，快速，有意义地提交到存储库是最有效的。

**我还推荐一个bug跟踪器，比如Redmine。您可以为每个人设置帐户，并为人员分配具有不同优先级的任务，还可以跟踪并查看是否有人处理了某些问题，或者是否有更多问题出现。

而且，如前所述，单元测试将有很大帮助。祝你好运！希望这有助于： - ）

Answer 3

重要的是：

• 计划 - 如果人们不知道他们要去哪里，他们就不会去任何地方。因此，任何项目的开始都需要一些人（通常是项目灰胡子）进行挤作一团并制定计划;该计划不需要非常详细，但仍然需要。
• 版本控制系统 - 如果没有这个，您就无法合作。你还需要坚定的承诺，如果事情没有得到承诺，他们就不算数。 “哦，它在我的一个沙箱中”只是一个蹩脚的借口。
• 问题跟踪器 - 您无法通过电子邮件文件夹跟踪这些内容。绝对应该是数据库支持的。
• 通知系统 - 人们需要知道什么时候提交他们维护的代码，或者对他们负责的错误做出评论。电子邮件可以为此工作，IRC也是如此（当然每个人都使用它）。
• 构建系统 - 如何发生这种情况并不重要，只要有一个动作就可以获得当前状态的完整构建，两者都是您的开发沙箱和主存储库。最佳选择取决于您使用的语言。
• 测试套件 - 测试套件可帮助人们避免愚蠢的错误。它需要像构建一样容易运行（构建的一部分是 good ）。请注意，测试只是对正确性的粗略替代，但它们比没有更好。

最后，您需要愿意共同努力实现该计划。这往往是困难的部分。

Answer 4

通常，最好不要将构建工件检入存储库。存储库将包含源代码树，构建配置等 - 由人类编写的任何内容。软件工程师将检查其代码的副本到本地文件系统并在本地构建。

将单元测试作为构建过程的一部分运行也是一种好习惯。通过这种方式，开发人员可以立即知道他的更改是否使任何单元测试无效，并且有机会在检查更改之前修复它们。

您可能希望查看版本控制系统（Subversion，CVS，Git等之一）的文档以及构建系统（例如，在Java中有Ant和Maven）。

Answer 5

  

程序员如何一起工作   公司的一部分软件

开发人员从不以团队形式工作。团队很糟糕。 Dilbert很有趣并不是因为他是像高飞这样的滑稽角色。他很有趣，因为他是真实的，人们认识到他所处的情况。

Answer 6

你所询问的事情没有标准。相反，存在惯例，这些惯例在很大程度上取决于组织的规模和成熟度。如果你是一个小型组织，比如几个程序员，那么对于进行编码，构建和测试的各个开发人员来说，事情可能会有些不正常。

在大型组织中，可能有专门的构建工程师和流程。这种组织通常会定期进行正式构建，例如每天一次，使用任何已签入的源代码。该过程通常还包括BVT（构建验证测试）和一些回归测试。开发人员将检查存储库中的代码，在本地处理自己的部分，然后将其签入。

在像微软或谷歌这样的大型组织中，他们将拥有一个完全专注的小组和完整的实验室，它将建立在或多或少的基础上，使每次运行的结果都可用。这些组织有非常正式的流程和程序，包括检查的内容和时间，代码审查流程等等。

Answer 7

简短的回答 - “这取决于”。

目前，我正在自己创建一个项目，所以我是构建/使用VCS的人。我知道其他地方你有团队通过 shudder 电子邮件一起工作。或者使用VCS的大型（+5）团队。

在这方面，我强烈建议至少学习一些VCS，而Joel Spolsky对Mercurial有一个很好的介绍tutorial。 Bazaar（我个人的选择）是相似的，然后Git是相似的下一个最接近的，但可能比任何一个（至少是ATM）更受欢迎。之后你就拥有相对较弱的SVN。

实际上，Joel talks关于你的大多数问题 - 我建议阅读他所拥有的10年档案 - 这些都是非常有用的信息，而且大部分都与你当前和未来的情况有关。

Answer 8

没有使用软件开发的烹饪书，但一般来说版本控制系统应该是构建系统的核心，即使您在一个只有开发人员的项目中工作。即使在这种情况下，能够恢复版本和阅读版本日志是非常受欢迎的帮助修复错误。这不是版本控制系统的唯一功能，但仅此一点就可以证明安装，配置和维护版本控制系统。

构建可以由每个开发人员在添加新代码时完成，也可以由“构建服务器”定期完成。最后一种方法需要更多设置，但有助于更快地发现构建错误。

Answer 9

正确的编程是一项深刻的事情，可以从经验中获益匪浅。配对编程就像运行多个意识处理器一样......一个人可以忽略另一个人看到的东西，只要他们进行沟通就可以带来很大的进步。

Answer 10

首先，团队使用存储库（可以是专业版本控制，或者只是一堆被认为是“实时”的目录，但是修订控制系统是事实上的标准）。此外，项目管理策略的方式取决于您的工作方式（瀑布，敏捷等）。如果您在迭代中工作，则构建自我维护的组件/插件/模块/库，并执行单元测试，直到其签名完成为止。作为一个团队，您在一个团队中工作，这意味着您不会同时在任何地方处理整个项目。相反，您可以在项目领域内执行任务。在某些情况下，您必须修复不属于您的代码，但这通常发生在发生奇怪的行为时。基本上，您正在测试您开发的部件。

让我举个例子给你。你是一群建筑工人。建筑师提出了建筑计划，工头看起来需要建造什么，然后雇用建筑师。泥瓦匠做墙壁，检查它们的强度并很好地粘合它们。电工完成了建筑物内的所有布线，因此电流可以流动。每个人都有自己的工作。有时，电工可能想与泥瓦匠讨论是否可以雕刻某些墙壁，但总是与工头一起。

我希望这对你有所帮助！

Answer 11

通常，源代码控制系统包含源代码，通常没有二进制文件。如果你想构建并运行它，你可以检查代码并在本地机器上构建它。

有些地方每晚运行以确保一切正常。甚至可能存在一些在服务器端运行的自动化测试。如果构建或其他任何内容失败，则会自动通知某人。

Answer 12

使用源代码控制方法的一个很好的介绍是Eric Sink的Source Control HOWTO http://www.ericsink.com/scm/source_control.html

在他的例子中，他使用SourceGear Vault，因为他编写了所有这些，但这些方法可以应用于其他版本控制系统。

Answer 13

这也是人们应该研究开源项目的一个很好的理由。

在大型OpenSource项目中工作的主要开发人员（如Chromium，Mozilla Firefox，MySQL，Popular Gnu Software）都是专业人士。他们拥有丰富的经验，这些项目经过多年的发展，有来自数百名专业人士的想法。

在这些OpenSource项目中可以找到其答案中提到的所有内容（计划，版本控制系统，问题跟踪器，通知系统，构建系统，测试套件）。

如果你真的想亲身体验，我强烈建议你去看一些流行的＆amp;大型OpenSource项目然后从任何项目中获取Source（使用Version Control）并将其构建为自己。

PS：我也是一名学生，参与OpenSource项目是我一生中做过的最好的事情。相信我！你也会有同感。