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

我总是一个人编程，我还是一个学生，所以我从来没有和其他人一起编程，我什至没有使用过版本控制系统。

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

该软件如何编译？是来自版本控制系统吗？是个人程序员吗？它是周期性的吗？是当某人决定建造时还是其他东西？是否进行了任何测试以确保其“有效”？

一切都会做。

实际上，这些过程的变化与许多公司一样多。含义：每家公司的约定与其他约定略有不同，但是在大多数地方都有一些通用的最佳实践。

始终有用的最佳做法

• 项目的所有源代码以及构建项目所需的所有代码都在版本控制（也称为源代码控制）下。任何人都应该能够一键构建整个项目。
  此外，不必要的文件（目标文件或编译的二进制）应不被添加到存储库，因为他们可以很容易再生，而且只会在回购浪费空间。
• 每个开发人员都应更新并提交几次版本控制。通常，当他们完成任务后，便会进行工作并对其进行足够的测试，以便他们知道它不包含琐碎的错误。
• 再说一遍：任何人都应该能够通过单击来构建项目。这很重要，并且易于测试。如果非程序员（例如老板）也能够这样做，则将具有很大的优势。（这使他们觉得能够准确地看到团队正在做什么。）
• 每个开发人员都应在将其提交到存储库之前测试他们要添加的新功能或错误修复。
• 设置一个服务器，该服务器定期（以预定间隔）从存储库中进行自我更新，并尝试在整个项目中构建所有内容。如果失败，它将向团队发送电子邮件以及对版本控制的最新提交（因为它未能构建哪个提交）以帮助调试问题。 这种做法称为持续集成，而构建也称为夜间构建。（这并不意味着开发人员不应在自己的计算机上构建和测试代码。如上所述，他们应该这样做。）
  
  
• 显然，每个人应该熟悉项目的基本设计/体系结构，因此，如果需要某些内容，团队中的其他成员不必重新发明轮子。编写可重用的代码是一件好事。
• 团队成员之间需要某种沟通。每个人都应该至少知道一点其他人在做什么。越多越好。这就是为什么每天站立对SCRUM团队有用的原因。
• 单元测试是一种非常好的做法，它可以自动测试代码的基本功能。
• 一个错误跟踪软件（有时被称为时间跟踪软件）是跟踪的一个很好的手段是什么错误是不同的团队成员有没有什么任务。这对测试也有好处：您项目的alpha / beta测试人员可以通过这种方式与开发团队进行沟通。

这些简单的操作可以确保项目不会失控，并且每个人都可以使用相同版本的代码。当某些情况变得非常糟糕时，持续集成过程会有所帮助。

这也可以防止人们提交未构建到主存储库中的内容。
如果要包括一个新功能，该功能可能需要几天的时间才能实施，并且会阻止其他人构建（和测试）项目，请使用版本控件的分支功能。

如果这还不够，那么您也可以将其设置为进行自动测试，如果有问题的项目可以这样做的话。

一些更多的想法

上面的列表乍一看可能非常繁重。我建议您根据需要遵循它：从版本控制和错误跟踪器开始，然后再根据需要设置持续集成服务器。（如果这是一个大项目，您很快就会需要它。）开始编写最重要部分的单元测试。如果还不够，那就写更多。

一些有用的链接：
持续集成，日常构建是您的朋友，版本控制，单元测试

例子：

对于版本控制，如今我倾向于将Git用于个人项目。Subversion也很流行，例如，如果使用Windows服务器，则VisualSVN非常容易设置。对于客户而言，TortoiseSVN最适合许多人。这是Git和SVN之间的比较。

对于错误跟踪软件，Jira和Bugzilla非常受欢迎。我们还在以前的工作场所使用过螳螂。

对于连续集成软件，可以使用Teamcity之一（同样值得注意的是CruiseControl及其.NET）。

回答您的问题“谁来决定项目的主要设计？”

当然，那将是首席开发人员。
在公司中，主要开发人员是与项目的财务/市场营销人员进行交谈的人员，并根据公司的财务能力，计划的功能，用户的要求以及可用的时间来确定架构。

这是一项复杂的任务，通常涉及一个以上的人。有时，还要求团队成员参与或就整个项目或特定部分的设计进行头脑风暴。

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

绝对利用存储库。每个人都可以远程访问所有代码，并添加/删除/更改任何内容。但是，关于颠覆的最好之处在于，如果有人破坏了代码，则可以还原到较早的版本并评估那里出了什么问题。但是，沟通仍然是关键，要知道队友在做什么，以免发生冲突。也不要坐在代码上，对存储库进行快速，有意义的提交才是最有效的。

**我还建议您使用Bug跟踪程序，例如Redmine。您可以为每个人设置帐户，分配具有不同优先级的人员任务，还可以跟踪并查看人员是否已经解决了某些问题，或者出现了更多问题。

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

重要的是：

• 一个计划-如果人们不知道要去哪里，就不会去任何地方。因此，任何项目的开始都需要几个人（通常是项目中的胡须）来扎堆，并提出一个计划。该计划不需要非常详细，但是仍然是必需的。
• 版本控制系统—没有这个，您就无法一起工作。您还需要坚定的承诺，即如果不承诺，则不予考虑。“哦，它在我的一个沙箱中”只是一个la脚的借口。
• 问题跟踪程序-您无法通过电子邮件文件夹跟踪这些情况。绝对应该由数据库支持。
• 通知系统-人们需要知道什么时候承诺将其维护的代码提交给他们维护的代码，或者何时注释他们负责的错误。电子邮件可以工作了这一点，因为可以IRC（只要每个人都使用它，当然）。
• 构建系统-这并不重要，如何发生这种情况，只要一个动作，你可以得到的东西的当前状态的一个完整的构建，无论你发展沙箱和主存储库。最佳选择取决于您使用的语言。
• 测试套件-测试套件可帮助人们避免愚蠢的错误。它需要与构建一样容易运行（成为构建的一部分是很好的）。请注意，测试只是正确性的粗略替代品，但它们要比没有要好得多。

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

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

将单元测试作为构建过程的一部分运行也是一种好习惯。这样，开发人员将立即知道他的更改是否使任何单元测试无效，并有机会在签入他的更改之前对其进行修复。

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

程序员如何在公司中共同开发软件

开发人员从不团队合作。球队很烂。 迪尔伯特很有趣，不是因为他是个像高飞这样的漫画人物。他很有趣，因为他是真实的人，人们会意识到他所处的状况。

您要问的事情没有标准。而是有约定，这些约定在很大程度上取决于组织的规模和成熟度。如果您在一个小型组织中，请使用几个程序员，那么对于各个开发人员进行编码，构建和测试，事情可能会变得有些非正式。

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

在最大的组织（如Microsoft或Google）中，他们将有一个完全敬业的小组和完整的实验室，它们或多或少会持续不断地建立，使每次运行的结果可用。这些组织具有非常正式的流程和程序，以检查哪些内容被检入，何时被检出，什么是代码审查过程等。

没有适用于软件开发的菜谱，但是通常，即使您是唯一开发人员的项目，版本控制系统也应该是构建系统的核心。即使在这种情况下，在修复错误时也非常欢迎能够还原版本并读取版本日志。这不是版本控制系统的唯一功能，但是仅此一项就可以证明安装，配置和维护版本控制系统是合理的。

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

简短的答案-“取决于”。

目前，我是一个人在做一个项目，所以我是构建/使用VCS的人。我知道您有其他团队通过颤抖的电子邮件一起从事该项目。或使用VCS的大型（+5）团队。

关于这一点，我强烈建议至少学习一些VCS，Joel Spolsky为Mercurial提供了很好的入门教程。集市（我的个人选择）相似，因此就相似性而言，Git位居第二，但它可能比任何一个都流行（至少是ATM）。之后，您将拥有SVN，相比之下，SVN相当薄弱。

实际上，乔尔（Joel）谈论了您的大多数问题-我建议您阅读他拥有的10年档案-这些都是非常有用的信息，并且大部分与您当前和近期的情况有关。

正确的编程是一件很深刻的事情，可以从经验中受益匪浅。结对编程就像运行多个感知处理器一样……一个人可以忽略另一个人看到的东西，只要他们交流，就可以取得很大的进步。

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

让我为您举例说明。您在一个建筑工人团队中。建筑师提供了一个建筑计划，领班看了建造的必要性，然后雇用了建造者。泥瓦匠砌墙，检查墙体的强度，然后很好地粘合起来。电工完成建筑物内的所有布线，以便电流流通。每个人都有自己的工作。有时，电工可能想与泥瓦匠商量是否可以雕刻某些墙壁，但始终与工头结合在一起。

希望对您有所帮助！

通常，源代码控制系统包含源代码，并且通常不包含二进制文件。如果要构建它并运行它，您将签出代码并在本地计算机上构建它。

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

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

在他的示例中，自从他写了SourceGear Vault以来，他一直使用SourceGear Vault，但是这些方法可以应用于其他版本控制系统。

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

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

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

如果您真的想动手体验，我强烈建议您浏览一些受欢迎的大型OpenSource项目，然后从任何项目中获取Source（使用Version Control）并自行构建。

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