本文介绍了什么是衡量JSP项目规模的好方法?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

鉴于现有的JSP项目,我想对项目视图"部分的复杂性/大小有所了解.到目前为止,这是我所做的:

Given an existing JSP project, I would like to get a feel for the complexity/size of the "view" portion of the project. Here's what I've done so far:

  • 拉出最近x个月内已从生产服务器编译的JSP列表(消除了死" jsps).
  • 编写快速扫描程序以查找导入到已编译页面中的JSP片段文件.
  • 将文件的大小和时间戳拉出文件系统.

因此,现在我有了一个页面列表以及导入到这些页面中的片段,以及它们的大小以及上次被编译和更改的时间.

So now I have a list of pages and the fragments imported into those pages, along with their size, and the last time they were compiled and changed.

但是我真正需要知道的是页面的复杂程度.其中一些页面上有很多Java代码.这是一个很大的项目,因此浏览每个页面和每个页面的大小将很繁琐,而且可能不够准确.

But what I really need to know is how complicated the page is; some of these pages have a whole lot of Java code on them. It's a big project, so to go through each page and size it would be tedious and probably not that accurate.

我打算写另一个扫描器来测量之间的代码,但是我想知道是否有某种指标生成器已经可以做到这一点.我希望它输出页面有多大"以及页面上代码有多大".重点是要分隔小,中,大和大页面,因此绝对度量值不如相对度量值重要.

I was going to write another scanner that measured the code between <% and %>, but I wondered if there was some kind of metrics generator out there that could already do that. I would like it to output how "big" the page was and how "big" the code on the page was. The point is to segregate the small, medium, big, and huge pages, so the absolute measurement is less important than the relative.

编写了另一台扫描程序以计算JavaScript行,Java(Scriptlet)行,HTML行和taglib使用实例的数量.因此,通过使用扫描仪的结果,我有了一些表明复杂性"的参数.不是很干净,但是现在还可以.

Wrote another scanner to count number of JavaScript lines, Java (Scriptlet) lines, HTML lines, and instances of taglib useage. So by using the results of the scanner, I have some parameters that would indicate 'complexity'. Not real clean, but it's ok for now.

推荐答案

所以问题是您的Java代码中散布着html,因此没有标准的度量工具可以工作.

So the issue is that you have smatterings of Java code interspersed with the html, so no standard metrics tool will work.

尚未完全上市,但是我们的源代码搜索引擎可能已经很接近了.这是一种通过使用语言准确的词法提取为源代码建立索引来搜索大型代码库的工具.这里的相关性是它计算索引文件的SLOC,注释计数,Halstead和Cyclomatic度量,因此,如果您只是忽略搜索功能,就可以得到度量.度量标准生成到XML文件(每个源文件一个记录"),因此您可以对它们进行任何进一步的处理.请参阅链接的网页上的指标讨论.

Not quite off the shelf, but our Source Code Search Engine might come pretty close. This is a tool for searching large code bases by indexing the source code using langauge-accurate lexical extraction. The relevance here is that it computes SLOC, comment counts, Halstead and Cyclomatic measures of the files it indexes, so you get metrics if you simply ignore the search feature. The metrics are generated to an XML file (with one "record" per source file) so you can do whatever further processing you want on them. See the metrics discussion on the linked web page.

虽然我们有一个JSP词法分析器,但尚未经过搜索引擎的测试.我们已经建立了数十个词法分析器,因此这对于我们来说应该很容易做到(并且我们很乐意这样做).那将直接产生您想要的答案.

While we do have a JSP lexer, it hasn't been tested with the Search Engine yet. We've built dozens of lexers so this should be pretty easy for us to do (and we'd be happy to do it). That would produce the answer you want directly.

如果您不想走这条路,可以遵循一个简单的想法,即提取<%和%>之间的代码,将其转储到与原始JSP文件平行的文件中,然后将该代码通过其(生产的)用于搜索引擎的Java语言提取器交给搜索引擎,并以此方式获取指标.这些词法分析器在文件格式错误方面非常强大,因此,提取的Java片段可能总体上不合法,这一事实不会对此造成困扰.

If you didn't want to go down that path, you could follow through with your simple idea of extracting the code between <% and %>, dump it into files parallel to the original JSP files,and hand that code to the search engine through its (production) Java lexeme extractor for the Search Engine, and get your metrics that way. The lexers are very robust in the fact of malformed files, so the fact that the Java fragments extracted might not collectively be quite legal wont bother it a bit.

这篇关于什么是衡量JSP项目规模的好方法?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-24 11:16