動的言語はアジャイル開発に不利ですか？
私がアジャイル開発を読んだことから、コードを図にリファクタリングまたはリバースエンジニアリングすることがよくあります。もちろん、それだけではありませんが、これら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人のビジネスクラスユーザーをどのように変更するかでした。
開発中の大規模なアプリケーションは、インターフェイスの変換が構築およびテストされている間、コードを凍結できません。メインの開発ストリームからコードリポジトリの並列ブランチで変換を構築してテストする必要がありました。変換が完全にテストされた後、単一の操作でメインコードストリームに適用されました。
17,100件の変更で35未満のバグが見つかりました。すべてのバグは3週間で迅速に解決されました。
変更を手動で行った場合、変換ルールを作成するのに235時間かかるのに対し、8,500時間かかると推定します。
タスクは、書き換えルールを使用して、予想時間の3％で完了しました。これは36倍の改善です。
「アプリケーションデータレイヤーの変換」よりWill Loew-Blosser OOPSLA 2002
あなたの原則は私に聞こえます正解。
C＃のような強く型付けされた言語は、常にリファクタリングを必要とするコードベースの良い候補です。基本的に、市場にあるほとんどのリファクタリングツール（Resharper、JustCodeなど）は、静的に型付けされたプログラミング言語で非常に効果的です。
現実の世界のプロジェクトは、アジャイル方法論のための動的型付け言語の使用について何を伝えていますか？
アジャイル/スクラム方法論を実践する開発チームにとって、鎧の下にリファクタリングツールの適切なセットがあることは非常に役立ちます（重要でもあります）。そうでなければ、今後のスプリントの突然の変更はすべて、変更または再設計するのが悪夢になる可能性があります。
したがって、アジャイル方法論は、静的に型付けされた言語や動的な1度の言語には利点を提供しません。それが提供するのは、強固なアプリケーションを構築するための反復的なアプローチです。