程序员如何协同完成一个项目？
我一直都是独自编程，我还是一名学生，所以我从来没有和其他人一起编程，我以前甚至没有使用过版本控制系统。
我现在正在开发一个项目，该项目需要了解程序员如何在公司中一起开发软件。
软件是如何编译的？是来自版本控制系统吗？是个人程序员做的吗？是周期性的吗？是当有人决定建造什么的时候吗？是否进行了任何测试以确保其“有效”？
任何事情都会做。
I've always programmed alone, I'm still a student so I never programmed with anyone else, I haven't even used a version control system before.
I'm working on a project now that requires knowledge of how programmers work together on a piece of software in a company.
How is the software compiled? Is it from the version control system? Is it by individual programmers? Is it periodic? Is it when someone decides to build or something? Are there any tests that are done to make sure it "works"?
Anything will do.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
事实上，有多少家公司，这些流程就有多少变化。含义：每个公司的惯例都与其他公司略有不同，但有一些通用的最佳实践在大多数地方都普遍使用。
始终有用的最佳实践
此外，不应将不必要的文件（目标文件或编译的二进制文件）添加到存储库中，因为它们可以很容易地重新生成，并且只会浪费存储库中的空间。
这种做法称为持续集成，构建也称为夜间构建。
（这并不意味着开发人员不应在自己的机器上构建和测试代码。如上所述，他们应该这样做。）
这些简单的事情可以确保项目不会失控，并且每个人都使用相同版本的代码。当事情变得非常糟糕时，持续集成过程会有所帮助。
它还可以防止人们提交未构建到主存储库的内容。
如果您想要包含一项需要数天时间才能实现的新功能，并且会阻止其他人构建（和测试）项目，请使用版本控制的分支功能。
如果这还不够，您还可以将其设置为进行自动化测试（如果相关项目可以的话）。
更多想法
乍一看，上面的列表可能非常重量级。我建议您根据需要遵循它：从版本控制和错误跟踪器开始，然后在需要时设置持续集成服务器。 （如果这是一个大型项目，您很快就会需要它。）开始为最重要的部分编写单元测试。如果还不够，那就多写一些。
一些有用的链接：
持续集成，每日构建是您的朋友，版本控制 , 单元测试
示例：
对于版本控制，我倾向于使用 Git 用于我现在的个人项目。 Subversion 也很流行，例如 VisualSVN 如果您使用 Windows 服务器，则设置起来非常容易。对于客户来说，TortoiseSVN 最适合很多人。 这是 Git 和 SVN 之间的比较。
对于错误跟踪软件，Jira 和 Bugzilla 非常受欢迎。我们还在之前的工作场所使用了 Mantis。
对于持续集成软件，有 Teamcity 之一（还有 CruiseControl 及其 .NET 对应项 值得注意）。
回答你的问题“项目的主体设计由谁决定？”
当然，那将是首席开发人员。
在公司中，首席开发人员是与项目的财务/营销人员交谈的人，并根据公司的财务能力、计划的功能、用户的需求以及可用的时间来决定架构。
这是一项复杂的任务，通常涉及多个人。有时，团队成员也会被要求参与或集思广益，讨论整个项目或特定部分的设计。
Actually, there are as many variations on these processes as many companies there are. Meaning: every company has a little bit different conventions than others, but there are some common best practices that are generally used in most places.
Best practices that are always useful
Furthermore, unnecessary files (object files or compiled binaries) should not be added to the repository, as they can be regenerated quite easily and would just waste space in the repo.
This practice is called continuous integration and the builds are also called nightly builds.
(This doesn't imply that developers should not build and test the code on their own machines. As mentioned above, they should do that.)
These simple things ensure that the project doesn't go out of control and everyone works on the same version of the code. The continuos integration process helps when something goes terribly bad.
It also prevents people from committing stuff that don't build to the main repository.
If you want to include a new feature that would take days to implement and it would block other people from building (and testing) the project, use the branches feature of your version control.
If that is not enough, you can set it up to do automated testing, too, if that is possible with the project in question.
Some more thoughts
The above list can be very heavyweight at first glance. I recommend that you follow it on an as-needed basis: start with a version control and a bug tracker, then later on set up the continuous integration server, if you need it. (If it's a large project, you're gonna need it very soon.) Start writing unit tests for the most important parts. If it's not enough, then write more of them.
Some useful links:
Continuous integration, Daily builds are your friends, Version control, Unit testing
Examples:
For version control, I tend to use Git for my personal projects nowadays. Subversion is also popular, and for example, VisualSVN is quite easy to set up if you use a Windows server. For client, TortoiseSVN works best for many people. Here is a comparison between Git and SVN.
For bug tracking software, Jira and Bugzilla are very popular. We also used Mantis at a previous workplace.
For continuous integration software, there is Teamcity for one (also, CruiseControl and its .NET counterpart are notable).
Answer to your question "who decides the main design of the project?"
Of course, that would be the lead developer.
In companies, the lead developer is the person who talks to the financial / marketing people of the project, and decides the arcithecture according to the financial capability of the company, the planned features the requirements from users, and the time that is available.
It is a complex task, and usually more than one people are involved. Sometimes members of the team are also asked to participate or brainstorm about the design of the entire project or specific parts.
我也是一名学生，最近完成了软件工程课程，整个学期包括一个巨大的小组项目。首先我要说的是，我们 12 个人花了整个学期才能完成的事情，我们 3 个人就可以完成。与人合作是一件艰难的事情。沟通是关键。
一定要使用存储库。每个人都可以远程访问所有代码，并添加/删除/更改任何内容。但关于颠覆的最好的部分是，如果有人破坏了代码，您可以恢复到早期版本并从那里评估出了什么问题。不过，沟通仍然很关键，了解你的队友在做什么，这样就不会发生冲突。也不要坐在代码上，快速、有意义地向存储库提交才是最有效的。
**我还推荐一个错误跟踪器，例如Redmine。您可以为每个人设置帐户，并为人员分配不同优先级的任务，还可以跟踪并查看人们是否已经解决了某些问题，或者是否出现了更多问题。
而且，正如之前所说，单元测试会有很大帮助。祝你好运！希望这有帮助:-)
I'm a student as well, who completed a software engineering course recently where the entire semester consisted of a giant group project. Let me just start by saying we could have done with 3 people what it took 12 of us the whole semester to do. Working with people is a tough thing. Communication is key.
Definitely utilize a repository. Each person can remotely access all the code, and add/delete/change anything. But the best part about subversion is that if someone breaks the code, your can revert to an earlier version and assess what went wrong from there. Communication is still key though, know what your teammates are doing so that there are no conflicts. Don't sit on your code either, make quick, meaningful commits to the repository to be the most effective.
**I'd also recommend a bug tracker, such as Redmine. You can set up accounts for everyone, and assign people tasks with different priorities, and also track and see if people have taken care of certain problems, or if more have come up.
And, as has been said before, unit testing will help greatly. Best of luck! Hope this helped :-)
开发人员从来不作为一个团队工作。团队很糟糕。 呆伯特很有趣，并不是因为他是像高飞这样的滑稽角色。他很有趣，因为他是真实的，人们认识他所处的情况。
Developers never work as a team. Teams suck. Dilbert is funny not because he's a comical character like Goofy. He's funny because he's real and people recognize the situations he's in.
一般来说，最好不要将构建工件签入存储库。存储库将包含源代码树、构建配置等——任何由人类编写的内容。软件工程师将把他们的代码副本检出到本地文件系统上并在本地构建它。
将单元测试作为构建过程的一部分运行也是一种很好的做法。这样，开发人员将立即知道他的更改是否使任何单元测试无效，并且有机会在签入他的更改之前修复它们。
您可能想查看版本控制系统（Subversion、CVS、Git 等之一）和构建系统（例如，Java 中的 Ant 和 Maven）的文档。
Generally it is good practice not to check build artifacts into the repository. The repository will contain the source tree, build configuration, etc - anything written by a human. Software engineers will check out a copy of their code onto their local filesystem and build it locally.
It is also good practice to have unit tests which are run as part of the build process. This way, a developer will know instantly if his changes have invalidated any of the unit tests, and will have the opportunity to fix them before checking in his changes.
You might like to look into the documentation for a version control system (one of Subversion, CVS, Git, etc) and for a build system (for example, in Java there are Ant and Maven).
最重要的是：
最后，您需要愿意共同努力实现计划。这往往是最困难的部分。
The big things are:
Finally, you need a willingness to work together toward fulfilling the plan. That's all too often the tough part.
你问的问题没有标准。相反，有一些惯例，这些惯例在很大程度上取决于组织的规模和成熟度。如果您在一个小型组织中，例如几个程序员，那么个别开发人员进行编码、构建和测试的情况可能会有些非正式。
在较大的组织中，可能有专门的构建工程师和流程。这种组织通常会使用签入的任何源代码定期进行正式构建，例如每天一次。该过程通常还包括 BVT（构建验证测试）以及可能的一些回归测试。开发人员将从存储库中检查代码，在本地处理自己的部分，然后将其签入。
在最大的组织中，例如微软或谷歌，他们将拥有一个完全专用的小组和完整的实验室，该实验室将构建在更多或更多的基础上-更少的连续基础，使每次运行的结果都可用。这些组织拥有非常正式的流程和程序，涉及签入内容、时间、代码审查流程等。
There is no standard for the things you're asking about. Rather, there are conventions and these depend heavily on the size and maturity of the organization. If you're in a small organization, say a couple of programmers, then things will probably be somewhat informal with the individual developers doing coding, builds, and test.
In larger organizations, there may be a dedicated build engineer and process. This kind of organization will usually do a formal build on a regular basis, say once a day, using whatever source code is checked in. The process will also usually include BVT (Build Validation Tests) and perhaps some regression tests. Developers will check out the code from the repository, work on their own portion locally, then check it in.
In the largest organizations, like Microsoft or Google, they will have a completely dedicated group and full lab that will build on a more-or-less continual basis, making the results of each run available. These organizations have very formal processes and procedures in place about what gets checked in and when, what the code review processes are, etc.
没有关于软件开发的指南，但一般来说，版本控制系统应该是构建系统的核心，即使您在一个项目中工作，而您是唯一的开发人员。即使在这种情况下，能够恢复版本并读取版本日志对于修复错误也是非常受欢迎的帮助。这不是版本控制系统的唯一功能，但这本身就证明了安装、配置和维护版本控制系统的合理性。
构建可以由每个开发人员在添加新代码时完成，也可以由“构建服务器”定期完成。最后一种方法需要更多设置，但有助于更快地发现构建错误。
There is no cookbook for working with software development, but in general the version control system should be the heart of your build system, even if you are working in a project where you are the only developer. Even in this case, being able to revert versions and read the version log is very welcome help in fixing bugs. This is not the only feature of a version control system, but this alone justifies installing, configuring and maintaining a version control system.
The build can be done either by each developer when adding new code, or periodically by a "build server". The last approach requires more setup, but helps finding out build errors sooner.
简短的回答是“这取决于”。
目前，我正在自己开发一个项目，所以我是构建/使用 VCS 的人。我知道在其他地方，你们的团队通过电子邮件一起致力于该项目。令人震惊。或者使用 VCS 的大型 (+5) 团队。
在这一点上，我强烈建议至少学习一些 VCS，Joel Spolsky 有一个很棒的 Mercurial 介绍性教程。 Bazaar（我个人的选择）是相似的，然后 Git 就相似性而言是第二接近的，但可能比其中任何一个都更受欢迎（至少是 ATM）。之后你就有了 SVN，相比之下它相当弱。
事实上，Joel 谈论解决了您的大部分问题 - 我建议您阅读 10 年他拥有的档案 - 这些都是非常有用的信息，其中大部分与您当前和近期的情况相关。
The short answer - "It depends".
Currently, I'm working on a project by myself, so I'm the one who builds/uses VCS. I know of other places that you have teams working on the project together by shudder email. Or big (+5) teams using VCS.
On that note, I highly recommend learning at least some VCS, and Joel Spolsky has a great introductory tutorial for Mercurial. Bazaar (my personal choice) is similar, and then Git is the next nearest in terms of similarity, but probably more popular than either (at least ATM). After that you have SVN which is pretty weak in comparison.
Actually, Joel talks about most of your questions - I'd recommend reading the 10 years of archives he has - it's all highly useful information, and most of it pertinent to your current and near-future situation.
正确的编程是一件很深刻的事情，从经验中受益匪浅。结对编程就像运行多个意识处理器……一个人可能会忽略另一个人看到的东西，只要他们进行交流，就可以取得巨大的进步。
Proper programming is a deep thing that benefits greatly from experience. Pair-programming is like running multiple processors of awareness... one can overlook something seen by the other and so long as they are communicating it can result in great progress.
首先，团队通过使用存储库（可以是专业版本控制，或者只是一堆被认为是“实时”目录的目录，但修订控制系统是事实上的标准）来工作。此外，项目管理策略的方式取决于您的工作方式（瀑布式、敏捷式等）。如果您以迭代方式工作，您将构建自我维持的组件/插件/模块/库，并执行单元测试，直到完成为止。作为一个团队，您在一个团队中工作，这意味着您不会同时在任何地方处理整个项目。相反，您将获得在项目领域内执行的任务。在某些情况下，您必须修复不属于您的代码，但这通常发生在发生奇怪的行为时。基本上，您正在对您开发的部件进行测试。
让我为您举例说明这一点。你在一个建筑工人团队中。建筑师提出建筑计划，工头查看建造的必要条件，然后雇用建造者。泥瓦匠砌墙，检查它们的强度并将它们很好地粘合起来。电工负责建筑物内的所有布线，以便电力能够流通。每个人都有自己的工作。有时，电工可能想与石匠讨论是否可以雕刻某些墙壁，但总是与工头一起讨论。
我希望这对您有帮助！
First of all, teams work by using repositories (which can be professional version control, or just a bunch of directories that is considered the 'live' one, however a revision control system is the de facto standard). Also, how the project is managed strategy depends on how you work (waterfall, agile, etc.). If you work in iterations, you build components/plugins/modules/libraries which are self-sustained, and you perform unit testing, until its signed off as finished. As a team, you work in a team which means you do don't work on the entire project everywhere at the same time. Instead, you get a task to perform inside a realm of the project. On some occasions you have to fix code that isn't yours, but that comes usually when a strange behavior occurs. Basically, you are doing the testing of the parts you develop.
Let me examplify this for you. You are inside a team of construction workers. The architect comes with a plan for a building, the foreman looks what the necessities are to construct and then hires the constructors. The mason does the walls, checks them for strength and glues them up nicely. The electrician does all the wiring inside the building so electricity can flow. Each man has their own job. Sometimes, the electrician might want to discuss with the mason if certain walls can be carved, but always in conjunction with the foreman.
I hope this is some help for you!
通常，源代码控制系统包含源代码，但通常没有二进制文件。如果您想构建并运行它，您可以检查代码并在本地计算机上构建它。
有些地方每晚运行构建以确保一切正常。甚至可能有一些在服务器端运行的自动化测试。如果构建或其他任何事情失败，系统会自动通知某人。
Typically, the source control system contains the source code and usually does not have the binaries. If you want to build it and run it, you would check the code out and build it on your local machine.
Some places run nightly builds to make sure everything works. There may even be some automated tests that are ran server-side. If the build or anything else fails, someone is notified automatically.
Eric Sink 的源代码控制 HOWTO http://www.ericsink.com/scm/source_control.html" rel="nofollow noreferrer">http://www.ericsink.com/scm/source_control.html 很好地介绍了使用源代码控制的方法。 ericsink.com/scm/source_control.html
在他的示例中，他使用了 SourceGear Vault，因为他编写了它，但这些方法可以应用于其他版本控制系统。
A good introduction to a method of using source control is Eric Sink's Source Control HOWTO http://www.ericsink.com/scm/source_control.html
In his examples he uses SourceGear Vault since he wrote it and all, but the methods can be applied to other version control systems.
这又是人们应该研究开源项目的一个很好的理由。
在大型开源项目（如 Chromium、Mozilla Firefox、MySQL、Popular Gnu Software）中工作的首席开发人员都是专业人士。他们拥有丰富的经验，这些项目是在数百名此类专业人士的想法的帮助下经过多年发展的。
其他人在答案中提到的所有内容（计划、版本控制系统、问题跟踪器、通知系统、构建系统、测试套件）都可以在这些开源项目中找到。
如果你真的想要亲身体验，我强烈建议你去体验一些流行的和有趣的东西。大型开源项目，然后从任何项目获取源代码（使用版本控制）并自行构建。
PS：我也是一名学生，参与开源项目是我一生中做过的最好的事情。相信我！你也会有同样的感觉。
This is again one good reason why one should look into Open Source projects.
The lead developers who work in big OpenSource projects (like Chromium , Mozilla Firefox, MySQL , Popular Gnu Software) are professionals. They have lot of experience and these projects have evolved over years with ideas from hundreds of such professionals.
Everything others mentioned in their answers (Plan, Version control system , Issue tracker , Notification system , Build system, Test suite, ) can be found in these OpenSource projects.
If you really want an hands on experience I strongly suggest you to go through some popular & big OpenSource projects and then get the Source from any project (using Version Control) and build it your self.
PS: I'm also a student and involving in OpenSource projects is the best thing I ever did in my life. Trust me! you'll also feel the same.