模块化Java:声明式模块化
本文是模块化Java系列文章的第4篇,介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起,而无需让代码依赖于OSGI API。
作者 Ian Roughley 译者 张雪、郭晓刚 发布于 2007年10月27日 下午8时46分
Crap4J这个新项目的目标非常清晰:
现在没有一种特别简单的,100%准确并且客观的方法来判定一段代码是否糟透了。不过研究和经验都能证明我们的直觉:那些由其他人写的过于复杂和曲折的代码往往就是那些让人说出“这简直是垃圾”的代码。如果看这段代码的人将来还要负责维护这段代码,那么他的反应往往就会变成“有没有搞错!”
但光是抱怨还不够,我们需要更精确的测量。Crap4j根据复杂性和测试覆盖率得出了一个数值指标。
给定任意Java方法m,m的CRAP值如下式计算:
CRAP(m) = comp(m)^2 * (1 - cov(m)/100)^3 + comp(m)
其中 comp(m)是方法m的圈复杂性(cyclomatic complexity),cov(m)自动测试(如JUnit测试,非人工QA)达到的测试覆盖率。圈复杂性(cyclomatic complexity)是一个广泛使用的著名指标,它的取值等于方法中唯一决策(unique decisions)的数量加1。测试覆盖率计算我们采用的是基本路径覆盖(basis path coverage)。
跟任何指标一样,指标的数值必须小心使用,不可盲从;不过这个指标的确可以作为改善代码的出发点,它提供了一种手段去明确定位最需要改进的代码。
较低的CRAP值表示代码不太复杂和/或代码受到了自动化、可重复的测试的周全保护,因此修改和维护代码的风险较小。较高的CRAP值表示修改的风险较大,因为受到高度复杂性或者低自动化测试覆盖率(甚至没有自动化测试)的双重威胁。
Crap4j可从 www.junitfactory.com/crap4j/update/下载,它是一个Eclipse插件。要获得更详细的信息,可以阅读JUnitFactory提供的介绍。
查看英文原文:Crap4J Seeks to Use Algorithms to Determine Code Quality本采访是在伦敦举行的QCon2009上记录的,Ian Robinson和Jim Webber探讨了如何将Web作为整合平台以及REST在理论上和实践中的好处。
项目管理对于项目成败至关重要,但实践中每个项目都有自己的独特性,没有现成的解决方案可以套用。书中从应对实际风险的角度出发,讲述了从项目启动、项目规划到项目结束的整个管理流程,展示了作者的思考过程。本迷你书从原书中精选出5个章节。
在这个演讲中,Fred将会揭示敏捷的一些外在因素,并会重点关注敏捷获得成功的内在原因。从案例研究和真实的项目经验来看,Fred认为:工具、管理体系都不能让你变得敏捷。敏捷的成功,植根于士气高涨、充分授权的工作者身上,他们能够以不同以往的方式思考问题。
Eben Hewitt的新书《Java SOA Cookbook》从Java实现的角度讨论了面向服务架构。Eben在书中讨论了SOA基础、工具、最佳实践和SOA治理等主题。
Mark Richards的新书《Java消息服务》第二版覆盖了JMS的许多主题, 包括发布和订阅模式以及点对点模式,消息过滤和事务等。InfoQ与Mark谈论了跟他的新作。
没有回复
关注此讨论 回复