程序员如何在项目中一起工作?

实际上,这些流程的变化和公司的变化一样多。含义:每个公司都有一些不同于其他公司的惯例,但在大多数地方都有一些常用的最佳实践。

总是有用的最佳实践

• 所有 项目的源代码以及构建它所需的任何内容都在下面 版本控制 (也称为源代码管理)。 任何人 应该能够通过单击一次构建整个项目。
  此外,不必要的文件(对象文件或编译的二进制文件)应该 不 添加到存储库中,因为它们可以很容易地重新生成,并且只会浪费repo中的空间。
• 每个开发者都应该 更新 和 犯罪 到版本控制,每天几次。大多数情况下,当他们完成任务后,他们正在进行工作并对其进行足够的测试,这样他们就知道它不包含琐碎的错误。
• 再一次: 任何人 应该能够通过单击来构建项目。这一点很重要,可以方便地为每个人测试。如果非程序员(如老板)也能做到这一点,那将是一大优势。(这让他们觉得能够准确地看到团队在做什么。)
• 每个开发者 应该测试 他们正在添加的新功能或错误修复 之前 它们将这些提交到存储库中。
• 建立一个服务器,定期(以预定的间隔)从存储库中更新自己,并尝试构建 一切 在 整个项目 . 如果失败,它将向团队发送电子邮件,同时向版本控制发送最新的提交(自提交失败以来,它就无法生成),以帮助调试问题。
  这种做法被称为 持续集成 建筑也被称为 每夜构建 .
  (这并不意味着开发人员不应该在自己的机器上构建和测试代码。如上所述,他们应该这样做。)
• 显然, 每个人 应该熟悉项目的基本设计/架构,因此如果需要什么,团队中的不同成员不必重新设计轮子。编写可重用代码是一件好事。
• 某种类型的 通信 团队成员之间需要。每个人都应该知道其他人在做什么,至少有一点。越多越好。这就是为什么 日常站立 在Scrum团队中很有用。
• 单元测试 这是一个很好的实践,可以自动测试代码的基本功能。
• 一 缺陷跟踪软件 (有时打电话 时间跟踪软件 )这是一种非常好的方法,可以跟踪存在哪些错误以及不同团队成员有哪些任务。它也适用于测试:项目的α/β测试人员可以通过这种方式与开发团队进行通信。

这些简单的事情确保项目不会失控,并且每个人都在同一版本的代码上工作。当事情变得非常糟糕时,ContinuOS集成过程会有所帮助。

它还防止人们提交不构建到主存储库的内容。
如果您希望包含一个需要几天才能实现的新功能,并且它会阻止其他人构建(和测试)项目,请使用 分支机构 版本控制的功能。

如果这还不够,您也可以设置它来进行自动化测试,如果这个项目有可能的话。

还有一些想法

上面的清单乍一看可能很重。我建议你在 根据需要 基础:从版本控制和bug追踪器开始,然后在以后设置持续集成服务器(如果需要的话)。(如果这是一个大项目,你很快就会需要它。)开始为最重要的部分编写单元测试。如果还不够,那就写更多。

一些有用的链接:
Continuous integration , Daily builds are your friends , Version control , Unit testing

实例:

对于版本控制,我倾向于使用 Git 我现在的个人项目。 Subversion 也很受欢迎,例如, VisualSVN 如果您使用的是Windows服务器,那么设置起来非常容易。对于客户, TortoiseSVN 对很多人来说效果最好。 Here is a comparison between Git and SVN.

对于bug跟踪软件, Jira 和 Bugzilla 非常受欢迎。我们也用过 Mantis 在以前的工作场所。

对于持续集成软件,有 Teamcity 对于一个(也) CruiseControl 及其 .NET counterpart 值得注意的是)

回答你的问题“谁决定项目的主要设计?”

当然,这将是主要的开发人员。
在公司中,主要开发人员是与项目的财务/营销人员交谈的人员,并根据公司的财务能力、计划的特点、用户的要求以及可用的时间来决定架构。

这是一项复杂的任务,通常涉及多个人。有时团队成员也被要求参与或集体讨论整个项目或特定部分的设计。

我也是一个学生,最近完成了一门软件工程课程,整个学期都是由一个庞大的小组项目组成的。让我先说,我们可以和3个人一起完成整个学期12个人要做的事情。与人共事是件困难的事。沟通是关键。

一定要使用存储库。每个人都可以远程访问所有代码,并添加/删除/更改任何内容。但是,关于Subversion最好的部分是,如果有人破坏了代码,您可以恢复到早期的版本,并评估出哪里出了问题。沟通仍然是关键,但要知道你的队友在做什么,这样才不会有冲突。也不要坐在代码上,快速、有意义地提交到存储库中以获得最有效的效果。

**我还建议使用bug追踪器,如Redmine。您可以为每个人设置帐户,分配具有不同优先级的人员任务,还可以跟踪和查看人员是否处理了某些问题,或者是否出现了更多问题。

正如前面所说,单元测试将有很大帮助。祝你好运!希望这有帮助:—)

重要的是:

• 一个计划 如果人们不知道他们要去哪里,他们就不会去任何地方。因此,任何项目的开始都需要一些人(通常是灰熊项目)来挤成一团,提出一个计划;计划不需要非常详细,但仍然是必需的。
• 版本控制系统 没有这个,你就不能一起工作。你还需要坚定的承诺,如果事情没有承诺,它们就不算数。_哦,它在我的一个沙盒里,_只是一个蹩脚的借口。
• 问题跟踪器 您不能通过电子邮件文件夹来跟踪这些事情。一定要有数据库支持。
• 通知系统 __人们需要知道他们维护的代码的承诺时间,或者对他们负责的错误作出评论。电子邮件 可以 为这个工作,就像IRC一样(当然前提是每个人都使用它)。
• 构建系统 “没关系” 怎样 这种情况会发生,只要使用一个操作,就可以完整地构建当前状态的内容,包括开发沙盒和主存储库。最好的选择取决于你使用的语言。
• 测试套件 测试套件可以帮助人们避免愚蠢的错误。它需要像构建一样易于运行(作为构建的一部分 好的 )请注意,测试只是一个简单的正确性替代品,但它们比什么都没有要好得多。

最后,你需要一个愿意为完成计划而共同努力的人。这往往是最困难的部分。

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

将单元测试作为构建过程的一部分运行也是一个好的实践。这样,开发人员将立即知道他的更改是否使任何单元测试失效,并有机会在签入他的更改之前修复它们。

您可能喜欢查看版本控制系统的文档(SubVIEW、CVS、Git等)和构建系统(例如,在Java中有Ant和Maven)。

程序员如何在 公司的软件

开发人员从不作为一个团队工作。团队吸吮。 dilbert 很有趣,不是因为他是一个滑稽的角色,比如goofy。他很有趣,因为他是真实的,人们认识到他所处的环境。

开发人员从不作为一个团队工作。团队吸吮。 Dilbert 很有趣,不是因为他是一个滑稽的角色,像高飞。他很有趣,因为他是真实的,人们认识到他的处境。

你所要求的东西没有标准。相反,还有一些约定,这些约定在很大程度上取决于组织的规模和成熟度。如果您在一个小的组织中,比如说几个程序员,那么对于从事编码、构建和测试的单个开发人员来说,事情可能有些非正式。

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

在最大的组织中,如微软或谷歌,他们将拥有一个完全专注的团队和完整的实验室,这些团队和实验室将或多或少地建立在一个连续的基础上,使每次运行的结果都可用。这些组织有非常正式的过程和过程,包括什么时候签入,什么时候代码评审过程,等等。

简短的回答——“取决于”。

目前,我自己在做一个项目,所以我是建立/使用风投的人。我知道在其他地方你有团队一起工作 战栗 电子邮件。或者使用风投的大型(+5)团队。

在那一点上,我强烈推荐至少学习一些风投,乔尔·斯波斯基有很好的入门知识 tutorial 为汞。巴扎(我个人的选择)是相似的,然后在相似性方面,git是下一个最接近的,但可能比两者都流行(至少ATM)。在那之后,你就有了SVN,这在比较上是很弱的。

事实上,乔尔 talks 关于你的大部分问题——我建议你阅读他拥有的10年档案——这些都是非常有用的信息,而且大部分都与你目前和不久的将来的情况有关。

在软件开发方面没有工作指南,但一般来说,版本控制系统应该是构建系统的核心,即使您正在一个项目中工作,而您是唯一的开发人员。即使在这种情况下,能够恢复版本并阅读版本日志对于修复bug也是非常受欢迎的帮助。这不是版本控制系统的唯一功能,但仅此一项就证明了安装、配置和维护版本控制系统的合理性。

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

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

首先,团队通过使用存储库(可以是专业版本控制,也可以是一组被认为是“实时”的目录,但是修订控制系统实际上是标准)工作。此外,项目管理策略的方式取决于您的工作方式(瀑布、敏捷等)。如果您在迭代中工作,那么您将构建自维持的组件/插件/模块/库,并执行单元测试,直到完成它的签署。作为一个团队,你在一个团队中工作,这意味着你不需要同时在所有地方工作整个项目。相反,您将得到一个要在项目领域内执行的任务。在某些情况下,您必须修复不属于您的代码,但这通常是在发生奇怪行为时发生的。基本上,您正在测试开发的部件。

让我给你举个例子。你在一个建筑工人队伍里。建筑师有一个建筑计划,工头看什么是必要的建设,然后雇用施工人员。泥瓦匠负责粉刷墙壁,检查墙壁的强度,并把它们粘得很好。电工在大楼内做所有的布线,这样电流就可以流动了。每个人都有自己的工作。有时,电工可能想和泥瓦匠讨论某些墙壁是否可以雕刻,但总是与工头一起。

希望这对你有帮助!

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

有些地方每晚都在建造以确保一切正常。甚至可能有一些自动测试在服务器端运行。如果生成或其他任何操作失败,将自动通知某人。

使用源代码管理的一个好方法是EricSink的源代码管理Howto http://www.ericsink.com/scm/source_control.html

在他的例子中,他使用了sourcegear vault,因为他写了所有的东西,但是这些方法可以应用到其他版本控制系统中。

这也是我们应该研究开源项目的一个很好的原因。

在大型开源项目(如Chromium、Mozilla Firefox、MySQL、流行的GNU软件)中工作的主要开发人员都是专业人员。他们拥有丰富的经验,这些项目经过多年的发展,从数百名这样的专业人士的想法。

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

如果您真的想要亲身体验,我强烈建议您先浏览一些流行的大型开源项目,然后从任何项目(使用版本控制)中获取源代码,然后自己构建它。

PS:我也是一名学生,参与开源项目是我一生中做过的最好的事情。相信我!你也会有同样的感觉。