动态语言是否不利于敏捷开发？

从我读到的内容来看，敏捷开发通常涉及到将重构或反向工程代码重构为图表。当然还有很多，但是如果我们考虑依赖这两种方法的实践，动态类型的语言是否处于不利地位？

看来静态类型的语言会使重构和逆向工程容易得多。

如果在动态类型语言中并非不可能，那么重构或（自动化）逆向工程难吗？现实世界中的项目说明了如何将动态类型的语言用于敏捷方法？

理论上讲，动态语言在所有其他条件相同的情况下处于劣势，因为它们很少指定代码的工作方式（约束是什么），因此可以自动完成较少的重构，并且也无法自动检测出现的问题。

但是其他所有条件都不相等。最受欢迎的动态语言允许高度紧凑但易于理解的代码，这通常使它们的开发速度更快，并使逻辑（可能会在重构中更改）的视觉更容易发现。因此，尽管您可能会失去使用动态语言进行工作的相对优势，但您仍然可能会领先于他人，特别是如果您打算以任何方式手动进行重构。

另一方面，存在静态类型的语言，其本质上与动态语言具有相同的优势（即，紧凑且易于理解，其中大多数类型都是推断的，但在那很多）：Haskell可能是主要的示例，但OCaML / F＃，Scala，其他也属于这一类。不幸的是，由于与最流行的静态类型化语言相比，它们的使用率较低，因此它们没有那么广泛的工具集（例如，用于重构）。

因此，作为底线，我认为您将在大多数语言中充分利用敏捷方法。我不会说现在有明显的赢家，因为实践尚未赶上理论。

自动重构是在Smalltalk（一种动态类型的语言）中发明的。因此，以动态类型的语言进行自动重构并非并非不可能。除打字纪律外，它的难易程度还更多地取决于其他因素。C ++和Java都是静态类型的，但是重构工具仅真正存在于Java中。具有内省性和简单语法的Smalltalk是重构工具的真正不错的选择。

在某些方面，动态类型实际上使重构更加容易。如果您有一个好的测试套件，则可以确保您的重构没有任何问题。动态类型的代码库通常较小。此外，重构往往会影响较少的代码。总体而言，手动重构动态代码库所涉及的工作少于静态代码库。

重构是在动态语言中发明的。自动重构工具是用动态语言发明的。IDE是用动态语言发明的。以动态语言发明了几种敏捷方法。

我真的没看到任何问题。

唯恐我们忘记了，一种称为“ 极端编程”（XP）的“敏捷”工作方式是在Smalltalk项目上创建的（Smalltalk当然可以算作“动态”语言）。

这是一个工业使用带有动态类型语言的重构工具的案例研究：

嘉吉公司开发了一个非常大的Smalltalk应用程序，以支持谷物升降机的运行以及相关的商品交易活动。Smalltalk客户端应用程序具有385个窗口和5,000多个类。此应用程序中约有2,000个类与早期（大约在1993年）的数据访问框架进行了交互。该框架动态执行对象属性到数据表列的映射。

分析表明，尽管动态查找消耗了客户端执行时间的40％，但这是不必要的。

开发了一个新的数据层接口，该接口要求业务类以显式编码的方法向列映射提供对象属性。测试表明，该接口的速度要快几个数量级。问题是如何更改数据层的2,100个业务类用户。

在开发和测试接口转换时，正在开发的大型应用程序无法冻结代码。我们必须在主要开发流的代码存储库的并行分支中构建和测试转换。对转换进行全面测试后，即可通过一次操作将其应用于主代码流。

在17,100个更改中，发现少于35个错误。所有错误均在三周内迅速得到解决。

如果手动进行更改，我们估计将花费8500小时，而制定转换规则则需要235小时。

通过使用重写规则，该任务在预期时间的3％中完成。这提高了36倍。

摘自“应用程序数据层的转换” Will Loew-Blosser OOPSLA 2002

另外，“无法进行更改的工具-具有转换大型Smalltalk程序的工具的经验”

您的原则思想对我来说是正确的。

像C＃这样的强类型语言是不断需要重构的代码库的良好候选者。基本上，市场上大多数重构工具（如Resharper，JustCode等）在静态类型的编程语言中都非常有效。

现实世界中的项目说明了如何将动态类型的语言用于敏捷方法？

对于实施敏捷/ Scrum方法论的开发团队来说，拥有一套精良的重构工具非常有帮助（甚至至关重要）。否则，即将进行的冲刺中所有突然的更改可能是修改或重新设计的噩梦。

因此，敏捷方法论无法为静态类型语言或动态语言提供任何优势。它提供了一种构建可靠应用程序的迭代方法。