Медленная сборка Scala :подходы к разработке, которых следует избегать

Во-первых, инкрементные сборки через SBT довольно круты, обычно в диапазоне < 1 секунды. Однако иногда вам нужно выполнить полную очистку/компиляцию или, в случае инкрементных сборок, вы вносите изменение в один файл , что затем запускает компиляцию десятков других файлов.

Это когда разработка на Scala становится менее... увлекательной, так как возникающее в результате замедление рабочего процесса может стимулировать переключение контекста (проверку электронной почты, последние потоки Stackoverflow и т. д. ), что слегка снижает продуктивность

Итак, каких подходов к разработке следует избегать, чтобы улучшить полную очистку/компилирование сборок, и (в идеале )изменить -один -файл -без -перекомпиляции -половины -инкрементные сборки приложения -?

Примеры, которые я могу придумать:
1 )лучше иметь тысячу строк, -это -весь файл scala, или несколько файлов разделены?
2 )можно мне мой торт (шаблон )или это увеличит время сборки?
3 )можно ли прокачать библиотечный шаблон x,y,z, или лучше найти другой способ?
4 )являются ли объекты пакета (с неявными )убийцами времени сборки?
5 )вложенных объектов и признаков?
6 )неявные методы/параметры или перестать быть умным и быть явным?

Конкретно, я подумываю отказаться от шаблона DAO, который я придумал, и объединить его в класс case ScalaQuery + объект-компаньон + минимальную черту поставщика базы данных. Это само по себе потеряет 20 файлов scala.

Приложение достаточно маленькое (120 scala + 10 java-файлов )для проведения рефакторинга без особых хлопот. Очевидно, что по мере роста scala-приложениятак же будет и время сборки, основанное только на LOC. Я просто пытаюсь увидеть, где обрезать жир, а где не беспокоить (, то есть оставить все как есть ), чтобы текущие и будущие приложения извлекали выгоду из выразительности, которую предоставляет Scala, без ненужного увеличения времени сборки.

Спасибо за несколько примеров вашего опыта хорошего, плохого и уродливого развития Scala по сравнению со временем сборки.