Scala slow compilaciones: enfoques de desarrollo para evitar

Question

En primer lugar, las compilaciones incrementales a través de SBT son bastante impresionantes, generalmente en el rango de 1 segundo de <. Sin embargo, a veces tiene que hacer una compilación/limpieza completa o, en el caso de compilaciones incrementales, hacer un cambio en un archivo que luego desencadena la compilación de docenas de otros archivos.

Esto es cuando el desarrollo se vuelve menos Scala ... diversión, ya que la desaceleración que resulta en el flujo de trabajo puede fomentar el cambio de contexto (consultar el correo electrónico, temas Stackoverflow, etc.), lo que hace que uno sutilmente menos productivos

Así , ¿cuáles son los enfoques de desarrollo que se deben evitar para mejorar las compilaciones completas de limpieza/compilación y (idealmente), compilaciones incrementales de cambio de un archivo sin recompilar?

Ejemplos que puedo pensar en:
1) ¿Es mejor tener un archivo scala de más de mil líneas, o varios archivos divididos?
2) ¿Puedo tener mi pastel (patrón) o eso inflará los tiempos de construcción?
3) ¿Puedo tener el patrón de biblioteca pimp'd x, y, z, o mejor, para encontrar otra forma?
4) son objetos de paquete (con implicits) un asesino de tiempo de compilación?
5) objetos y rasgos anidados?
6) métodos/parámetros implícitos o dejar de ser inteligente y ser explícito?

Concretamente, estoy pensando en abandonar un patrón de tortas DAO. Creo y me estoy consolidando en la clase de caso ScalaQuery + objeto acompañante + rasgo de proveedor mínimo de base de datos. Solo eso arrojará 20 archivos scala.

La aplicación es suficientemente pequeña (120 scala + 10 archivos java) para refactorizar ahora sin demasiada molestia. Obviamente, a medida que crece la aplicación de scala, también aumentan los tiempos de compilación, solo basados ​​en los LOC. Solo estoy tratando de ver dónde recortar la grasa y dónde no molestar (es decir, mantener las cosas como están) para que las aplicaciones actuales y futuras se beneficien de la expresividad que ofrece Scala sin inflar innecesariamente los tiempos de construcción.

Gracias por algunos ejemplos de su experiencia de lo bueno, lo malo y lo feo del desarrollo de la scala en comparación con los tiempos de compilación.

Answer 1

Eche un vistazo a how incremental recompilation works in SBT.

Se es más o menos esto:

1. Encuentra todas las clases cuya API visible para el público han cambiado
2. Invalidar todos sus dependientes, dependientes de sus dependientes, y así sucesivamente.

Para los fines de SBT, un "dependiente" es a la vez un usuario de la clase y una clase definido en el mismo archivo.

ejemplo de Owen para foo.scala incluso podría ser esto, y que vería el tema:

object foo { 
    def z: Int = 8 
} 

object foo2 { 
    class A { ... } 
} 

Buenas prácticas:

• archivos separados para clases separadas
• de grano fino interfaces
• Utilice el mismo nivel de abstracción en los objetos complementarios que en sus clases complementarias; si el objeto complementario se extiende a través de capas de abstracción, tire de él hacia una clase y archivo separados.

Answer 2

Me he dado cuenta de que los miembros del tipo pueden forzar las reconstrucciones en lugares que no esperabas. Por ejemplo:

foo.scala:

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

bar.scala:

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

Cambiar el valor de z no fuerza bar volver a compilar. Cambiar el tipo de F sí lo hace, aunque bar nunca se refiere a F o incluso a A. Por qué, no tengo ni idea (Scala 2.9.1).