它 * 确实 * 会导致不同类别的bug和过程。它还使编写测试更快更自然，有助于缓解bug问题。
发现行为在哪里定义和使用可能会有问题。没有一个很好的方法来解决这个问题，尽管IDE在这方面随着时间的推移变得越来越好。
您的代码不应该更难阅读--主线代码应该更容易阅读。动态行为应该消失在应用程序中，并且为需要理解这些级别功能的开发人员适当地记录下来。
魔术确实使发现变得更加困难，这意味着其他文档的方式，特别是人类可读的测试（想想easyb，spock等）和散文，变得更加重要。

这是有点老，但我想分享我的经验，如果有人来寻找一些想法的主题：
现在，我们正在一个小团队（3个开发人员）中使用eclipse 3.7和groovy-eclipse 2.7，由于我们没有测试脚本，我们的groovy开发主要是通过显式地使用类型来完成的。
例如，使用服务类方法时：

void validate(Product product) {
  // groovy stuff
}

Box pack(List<Product> products) {
  def box = new Box()
  box.value = products.inject(0) { total, item ->
    // some BigDecimal calculations =)
  }
  box
}

我们通常填写type，这使得eclipse能够自动完成，最重要的是，允许我们重构代码，查找用法等。
这阻止了我们使用元编程，除了我发现groovy-eclipse支持并检测到的类别。
尽管如此，Groovy还是很不错的，我们的很多业务逻辑都是用Groovy代码编写的。
在使用groovy时，我们在生产代码中遇到了两个问题，这两个问题都是由于糟糕的手动测试造成的。
我们还需要进行大量的XML构建和解析，并在将其发送到Web服务等之前对其进行验证。
我们使用一个小脚本连接到一个内部系统，它的使用非常有限（在系统的其他部分不需要）。这段代码是我完全使用动态类型开发的，使用元类覆盖方法和所有这些东西，但这是一个例外。
我认为groovy 2.0（当然，groovy-eclipse也会沿着而来）和它的@TypeChecked对于我们这些将groovy作为“java++"使用的人来说将是非常棒的。

对我来说，有两种类型的重构：
1.基于IDE的重构（提取到方法、重命名方法、引入变量等）。
1.手动重构。（将方法移动到不同的类，更改方法的返回值）
对于基于IDE的重构，我还没有发现一个IDE在Groovy上做得像在Java上一样好。例如，在eclipse中，当你提取到方法时，它会寻找重复的示例来重构调用方法，而不是重复的代码。对于Groovy，这似乎不会发生。
我相信你可以看到手工重构变得更容易了。如果没有测试，我同意这可能会更难。
cleaner code的说法是**100%准确的。**我大胆猜测，好的Java和好的Groovy代码至少是3：1的代码行数。作为一个Groovy新手，我每天都会努力学习至少一种新的方法来做一些事情。对我改进Groovy有很大帮助的是简单地阅读API。我觉得Collection、String和List可能是功能最多的，我用得最多的是它们来帮助我的Groovy代码真正成为Groovy。
http://groovy.codehaus.org/groovy-jdk/java/util/Collection.html
http://groovy.codehaus.org/groovy-jdk/java/lang/String.html
http://groovy.codehaus.org/groovy-jdk/java/util/List.html
既然你编辑了问题，我也会编辑我的答案：）
你可以做的一件事就是告诉intellij你的对象上的动态方法：What does 'add dynamic method' do in Groovy/IntelliJ?。这可能会有点帮助。
我使用的另一个技巧是在初始编码时输入我的对象，并在完成后删除输入。例如，我似乎永远记不起字符串上是.substring（..）还是.subString（..）。因此，如果你输入你的对象，你会得到更好的代码完成。
至于你的其他要点，我真的需要看看一些代码，以便能够给予一个更好的答案。