在Java项目里增加一门语言总该有正当的理由和根据。在这一节，我们希望你想想那些理由，以及如何把它们应用到你的项目中。
一开始我们会快速比较一下Scala跟Java，然后看看什么时候，以及如何开始使用Scala。为了让这一篇幅较短的章节更完整，我们会看一些示警信号，当出现这些信号时，Scala可能不是最适合你项目的语言。
9.2.1 Scala和Java的比较
我们在表9-1中对这两种语言的主要差异做了汇总。语言的“表皮层”是指该语言关键字的数量和开发人员用它干活必须掌握的独立语言结构的数量。
表9-1 比较Scala和Java
这些差异是Scala得到Java开发人员青睐，可以把它当做某些项目或组件的备选语言的部分原因。接下来我们会给出把Scala引入项目的更多细节。
9.2.2 何时以及如何开始使用Scala
我们在第7章讨论过，在已有项目中引入新语言时，最好从风险比较低的区域开始。ScalaTest测试框架（见第11章）就是这样的低风险区。如果Scala实验不顺利，那所有的成本就是开发人员浪费的时间（这些单元测试有可能变成普通的JUnit测试）。
一般来说，适合在项目中引入Scala的组件应该基本满足下面这些条件：
- 你有信心评估所需的工作量；
- 问题域边界明确，定义清晰；
- 需求说明正确；
- 与其他组件的互操作性需求已知；
- 确定了愿意学习新语言的开发人员。
经过深思熟虑选定合适区域后，你就可以开始实现自己的第一个Scala组件了。下面有些指导原则，事实证明它们能让初始组件按部就班地进行：
- 以快速扣杀开始；
- 尽早跟已有的Java组件测试交互操作；
- 有定义扣杀成功或失败的入门标准（基于需求）；
- 如果扣杀失败，要有B计划；
- 在预算中为新组件留出额外的重构时间（用新语言编写的第一个项目欠下的技术债几乎肯定会比用团队已经熟悉的语言编写来得高）。
在评估Scala时，另外一个应该考虑的是检查那些明显让Scala对项目来说不太理想的迹象。
9.2.3 Scala可能不适合当前项目的迹象
下面这些迹象表明Scala可能并不适合你的项目。如果出现了其中一个或多个迹象，你应该慎重考虑引入Scala的时机是否恰当。如果超过两个，那基本就没什么戏了。
- 受到了业务小组和其他程序支持小组的抵制，或缺乏动力。
- 开发团队没有明显的学习Scala的动力。
- 小组中分帮结派或政治上存在巨大分歧。
- 小组中高级技术人员的支持力度不够。
- 截止日期太紧张（没时间学习新语言）。
另外一个要密切关注的因素是，团队是否分散在全球各地。如果你用来开发（或支持）Scala代码的员工分散在几个地方，那会增加Scala培训人员的成本和负担。
现在我们已经讨论过把Scala引入项目的机制了，接下来该去看看Scala的语法了。我们会重点关注让Java开发人员更轻松的特性，鼓励更加紧凑的代码，少点套路化和挥之不去的繁琐。