Versions Compared

Version Old Version 3 New Version Current
Changes made by

Moses Kim

Moses Kim

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Info

SQ Official Doc Link: https://docs.sonarqube.org/display/SONAR/Concepts



Panel
borderColor#888888

Table of Contents

Table of Contents
indent16px


아키텍처(Architecture)

Concept

Definition

Related Topics

Analyzer소스 코드를 분석하여 스냅샷(snapshot)을 계산하는 클라이언트 어플리케이션.SonarQube 설치 및 업그레이드 참조
Database

다음 내용을 저장합니다:

  • 환경설정(configuration)
  • 스냅샷(snapshots)
SonarQube 설치 및 업그레이드 참조
Server스냅샷(snapshot) 데이터를 브라우즈하고, 환경 설정값을 변경하기 위해 사용하는 웹 인터페이스SonarQube 설치 및 업그레이드 참조

 

품질(Quality)

Concept

Definition

Related Topics

Bug코드의 잘못된 지점을 표시하는 이슈. An issue that represents something wrong in the code. If this has not broken yet, it will, and probably at the worst possible moment. This needs to be fixed. Yesterday이슈입니다. 소프트웨어가 깨지기 직전의 상태에 있으며, 이 이슈는 반드시 수정되어야 합니다. 
Check

체크(Check) = 코딩 규칙(Coding Rule)

 
Code SmellA maintainability-related issue in the code. Leaving it as-is means that at best maintainers will have a harder time than they should making changes to the code. At worst, they'll be so confused by the state of the code that they'll introduce additional errors as they make changes

유지보수성과 관련된 이슈입니다. 해당 이슈를 현재 상태로 두는 것은 최선의 경우, 코드 유지보수 담당자가 코드 변경시 필요한 것보다 더 많은 노력을 들여야 함을 의미합니다. 최악의 경우, 코드를 이해할 수 없을 정도로 혼란스럽기 때문에 코드를 변경할 때마다 새로운 에러가 추가될 수 있습니다.

 
Coding Rule

A good coding practice. Not complying to coding rules leads to quality flaws and creation of issues in SonarQube.

Coding rules can check quality on files, unit tests or packages바람직한 코딩 프랙티스입니다. 코딩 프랙티스를 준수하지 않는 경우 코드 품질 저하가 발생하며, SonarQube에 이슈가 생성됩니다.

코딩 규칙들은 파일(file), 단위 테스트(unit test) 혹은 패키지(package)를 대상을 품질을 확인합니다.

See Viewing Unit Tests > Issues Perspective
ComponentA piece of software 소프트웨어 일부(project, module/package, file) or a view or a developer, 뷰(view) 혹은 디벨로퍼(developer)를 의미합니다. 
CostSee 개선 비용(Remediation Cost) 참조. 
DebtSee 기술 부채(Technical Debt) 참조. 
Issue

When a component does not comply with a Component가 coding rule, an issue is logged (was violation prior to SonarQube 3.6) on the snapshot.

An issue can be logged on a source file or a unit test file. There are 3 types of issue:

  • Code Smell : an issue affecting your maintainability rating, preventing you to inject changes as fast as when you start from scratch
  • Bug : an issue highlighting a real or potential point of failure in your software
  • Vulnerability : an issue highlighting a security hole that can be used to attack your software
 
Leak PeriodThe period for which you're keeping a close watch on the introduction of new problems in the code. Typically this is since the previous_version, but if you don't use a Maven-like versioning scheme you may need to set a relatively arbitrary time period such as 21 days or since a specific date. 
Measure

The value of a metric for a given component at a given time.

Examples:

  • 125 lines of code on class MyClass
    • Density of duplicated lines of 30.5% on project myProject

    을 만족하지 못하는 경우, 이슈(SQ v3.6이전에는 violation)는 snapshot에 기록됩니다.

    이슈는 소스 파일 혹은 단위 테스트 파일을 대상으로 기록되며, 다음 세 가지 종류로 구분합니다:

    • 코드 악취(Code Smell) : 유지보수성 등급(maintainability rating)에 영향을 미치는 이슈로, 소스 코드의 신속한 변경을 어렵게 합니다.
    • 버그(Bug) : 소프트웨어가 포함하고 있는 실제 혹은 잠재적인 실패 지점입니다.
    • 취약점(Vulnerability) : 소프트웨어를 공격할 수 있는 보안상의 헛점을 의미합니다.
    		 
    Leak Period

    코드가 가진 새로운 문제를 보다 집중해서 확인하는 기간을 의미합니다. 일반적으로 직전에 분석한 버전(previous_version)을 의미하지만, Maven과 비슷한 방식의 버전 정책을 사용하지 않는다면 21일 혹은 특정 날짜 이후 등, 상대적으로 임의의 시간 기준을 설정해야 할 수 있습니다.

    		 
    Measure

    지정한 시점의 대상 component에 대한 metric 값입니다.

    예:

    • MyClass 클래스의 125 라인의 코드
    • myProject 프로젝트의 코드 라인 중복 밀도 30.5%
    		 
    Metric

    A type of measurement. Metrics can have varying values, or measures, over time. Examples: number of lines of code, complexity, etc.

    A metric may be either:

    • qualitative: gives a quality indication on the component (ex: density of duplicated lines, line coverage by tests, etc.)
    • or quantitative: does not give a quality indication on the component (ex: number of lines of code, complexity, etc.)
    		See detailed documentation on metrics.
    Non-functional requirementNon-functional requirement = coding rule 
    Quality Profile

    A set of coding rules.

    Each snapshot is based on a single quality profile.

    		See Quality Profiles.
    Remediation CostThe estimated time required to fix Vulnerability and Reliability Issues. 
    Snapshot

    A set of measures and issues on a given component at a given time.

    A snapshot is generated for each analysis.

    		 
    Technical DebtThe estimated time required to fix all Maintainability Issues / code smells 
    VulnerabilityA security-related issue which represents a potential backdoor for attackers. See also Security-related rules.