我一直都是一个人编程，我还是个学生，所以我从来没有和其他人一起编程，我以前什至没有使用过版本控制系统。
我现在正在开展一个项目，该项目需要了解程序员如何在公司的某个软件上协同工作。
软件是如何编译的？是来自版本控制系统吗？是个别程序员的吗？是周期性的吗？是当有人决定建造还是什么的时候？是否进行了任何测试以确保其“有效”？
什么都可以。
【问题讨论】：
标签： unit-testing version-control compilation continuous-integration
正确的编程是一件深刻的事情，可以从经验中受益匪浅。结对编程就像运行多个感知处理器......一个可以忽略另一个看到的东西，只要他们正在交流，它就可以带来很大的进步。
【讨论】：
一般来说，最好不要将构建工件检查到存储库中。存储库将包含源代码树、构建配置等 - 任何由人类编写的内容。软件工程师会将他们的代码副本检出到本地文件系统并在本地构建。
在构建过程中运行单元测试也是一种很好的做法。这样，开发人员将立即知道他的更改是否使任何单元测试无效，并有机会在签入他的更改之前修复它们。
您可能希望查看版本控制系统（Subversion、CVS、Git 等之一）和构建系统（例如，Java 中有 Ant 和 Maven）的文档。
【讨论】：
通常，源代码控制系统包含源代码，通常没有二进制文件。如果您想构建并运行它，您可以检查代码并在本地机器上构建它。
有些地方每晚运行构建以确保一切正常。甚至可能有一些在服务器端运行的自动化测试。如果构建或其他任何事情失败，则会自动通知某人。
【讨论】：
您所问的问题没有标准。相反，有一些约定，这些约定在很大程度上取决于组织的规模和成熟度。如果您在一个小型组织中，比如几个程序员，那么在进行编码、构建和测试的个人开发人员中，事情可能会有些非正式。
在较大的组织中，可能会有专门的构建工程师和流程。这种组织通常会定期进行正式构建，比如每天一次，使用签入的任何源代码。该过程通常还包括 BVT（构建验证测试），也许还有一些回归测试。开发人员将从存储库中签出代码，在本地处理自己的部分，然后签入。
在 Microsoft 或 Google 等最大的组织中，他们将拥有一个完全专门的小组和完整的实验室，将在或多或少的持续基础上进行构建，从而提供每次运行的结果。这些组织有非常正式的流程和程序，用于检查什么、何时检查、代码审查流程是什么等。
【讨论】：
简短的回答 - “视情况而定”。
目前，我自己在做一个项目，所以我是构建/使用 VCS 的人。我通过 shdder 电子邮件知道您在其他地方有团队一起从事该项目的工作。或者使用 VCS 的大 (+5) 团队。
在这点上，我强烈建议您至少学习一些 VCS，并且 Joel Spolsky 为 Mercurial 提供了一个很棒的介绍 tutorial。 Bazaar（我个人的选择）是相似的，然后 Git 在相似性方面是第二接近的，但可能比两者都更受欢迎（至少 ATM）。之后你的 SVN 就比较弱了。
实际上，Joel talks 关于您的大部分问题 - 我建议您阅读他拥有的 10 年档案 - 这些都是非常有用的信息，其中大部分与您当前和近期的情况有关。
【讨论】：
实际上，这些流程的变化与公司数量一样多。含义：每家公司的惯例都与其他公司略有不同，但有一些在大多数地方普遍使用的常见最佳实践。
这些简单的事情确保项目不会失控，并且每个人都使用相同版本的代码。当事情变得非常糟糕时，持续集成过程会有所帮助。
它还可以防止人们将未构建的内容提交到主存储库。
如果您想包含一项需要数日才能实现的新功能，并且会阻止其他人构建（和测试）项目，请使用版本控制的分支功能。
如果这还不够，您也可以将其设置为进行自动化测试，前提是相关项目可以这样做。
上面的列表乍一看可能很重量级。我建议您在按需的基础上遵循它：从版本控制和错误跟踪器开始，然后在需要时设置持续集成服务器。 （如果这是一个大型项目，您很快就会需要它。）开始为最重要的部分编写单元测试。如果还不够，那就多写几篇吧。
一些有用的链接：
Continuous integration、Daily builds are your friends、Version control、Unit testing
对于版本控制，我现在倾向于将Git 用于我的个人项目。 Subversion 也很受欢迎，例如，如果您使用 Windows 服务器，VisualSVN 很容易设置。对于客户，TortoiseSVN 最适合许多人。 Here is a comparison between Git and SVN.
对于错误跟踪软件，Jira 和 Bugzilla 非常受欢迎。我们还在以前的工作场所使用过Mantis。
对于持续集成软件，有一个 Teamcity （另外，CruiseControl 和它的 .NET counterpart 是值得注意的）。
当然，那将是首席开发人员。
在公司中，首席开发人员是与项目的财务/营销人员交谈的人，并根据公司的财务能力、计划的功能、用户的要求和可用的时间来决定架构。
这是一项复杂的任务，通常需要多人参与。有时还要求团队成员参与整个项目或特定部分的设计或集思广益。
【讨论】：
首先，团队使用存储库（可以是专业的版本控制，或者只是一堆被认为是“实时”的目录，但是修订控制系统是事实上的标准）工作。此外，项目管理策略的方式取决于您的工作方式（瀑布式、敏捷等）。如果您在迭代中工作，您将构建自我维持的组件/插件/模块/库，并执行单元测试，直到其完成。作为一个团队，你在一个团队中工作，这意味着你不会同时在任何地方处理整个项目。相反，您需要在项目的领域内执行一项任务。在某些情况下，您必须修复不属于您的代码，但这通常发生在发生奇怪行为时。基本上，您正在测试您开发的部件。
让我为你举例说明。你在一个建筑工人团队中。建筑师提出了一个建筑计划，工头查看建造的必需品，然后雇用施工人员。泥瓦匠做墙壁，检查它们的强度并将它们很好地粘合起来。电工在建筑物内完成所有布线，以便电流流动。每个人都有自己的工作。有时，电工可能想与泥瓦匠讨论是否可以雕刻某些墙壁，但总是与工头一起讨论。
希望对你有所帮助！
【讨论】：
我也是一名学生，最近完成了一门软件工程课程，整个学期都由一个大型小组项目组成。让我首先说我们可以用 3 个人完成整个学期需要 12 个人才能完成的工作。与人合作是一件艰难的事情。沟通是关键。
一定要使用存储库。每个人都可以远程访问所有代码，并添加/删除/更改任何内容。但是关于 subversion 最好的部分是，如果有人破坏了代码，您可以恢复到早期版本并从那里评估哪里出了问题。沟通仍然是关键，知道你的队友在做什么，这样就不会发生冲突。也不要坐在你的代码上，对存储库进行快速、有意义的提交是最有效的。
**我还推荐一个错误跟踪器，例如 Redmine。您可以为每个人设置帐户，并为人们分配不同优先级的任务，还可以跟踪并查看人们是否解决了某些问题，或者是否出现了更多问题。
而且，如前所述，单元测试将大有帮助。祝你好运！希望这会有所帮助:-)
【讨论】：
重要的是：
最后，您需要愿意为完成计划而共同努力。这往往是最困难的部分。
【讨论】：
没有关于软件开发的食谱，但总的来说，版本控制系统应该是您构建系统的核心，即使您在一个项目中工作，而您是唯一的开发人员。即使在这种情况下，能够恢复版本并阅读版本日志对于修复错误也是非常受欢迎的帮助。这不是版本控制系统的唯一功能，但仅此一点就证明了安装、配置和维护版本控制系统的合理性。
构建可以由每个开发人员在添加新代码时完成，也可以由“构建服务器”定期完成。最后一种方法需要更多设置，但有助于更快地发现构建错误。
【讨论】：
程序员如何在一个 公司的软件
开发人员从不作为一个团队工作。团队很烂。 Dilbert 很有趣，不是因为他是像高飞这样的滑稽角色。他很有趣，因为他是真实的，人们认识到他所处的情况。
【讨论】：
Eric Sink 的 Source Control HOWTO http://www.ericsink.com/scm/source_control.html 很好地介绍了使用源代码控制的方法
在他的示例中，他使用 SourceGear Vault，因为它是他编写的，但这些方法可以应用于其他版本控制系统。
【讨论】：
这也是应该研究开源项目的一个很好的理由。
在大型开源项目（如 Chromium、Mozilla Firefox、MySQL、Popular Gnu Software）中工作的主要开发人员都是专业人士。他们拥有丰富的经验，多年来，这些项目在数百名此类专业人士的想法下不断发展。
其他人在回答中提到的所有内容（计划、版本控制系统、问题跟踪器、通知系统、构建系统、测试套件）都可以在这些开源项目中找到。
如果您真的想要亲身体验，我强烈建议您查看一些流行的大型开源项目，然后从任何项目中获取源代码（使用版本控制）并自行构建。
PS：我也是一名学生，参与开源项目是我一生中做过的最好的事情。相信我！你也会有同样的感觉。
【讨论】：