建立一个新的Java开发商店

Question

我正在建立一个Java开发商店，目前仅供我自己作为唯一的开发人员，但随着业务的增长需要雇用其他人。显然，我希望将其设置得正确，以便随着更多人的加入，他们可以立即提高工作效率。请帮助建议我想做的事情，以及做这些事情的工具。

这就是我认为我需要的东西：

• 分布式源代码/版本控制（Subversion？）
• 错误跟踪（Trac会这样做吗？）
• 文档（内部和面向客户）
• 团队沟通
• 频繁的自动化建设
• 可能会确保自动测试在签入过程中通过了吗？

Answer 1

我喜欢Hudson的持续集成构建，我喜欢JIRA进行问题跟踪。 Eclipse有两个插件。

Hudson可以观看软件存储库并重建那些使用已更改资源的项目。

如果你需要比javadoc更多的文档（这是很多），那么考虑一下Wiki。易于使用，有一点结构，您可以将其按摩成PDF。

源代码控制是一个错误。太多可供选择。对于一个小型开发团队来说，可以从subversion或CVS开始（这是旧的但具有最高的IDE支持），当你长大并了解自己的需求时，就转移到更好的开发团队。大多数人都有svn或cvs的迁移工具。从例如移动更难git到Mercurial，你肯定希望有一个实现多个。记住要有源控制存储库的良好备份 - 这是您的业务。频繁的rsyncs，通常是磁带。

---

编辑：你也想要不错的硬件。对于Continuous Integration服务器，您可以负担得起的最快的构建机器。对于您自己来说，您可以负担得起的最大显示器（不是尺寸，分辨率）适用于您的主显示器和尽可能多的额外显示器（包括适配器到您的计算机）。我发现Mac使用的像素比Windows好，所以这也可能是一个重点。

我的主显示器旋转90度。这允许我一次看到许多行而不是几行。 （由于某种原因，传统说编辑区域应该宽而短，这可能在单词中起作用，但在代码中不能超过72个字符的代码中起作用）

关于Eclipse的注意事项：使用源存储库为每个项目创建一个工作区！使用Java编辑器保存功能可以在每次保存时重新格式化代码 - 这使得它在前面更具可读性，并且在源库中更好，因为更改标记在正确的版本中。

---

编辑：CI服务器需要比开发机器更好的原因是因为每次将内容检查到源存储库时它都会运行所有测试。过了一会儿，这需要时间。

就我个人而言，我发现测试适用于库例程。它们指明哪些有效，哪些无效。为整个应用程序编写好的测试更难，但是你可能想从头开始研究它，因为它可以确保一切都适用于每次检查。如果你不熟悉这个概念，写一个评论。 / p>

无论您选择哪个部件，如果他们能够一起工作，您将会很高兴。例如，Hudson知道如何与JIRA交谈。 JIRA知道如何查看CVS。

Answer 2

要了解大量人员如何构建良好的软件开发环境，请阅读joels test

的12个点。

此列表不包含对您更重要的内容。让客户让他们支付和管理合法的东西和税收。

Answer 3

最重要的是，合适的员工：

• 找到工作和处理客户（又名销售人员）的优秀人才
• 让聪明的软件工程师完成工作（http://www.joelonsoftware.com/items/2007/06/05.html）
• 找一个了解会计和当地法律和税收法规的人，这样你就不会有任何惊喜

工具/流程：

• 使用分布式版本控制系统，如git或mercurial
• jira等用于错误/问题跟踪
• 与哈德森或巡航控制的持续整合
• 维基系统分享团队的实际知识
• 单元测试，三叶草，checkstyle，findbugs，......

从管理角度来看，我会尝试

• 每日站立会议（结账scrum），让团队更新成员通过说出做了什么，做什么和将做什么来提交
• 时间盒会议，其他一切都很糟糕。
• 计划迭代/冲刺
• 让团队进行任务时间估算
• 结对编程（让你获得更好的代码）
• 代码评论（建立信任）
• 每周内部“techtalks”为团队建立强烈的感觉
• twitter就像通信工具一样，保持所有不同步并以最少的注意力进行通知
• 将团队发展为动态语言（groovy，scala，...）
• 你自己，听听http://manager-tools.com/的那些人说的话......

祝你好运！

Answer 4

我们一直在使用：

版本控制：

• subversion - 它没有分发，但如果防火墙存在问题，可以通过几种不同的协议访问它。我不确定我们是否需要分布式版本控制，阅读Eric Sink's take至少是有趣的

问题跟踪：

• Fogbugz - 由于内置的​​维基和讨论板，您可以免费与团队进行讨论和沟通。

持续整合：

• CruiseControl - 我们一直在谈论切换到Hudson，但Cruise现在工作得很好 - 它运行我们的单元测试。

开发环境：

• Netbeans和Eclipse - 没有理由支付Java IDE。快速进入的一个导入点是Netbeans和Eclipse都将所有项目数据存储为文本文件，版本控制得很好。见this question。使用IDE which used binary project files时，我们感到头疼。

分析器：

• JDK VisualVM - 免费且有效。我曾经非常喜欢YourKit，但VisualVM现在做了很多。

机制的文档：

• javadoc和fogbugz wiki页面的组合以及内部的巡航仪表板。对于外部我们正在使用RoboHelp而我们不喜欢它。

其他工具：

• Findbugs - 有助于捕捉有时真正愚蠢的事情，有时甚至是你从未意识到的惊人怪癖。 PMD也适用于其中一些。
• 我们发现聊天工具对沟通非常有帮助。我们曾经访问Sametime并且它有一个非常棒的会议功能。然而，那被霸主带走了一个未知的原因。

Answer 5

以下是我们的五位开发人员团队在一年内使用的开发堆栈：

• Eclipse IDE（对我们来说比NetBeans更好）
• Maven作为一个项目理解和构建工具 - 只是一个必须的工具！
• Nexus：Maven Repository Manager - 用作代理，管理内部和第三方库的本地Maven仓库;使用简单，如果您打算使用Maven
，这是非常必要的
• Subversion for source versioning - 之所以被选中，主要是因为非常好的IDE支持（Eclipse IDE的Subclipse）
• Trac作为一个bug跟踪和需求管理工具 - 它很好地与Subversion集成，有非常有用的插件，包括博客和讨论插件;它也可以与Eclipse Mylyn集成。
• Hudson作为持续集成，与Subversion，Maven和Trac很好地集成 - 即使对于一个小团队也非常有价值。
• Sonar代码质量管理平台 - 将大量代码质量矩阵与直观的Web界面集成的工具，支持代码审查和深入分析，以分析问题;与Maven集成。

在我们的例子中，这个开发堆栈在Ubuntu（工作站组件：Eclipse IDE，Maven）和CentOS（服务器组件：Maven，Nexus，Subversion，Trac，Hudson，Sonar）下运行。

至于文档，LaTeX（Ubuntu下的TexLive和Kile）可以很好地支持高质量的PDF生成。 Subversion可以像应用程序源一样管理文档源。允许制作简单的多页文档和大型多章书。

希望这有帮助。

Answer 6

分布式源代码/版本控制（Subversion？）

• Subversion足够好，除非您想将此作为学习Git或Mercurial的机会。

错误跟踪（Trac会这样做吗？）

• 如果您不介意CamelCaseTurningIntoWikiWords，Trac可以正常工作。 JIRA比较漂亮，但（如上所述）不是免费的，我发现它data-ink ratio非常低。一旦你了解了UI的哪些部分可以忽略，那就很好。

文档（内部和面向客户）

• 在内部，我更愿意沟通文档，除非你真的愿意花时间保持内部文档的更新。 Javadoc您的集成点（内部/外部API），但尽量保持您的代码和构建脚本尽可能自我记录。

• 那就是说，需求文档很有用。我建议使用一个跟踪系统来处理错误和要求。 JIRA允许您创建分层问题，但在您需要之前我不会为此烦恼。

• Trac包含一个Wiki，虽然太多内容会变得陈旧，但它可以很方便。

• 面向客户的文档遍布地图 - 很大程度上取决于您正在做什么。如果你需要大手册（打印或HTML或在线帮助），FrameMaker + DITA Open Toolkit是一个不错的组合，但是FrameMaker许可证会让你回到1000美元。

• 在某一点上，这会影响企业传播（marcom和PR），这是一种不同的动物。

团队沟通

• Google Talk（或您选择的即时消息框架），电子邮件以及偶尔的Skype电话会议可能都是您所需要的。

• 内部维基和/或内部博客可能不错，但即使您添加了更多开发人员，也可能不会马上使用它们。 Trac包含一个维基。

频繁的自动化建设

• 从CruiseControl切换到Hudson让这里的每个人都更加快乐 - 两个团队独立做出了同样的决定，他们都很满意。 Hudson的灵活性，易于配置和闪亮。

• 我还没有被Maven说服。我怀疑它的价值取决于您希望自动下载所有开源库的最新版本的程度。

  • 编辑（2010年2月）添加：现在有几个月的Maven 2经验，我仍然不相信。我认为（像许多框架一样，例如Rails）如果你从头开始并按照惯例构建你的项目，它可能会很好用，但是如果你已经有了自己的结构，那么它就没那么有利了。

可能需要确保自动测试在签到过程中通过？

• 我建议不要这样做。大多数情况下测试将通过（或者应该是，无论如何）只要持续集成能够快速通知您失败，并且您还拥有稳定的自动构建（几天的夜间构建，标记的迭代构建等） 。），你想要更多更快的签到，而不是更少和更慢。

Answer 7

Subversion 不分布式方法 - 改为Mercurial，Bazaar或git！

是的，Trac会进行错误跟踪（除此之外 - 检查out！）。

文档确实是必须的，但我不确定你在问什么 - 工具呢？为什么不只是javadoc？

对于沟通，您可以使用许多工具，例如Skype，电子邮件，多种IM等等 - 我认为您需要更好地表达您的具体问题以获得具体建议。谷歌浪潮一旦成熟可能会很好，但它还没有生产就绪。

对于持续构建签出CruiseControl - 当然它也运行测试＆amp; c。

你可以为我提到的任何构建系统（甚至是旧的svn ;-)编写“触发器”来运行一些测试套件，如果失败则拒绝提交。

Answer 8

还有一些项目：

• IDE
• 计费软件 - 你会收费吗？ 小时？如果是这样，您可能想跟踪 你的时间是什么。
• 某种异地备份。

您的每一个要点可能都是社区维基。虽然最后你可能不太关心每个领域的最佳品种，但更关心它们与你的IDE或彼此的整合程度。

另外，如果您真的希望让新的队友快速上手并运行，请考虑尽可能多地将您的开发环境放入源代码管理中，这样您就可以将“dev-env”项目签出到新计算机上立即启动并运行！

Answer 9

您的一个规范（在您的问题中）说：

  

也许确保自动化   测试通过办理登机手续   过程

我建议这是必要的。查看this matrix of continuous integration servers以查看哪一个符合您的要求。

Answer 10

如果您只是自己作为唯一的开发人员，但在某些时候进行扩展，根据您正在开发的内容，可能值得查看平台即服务（PaaS）产品，例如https://www.openshift.com或https://www.heroku.com/，它们都提供开发者帐户，但您可以根据需要扩展到付费帐户。

OpenShift为Jenkins提供CI盒式磁带，因此您可以在几分钟内完成一次使用Jenkins和JBoss AS或WildFly等应用服务器的DVCS（git），根据您的需求和方式很多时候你想专心在本地设置它，我更倾向于使用PaaS。

Answer 11

不要使用Trac，而是考虑Redmine。它允许您在一个问题跟踪系统中存储多个项目。然后，您可以为每个项目使用相同的设置，而不必拥有N个Trac实例。

Answer 12

对于初学者来说，SVN对您来说已经足够了。肯定得到一个bugtracker。 JIRA很好，但不是免费的。强制执行“没有bugtrecker票证就没有提交”的规则。这样您就可以跟踪开发。在每次进入主分支后进行巡航控制并运行构建+单元测试。应在单独的分支上进行更大的更改，然后将其合并到主分支中。

投资一个好的IDE（我建议使用intelliJ IDEA）和一个好的分析器（我推荐JProfiler）。他们不是免费的，但他们绝对物有所值。