领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
静态分析工具综述：Roodi、Rufus、Reek和Flay
作者 Werner Schuster 译者 杨晨 发布于 2008年11月26日
静态分析工具能够保证代码的质量，发现并警告潜在的bug。静态编译语言的编译器经常运行静态分析检查，然后以警告的形式报告潜在的问题。流行的独立分析工具有C的lint和Smalltalk的Lint等等，许多现代的IDE同样也能够对代码进行静态分析，还能够随着代码的编辑进行增量的检查。
在很长的时间里，由于没有访问Ruby资源中抽象语法树（AST）的标准方法，Ruby在静态分析工具方面总是不能得心应手。解决方案之一是使用ParseTree这个gem，这个工具使用了原生扩展，来实现对Ruby代码解析树的访问。ParseTree也只是在Ruby 1.8中可用，不过似乎1.9不会继续支持它（Ruby 1.9将会支持Ripper，这个库支持对源文件进行解析，但是不支持实时访问解析树）。ParseTree现在并不能很好支持那些新的Ruby实现。
再来介绍一下ruby_parser，这是一个Ruby的解析器，它是用Ruby编写的，并且承诺改进这些问题。这个项目最近发布了2.0版本，不但改善了性能，而且将行号作为元数据加入到AST中。后者对于静态分析工具是非常重要的，因为这些工具需要报告发现问题的位置。
有一点至关重要，那就是所有现存的Ruby IDE都是使用Java（例如Aptana或3rdRail等基于Eclipse的IDE、Netbeans的Ruby支持，或者JetBrains的RubyMine） 或者.NET（基于Visual Studio的Ruby In Steel）编写而成的。所有这些IDE都包含对Ruby代码的静态分析代码，但是它们都不是Ruby编写的。基于Java或者.NET语言，并采用 Ruby解析器和AST的静态分析代码，显然不能够支持MRI或者其他的Ruby实现方式。UnifiedRuby派生自ParseTree，对 ParseTree的输出进行整理加工，还与ruby_parser相结合，它现在可以解析Ruby的源代码，并且能够通过纯Ruby来进行分析。
在过去几个月里，发布了一系列的静态分析工具。
Flay，这是由Ryan Davis编写的工具，能够检查重复的codebase。这个工具使用了AST而不是直接分析源代码，从而能够结构化地比较代码。拷贝或者粘贴的代码即使经过了些许修改，也能够被检测到。Ryan之前曾经发布过另外一个静态分析工具flog，这个工具主要根据其内置的各种不良代码匹配模式计算codebase的得分，例如过多的依赖等等。Flay和Flog都能够使用命令行检查codebase。Flay使用ruby_parser对Ruby代码进行解析。
Reek由Kevin Rutherford编写，是一个“ruby代码的怪味道嗅探器”。它能够检查非常长的方法体、臃肿的类、错误的名称等等。这些检查是通过继承自SexpProcessor，并且访问AST来实现的。Reek的代码可以在Github上下载。
Roodi是一个与reek非常相似的工具，它能够对codebase进行一系列的检查。Roodi检查方法或模块是否符合命名规则，或者最大参数数目等是否一致等等。其他的检查项目包括提供诸如避免for循环之类的建议等等。在YAML文件中包含了其他附加功能的配置，而且配置起来非常方便。同样地，编写新的检查类也非常容易。检查器的类是通过注册AST的节点，然后监控这个节点的子树来实现检查功能的。
Rufus，这是一个由John Mettraux编写的工具，这个工具能够检查Ruby中不需要或者不安全的代码。Rufus的库能够在加载某些Ruby源代码之前检查它们。例如，加载一个只有一行（例如exit）代码的Ruby文件可不是什么好主意。这个库是可配置的，能够自定义匹配模式，决定哪些代码将要被排除掉。
你打算把这些工具添加到持续集成的配置中吗？你希望对代码进行什么检查，或者打算自己编写哪些检查功能呢？
查看英文原文：Static Analysis Tools Roundup: Roodi, Rufus, Reek, Flay
译者 杨晨 对数据库和搜索引擎有深入了解，尤其擅长经典计算机科学理论，对历史学兴趣浓厚。
没有回复
关注此讨论 回复