Introduction 

소프트웨어 품질은 모든 상업적 기업의 관심사가되고 있습니다. 비즈니스 핵심 시스템을 실행하는데에 소프트웨어의 역할이 점차 확대되고 있기 때문입니다. 소프트웨어 품질은 외부 혹은 내부 품질로 구성됩니다. 외부 혹은 기능적 품질은 소프트웨어가 그것이 정의된 기능 요구사항과 잘 맞는지 의도한데로 동작하는지를 나타냅니다. 내부 품질은 견고성, 표준 준수, 유지보수성과 같은 코드의 주요 내부 특성을 설명한다. 업계 통계에 따르면 평균적으로 소프트웨어 제품의 평생 비용의 80%가 유지 관리에 소요되며 유지 관리 비용은 내부 품질에 따라 높은 가변성을 나타낸다. 이것은 오늘날 소프트웨어 제품의 유지 보수 가능성 수준이 내일의 비용 책임 수준을 결정한다는 것을 의미한다.

코드 품질 관리에 대한 기존의 접근법은 시간 엄수 감사 혹은 소스 코드에 대한 주기적인 감사와 같은 품질 게이트를 포함합니다. 이러한 감사는 보통 기능 테스트 후 혹은 동안에 개발 프로세스의 "last mile" 동안 외부 감사자에 의해 수행된다. 본질적으로 정시 감사는 "완료된" 소프트웨어를 변경하기 때문에 개발주기에 혼란을 야기할 수 있습니다. 최선의 경우, 이 품질 제어 접근은 지연과 재작업을 이끈다.  최악의 경우, 품질이 떨어지는 소프트웨어가 릴리즈 됩니다. 두 경우 모두, 기존의 접근 방식은 품질의 소프트웨어를 구축하는 것은 지나치게 복잡하고 비싸다는 인식을 촉진한다. 

새로운 모델을 위한 절박한 필요 중 하나는 개발 사이클 전역에 품질을 강조하는 것이고 다른 하나는 내부 품질 이슈들의 신속한 해결을 확인하기 위해 짧은 피드백 루프를 가지는 것이다. 즉, 모델은 처음부터 품질을 관하는 것이다. 

Continuous Inspection은 내부 코드 품질을 소프트웨어 개발 라이프 사이클의 필수 요소로 만들기 위해 설계된 전체적이며 완벽하게 구현된 프로세스 입니다. 라이프 사이크 전역에서 모든 이해관계자를 위한 가시성을 높임으로써, Continuous Inspection은 기업이 코드 품질을 온 마음으로 받아 들일 수 있도록 해줍니다.  SonarSource가 지원하는 Continuous Inspection 패러다임은 매우 효과적이며, 모든 산업 분야에서 소기업에서 포춘지 100 비즈니스에 이르는 조직에서 실제 세계에서 작동하는 것이 입증되었습니다. 이 백서는 코드 품질 관리의 주요 문제점을 자세히 설명한다. 그다음 Continuous Inspection 패러다임을 소개하고 이러한 문제를 해결하는 방법을 보여주며 수천 개의 기업이 소프트웨어 품질을 향상 시킬 수 있도록 지원한다.

Key Challenges in Code Quality Management

정시 감사는 설계 상 지정된 간격으로 이루어지며 지속적이지는 않습니다. 코드 품질 관리를 위한 접근에는 4가지 주요 유형의 단점이 있으며 이 단점에 대해서는 이 절에서 자세히 설명한다.

Too Little, Too Late

정시 감사는 Cosmetic과 Structural 변경 - 두 종류의 개선을 식별한다. 

Cosmetic 변경은 최소 수정이 필요한 반면, Structural 변경에는 주요 소프트웨어 재설계가 포함될 수 있다. 이러한 변경이 필요할 수 있지만, 정시 감사의 경우 개발을 어렵게 만드는 과정이 너무 늦게 정의되고 소프트웨어 릴리즈 날짜에 이러한 변경을 포함하도록 재 계획해야하고 새로운 비즈니스 요구사항을 처리해야하는 기회를 놓칠 수 있습니다. 

Pushback from Development Teams

개발자는 정시 감사로부터 생성된 실행 계획을 철회하는 경향이 있다. 왜냐하면 그들은 

• 팀 외부에서 생성되어 일상 업무에서 새로운 제약으로 간주한다. 
• 주관적이다. 조사 결과는 객관적인 조치보다는 감사인의 판단에 의존한다.
• 문맥과 히스토리 정보를 잃어 부적절한 것으로 여겨진다. 
• 변경으로 인해 invalidate되고 빠르게 out-dated 된다. 
• 개발자 및 이해관계자를 검토 및 감사 프로세스에 참여시키지 않는다. 
• 개발자들은 너무 늦게 개입하고 기능을 감사 할때까지는 개발자가 코드를 다시 학습하여 찾기를 처리해야 한다.

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 :

1. 개발자 프로세스에서 모든 이해관계자는 소프트웨어 품질에 대한 의미있는 데이터에 즉시 액세스 할 수 있어야 한다.
2. 소프트웨어 품질 관리는 개발 초기부터 모든 사람의 관심을 받아야 하지만 개발팀의 궁극적인 책임이다. 
3. 소프트웨어 품질은 개발 프로세스의 일부입니다. 즉, 품질 기준 충족은 개발 완료를 선언할 수 있는 어려운 요구사항 중 하나이다.
4. 소프트웨어 품질 요구사항은 객관적이어야하며 주관적인 합격/불합격 결정을 요구하지 않아야 한다. 
5. 가능한 많이, 소프트웨어 품질 요구사항은 세부사항에 관계없이 모든 소프트웨어 제품에 공통적이여야 한다. 
6. 소프트웨어 품질 데이터는 최신 버전이여야 한다. (즉, 최신 버전의 코드에서 측정)
7. 소프트웨어 제품은 지속적으로 인스펙션되어야 한다. 그래서 에러는 빠르게 발견되고 쉽게 교정되어야 한다. 개발자는 새로운 품질 결함을 도입하자마자 발견할 수 있어야 한다. IDE에서 코드를 작성할 때 맞춤법 검사기가 맞춤법 오류를 강조 표시하는 것과 유사합니다. 
8. Push 혹은 Pull을 통해서든, 새로운 품질 결함이 주입될때 이해관계자는 알람을 받아야한다. 새로운 이슈의 투입은 추적되어야 품질에 대해 신속하고 충분한 정보를 바탕으로 의사 결정을 내릴 수 있다. 
9. 소프트웨어 품질 데이터는 절대값과 차등값으로 사용할 수 있어야 한다. 그래야 개발 팀은 발생되는 이슈의 흐름을 완전히 제어할 수 있다.
10. 모든 새로운 이슈와 존재하는 크리티컬한 이슈는 해결을 위해 명확한 경로와 일정이 지정되어야 한다.