14

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

这是 Scala 开发变得不那么有趣的时候，因为由此导致的工作流程放缓会鼓励上下文切换（检查电子邮件、最新的 Stackoverflow 线程等），这会巧妙地降低工作效率

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

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

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

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

感谢您提供一些关于 scala 开发相对于构建时间的好、坏和丑的体验示例。

4

2 回答 2

3

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

foo.scala：

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

bar.scala：

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

更改 的值z不会强制bar重新编译。改变 dos 的类型F，即使bar从不指代F甚至指代A. 为什么，我不知道（Scala 2.9.1）。

于 2012-07-22T16:59:35.820 回答
2

看看增量重新编译在 SBT中是如何工作的。

大致是这样的：

  1. 查找所有公开可见 API 已更改的类
  2. 使其所有家属、其家属的家属等无效。

对于 SBT，“从属”既是类的用户，又是在同一文件中定义的类。

Owen 的 foo.scala 示例甚至可能是这样的，您会看到问题：

object foo {
  def z: Int = 8
}

object foo2 {
  class A { ... }
}

良好做法：

  • 单独类的单独文件
  • 细粒度的接口
  • 在伴生对象中使用与其伴生类相同的抽象级别；如果伴随对象通过抽象层达到，则将其拉入单独的类和文件中。
于 2012-07-30T17:54:44.327 回答