動的言語はアジャイル開発にとって不利ですか？

私が読んだアジャイル開発から、コードをダイアグラムにリファクタリングまたはリバースエンジニアリングすることがよくあります。もちろんそれ以上のものがありますが、これら2つの方法に依存するプラクティスを考慮すると、動的に型付けされた言語は不利になりますか？

静的に型付けされた言語は、リファクタリングとリバースエンジニアリングをはるかに容易にするようです。

動的に型付けされた言語では不可能ではないにしても、リファクタリングまたは（自動化された）リバースエンジニアリングは困難ですか？現実のプロジェクトは、アジャイル手法のための動的に型付けされた言語の使用について何を教えていますか？

動的言語は理論的には不利であり、他のすべてが等しいのは、コードの動作方法（制約の内容）に関する指定が少ないため、リファクタリングが自動的に行われず、発生した問題も自動的に検出できないためです。 。

しかし、他のすべては同等ではありません。最も人気のある動的言語は、非常にコンパクトでありながら理解しやすいコードを可能にします。これにより、一般的に開発が高速になり、リファクタリングで変更される可能性のあるロジックが視覚的に見つけやすくなります。したがって、動的言語で作業することの相対的な利点の一部を失う可能性がありますが、特にリファクタリングを手作業で行うことを計画している場合は特に、先に出てくる可能性があります。

一方、動的言語と本質的に同じ利点を持つ静的に型付けされた言語が存在します（つまり、コンパクトでわかりやすい-型はほとんど推測されますが、非常に多くあります）：Haskellはおそらく主な例ですが、OCaML / F＃、Scala、その他もこのカテゴリに属します。残念ながら、最も一般的な静的型付け言語よりも使用頻度が低いため、それらのツールセット（リファクタリングなど）はそれほど豊富ではありません。

結論として、私はあなたがほとんどの言語でアジャイルな方法論で適切にやると思う。実践がまだ理論に追いついていないので、明確な勝者がいるとは言いません。

自動リファクタリングは、動的に型指定された言語であるSmalltalkで発明されました。いいえ、動的に型付けされた言語で自動リファクタリングを行うことは不可能ではありません。それがどれほど難しいかは、タイピングの訓練以外の他の要因により大きく左右されます。C ++とJavaはどちらも静的に型指定されていますが、リファクタリングツールは実際にはJavaにのみ存在します。内省とシンプルな構文を備えたSmalltalkは、リファクタリングツールの非常に優れた候補です。

いくつかの点で、動的型付けは実際にリファクタリングを容易にします。優れたテストスイートがある場合は、リファクタリングによって問題が発生していないことを確認できます。通常、動的に型指定されたコードベースはより小さくなります。さらに、リファクタリングの影響を受けるコードは少なくなります。動的なコードベースを手動でリファクタリングするのに要する労力は、静的なコードベースよりも少なくなります。

リファクタリングは動的言語で発明されました。自動リファクタリングツールは、動的言語で発明されました。IDEは動的言語で発明されました。動的言語でいくつかのアジャイル手法が考案されました。

本当に問題は見当たりません。

忘れないように、「アジャイル」な働き方は、 Extreme Programming（XP）、Smalltalkプロジェクトで作成されました（Smalltalkは確かに「動的」言語としてカウントされます）。

動的に型付けされた言語で提供されるリファクタリングツールの産業利用のケーススタディを次に示します。

カーギルでは、穀物エレベーターの操作と関連する商品取引活動をサポートするために、非常に大きなSmalltalkアプリケーションが開発されました。Smalltalkクライアントアプリケーションには、385個のウィンドウと5,000以上のクラスがあります。このアプリケーションの約2,000のクラスは、初期（1993年頃）のデータアクセスフレームワークと対話しました。フレームワークは、オブジェクト属性のデータテーブル列へのマッピングを動的に実行しました。

分析の結果、動的なルックアップはクライアントの実行時間の40％を消費しましたが、不要であることがわかりました。

ビジネスクラスが明示的にコード化されたメソッドの列マッピングにオブジェクト属性を提供することを必要とする新しいデータレイヤーインターフェイスが開発されました。テストにより、このインターフェースは桁違いに高速であることが示されました。問題は、データレイヤーの2,100のビジネスクラスユーザーを変更する方法でした。

開発中の大規模なアプリケーションは、インターフェイスの変換が構築およびテストされている間、コードをフリーズできません。メイン開発ストリームからコードリポジトリの並列ブランチで変換を構築し、テストする必要がありました。変換が完全にテストされると、1回の操作でメインコードストリームに適用されました。

17,100件の変更で見つかったバグは35個未満です。すべてのバグは3週間で迅速に解決されました。

変更が手動で行われた場合、変換ルールを開発するのに235時間かかったのに対して、8,500時間かかったと推定されます。

タスクは、書き換えルールを使用して、予想される時間の3％で完了しました。これは36倍の改善です。

「アプリケーションデータレイヤーの変換」よりWill Loew-Blosser OOPSLA 2002

また- 「不可能な変更を加えるためのツール - 大きなSmalltalkプログラムを変換するためのツールの経験」

あなたの原則は私に正しいと思われると思った。

C＃のような強く型付けされた言語は、リファクタリングを常に必要とするコードベースの良い候補です。基本的に、市場のほとんどのリファクタリングツール（Resharper、JustCodeなど）は、静的に型付けされたプログラミング言語で非常に効果的です。

現実のプロジェクトは、アジャイル手法のための動的に型付けされた言語の使用について何を教えていますか？

アジャイル/スクラムの方法論を実践している開発チームにとって、優れたリファクタリングツールのセットを装甲下に置くことは非常に役立ちます（重要な場合もあります）。そうしないと、今後のスプリントの突然の変更はすべて、変更または再設計するのが悪夢になる可能性があります。

したがって、アジャイル手法は、静的に型付けされた言語や動的な一度の利点を提供しません。それが提供するのは、強固なアプリケーションを構築するための反復的なアプローチです。