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

Question

首先,通过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开发的好,坏和丑的一些示例.

Answer 1

看一下SBT 中增量重新编译的工作原理。

大致是这样的：

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

就 SBT 而言，“依赖者”既是该类的用户，又是同一文件中定义的类。

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

object foo {
  def z: Int = 8
}

object foo2 {
  class A { ... }
}

良好做法：

• 不同类的单独文件
• 细粒度接口
• 在伴生对象中使用与其伴生类相同的抽象级别；如果伴随对象通过抽象层向上延伸，则将其拉入单独的类和文件中。