코드 메트릭스의 매력은 무엇입니까?

코드 메트릭스의 매력은 무엇입니까? [닫은]

---

나는 최근에 많은 '코드 메트릭'관련 질문을 보았고 그 매력이 무엇인지 궁금해해야합니까? 다음은 최근 몇 가지 예입니다.

• 제공된 코드가 형편 없다고 확신하는 코드 메트릭
• 코드 줄 수가 유용한 지표 일 때
• 품질 테스트 작성

내 생각에는 어떤 메트릭도 코드 리뷰를 대체 할 수 없습니다.

• 일부 측정 항목은 때때로 검토가 필요한 장소를 나타낼 수 있습니다.
• 짧은 기간에 걸친 지표의 급격한 변화는 검토가 필요한 장소를 나타낼 수 있습니다.

그러나 나는 그 자체로 항상 '양호'또는 '나쁜'코드를 나타내는 단일 측정 항목을 생각할 수 없습니다. 측정으로 볼 수없는 것에 대한 예외와 이유가 항상 있습니다.

내가 간과 한 코드 메트릭에서 얻을 수있는 마법 같은 통찰력이 있습니까? 게으른 프로그래머 / 관리자는 코드를 읽지 않을 변명을 찾고 있습니까? 사람들이 거대한 레거시 코드 기반을 제시하고 시작할 곳을 찾고 있습니까? 무슨 일이야?

참고 : 특정 스레드에 대한 답변과 댓글 모두에 대해 이러한 질문 중 일부를 요청했지만 답변이 없었기 때문에 뭔가 빠진 것이있을 수 있으므로 일반적으로 커뮤니티에 질문해야한다고 생각했습니다. 메트릭 배치 작업을 실행하고 실제로 다른 사람의 코드 (또는 내 코드)를 다시 읽을 필요가없는 것이 좋을 것입니다. 실용적이지 않다고 생각합니다!

편집 : 논의되는 모든 메트릭은 아니지만 대부분의 메트릭에 대해 잘 알고 있습니다. 단순히 또는 임의의 품질 표준으로 볼 수는 없습니다.

---

이 스레드의 답변은 다음과 같이 다소 이상합니다.

• "팀", "유일한 수혜자"처럼 말한 메트릭스;
• "메트릭"은 그 자체로 어떤 의미를 지닙니다.

1 / Metrics는 한 모집단이 아니라 3 명을 위한 것입니다 .

• 개발자 : 코드의 정적 분석 (순환 복잡도, 주석 품질, 줄 수 등)과 관련된 즉각적인 정적 코드 메트릭 에 관심이 있습니다 .
• 프로젝트 리더 : 단위 테스트, 코드 커버리지, 지속적인 통합 테스트에서 발생 하는 일일 라이브 코드 메트릭에 관심이 있습니다.
• 비즈니스 후원자 (항상 잊혀지지 만 이해 관계자이며 개발 비용을 지불하는 사람) : 아키텍처 설계, 보안, 종속성 등에 관한 주간 글로벌 코드 메트릭 에 관심이 있습니다 .

이러한 모든 메트릭은 물론 세 모집단 모두에서보고 분석 할 수 있지만 각 유형은 각 특정 그룹에서 더 잘 사용되도록 설계되었습니다.

2 / 메트릭은 그 자체로 코드 의 스냅 샷 을 나타내며, 이는 ... 아무것도 의미하지 않습니다!

"양호"또는 "나쁜"코드를 나타낼 수있는 것은 이러한 메트릭의 조합 및 다양한 분석 수준의 조합이지만 더 중요한 것은 해당 메트릭의 추세 가 중요하다는 것입니다.

이는 비즈니스 관리자 / 프로젝트 리더 / 개발자가 가능한 다양한 코드 수정 중에서 우선 순위 를 정하는 데 도움이되므로 실질적인 부가가치를 제공 할 메트릭 의 반복 입니다.

---

즉, "메트릭의 매력"에 대한 귀하의 질문은 다음과 같은 차이점을 나타낼 수 있습니다.

• "아름다운"코드 (항상 보는 사람-코더의 눈에 있음)
• "좋은"코드 (작동하고 작동 함을 증명할 수 있음)

예를 들어, 순환 복잡도가 9 인 함수는 순환 복잡도가 42 인 긴 복잡한 함수와는 반대로 "아름다운"으로 정의 될 수 있습니다.

그러나 다음과 같은 경우 :

• 후자의 함수는 95 %의 코드 커버리지 와 결합 된 꾸준한 복잡성을 가지고 있습니다.
• 전자가 갖는 반면, 증가 복잡도 조합 의 ... 0 % 커버리지를

다음과 같이 주장 할 수 있습니다.

• 후자는 " 좋은 "코드를 나타냅니다 (작동하고 안정적이며 변경해야하는 경우 수정 후에도 작동하는지 확인할 수 있음).
• 전자는 " 나쁜 "코드입니다 (아직해야하는 모든 작업을 처리하기 위해 몇 가지 케이스와 조건을 추가해야하며 회귀 테스트를 수행하는 쉬운 방법이 없습니다)

---

요약하면 다음과 같습니다.

그 자체로 항상 표시하는 단일 측정 항목 [...]

: 코드가 더 "아름답다"는 점을 제외하면 그 자체로 많은 것을 의미하지는 않습니다.

내가 간과 한 코드 메트릭에서 얻을 수있는 마법 같은 통찰력이 있습니까?

메트릭 의 조합 과 추세 만이 진정한 "마법의 통찰력"을 제공합니다.

---

나는 몇 달 전에 순환 복잡성을 측정하는 1 인 작업으로 수행 한 프로젝트가있었습니다. 그것은 이러한 종류의 측정 항목에 대한 저의 첫 노출이었습니다.

내가받은 첫 번째 보고서는 충격적이었습니다. 거의 모든 기능이 테스트에 실패했습니다. 심지어 매우 간단한 기능도 마찬가지였습니다. 논리적 하위 작업을 한 번만 호출하더라도 하위 루틴으로 이동하여 복잡한 문제를 해결했습니다.

나머지 절반의 루틴에 대해서는 프로그래머로서의 저의 자부심이 시작되었고, 동일한 방식으로 더 간단하고 더 읽기 쉽게 다시 작성하려고했습니다. 그게 효과가 있었고 저는 고객의 복잡성 임계 값을 최대한 낮출 수있었습니다.

In the end I was almost always able to come up with a better solution and much cleaner code. The performance did not suffered from this (trust me - I'm paranoid on this, and I check the disassembly of the compiler output quite often).

I think metrics are a good thing if you use them as a reason/motivation to improve your code. It's imortant to know when to stop and ask for a metric violation grant though.

Metrics are guides and helps, not ends in itself.

---

The best metric that I have ever used is the C.R.A.P. score. http://www.artima.com/weblogs/viewpost.jsp?thread=215899

Basically it's an algorithm that compares weighted cyclomatic complexity with automated test coverage. The algorithm looks like this: CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) where comp(m) is the cyclomatic complexity of method m, and cov(m) is the test code coverage provided by automated tests.

The authors of the afore mentioned article (please, go read it...it's well worth your time) suggest a max C.R.A.P. score of 30 which breaks down in the following way:

Method’s Cyclomatic Complexity        % of coverage required to be
                                      below CRAPpy threshold
------------------------------        --------------------------------
0 – 5                                   0%
10                                     42%
15                                     57%
20                                     71%
25                                     80%
30                                    100%
31+                                   No amount of testing will keep methods
                                      this complex out of CRAP territory.

As you quickly see, the metric rewards writing code that is not complex coupled with good test coverage (if you are writing unit tests, and you should be, and are not measuring coverage...well, you probably would enjoy spitting into the wind as well). ;-)

For most of my development teams I tried really hard to get the C.R.A.P. score below 8, but if they had valid reasons to justify the added complexity that was acceptable as long as they covered the complexity with sufficient tests. (Writing complex code is always very difficult to test...kind of a hidden benefit to this metric).

Most people found it hard initially to write code that would pass the C.R.A.P. score. But over time they wrote better code, code that had fewer problems, and code that was a lot easier to debug. Out of any metric, this is the one that has the fewest concerns and the greatest benefit.

---

A good code review is no substitute for a good static analysis tool, which is of course not substitute for a good set of unit tests, now unit tests are no good without a set of acceptance tests......

Code metrics are another tool to put into your tool box, they are not a solution in their own right they are just a tool to be used as appropriate (with of course all the other tools in your box!).

---

For me the single most important metric that identifies bad code is cyclomatic complexity. Almost all methods in my projects are below CC 10 and bugs are invariably found in legacy methods with CC over 30. High CC usually indicates:

• code written in haste (ie. there was no time to find an elegant solution and not because the problem required a complex solution)
• untested code (no one writes tests for such beasts)
• code that was patched and fixed numerous times (ie. riddled with ifs and todo comments)
• a prime target for refactoring

---

People are drawn to the idea of mechanistic ways to understand and describe code. If true, think of the ramifications for efficiency and productivity!

I agree that a metrics for "code goodness" is about as sensible as a metric for "good prose." However that doesn't mean metrics are useless, just perhaps misused.

For example, extreme values for some metrics point the way to possible problems. A 1000-line-long method is probably unmaintainable. Code with zero unit test code coverage probably has more bugs that similar code with lots of tests. A big jump in code added to a project just before release that isn't a third-party library is probably cause for extra attention.

I think if we use metrics as a suggestion -- a red flag -- perhaps they can be useful. The problem is when people start measuring productivity in SLOC or quality in percentage of lines with tests.

---

My highly subjective opinion is that code metrics expresses the irresistable institutional fascination with being able to quantify something inherently unquantifiable.

Makes sense, in a way, at least psychologically - how can you make decisions on something you can't evaluate or understand? Ultimately, of course, you can't evaluate quality unless you're knowledgeable about the subject (and are at least as good as the what you're trying to evaluate) or ask someone who's knowledgeable, which of course just puts the problem back one step.

In that sense, maybe a reasonable analogy would be evaluating college entrants by SAT scores, it's unfair and misses every kind of subtlety but if you need to quantify you've got to do something.

Not saying I think it's a good measure, only that I can see the intitutional irresistability of it. And, as you pointed out, there are probably a few reasonable metrics (lots of 500+ line methods , high complexity-probably bad). I've never been at a place that bought into this,though.

---

There's one code metric I believe in.

I'm working on a big system. When a single new requirement comes to me, I set about coding it up. When I'm done and got the bugs worked out, I check it into the version control system. That system does a diff, and counts up all the changes I made.

The smaller that number is, the better.

---

Metrics and automated tests aren't meant to be a replacement for full code reviews.

They just speed things up. With an automated checker, it's very easy to see which conventions you've forgotten to follow, that you're using the designated packages and methods, etc. You can see what you can fix without using other people's time.

Managers also like metrics them because they feel they're getting an exact figure on productivity (though that's often not really the case) and they should be able to juggle people better.

---

Measurements are only useful if:

• The team developed them
• The team agreed to them
• They are being used to identify a specific area

In general, any metric that doesn't fit into that will suffer from the team optimizing to it. You want to measure lines of code? By gosh, watch how many they can write! You want to measure code coverage, by golly, watch me cover that code!

I think metrics can be useful for identifying trends, and in fact, I've seen some useful ones, such as plotting when the build breaks, code churn (number of lines of code changing throughout the project) and other things. But if the team isn't coming up with them, or they don't agree or understand them, you are likely in a world of hurt.

---

Here is some Complexity Metrics from stan4j(http://stan4j.com/).

An eclipse class structure analyze tool.

I like this tool and the metrics. I treat the metrics as statistics, indicators, warning messages. Sometime due to some methods or some classes really has some complicated logic made them to be complex, what shall be done is keep an eye on them, review them to see if there is an need to refactor them or review them carefully, due to normally they are error prone. Also I use it as analyze tool to learn source code, due to I like to learn from complex to simple.Actually it includes some other metrics such as Robert C. Martin Metrics, Chidamber & Kemerer Metrics,Count Metrics But I like this one best

Complexity Metrics

Cyclomatic Complexity Metrics

Cyclomatic Complexity (CC) The cyclomatic complexity of a method is the number of decision points in the method's control flow graph incremented by one. Decision points occur at if/for/while statements, case/catch clauses and similar source code elements, where the control flow is not just linear. The number of (byte code) decision points introduced by a single (source code) statement may vary, depending e.g. on the complexity of boolean expressions. The higher the cyclomatic complexity value of a method is, the more test cases are required to test all the branches of the method's control flow graph.

Average Cyclomatic Complexity Average value of the Cyclomatic Complexity metric over all methods of an application, library, package tree or package.

Fat Metrics The Fat metric of an artifact is the number of edges in an appropriate dependency graph of the artifact. The dependency graph type depends on the metric variant and the chosen artifact:

Fat The Fat metric of an application, library or package tree is the edge count of its subtree dependency graph. This graph contains all the artifact's children in the package tree hierarchy, thereby also including leaf packages. (To see the appropriate graph in the Composition View, the Structure Explorer's Flat Packages toggle has to be disabled. The Show Libraries toggle has to be enabled if the chosen artifact is a library, otherwise it has to be disabled.)

The Fat metric of a package is the edge count of its unit dependency graph. This graph contains all top level classes of the package.

The Fat metric of a class is the edge count of its member graph. This graph contains all fields, methods and member classes of the class. (This graph and the Fat value are only available if the code analysis was performed with Level of Detail Member, not Class.)

Fat for Library Dependencies (Fat - Libraries) The Fat for Library Dependencies metric of an application is the edge count of its library dependency graph. This graph contains all libraries of the application. (To see the appropriate graph in the Composition View, the Structure Explorer's Show Libraries toggle has to be enabled.)

Fat for Flat Package Dependencies (Fat - Packages) The Fat for Flat Package Dependencies metric of an application is the edge count of its flat package dependency graph. This graph contains all packages of the application. (To see the appropriate graph in the Composition View, the Structure Explorer's Flat Packages toggle has to be enabled and the Show Libraries toggle has to be disabled.)

The Fat for Flat Package Dependencies metric of a library is the edge count of its flat package dependency graph. This graph contains all packages of the library. (To see the appropriate graph in the Composition View, the Structure Explorer's Flat Packages and Show Libraries toggles have to be enabled.)

Fat for Top Level Class Dependencies (Fat - Units) The Fat for Top Level Class Dependencies metric of an application or library is the edge count of its unit dependency graph. This graph contains all the top level classes of the application or library. (For reasonable applications it is too large to be visualized and thus can not be displayed in the Composition View. Unit dependency graphs may only be displayed for packages.)

---

Metrics may be useful to determine the improvement or degradation in a project, and can certainly find style and convention violations, but there is no substitute for doing peer code reviews. You can't possibly know the quality of your code without them.

Oh ... and this assumes that at least one of the participants in your code review has a clue.

---

I agree with you that code metrics should not substitute a code review but I believe that they should complement code reviews. I think it gets back to the old saying that "you cannot improve what you cannot measure." Code metrics can provide the development team with quantifiable "code smells" or patterns that may need further investigation. The metrics that are captured in most static analysis tools are typically metrics that have been identified over the course of research in our field's short history to have significant meaning.

---

Metrics are not a substitute for code review, but they're far cheaper. They're an indicator more than anything.

---

One part of the answer is that some code metrics can give you a very quick, initial stab at an answer to the question: What is this code like?

Even 'lines of code' can give you an idea of the size of the code base you are looking at.

As mentioned in another answer, the trend of the metrics gives you the most information.

---

Metrics of themselves are not particularly interesting. It's what you do with them that counts.

For example if you were measuring the number of comments per line of code what would you consider a good value? Who knows? Or perhaps more importantly, everyone has their own opinion.

Now if you collect enough information to be able to correlate the number of comments per line of code against the time taken to resolve a bugs or against the number of bugs found that are attributed to coding, then you may start to find an empirically useful number.

There is no difference between using metrics in software and using any other performance measure on any other process - first you measure, then you analyse, then you improve the process. If all you're doing is measuring, you're wasting your time.

edit: In response to Steven A. Lowe's comments - that's absolutely correct. In any data analysis one must be careful to distinguish between causal relationship and a mere correlation. And the selection of the metrics on the basis of suitability is important. There is no point in trying to measure coffee consumption and to attribute code quality (although I'm sure some have tried ;-) )

But before you can find the relationship (causal or not) you have to have the data.

The selection of the data to collect is based on what process you wish to verify or improve. For example, if you're trying to analyse the success of your code review procedures (using your own definition for "success", be that reduced bugs or reduced coding bugs, or shorter turnaround time or whatever), then you select metrics that measure the total rate of bugs and the rate of bugs in reviewed code.

So before you collect the data you have to know what you want to do with it. If metrics is the means, what is the end?

---

I don't think small changes in metrics are meaningful: a function with complexity 20 is not necessarily cleaner than a function with complexity 30. But it's worth running metrics to look for large differences.

One time I was surveying a couple dozen projects and one of the projects had a maximum complexity value around 6,000 while every other project had a value around 100 or less. That hit me over the head like a baseball bat. Obviously something unusual, and probably bad, was going on with that project.

---

We're programmers. We like numbers.

Also, what are you going to do, NOT describe the size of the codebase because "lines of code metrics are irrelevant"?

There is definitely a difference between a codebase of 150 lines and one of 150 million, to take a silly example. And it's not a hard number to get.

참고URL : https://stackoverflow.com/questions/195887/what-is-the-fascination-with-code-metrics