14

まず第一に、SBTを介したインクリメンタルビルドは非常に優れており、通常は1秒未満の範囲です。ただし、完全なクリーン/コンパイルを実行する必要がある場合や、インクリメンタルビルドの場合は、1つのファイルに変更を加えて、他の数十のファイルのコンパイルをトリガーする場合があります。

これは、Scalaの開発が楽しくなくなるときです。ワークフローの速度が低下すると、コンテキストの切り替え（電子メール、最新のStackoverflowスレッドなどを確認する）が促進され、生産性がわずかに低下するためです。

では、完全なクリーン/コンパイルビルド、および（理想的には）アプリケーションの半分を再コンパイルせずに1つのファイルを変更するインクリメンタルビルドを改善するために避けるべき開発アプローチは何ですか？

私が考えることができる例：
1）1000行以上のdo-it-all scalaファイル、または複数のファイルを分割する方が良いですか？
2）ケーキ（パターン）をもらえますか、それともビルド時間が長くなりますか？
3）x、y、zライブラリパターンをpimpしたり、別の方法を見つけたりすることはできますか？
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の型を変更することはできます。理由はわかりません (Scala 2.9.1)。FbarFA

于 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 に答える