程序员如何在项目上一起工作？
Leo*_*eda 75 version-control continuous-integration unit-testing compilation
我总是独自编程,我还是学生,所以我从未与其他人一起编程,我以前甚至都没有使用版本控制系统.
我现在正在开展一个项目,需要了解程序员如何在公司的一个软件上协同工作.
软件是如何编译的？它来自版本控制系统吗？是个别程序员吗？这是周期性的吗？是有人决定建造什么的吗？是否有任何测试以确保它"有效"？
什么都行.
Ven*_*emo 54
实际上,这些流程的变化与许多公司一样多.含义:每个公司都有一些不同的约定,但有一些常见的最佳实践通常在大多数地方使用.
始终有用的最佳做法
- 项目的所有源代码以及构建它所需的任何内容都受版本控制(也称为源代码控制).任何人都应该只需点击一下即可构建整个项目.
此外,不必要的文件(目标文件或编译的二进制)应不被添加到存储库,因为他们可以很容易再生,而且只会在回购浪费空间. - 每个开发人员应该每天更新并提交版本控制几次.大多数情况下,当他们完成任务时,他们正在进行并对其进行足够的测试,以便他们知道它不包含琐碎的错误.
- 再说一遍:任何人都应该只需点击一下即可构建项目.这很重要,可以轻松测试每个人.如果非程序员(例如老板)也能够做到这一点,那将是一大优势.(这让他们觉得能够看到团队正在做什么.)
- 每个开发人员都应该在将新功能或错误修复提交到存储库之前对其进行测试.
- 设置一个定期(以预定间隔)从存储库更新自身的服务器,并尝试在整个项目中构建所有内容.如果失败,它会向团队发送电子邮件以及版本控制的最新提交(因为它无法构建它的提交)以帮助调试问题.
这种做法称为持续集成,构建也称为夜间构建.(这并不意味着开发人员不应该在自己的机器上构建和测试代码.如上所述,他们应该这样做.)
- 显然,每个人都应该熟悉项目的基本设计/架构,因此如果需要某些东西,团队的不同成员就不必重新发明轮子.编写可重用代码是一件好事.
- 团队成员之间需要进行某种沟通.每个人都应该知道其他人在做什么,至少是一点点.越多越好.这就是为什么每日站立对SCRUM团队有用.
- 单元测试是一种非常好的做法,可以自动测试代码的基本功能.
- 一个错误跟踪软件(有时被称为时间跟踪软件)是跟踪哪些错误是有和不同的团队成员有什么任务的一个很好的手段.它也适用于测试:项目的alpha/beta测试人员可以通过这种方式与开发团队进行通信.
这些简单的事情确保项目不会失控,并且每个人都使用相同版本的代码.当事情变得非常糟糕时,连续集成过程会有所帮助.
它还可以防止人们提交不构建到主存储库的东西.
如果要包含一个需要数天才能实现的新功能,并且它会阻止其他人构建(和测试)项目,请使用版本控制的分支功能.
如果这还不够,您可以将其设置为进行自动化测试,如果可能的话,可以使用相关项目.
更多的想法
上面的列表乍一看可能非常重量级.我建议您根据需要进行操作:从版本控制和错误跟踪器开始,然后在需要时设置持续集成服务器.(如果这是一个大项目,你很快就会需要它.)开始为最重要的部分编写单元测试.如果还不够,那就写下更多.
一些有用的链接:
持续集成,每日构建是你的朋友,版本控制,单元测试
例子:
对于版本控制,我现在倾向于将Git用于我的个人项目.Subversion也很流行,例如,如果使用Windows服务器,VisualSVN很容易设置.对于客户来说,TortoiseSVN最适合很多人.这是Git和SVN之间的比较.
对于错误跟踪软件,Jira和Bugzilla非常受欢迎.我们还在以前的工作场所使用过Mantis.
对于持续集成软件,有一个Teamcity(同样,CruiseControl和它的.NET对应物值得注意).
回答你的问题"谁来决定项目的主要设计？"
当然,这将是首席开发人员.
在公司中,主要开发人员是与项目的财务/营销人员交谈的人,并根据公司的财务能力,计划的特征来自用户的要求以及可用的时间来决定结构.
这是一项复杂的任务,通常涉及不止一个人.有时,团队成员也被要求参与或集体讨论整个项目或特定部分的设计.
- @Shyam - 实际上,我听说过Git.它有其优点,但我不会说"更优越".特别是考虑到它还没有一个像样的Windows客户端.不过,这更多的是个人偏好,所以我把它添加到我的答案中. (5认同)
- 你应该考虑Git over Subversion.Subversion优于CVS,而Git远优于Subversion.而且,即使容易学习,颠覆也有一些怪癖.特别是插件的形式.即使TortoiseSVN很甜(在Windows系统上工作时). (4认同)
- @Laith J：1. 工作一般很无聊 2. 耐心是一种美德。3.无论谁设计项目，客户决定。无论您有“多么”创新、奇妙或绝妙的想法。可交付成果。工作是为了活着，而不是为了工作而活着。 (2认同)
小智 11
我也是一名学生,他最近完成了一个软件工程课程,整个学期由一个巨大的小组项目组成.首先我要说的是,我们可以和3个人一起完成整个学期12个人的工作.与人合作是一件艰难的事情.沟通是关键.
绝对利用存储库.每个人都可以远程访问所有代码,并添加/删除/更改任何内容.但是关于颠覆的最好的部分是,如果有人破坏了代码,你可以恢复到早期版本并评估那里出了什么问题.沟通仍然是关键,知道你的队友在做什么,这样就没有冲突.不要坐在你的代码上,快速,有意义地提交到存储库是最有效的.
**我还推荐一个bug追踪器,比如Redmine.您可以为每个人设置帐户,并为人员分配具有不同优先级的任务,还可以跟踪并查看人员是否已经处理了某些问题,或者是否有更多问题出现.
并且,如前所述,单元测试将有很大帮助.祝你好运!希望这有帮助:-)
重要的是:
- 计划 - 如果人们不知道他们要去哪里,他们就不会去任何地方.因此,任何项目的开始都需要一些人(通常是项目灰胡子)进行挤作一团并制定计划; 该计划不需要非常详细,但仍然需要.
- 版本控制系统 - 如果没有这个,你就不能合作了.你还需要坚定的承诺,如果事情没有得到承诺,他们就不算数."哦,它在我的一个沙箱中"只是一个蹩脚的借口.
- 问题跟踪器 - 您无法通过电子邮件文件夹跟踪这些事情.绝对应该是数据库支持的.
- 通知系统 - 人们需要知道什么时候提交他们维护的代码或者对他们负责的错误做出评论.电子邮件可以为此工作,IRC也是如此(当然每个人都使用它).
- 构建系统 -它并不真正的问题是如何出现这种情况,只要一个动作,你可以得到的东西的当前状态的一个完整的构建,无论你发展沙箱和主存储库.最佳选择取决于您使用的语言.
- 测试套件 - 测试套件可以帮助人们避免愚蠢的错误.它需要像构建一样容易运行(构建的一部分是好的).请注意,测试只是对正确性的粗略替代,但它们比没有好多了.
最后,您需要愿意共同努力实现该计划.这往往是艰难的部分.
通常,最好不要将构建工件检入存储库.存储库将包含源代码树,构建配置等 - 由人类编写的任何内容.软件工程师将检查其代码的副本到其本地文件系统并在本地构建它.
将单元测试作为构建过程的一部分运行也是一种好习惯.这样,开发人员将立即知道他的更改是否使任何单元测试无效,并且有机会在检查他的更改之前修复它们.
您可能希望查看版本控制系统(Subversion,CVS,Git等之一)的文档以及构建系统(例如,在Java中有Ant和Maven).
