Question

首先，通过SBT的增量构建非常棒，通常在＆lt; 1秒范围。但是，有时您必须进行完全清理/编译，或者在增量构建的情况下，您对一个文件进行更改，然后触发编译其他几十个文件。

这就是Scala开发变得不那么有趣了，因为工作流程的减慢可以鼓励上下文切换（检查电子邮件，最新的Stackoverflow线程等），这会巧妙地降低工作效率

那么，为了改进完整的清理/编译构建，以及（理想情况下）更改一个文件而不重新编译一半应用程序增量构建，需要避免哪些开发方法？

我能想到的例子：
1）最好有一千多行的do-it-all scala文件，或几个文件分开？
2）我可以拥有蛋糕（模式）还是会延长构建时间？ 3）我可以使用pimp'd x，y，z库模式，或者更好地找到另一种方式吗？ 4）包装对象（带有隐含）是构建时间杀手吗？ 5）嵌套对象和特征？
6）隐含的方法/参数或停止聪明和明确？

具体来说，我正在考虑放弃我提出的蛋糕模式DAO并整合到ScalaQuery案例类+伴随对象+最小数据库提供程序特征中。仅此一项就会删除20个scala文件。

应用程序足够小（120 scala + 10个java文件）现在重构，没有太多麻烦。显然，随着scala应用程序的增长，构建时间也会增长，仅基于LOC。我只是想看看在哪里修剪脂肪以及在哪里不要打扰（即保持原样），因此当前和未来的应用程序将受益于scala提供的表现力，而不会不必要地延长构建时间。

感谢您对scala开发的良好，糟糕和丑陋体验与构建时间相关的一些示例。

Answer 1

我注意到类型成员可以在你不期望的地方强制重建。例如：

foo.scala ：

object foo {
    class A {
        type F = Float
    }
    def z: Int = 8
}

bar.scala ：

object bar {
    def run { println(foo.z) }
}

更改z的值不会强制重新编译bar。即使F永远不会引用bar甚至引用F，也会更改A的类型。为什么，我不知道（Scala 2.9.1）。

Answer 2

看看how incremental recompilation works in SBT。

大致是这样的：

查找公开可见API已更改的所有类
使其所有受抚养人，其受抚养人的家属等无效。

出于SBT的目的，“依赖”既是类的用户又是在同一文件中定义的类。

欧文的foo.scala的例子甚至可能是这个，你会看到这个问题：

object foo {
  def z: Int = 8
}

object foo2 {
  class A { ... }
}

良好做法：

单独文件的单独文件
细粒度接口
在伴随对象中使用与其伴随类相同的抽象级别;如果伴侣对象通过抽象层到达，则将其拉入单独的类和文件中。

Scala缓慢构建：避免开发方法

2 个答案: