建立一个新的Java开发工作室
我正在建立一个Java开发商店，目前仅供我自己作为唯一的开发人员，但随着业务的增长需要雇用其他人。 显然，我希望将其设置正确，以便随着更多人进来，他们可以立即发挥作用。 请帮助建议我想要做的事情，以及做这些事情的工具。
这是我认为我需要的：
- 分布式源代码/版本控制（Subversion？）
- 错误跟踪（Trac会这样做吗？）
- 文档（内部和面向客户）
- 团队沟通
- 经常自动化建设
- 也许确保自动测试作为签到过程的一部分通过的东西？
我喜欢Hudson的持续集成构建，我喜欢JIRA进行问题跟踪。 Eclipse有两个插件。
Hudson可以监视软件存储库并重建那些使用已更改资源的项目。
如果你需要比javadoc更多的文档（这是很多），那么考虑一下Wiki。 易于使用，有一点结构，你可以按摩成PDF。
源代码控制是一个bugger。 太多可供选择。 对于一个小型开发团队来说，无论是subversion还是CVS（这都是旧的但具有最高的IDE支持），当你长大并了解你的需求时，那么就转移到更好的。 大多数都有svn或cvs的迁移工具。 从例如git转移到Mercurial更难，而且你明确地想要一个具有多个实现的人。 记住要对源代码控制存储库进行良好的备份 – 这是您的业务。 频繁的rsyncs，通常是磁带。
编辑：你也想要体面的硬件。 对于Continuous Integration服务器，您可以负担得起的最快的构建机器。 对于您自己而言，您可以为主显示器提供最大的显示器（不是尺寸，分辨率）以及您可以承受的额外显示器（包括适配器到您的计算机）。 我发现Mac使用的像素比Windows好，所以这也可能是一个重点。
我的主显示器旋转90度。 这允许我一次看到许多行而不是几行。 （由于某种原因，传统说编辑区域应该宽而短，这可能在单词中起作用，但在代码中不能超过72个字符的代码中起作用）
关于Eclipse的注意事项：使用源存储库为每个项目创建一个工作区！ 使用Java编辑器保存function可以在每次保存时重新格式化代码 – 这使得它更具可读性，并且随着更改以正确的版本标记，源代码库更好。
编辑：CI服务器需要比开发机器更好的原因是因为每次将内容检查到源存储库时它都会运行所有测试。 过了一会儿，这需要时间。
就个人而言，我发现测试适用于库例程。 它们指明哪些有效，哪些无效。 为整个应用程序编写好的测试更难，但是你可能想从头开始研究它，因为它允许你确保一切都适用于每次签入。如果你不熟悉这个概念，写一个评论。
无论您选择哪个部件，如果他们能够一起工作，您将会很高兴。 例如，Hudson知道如何与JIRA交谈。 JIRA知道如何看待CVS。
要了解大量人们想要建立一个良好的软件开发环境，请阅读本文关于12点的joel测试
此列表不包括对您更重要的事项。 让客户让他们支付和管理合法的东西和税收。
最重要的是，合适的员工：
- 找到工作和处理客户的优秀人才（又名销售人员）
- 让聪明的软件工程师完成工作（ http://www.joelonsoftware.com/items/2007/06/05.html ）
- 找一个了解会计和当地法律和税收法规的人，这样你就不会有任何意外
工具/流程：
- 使用像git或mercurial这样的分布式版本控制系统
- 用于错误/问题跟踪的jira等
- 与哈德逊或巡航控制系统持续集成
- 维基系统分享团队切实的知识
- unit testing，三叶草，checkstyle，findbugs，…
从管理的角度来看，我会尝试
- 每日站立会议（结账scrum），让团队更新成员通过说出做了什么，做什么和将做什么来提交
- 时间盒会议，其他一切都很糟糕。
- 计划迭代/冲刺
- 让团队做任务时间估计
- 结对编程（获得更好的代码）
- 代码评论（建立信任）
- 每周在家里“techtalks”为团队建立强烈的意识
- Twitter喜欢通信工具，以最小的分心保持所有insync和通知
- 培养团队走向动态语言（groovy，scala，……）
- 亲自，听听http://manager-tools.com/上的那些人不得不说…
祝好运！
我们一直在使用：
版本控制：
- subversion – 它没有分发，但如果防火墙是个问题，它可以通过几种不同的协议访问。 我不确定我们是否需要分布式版本控制，阅读Eric Sink的观点至少是有趣的
问题跟踪 ：
- Fogbugz – 由于内置的wiki和讨论板，您可以免费获得团队讨论和沟通。
持续集成：
- CruiseControl – 我们一直在谈论切换到Hudson，但Cruise现在工作得很好 – 它运行我们的unit testing。
开发环境：
- Netbeans和Eclipse – 没有理由支付Java IDE。 快速进入的一个导入点是Netbeans和Eclipse都将所有项目数据存储为文本文件，版本控制得很好。 看到这个问题 。 使用使用二进制项目文件的IDE时，我们头痛不已。
探查：
- JDK VisualVM – 它是免费的，它的工作原理。 我曾经非常喜欢YourKit，但VisualVM现在做的很多。
机制的文档：
- 结合了javadoc和fogbugz wiki页面以及内部的巡航仪表板。 对于外部我们使用RoboHelp而我们不喜欢它。
其他工具：
- Findbugs – 有助于捕捉有时真正愚蠢的东西，有时甚至是你从未意识到的惊人怪癖。 PMD也适用于其中一些。
- 我们发现聊天工具对沟通非常有帮助。 我们曾经访问过Sametime ，它有一个非常棒的会议function。 尽管如此，这被一些未知的原因带走了。
以下是我们的五位开发人员团队在一年内使用的开发堆栈：
- 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很好地集成 – 即使对于一个小团队也非常有价值。
- 声纳代码质量管理平台 – 将大量代码质量矩阵与直观的Web界面集成的工具，支持代码审查和深入分析问题; 与Maven集成。
在我们的例子中，这个开发堆栈在Ubuntu（工作站组件：Eclipse IDE，Maven）和CentOS（服务器组件：Maven，Nexus，Subversion，Trac，Hudson，Sonar）下运行。
至于文档，LaTeX（Ubuntu下的TexLive和Kile）可以很好地支持高质量的PDF生成。 Subversion可以像应用程序源一样管理文档源。 允许制作简单的多页文档和大型多章书。
希望这可以帮助。
分布式源代码/版本控制（Subversion？）
- Subversion很好，除非你想用它作为学习Git或Mercurial的机会。
错误跟踪（Trac会这样做吗？）
- 如果你不介意CamelCaseTurningIntoWikiWords，Trac工作正常。 JIRA很有魅力，但（如上所述）不是免费的，我发现它的数据墨水比率非常低。 一旦你了解了UI的哪些部分可以忽略，那就很好了。
文档（内部和面向客户）
-
在内部，我更愿意沟通文档，除非你真的愿意花时间保持内部文档的更新。 Javadoc您的集成点（内部/外部API），但尽量保持您的代码和构建脚本尽可能自我记录。
-
也就是说，需求文档很有用。 我建议使用一个跟踪系统来处理错误和要求。 JIRA允许您创建分层问题，但在您需要它之前我不会打扰它。
-
Trac包含一个Wiki，虽然太多的内容会变得陈旧，但它可以很方便。
-
面向客户的文档遍布地图 – 很大程度上取决于您正在做什么。 如果你需要大手册（打印或HTML或在线帮助），FrameMaker + DITA Open Toolkit是一个很好的组合，但是FrameMaker许可证会让你回到1000美元。
-
在某种程度上，这涉及企业通信（marcom和PR），这是一种不同的动物。
团队沟通
-
您可能只需要Google Talk（或您选择的即时消息框架），电子邮件和偶尔的Skype电话会议。
-
内部维基和/或内部博客可能不错，但即使您添加了更多开发人员，也可能不会立即使用它们。 Trac包含一个wiki。
经常自动化建设
-
从CruiseControl切换到Hudson让这里的每个人都更加快乐 – 两个团队独立做出了同样的决定，并且都很满意。 Hudson的灵活性，易于配置和shiny。
-
我还没有被Maven说服。 我怀疑它的价值取决于您希望自动下载所有开源库的最新版本的程度。
- 编辑（2010年2月）补充：现在几个月的Maven 2经验，我仍然不相信。 我认为（像许多框架一样，例如Rails）如果你从头开始并按照惯例构建你的项目，它可能会很好用，但是如果你已经拥有自己的结构，那么它就没那么有利了。
也许确保自动测试作为签到过程的一部分通过的东西？
- 我建议不要这样做。 大多数情况下测试将通过（或者应该是，无论如何）只要持续集成能够快速通知您失败，并且您还拥有稳定的自动构建（几天的夜间构建，标记的迭代构建等） 。），你想要更多更快的签到，而不是更少，更慢。
Subversion 不是一种分布式方法 – 改为Mercurial，Bazaar或git！
是的，Trac确实进行了错误跟踪（除此之外 – 检查出来 ！）。
文档确实是必须的，但我不确定你在问什么 – 工具呢？ 为什么不只是javadoc ？
对于沟通，您可以使用许多工具，例如skype，电子邮件，多种IM等等 – 我认为您需要更好地表达您的具体问题以获得具体建议。 谷歌浪潮一旦成熟可能会很好，但它还没有生产就绪。
对于连续构建检查CruiseControl – 当然它也运行测试＆c。
您可以为我提到的任何构建系统（甚至是旧的svn ;-)编写“触发器”来运行某些测试套件，如果失败则拒绝提交。
还有一些项目：
- IDE
- 计费软件 – 您会按小时收费吗？ 如果是这样，您可能想要跟踪您的时间。
- 某种异地备份。
你的每个子弹点都可能是社区维基。 虽然最后你可能不太关心每个领域的最佳品种，但更关心它们与IDE或彼此的整合程度。
此外，如果您真的希望让新的队友快速上手并运行，请考虑尽可能多地将您的开发环境放入源代码管理中，这样您就可以将“dev-env”项目签出到新计算机上并启动马上跑！
您的一个规格（在您的问题中）说：
也许确保自动测试作为签到过程的一部分通过的东西？
我建议这是必不可少的 。 查看这个连续集成服务器矩阵，看看哪个符合您的要求。
如果您只是自己作为唯一的开发人员，但在某些时候扩展，根据您正在开发的内容，可能值得查看平台即服务（PaaS）产品，例如https： //www.openshift.com或https://www.heroku.com/ ，两者都提供开发者帐户，但您可以根据需要扩展到付费帐户。
OpenShift为Jenkins提供CI盒式磁带，这样你就可以在几分钟内完成DVCS（git），使用Jenkins的CI以及像JBoss AS或WildFly这样的app服务器…根据你的需求和你花多少时间我希望致力于在本地设置这个，我更倾向于使用PaaS。
而不是使用Trac，考虑Redmine。 它允许您在一个问题跟踪系统中存储多个项目。 然后，您可以为每个项目使用相同的设置，而不必拥有N个Trac实例。
对于初学者来说，SVN对您来说已经足够了。 肯定会得到一个bugtracker。 JIRA很好，但不是免费的。 实施规则“没有bugtrecker票证就没有提交”。 这样您就可以跟踪开发。 在每次进入主分支后进行巡航控制并运行构建+unit testing。 应在单独的分支上进行更大的更改，然后将其合并到主分支中。
投资一个好的IDE（我推荐intelliJ IDEA）和一个好的剖析器（我推荐JProfiler）。 他们不是免费的，但他们绝对物有所值。