aty

代码质量、面向对象度量、重构、设计模式、设计原则以及实践

structure101至此2种仓库：local repository和remote repository。远程仓库是structure101官方维护：我们可以将项目的字节码提交到这里，给大家共享，这样别人也能够看。上图可以看到：常见的第三方开源框架如struts2、spring将自己的字节码传给了官方的远程仓库。这样我们按照完structure101后，就可以打开远程仓库下的这些项目，查看这些常见开源项目的度量结果。一般我们还是使用local repository，本地仓库的使用是很容易的，那么它的意义在

现在我们看下如何新建一个structure101项目以及Project Properties的设置。项目设置包括如下内容：Project type、breakout、Excludes、Externals、Granularity、Source files和Transformations。配置好这些设置选项之后，我们可以另存为一个.hsp文件，这样下次使用的时候就可以直接打开hsp。配置项包括project type、breakout、Granularity、Externals、Excludes、Source

上一篇博客介绍了structure101的Collaboration、Class Hierarchy、Call Graph视图，这3个视图很好理解、很容易使用，在eclipse等IDE中也有类似的功能。本文主要介绍Slices视图。

上一篇博客介绍了slices视图的基本使用，但是遗留了3个问题。经过几天的探索，终于弄懂了这3个遗留问题。1.design level 1~n到底是啥，有什么指导意义，数量又是怎么计算的？2.C的计算公式是啥？3.Groups 和Tangles页签的#Parents是怎么计算的，有什么意义？

度量一个函数(方法)是否复杂，最常用的方法就是计算函数的圈复杂度cyclomatic complexity (CC)，也就是“McCabe’s Metric”。业界CC的threshold一般是15，CC>15的函数被认为是非常复杂的。函数是否复杂的度量已经很成熟了，structure101度量函数是否fat，用的也是CC，临界值也设置的是15。structure101扩展了CC的概念，提出了度量class、leaf package、meta package复杂度的方法。meta package也就是上图中

structure101视图之Call graph、Class Hierarchy、Collaboration

在java的世界里，静态代码检查工具有很多，比如CheckStyle、PMD、FindBugs、Eclipse Metrics、Eclipse Simian等都是非常实用的工具。静态检查工具主要侧重于代码层面的质量，structure101和inFusion等则是设计层面的度量工具，更加侧重软件架构、设计、依赖等。最近打算重新温习下structure101这个很好用的工具，记录在博客里，我发现网上关于structure101的中文资料很少。

金字塔视图通过将复杂性、耦合和继承量化并集成来可视化整个系统的结构。金字塔视图描述了系统三个不同的角度：大小和结构复杂度，耦合和继承关系使用。这三个角度用了八个客观的度量值（两边肩上的值）来客观的描述。所有这些值有一个特征：与系统的大小无关，这样可客观的评价系统的设计质量（红色偏高、蓝色偏低、绿色正常）。

Robert C. Martin名著《敏捷软件开发：原则、模式与实践》一书第20章“包的设计原则”提到了几个很重要的设计原则。这篇文章主要看下涉及包的依赖性和稳定性的3个设计原则ADP/SDP/SAP。熟悉这3个设计原则之后，我们再看下度量工具jDepend的使用。

inFusion工具是一个基于对软件代码的扫描分析，得出子系统与子系统、模块与模块、类与类之间的关系，再根据这些关系推出是否有软件架构设计缺陷，并指导软件重构的工具.