...
소개
소프트웨어 품질은 모든 상업적 기업의 관심사가되고 있습니다관심사가 되고 있다. 비즈니스 핵심 시스템을 실행하는데에 가치를 실행하는데 소프트웨어의 역할이 점차 확대되고 있기 때문이다.
일반적으로 소프트웨어 때문입니다. 소프트웨어 품질은 외부 혹은 내부 품질로 구성됩니다. 외부 혹은 구성된다. 외부 품질 즉 기능적 품질은 소프트웨어가 그것이 정의된 기능 요구사항과 잘 맞는지 의도한데로 동작하는지를 나타냅니다동작하는가와 관려있다. 내부 내부 품질은 소프트웨어의 견고성, 표준 준수, 유지보수성, 유지보수성과 보안 취약성과 같은 코드의 주요 내부 특성을 설명한다말한다. 업계
업계 통계에 따르면 평균적으로 소프트웨어 제품의 평생 제품 비용의 80%가 유지 관리에 소요되며 유지 관리 유지보수에 소요된다고 한다. 유지보수 비용은 내부 품질에 따라 높은 가변성을 나타낸다. 이것은 이것은 오늘날 소프트웨어 제품의 유지 보수 가능성 수준이 가능성이 내일의 비용 책임 수준을 결정한다는 것을 의미한다.
기존의 코드 품질 관리에 대한 기존의 접근법은 시간 엄수 감사 혹은 소스 코드에 관리 접근법은 소스코드에 대한 주기적인 감사와 같은 품질 게이트를 포함합니다통해 이뤄진다. 이러한 감사는 보통 기능 테스트 후 혹은 기능 테스트 동안에 개발 프로세스의 "last mile" 동안 마지막에 외부 감사자에 의해 수행된다. 본질적으로 정시 감사는 "완료된" 소프트웨어를 변경하기 때문에 개발주기에 혼란을 야기할 수 있습니다. 최선의 경우, 이 품질 제어 접근은 지연과 재작업을 이끈다. 최악의 경우, 품질이 떨어지는 소프트웨어가 릴리즈 됩니다. 두 경우 모두, 기존의 접근 방식은 품질의 소프트웨어를 구축하는 것은 지나치게 복잡하고 비싸다는 인식을 촉진한다.
새로운 모델을 위한 절박한 필요 중 하나는 개발 사이클 전역에 품질을 강조하는 것이고 다른 하나는 내부 품질 이슈들의 신속한 해결을 확인하기 위해 짧은 피드백 루프를 가지는 것이다. 즉, 모델은 처음부터 품질을 관하는 것이다.
의해서 수행된다. 이때 발견되는 오류들은 소프트웨어 개발 일정에 영향을 주며, 최악의 경우, 저품의 소프트웨어를 출시하게 된다.
지속적인 코드 인스펙션(Continuous Code Inspection)은 위와 같은 문제를 해결하기 위해 Continuous Inspection은 내부 코드 품질을 소프트웨어 개발 라이프 사이클의 필수 요소로 만들기 위해 설계된 전체적이며 완벽하게 구현된 프로세스 입니다. 라이프 사이크 전역에서 모든 이해관계자를 위한 가시성을 높임으로써, Continuous Inspection은 기업이 코드 품질을 온 마음으로 받아 들일 수 있도록 해줍니다. SonarSource가 지원하는 Continuous Inspection 패러다임은 매우 효과적이며, 모든 산업 분야에서 소기업에서 포춘지 100 비즈니스에 이르는 조직에서 실제 세계에서 작동하는 것이 입증되었습니다. 이 백서는 코드 품질 관리의 주요 문제점을 자세히 설명한다. 그다음 Continuous Inspection 패러다임을 소개하고 이러한 문제를 해결하는 방법을 보여주며 수천 개의 기업이 소프트웨어 품질을 향상 시킬 수 있도록 지원한다.
Key Challenges in Code Quality Management
라이프사이클 동안 필수 요소로 만들게 해주는 완벽한 프로세스이다.
코드 품질 관리의 주요 문제
일반적인 정기 감사는 프로세스 상의 지정된 시기에 이뤄지며 지속적이지 못한다. 이러한 정시 감사는 설계 상 지정된 간격으로 이루어지며 지속적이지는 않습니다. 코드 품질 관리를 위한 접근에는 다음과 같은 4가지 주요 유형의 단점이 있으며 이 단점에 대해서는 이 절에서 자세히 설명한다.
Too Little, Too Late
정시 감사는 Cosmetic과 Structural 변경 - 두 종류의 개선을 식별한다.
유형의 문제점을 가진다.
1. 너무 작게 그리고 너무 늦게 수행
정기 감사는 통해 표면적인 오류와 구조적인 오류를 식별할 수 있다. 표면적 오류는 최소한의 수정이 일어나지만, 구조적인 변경은 주요 소프트웨어에 대한 Cosmetic 변경은 최소 수정이 필요한 반면, Structural 변경에는 주요 소프트웨어 재설계가 포함될 수 있다. 이러한 변경이 필요할 수 있지만, 정시 감사의 경우 개발을 어렵게 만드는 과정이 너무 늦게 정의되고 소프트웨어 릴리즈 날짜에 이러한 변경을 포함하도록 재 계획해야하고 개발 후반에 발견되기 때문에 소프트웨어 개발과 릴리즈에 대한 일정 수정이 불가피하고 이로인해 새로운 비즈니스 요구사항을 처리해야하는 기회를 놓칠 수 있습니다있다.
...
2. 개발팀으로부터 푸시백
개발자는 정시 감사로부터 생성된 실행 계획을 철회하는 경향이 있다. 왜냐하면 그들은 정기 감사로부터 발견 문제에 대해 경외시하는 경향이 있다. 그 이유는 다음과 같다.
팀 외부에서
...
생성된 문제를 일상 업무와 다르게 생각한다.
이러한 문제들을 외부 감사자의 주관에 따른 것으로 판단한다.
문맥과 히스토리
...
정보가 없기 떄문에 부적절한 것으로
...
여긴다.
...
개발자는 너무 늦게 참여하고 감사 종료 후 다시 코드를 학습해야 한다.
3. 책임 소재 부재
정기 감사의 경우 품질 프로세스에 대한 책임 소재가 불명확하다. 감사자들은 코드를 소유하고 있지 않기 때문에 문제 해결에 대한 제어가 힘들어 품질 프로세스를 소유할 수 없다. 반대로 개발자들은 검토 과정에 참여하지 않기 때문에 품질 프로세스에 대한 책임이 없다.
4. 표준화되지 않은 품질 요구사항
프로젝트 유형과 개발 부서에 따라 서로 다른 품질 요구사항이 적용될 수 있다. 예를 들어 기존의 개발된 레거시 프로젝트와 현재 진행 중인 프로젝트는 서로 다른 품질 기준으로 측정할 수 있으며, 자체 개발한 코드와 아웃소싱된 코드 역시 다른 품질 기준으로 판달할 수 있다. 이러한 표준화되지 않은 품질 요구사항은 소프트웨어 품질을 절대적으로 평가를 할 수 없게 만들다.
지속적인 코드 인스펙션
지속적인 통합(Continuous Integration)이 여러 개발자의 변경사항을 지속적으로 통합할때 발생할 수 있는 문제를 방지할 수 있듯이 품질 요구사항을 지속적으로 준수하는 것은 기존의 감사에서 발생하는 문제점들을 방지할 수 있다.
지속적인 코드 인스펙션은
Lack of Process Ownership
거기에는 조직 내에서 품질 프로세스의 소유권의 명백히 부족하다. 감사원은 코드를 소유하지 않고 문제 해결을 제어할 수 없기 때문에 프로세스를 소요할 수 없다. 마찬가지로 모델의 명령 및 제어 특성으로 인해 검토 과정에 참여하지 않아 개발 팀이 프로세스를 소유할 수 없다. 따라서 품질에 책임이 있는 두 개의 연결이 끊어진 그룹 모두 책임을 지지 않는다.
Heterogeneous Requirements
품질게이트 중에 발견된 총 이슈 수와 같이 절대적인 값으로 소프트웨어를 측정하는 전형적인 접근은 평가자가 Origin에 따라 각기 다른 요구사항에 대응하여 각 애플리케이션을 측정하도록 한다. 예를 들어, 레거시 프로젝트는 그린 필드 프로젝트와 동일한 고품질 표준을 유지하지 못할 수 있으며, 자체 개발은 아웃소싱 코드와 다르게 판단될 수 있다. 이것은 소프트웨어를 생산에 적용하고 각 프로젝트가 출시되기 전에 품질 임계 값에 대해 동일한 절대 값에 도달하도록 요구해야하기 때문이다. 이러한 절대값을 사용하면 모든 응용 프로그램에 공통적인 요구사항을 적용하는 것이 거의 불가능하며 따라서 전반적인 우수 사례를 채택하기가 어렵다.
위에 요약된 코드 품질 관리에서 문제점과 함께 결합하여 "품질 소프트웨어를 만드는 것은 비용이 든다."는 자기 실현적인 인식을 가지게 된다. 기존 방식에서는 품질 관리가 너무 늦어 효과적이지 못하며 개발 주기가 중단되어 예상치 못한 지연, 계획되지 않은 재작업 혹은 누락된 기능이 발생했다. 품질 측정을 철회하는 개발 팀은 팀의 생산성과 협업을 줄인다. 게다가 전형적인 접근 방법은 개발자 교육의 필요성을 고려하지 않았기 때문에 기업은 전반적인 품질을 장기간 개선하지 못한다. 결과적으로 회사내에서 프로젝트에서 프로젝트로 개발자가 재 할당될때마다 프로젝트 라이프사이클 동안 동일하거나 비슷한 품질 이슈들을 반복적으로 발생한다.
About Continuous Inspection
SonarSource의 설립자인 우리는 수년간 그 분야에서 일해온 전통적 모델의 단점을 잘 알고 있다. 지속적인 통합의 등장과 함께, 우리는 다른 모델이 가능하다고 생각했다. 여러 개발자의 변경사항을 지속적으로 통합하는 것이 통합 문제를 방지하는 것처럼 품질 게이트 표준을 지속적으로 적용하는 것은 시간에 구애 받지 않는 감사 모델의 문제점을 방지한다.
Continuous Inspection은 소프트웨어 개발 라이프사이클의 완전한 부분으로 내부 소프트웨어 품질을 만들기 위해 설계된 향상 시킬 수 있는 코드 품질 관리에서 관리를 위한 새로운 패러다임이다. 프로젝트의 프로젝트의 내부 소프트웨어 품질과 모든 이해관계자를 위한 위해 소프트웨어 품질의 가시화 모두를 증가시키는 완전히 실현된 프로세스이다. Continuous Inspection은 지속적인 코드 품질 관리를 제공하고 개발 프로젝트의 ROI를 대폭 높여준다. Continuous Inspection에서 주요 컨셉은 문제를 조기에 해결하는 것이다. 이 모델에서, 자동화된 코드 감사는 매일 수행되고 조직내에서 사용할 수 있게 해준다. 이 객관적이고 자동화된 감사는 유지보수 가능성, 버그를 위한 테스트, 팀 코딩 표준과 비교하는 것에 따라 프로젝트의 코드를 분석한다. 감사는 개발자 환경에서 직접적으로 이슈를 감지하는 도구들에 의해 완료된다. 팀 구성원은 문제가 발견되는 즉시 알림을 받으므로 최대한 빨리 해결할 수 있다. 이러한 알림의 적시성은 나쁜 습관에서 코더를 훈련시켜 좋은 습관으로 이끌어주는 부가적인 이점을 가지고 있다.
Continuous Integration은 작고 신속한 문제 식별 및 처리 과정을 통해 개발 팀의 효율성을 높이고 더 높은 품질의 코드 개발을 촉진하여 응용 프로그램의 수명을 연장하는 것이 입증되었다. Continuous Inspection의 가장 중요한 측면은 10가지 원칙으로 요약할 수 있다.
The 10 principles of Continuous Inspection :
품질 가시화 증가시킬 수 있다.
지속적인 코드 인스펙션의 주요 컨셉은 지속적으로 코드 품질 관리를 할 수 있게 해주고 발견된 문제를 조기에 해결할 수 있게 해준다. 자동화된 코드 감사를 매일 수행하고 조직에서 이것을 언제든 확인할 수 있게 해준다. 이러한 지속적인 코드 인스펙션은 코드 문제를 식별하고 빠르게 처리함으로써 팀의 효율성과 코드 품질을 향상 시킬 수 있게 해준다.
지속적인 코드 인스펙션의 10가지 원칙
지속적인 코드 인스펙션의 수행을 위해 다음과 같은 10가지 원칙을 보장할 수 있어야 한다.
- 소프트웨어 품질 데이터에 언제든 개발자 프로세스에서 모든 이해관계자는 소프트웨어 품질에 대한 의미있는 데이터에 즉시 액세스 할 수 있어야 한다.
- 소프트웨어 품질 관리는 개발 초기부터 모든 사람의 관심을 받아야 하지만 개발팀의 궁극적인 책임이다. 품질은 개발자의 책임이어야 한다.
- 소프트웨어 품질은 개발 프로세스의 일부입니다. 즉, 품질 기준 충족은 개발 완료를 선언할 수 있는 어려운 요구사항 중 하나이다프로세서의 일부여야 한다.
- 소프트웨어 품질 요구사항은 객관적이어야하며 주관적인 합격/불합격 결정을 요구하지 않아야 객관적이어야 한다.
- 가능한 많이, 소프트웨어 품질 요구사항은 세부사항에 관계없이 모든 소프트웨어 제품에 공통적이여야 공통적으로 적용되어야 한다.
- 소프트웨어 품질 데이터는 항상 최신 버전이여야 버전이어야 한다. (즉, 최신 버전의 코드에서 측정)
- 소프트웨어 제품은 지속적으로 인스펙션되어야 한다. 그래서 에러는
- 문제는 빠르게 발견되고 쉽게 교정되어야 수정될 수 있어야 한다. 개발자는 새로운 품질 결함을 도입하자마자 발견할 품질 결함이 발견되자마자 알 수 있어야 한다. IDE에서 코드를 작성할 때 맞춤법 검사기가 맞춤법 오류를 강조 표시하는 것과 유사합니다.
- Push 혹은 Pull을 통해서든, 새로운 품질 결함이 주입될때 이해관계자는 알람을 받아야한다. 새로운 이슈의 투입은 추적되어야 품질에 대해 신속하고 충분한 정보를 바탕으로 의사 결정을 내릴 수 있다. 새로운 품질 결함을 발견 즉시 알림 받을 수 있어야 한다.
- 소프트웨어 품질 데이터는 절대값과 차등값으로 사용할 수 있어야 한다. 그래야 개발 팀은 발생되는 이슈의 흐름을 완전히 제어할 수 있다.구분되어야 한다.
- 발견된 문제를 해결하기 모든 새로운 이슈와 존재하는 크리티컬한 이슈는 해결을 위해 명확한 경로와 일정이 지정되어야 한다.
...
지속적인 코드 인스펙션을 위한 솔루션
앞서 설명한 지속적인 코드 인스펙션을 위한 10가지 원칙을 보장하기 위한 핵심적인 도구는 SonarQube이다.
개발 프로세스에서 완벽한 자동화를 위해서는 형상관리 도구(Bitbucket)와 CI 빌드 도구(Bamboo)가 필수적으로 필요하다. 다음 그림은 Bitbucket, Bamboo, SonarQube를 사용한 지속적인 코드 인스펙션 솔루션을 보여준다.
- Push changes to dev branch
개발자는 자신이 개발한 소스 코드를 개발 브랜치로 푸시한다. - Trigger build
Bamboo CI 서버는 Bitbucket의 Git 저장소를 트리거하여 빌드를 수행한다. - Build verification & unit test
Bamboo CI 서버는 빌드 검증 결과와 단위 테스트 결과를 Bitbucket에 알려준다. - Static analysis
Bamboo CI 서버는 코드 감사 결과를 SonarQube에 업데이트 한다. - Pull Request
개발자는 개발 브랜치에 개발한 코드를 마스터 브랜치로 머지하기 위해 Pull Request를 수행한다. - Code Inspection
SonarQube는 코드 감사 결과를 Pull Request에 업데이트 한다. - Code Review and Code Merge
리뷰어는 코드 감사 결과를 확인하고 소스 코드를 머지한다.
마무리
지속적인 코드 인스펙션은 소프트웨어 품질 향상을 위해 도입해야할 필수 과제이며, 이를 통해 다음과 같은 이점을 누릴 수 있다.
- 개발자는 조직의 품질 요구사항에 따라 개발 코드의 품질에 대한 지속적인 피드백을 받을 수 있다.
- 조직과 프로젝트의 품질 현황 및 향상 지표를 확인할 수 있다.
- 품질 결함 발생
...
- 시 즉각 알림을 받는다.
- 품질
...
- 감사는 매일 실행된다.
...
- 개발자에게 코드 품질과 관련된 지속적인 교육 지원한다.
- 프로젝트
...
- 이해관계자는 소프트웨어 품질에 대한 의미 있는
...
- 정보를 실시간으로 확인한다.
...
- 조직의 개발 능력은 지속적으로 향상된다.
- 품질 요구사항은
...
- 객관적인 기준에 따라 자동화된 방식으로
...
- 이뤄진다.
- 팀은 새로운 문제가 발생시 추적할
...
- 수 있다.
지속적인
...
코드 인스펙션 패러다임은 포춘 선정 100대 기업들 실제 도입하여 사용하고 있으며 매일 2만명 이상의 개발자가 5천개 이상의 소프트웨어 제품에서 6억 라인 이상의 코드를 점검하고 있다. 이는 소프트웨어 품질 및 안정성을 향상시켜 근본 원인 분석 및 리스크 관리에 소요되는 비용을 절약할 수 있게 해준다.