Closed. This question is
opinion-based。它当前不接受答案。
想要改善这个问题吗？更新问题，以便
editing this post用事实和引用来回答。
1年前关闭。
Improve this question
我是一名初级开发人员，最近开始在一个很小的办公室工作，他们在那里做很多内部开发工作。我从未参与过一个涉及多个开发人员的项目，或者像这些开发人员一样庞大和复杂的项目。
问题在于他们没有充分利用所有可用的工具(版本控制，自动化构建，持续集成等):主要是一个项目是eclipse/netbeans中的一个大项目，使用cvs进行版本控制，并且一切都已 checkin 。 (包括库jar)，当我开始为小任务创建分支并将它们合并回去时，它们第一次开始使用分支。随着项目变得越来越大，越来越复杂，依赖关系，与IDE关联的项目结构，建筑有时可能是PITA等问题开始出现。这充其量是忙碌的。
我想要的是建立一个开发环境，其中大多数问题都将消失，我可以节省时间和精力。我想以独立于版本控制使用的IDE的方式来设置项目(我现在倾向于SVN)，避免依赖困惑并尽可能地自动构建。
我知道有多种方法和工具可以解决此问题，并且不想看到一场神圣的 war ，我非常感谢根据经验和遇到类似问题时发现有用的实用建议。所有项目都是Java项目，范围从Web应用程序到“通用”项目，我大多数时候都使用Eclipse，但在需要时也使用Netbeans。提前致谢。
您似乎几乎正好在我1.5年前开始工作的那个地方，唯一的不同是您开始玩弄分支，而实际上这是我们在工作中仍然不做的事情但稍后会在此答案中提供更多信息。
无论如何，您列出了一组非常好的工具，这些工具可以帮助一家小型公司，并且这些子程序可以很好地作为子主题工作，因此，不用多说，
版本控制系统
大多数小公司目前都使用CVS或SVN，这没有什么不好，实际上，我真的担心如果根本没有使用任何版本控制。但是，您必须正确使用版本控制权，只有版本控制权才能使您的生活更轻松。我们目前使用CVS并正在研究Mercurial，但是我们发现在使用CVS时，以下内容可以作为一组很好的约定(我也怀疑SVN):
所有提交者都有单独的用户。知道谁犯了什么是无价的。 不允许空提交消息。实际上，如果可能的话，将存储库配置为拒绝没有注释和/或默认注释的任何提交。 FooBarizer的初始提交比Empty日志消息更好
使用标签来标记里程碑，原型(prototype)，alpha，beta，发行候选版本和最终版本。不要将标签用于实验性工作或用作脚注/Post-It notes。 不要使用分支，因为如果您继续开发应用程序，它们实际上将无法工作。这主要是因为在CVS和SVN中分支无法按预期工作，并且随着时间的推移保持两个以上的 Activity 分支(头分支和任何辅助分支)变得徒劳无益。 永远记住，对于软件公司而言，源代码是您的收入来源，并包含您的所有商业值(value)，因此请按这种方式对待。另外，如果您还有70分钟的时间，我真的建议您通过
this talk观看Linus Thorvalds在Google上提供的有关
git和(d)VCS的总体信息，这真的很有见地。
自动化构建和持续集成环境
这些实际上是相同的。
Daily builds是一个PR笑话，除了一些非常基本的“它可以编译吗？”之外，它与实际软件的状态几乎没有任何相似之处。问题。您可以编译很多无用的代码噪音，保持软件质量与编译代码无关。
另一方面，单元测试是保持软件质量的一种好方法，我可以个人自豪地说，严格的单元测试甚至可以帮助最差的程序员改善很多错误并捕获愚蠢的错误。实际上，到目前为止，我编写的代码只存在三个错误，这些错误已经到达了生产环境，我想说在18个月中，这真是一个了不起的成就。在我们的新生产代码中，我们的
code coverage指令通常为+ 80％，大多数情况下为+ 90％，在一种特殊情况下，一直达到98％。这部分是一个非常活跃的领域，您最好在以下方面进行谷歌搜索:TDD，BDD，单元测试，集成测试，验收测试，xUnit，模拟对象。
我知道这有点冗长。以上所有方面的实际目的是:如果您想拥有自动化构建，请在每次有人提交时进行自动构建，并确保针对生产代码的单元测试数量不断增加和改进。让您选择的持续集成系统(我们使用
Hudson CI)运行与项目相关的所有单元测试，并且仅在所有测试通过后才接受构建。不要妥协!如果单元测试表明该软件已损坏，请修复该软件。
此外，持续集成系统不仅用于编译代码，还应用于跟踪软件项目指标的状态。对于Hudson CI，我可以推荐所有这些插件:
Checkstyle-检查实际的源代码是否以您定义的方式编写。编写可维护代码的很大一部分是使用通用约定。 Cobertura-代码覆盖率指标，对于查看覆盖率随时间如何发展非常有用。此外，与“来源就是上帝”的思路保持一致，如果覆盖率低于某个特定水平，则可以丢弃建筑物。 Task Scanner-简单但轻松:扫描代码中的特定标签，例如BUG，TODO，NOTE等，并从中创建一个列表，以供所有人阅读。跟踪简短说明或需要修复的缺陷或已知缺陷的简单方法。 项目结构和依赖性管理
这是一个有争议的。基本上，每个人都认为拥有统一的结构是很棒的，但是由于存在多个阵营，它们的要求，习惯和观点各不相同，因此他们往往会意见分歧。例如，Maven的人真的相信只有一种方法-Maven的方法可以完成工作，而
Ivy支持者则认为项目结构不应该受到外部各方的束缚，只有依赖关系才需要妥善管理并以统一的方式只是并不清楚，我们公司只是喜欢 Ivy 。
因此，由于我们不使用外部参与者强加的项目结构，因此我将向您介绍一些有关我们如何融入当前项目结构的信息。
最初，我们将单个项目用于实际软件和相关测试(通常称为Product和Product_TEST)。这非常接近您所拥有的文件，一个巨大的目录包含与JAR直接相关的所有依赖关系，直接包含在目录中。我们所做的是，我们从CVS中 check out 了两个项目，然后将实际项目作为运行时依赖项链接到Eclipse中的测试软件项目。有点笨拙，但它起作用了。
我们很快意识到这些额外的步骤是完全没有用的，因为通过使用
Ant-顺便说一句，您可以直接在Hudson中调用Ant任务-我们可以告诉JAR/WAR构建步骤忽略文件名中的所有内容(例如， (以Test或TestCase结尾)或按源文件夹。不久，我们将软件项目转换为使用一个简单的结构，即两个根文件夹
src和
test。从那以后我们再也没有回头。当前唯一的争论是我们是否应允许在我们的标准项目结构中存在名为
spikes的第三个文件夹，而这根本不是一个非常激烈的争论。
这非常有效，并且不需要任何其他IDE的任何其他支持或插件，这是一个很大的优点-我们没有选择Maven的第二个原因是
M2Eclipse基本上是如何接管Eclipse的。而且，由于您一定想知道，拒绝Maven的第一个原因是Maven本身的笨拙，无休止的冗长的XML声明用于配置以及相关的学习曲线被认为对于使用它会产生太大的成本。
有趣的是，稍后提交Ivy而不是Maven使得我们可以平稳地进行一些
Grails开发，该开发在构造Web应用程序时使用文件夹和类名作为几乎所有内容的约定。
也是关于Maven的最后一点，尽管它声称要促进约定优于配置，但如果您不想按照Maven的结构所说的应该做的事情来做事情，则由于上述原因，您会感到痛苦。当然，拥有约定是一种预期的副作用，但是约定不应该是最终的，总是必须至少有一些更改的余地，弯曲规则或从特定的集合中选择适当的规则。
简而言之，我认为Maven是火箭筒，您在房子里工作，而您的最终目标是确保它没有错误。尽管您选择了其中任意两个，但它们中的每一个都很好并且可以工作，但是三个一起工作是行不通的。
最后的话
只要您少于10名以代码为中心的人员，您就具有执行重要决策所需的全部灵活性。当您超越这一点时，无论选择是好是坏，您都必须忍受所做的任何选择。不要只是相信您在Internet上听到的东西，坐下来并严格地测试所有内容-哎呀，我们的高级技术人员甚至写了关于Java Web框架的单例汉论文，只是为了弄清楚我们应该使用哪种框架-并真正弄清您的想法真的需要。不要仅仅因为您可能需要它在不久的将来提供的某些功能而做出任何 promise ，而是选择那些对整个公司造成最小负面影响的事情。作为我工作的公司的第十个人，我可以用自己的鲜血在本段中的所有内容下签名，我们目前有16多名员工在工作，改变某些惯例在这一点上确实有点吓人。