unit-testing - 程序员如何在一个项目上协同工作？

Question

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

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

软件是怎么编译的？它来自版本控制系统吗？是由个别程序员吗？是周期性的吗？是在有人决定 build 还是什么的时候？是否进行了任何测试以确保它“有效”？

什么都行。

Answer 1

实际上，这些流程的变化与有多少公司一样多。意思是:每家公司的惯例都与其他公司略有不同，但有一些通用的最佳实践通常在大多数地方使用。

始终有用的最佳实践

全部 项目的源代码以及构建它所需的任何内容都处于版本控制(也称为源代码控制)之下。 任何人 应该能够一键构建整个项目。
此外，不必要的文件(目标文件或编译后的二进制文件)应该 不是 被添加到存储库中，因为它们可以很容易地重新生成并且只会浪费存储库中的空间。

每个开发者都应该更新 和 提交 每天几次版本控制。大多数情况下，当他们完成他们正在处理的任务并对其进行足够的测试后，他们就知道它不包含微不足道的错误。

再次:任何人应该能够通过单击构建项目。这很重要，并且让每个人都可以轻松进行测试。如果非程序员(例如老板)也能够这样做，那将是一个巨大的优势。 (这让他们觉得能够准确地看到团队正在做什么。)

每位开发者 应该测试 他们添加的新功能或错误修复 之前 他们将这些提交到存储库。

设置一个服务器，定期(以预定的时间间隔)从存储库更新自身并尝试构建 一切在 整个项目 .如果失败，它会向团队发送电子邮件以及对版本控制的最新提交(从哪个提交未能构建)以帮助调试问题。
这种做法称为持续集成，构建也称为夜间构建。
(这并不意味着开发人员不应在自己的机器上构建和测试代码。如上所述，他们应该这样做。)

显然，大家应该熟悉项目的基本设计/架构，因此如果需要某些东西，团队的不同成员不必重新发明轮子。编写可重用的代码是一件好事。

某种 通讯团队成员之间需要。每个人都应该知道其他人在做什么，至少是一点点。越多越好。这就是为什么每日站会 在 SCRUM 团队中很有用。

单元测试 是一种非常好的做法，可以自动测试代码的基本功能。

A 漏洞跟踪软件 (有时称为时间跟踪软件)是跟踪存在哪些错误以及不同团队成员有哪些任务的非常好的方法。这也有利于测试:您项目的 alpha/beta 测试人员可以通过这种方式与开发团队进行交流。

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

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

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

还有一些想法

上面的列表乍一看可能非常重量级。我建议您在 上关注它按需 基础:从版本控制和错误跟踪器开始，然后在需要时设置持续集成服务器。 (如果它是一个大型项目，您很快就会需要它。)开始为最重要的部分编写单元测试。如果还不够，那就多写点吧。

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

例子:

对于版本控制，我倾向于使用 Git对于我现在的个人项目。 Subversion也很流行，比如 VisualSVN如果您使用 Windows 服务器，则设置起来非常容易。对于客户， TortoiseSVN最适合许多人。 Here is a comparison between Git and SVN.

对于错误跟踪软件， Jira和 Bugzilla很受欢迎。我们还使用了 Mantis在以前的工作场所。

对于持续集成软件，有 Teamcity其中之一(还有 CruiseControl 和它的 .NET counterpart 值得注意)。

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

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

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