맨위로가기

코드 검토

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

코드 검토는 작성된 코드의 품질을 향상하고 오류를 줄이기 위해 수행되는 검토 방식이다. 코드 작성 이전의 산출물에는 다른 검토 방법을 사용하며, 코드 검토를 통해 오류의 상당 부분을 제거하고 디버깅, 유지보수, 기능 개선 작업을 효과적으로 수행할 수 있다. 코드 규칙 검사, 실패 검출, 워크 스루 등의 종류가 있으며, 정적 코드 분석 도구를 통해 지원받을 수 있다. 코드 검토는 소프트웨어의 진화 가능성과 유지보수성에 영향을 미치며, 개발자 간의 공통 인식을 형성하고 코드의 가독성을 높이는 효과가 있다. 그러나, 코드 리뷰보다 코딩 규칙 정비가 더 중요하다는 비판과 작업 지연 가능성, 개인의 기술에 따라 검토의 품질이 달라진다는 단점도 존재한다.

더 읽어볼만한 페이지

  • 동료평가 - 학술지
    학술지는 특정 학문 분야의 연구 논문 등을 정기적으로 발행하는 출판물로, 연구자들의 지식 공유 및 학문적 발전을 위한 매개체로서 중요한 역할을 하며, 전자 저널 및 오픈 액세스 운동으로 접근성이 높아지고 학술적 가치를 인정받기 위한 심사 과정이 중요하게 작용한다.
  • 동료평가 - 동료 평가
    동료 평가는 전문가들이 연구의 질을 높이고 오류를 찾아 저작물의 완성도를 높이는 평가 방식이지만, 심사 지연, 아이디어 도용, 심사자의 주관성 등의 문제점과 비판이 존재하여 개선 방안이 모색되고 있다.
  • 소프트웨어 리뷰 - 페어 프로그래밍
    페어 프로그래밍은 두 명의 프로그래머가 한 컴퓨터로 코드를 함께 작성하며, 드라이버와 네비게이터 역할을 번갈아 수행하여 지식 공유, 실시간 코드 검토, 문제 해결 능력 향상 등의 이점을 제공하는 소프트웨어 개발 방법이다.
  • 소프트웨어 리뷰 - 정적 프로그램 분석
    정적 프로그램 분석은 소프트웨어 개발 시 코드를 실행 없이 분석하여 오류, 보안 취약점, 코딩 표준 위반 등을 탐지하는 기술로, 개발 비용 절감, 품질 향상, 시스템 신뢰성 확보에 기여하며 다양한 레벨로 분석 가능하다.
  • 소스 코드 - 헤더 파일
    헤더 파일은 프로그래밍 언어에서 코드 재사용성, 모듈화, 컴파일 시간 단축에 기여하며 함수 프로토타입, 변수 선언 등을 포함하고 `#include` 지시어로 소스 코드에 포함되어 사용되는 파일이다.
  • 소스 코드 - 헝가리안 표기법
    헝가리안 표기법은 변수 이름에 데이터 타입이나 목적을 나타내는 접두사를 붙이는 명명 규칙으로, 찰스 시모니가 고안하여 마이크로소프트에서 널리 사용되었으나, 코드 가독성 향상에 대한 유용성 논란과 함께 최신 IDE 환경에서는 불필요하다는 비판도 있다.
코드 검토
개요
정의소프트웨어 개발 과정에서 코드의 품질을 향상시키기 위해 한 명 이상의 사람이 코드를 검사하는 활동
목적결함을 찾고 수정하여 소프트웨어 품질을 개선하는 것
다른 이름코드 검사
피어 리뷰
소프트웨어 검토
기술 검토
방법
공식 검토계획, 회의, 후속 작업이 포함된 구조화된 프로세스
일반적으로 중요한 코드에 사용
비공식 검토페어 프로그래밍, 어깨 너머 검토, 임시 검토 등
더 가볍고 유연한 접근 방식
이점
결함 발견개발 초기 단계에서 결함을 식별하고 수정
코드 품질 향상코드 가독성, 유지보수성, 성능 개선
코딩 표준 준수
지식 공유팀 구성원 간의 지식 공유 및 학습 촉진
위험 감소출시 전 잠재적 문제 식별 및 해결
고려 사항
검토 범위검토할 코드의 양과 복잡성
검토자 선택적절한 기술과 경험을 가진 검토자 선택
검토 도구코드 검토 프로세스 지원 도구 활용
피드백 처리검토 피드백을 건설적으로 처리하고 코드에 반영
관련 활동
소프트웨어 테스트코드의 기능적 정확성 검증
정적 분석코드를 실행하지 않고 잠재적 오류 식별
소프트웨어 유지보수코드 검토를 통해 유지보수 용이성 향상

2. 검토 방식

코드 검토는 코드 작성 과정에서 발생하는 오류를 줄이고, 코드의 품질을 높이기 위해 사용되는 여러 방식이 있다.


  • '''코드 규칙 검사(Coding Rule Check)''': 미리 정해진 코딩 규칙에 따라 코드가 작성되었는지 검사한다. 빠른 시간 안에 검토가 가능하고 품질 향상 효과가 크지만, 오류 검출율은 낮다.[26]
  • '''실패 검출(Fault Detection)''': 오류를 유발하는 코드 형태를 추적하여 발생 여부를 판단한다. 오류 검출이 효과적이지만, 코드 추적 대상이 광범위해져 시간이 오래 걸릴 수 있다.[26]
  • '''워크 스루(Work Thru)''': 작성된 시나리오에 따라 코드를 시뮬레이션하여 검출한다. 유일하게 기능 검사가 가능하지만, 투자되는 시간에 비해 비효율적이다.[26]


CVS 등 온라인 소프트웨어 저장소를 이용하면 여러 사람이 공동으로 코드 리뷰를 수행할 수 있다. 버전 관리 시스템(VCS) 및 호스팅 서비스를 이용한 소프트웨어 개발에서는 코드 수정을 포함한 분기 대상 브랜치의 풀 리퀘스트(pull request)를 제출할 때 리뷰를 받고, 통과된 코드만 분기 원본 브랜치에 병합하여 수정으로 인한 결함 혼입 위험을 줄일 수 있다.

소프트웨어 개발자를 대신하여 전형적인 보안 허점을 찾는 작업을 수행하는 자동화된 코드 리뷰 소프트웨어도 있다. Flawfinder[27]나 Rough Auditing Tool for Security (RATS)[28] 등이 그 예시이다. GitHub와 연계하는 Sider와 같은 자동화 서비스도 있다.

2. 1. 적용 대상

코드 검토는 작성된(완성된) 코드에만 적용이 가능하다. 코드 작성 이전의 아키텍처와 소프트웨어 디자인 산출물 및 작성된 코드의 실행 가능한 형태는 다른 검토 방법을 이용해야 한다.[26]

2. 2. 적용 단계

코드 검토는 코드 작성 과정에서 검토 주최자가 적절한 시기를 선정하여 진행한다.[26] 작성된 지 얼마 되지 않은 소스 코드나 충분한 테스트가 이루어지지 않은 코드는 잠재적으로 버그나 보안 허점을 포함하는 경우가 많다. 또한 직접적인 결함은 없더라도 명명 규칙을 따르지 않거나 모듈 분할과 같은 구조 설계가 부적절하여 가독성이나 유지 보수성에 문제가 있는 경우도 있다. 최적화되지 않은 코드는 메모리나 프로세서 시간과 같은 계산 자원을 낭비하여 성능 저하를 초래하는 문제를 안고 있는 경우도 있다.

2. 3. 적용 효과

코드 검토를 통해 다음과 같은 효과를 기대할 수 있다.

  • 리뷰에서 발견된 유사한 버그에 대해 리뷰 참가자 간의 공통 인식을 형성할 수 있다.
  • 버그 은폐를 줄일 수 있다.
  • 리뷰를 수행한다는 의식으로 인해, 타인에게 보여지는 코드를 작성하게 되어 가독성이 향상된다.
  • 코딩 규약 등에 대한 각자의 인식 차이를 수정할 수 있다.
  • 코드 작성 과정에서 발생하는 60% ~ 70% 이상의 오류를 제거하고 디버깅, 유지보수, 기능 개선 작업 과정을 효과적으로 수행할 수 있다.[26]


다만, 그 특성상 개발 과정상의 문제점도 많아 비판도 있다(#비판 항목 참조).

3. 종류

IEEE 1028에 코드 검토 프로세스의 추가 유형이 명시되어 있다.[5]


  • 관리 검토
  • 기술 검토
  • 감사

3. 1. 코드 규칙 검사 (Coding Rule Check)

미리 정의된 코딩 규칙에 따라 코드가 작성되었는지 검사하며 빠른 시간에 검토하고, 품질 향상 효과가 매우 크지만 오류 검출율이 낮다.[26]

3. 2. 실패 검출 (Fault Detection)

오류를 유발하는 코드의 형태를 추적하여 발생 여부를 판단하는 방법이다. 오류 검출이 효과적으로 가능하지만, 코드의 추적 대상이 광범위해지며 이에 따라서 요구되는 시간이 증가한다.

3. 3. 워크스루 (Walk-through)

작성된 시나리오에 따라 코드를 시뮬레이션하여 검출하는 방법으로, 유일하게 기능 검사가 가능하지만 투자되는 시간에 비해 비효율적이다.

3. 4. 검사 (Inspection)

코드 검사 방법에는 다음과 같은 세 가지 주요 방법이 있다.[6]

  • 코드 규칙 검사: 미리 정의된 코딩 규칙에 따라 코드가 작성되었는지 검사한다. 빠른 시간 안에 검토가 가능하고 품질 향상 효과가 크지만, 오류 검출율은 낮다.
  • 실패 검출(Fault Detection): 오류를 유발하는 코드 형태를 추적하여 발생 여부를 판단한다. 오류 검출이 효과적이지만, 코드 추적 대상이 광범위해져 요구되는 시간이 증가한다.
  • 워크 스루(Work Thru): 작성된 시나리오에 따라 코드를 시뮬레이션하여 검출한다. 유일하게 기능 검사가 가능하지만, 투자되는 시간에 비해 비효율적이다.


과거에 상세히 연구되고 설명된 최초의 코드 검토 프로세스는 마이클 페이건에 의해 "검토"라고 불렸다.[6] 페이건 검토는 여러 참가자와 단계를 거치는 신중하고 상세한 실행을 포함하는 공식적인 프로세스이다. 공식적인 코드 검토에서, 소프트웨어 개발자들은 인쇄된 사본을 사용하여 코드를 한 줄씩 검토하기 위해 일련의 회의에 참석한다. 연구에 따르면 공식 검토는 결함을 식별하는 데 매우 철저하고 효과적이다.[6]

3. 5. 정기적인 변경 기반 코드 검토 (Regular change-based code review)

최근 몇 년 동안, 많은 업계 팀들이 각 검토의 범위를 티켓, 사용자 스토리, 커밋 또는 기타 작업 단위에서 수행된 코드베이스 변경 사항에 맞춘 더 가벼운 검토 프로세스를 채택했다.[7][3] 또한, 모든 티켓에 대한 필수 검토와 같이 검토 작업을 개발 워크플로우에 통합하는 규칙 또는 관례가 있으며, 일반적으로 각 검토를 명시적으로 계획하는 대신 풀 리퀘스트의 일부로 수행된다. 이러한 프로세스를 "정기적인 변경 기반 코드 검토"라고 한다.[1] 이 기본 프로세스에는 많은 변형이 있다. 2017년 240개 개발팀을 대상으로 한 설문 조사에 따르면 코드 검토를 사용하는 팀의 90%가 변경 기반 프로세스를 따랐으며, 60%는 특히 정기적인 변경 기반 검토를 사용했다.[3] 마이크로소프트[8], 구글[9], 페이스북을 포함한 주요 소프트웨어 기업들이 변경 기반 코드 검토 프로세스를 따른다.

4. 효과

코드 검토의 주요 목표는 품질 문제의 직접적인 발견이지만,[3] 코드 검토는 일반적으로 다음과 같은 목표들을 달성하기 위해 수행된다:[15][4]


  • '''코드 품질 향상''' - 가독성, 통일성 및 이해도를 높여 내부 코드 품질 및 유지보수성 향상
  • '''소프트웨어 결함 감지''' - 외부 측면, 특히 정확성과 관련된 품질을 개선하고 성능 문제, 보안 취약점 및 주입된 악성 코드와 같은 문제점 발견
  • '''학습/지식 전달''' - 리뷰어와 작성자 모두에게 코드베이스 지식, 해결 방법 및 품질 기대치를 공유
  • '''상호 책임감 증대''' - 집단적인 코드 소유권과 연대 의식 증대
  • '''더 나은 솔루션 찾기''' - 현재 코드 범위를 넘어 새롭고 더 나은 솔루션과 아이디어에 대한 아이디어 창출
  • '''QA 가이드라인, ISO/IEC 표준 준수''' - 코드 검토는 항공 교통 관제 소프트웨어 및 안전 필수 시스템과 같은 일부 상황에서 필수적임


작성된 지 얼마 되지 않은 소스 코드나 충분한 테스트가 이루어지지 않은 코드는 잠재적으로 버그나 보안 허점을 포함하는 경우가 많다. 또한 직접적인 결함은 없더라도 명명 규칙을 따르지 않거나 모듈 분할과 같은 구조 설계가 부적절하여 가독성이나 유지 보수성에 문제가 있는 경우도 있다. 최적화되지 않은 코드는 메모리나 프로세서 시간과 같은 계산 자원을 낭비하여 성능 저하를 초래하는 문제를 안고 있는 경우도 있다. 소프트웨어 품질을 높이기 위해서는 이러한 결함이나 문제점을 제거할 필요가 있다. 숨겨진 결함이나 문제의 수는 일반적으로 소스 코드를 작성한 개발자(프로그래머)의 설계 기술이나 구현 기술에 따라 다르지만, 이를 발견하고 수정하는 방법 중 하나는 본인 또는 타인이 소스 코드의 심사를 하는 것, 즉 '''코드 리뷰'''이다[26]。

온라인 소프트웨어 저장소 (익명의 CVS 등)를 사용하면 여러 개인이 공동으로 코드 리뷰를 수행할 수 있다. 버전 관리 시스템(VCS) 및 호스팅 서비스를 이용한 소프트웨어 개발에서는 코드 수정을 포함한 분기 대상 브랜치의 풀 리퀘스트(pull request)를 제출할 때 리뷰를 받고, 리뷰를 통과한 코드만 분기 원본 브랜치에 병합되도록 함으로써, 수정으로 인해 다른 결함이 혼입될 위험을 줄일 수 있다.

코드 리뷰를 자동화하는 소프트웨어를 사용하면 소프트웨어 개발자를 대신하여 전형적인 보안 허점을 찾는 작업을 수행한다. GitHub와 연계하는 Sider와 같은 자동화 서비스도 있다.

코드 검토를 실시함으로써 다음과 같은 효과를 기대할 수 있다.

  • 리뷰에서 발견된 유사한 버그에 대해 리뷰 참가자 간의 공통 인식을 형성할 수 있다.
  • 버그 은폐를 감소시킬 수 있다.
  • 리뷰를 수행한다는 의식으로 인해, 타인에게 보여지는 코드를 작성하게 되어 가독성이 향상된다.
  • 코딩 규약 등에 대한 각자의 인식 차이를 수정할 수 있다.

5. 코드 검토의 효율성 및 가이드라인

케이퍼스 존스(Capers Jones)는 12,000개 이상의 소프트웨어 개발 프로젝트를 분석하여, 형식적 검토는 60~65%의 잠재 결함 발견율을 보인 반면, 비형식적 검토는 50% 미만의 결함을 발견했다는 결과를 제시했다. 대부분의 테스트에서는 잠재 결함 발견율이 약 30%였다.[10][11] 그러나 "동료 코드 검토의 최고의 비결(Best Kept Secrets of Peer Code Review)"이라는 책에 실린 코드 검토 사례 연구는 케이퍼스 존스의 연구와 상반된 결과를 보였는데, 경량 검토가 비용 및 자금 측면에서 더 효율적이면서도 형식적 검토만큼 많은 버그를 발견할 수 있다는 점을 발견했다.[10][12]

연구에 따르면 코드 검토 의견의 최대 75%는 기능보다는 소프트웨어 진화 가능성과 유지보수성에 영향을 미치는 것으로 나타났다.[13][14][15][16] 이는 코드 검토가 긴 제품 또는 시스템 수명 주기를 가진 소프트웨어 회사에게 훌륭한 도구임을 시사한다.[17] 코드 검토에서 논의되는 문제의 15% 미만이 버그와 직접적으로 관련이 있다.[18]

코드 검토의 효과는 검토 속도와 상관관계가 있는데, 최적의 코드 검토 속도는 시간당 200~400행이다.[19][20][21][22] 임베디드 소프트웨어와 같은 안전 필수 소프트웨어의 경우, 시간당 수백 행 이상의 코드를 검토하는 것은 오류를 발견하기에는 너무 빠를 수 있다.[19][23]

작성된 지 얼마 되지 않은 소스 코드나 충분한 테스트가 이루어지지 않은 코드는 잠재적으로 버그나 보안 허점 등의 문제점을 포함하는 경우가 많다. 또한 직접적인 결함은 없더라도 명명 규칙을 따르지 않거나 모듈 분할과 같은 구조 설계가 부적절하여 가독성이나 유지 보수성에 문제가 있는 경우도 있다. 최적화되지 않은 코드는 계산 자원을 낭비하여 성능 저하를 초래하기도 한다. 소프트웨어 품질을 높이기 위해서는 이러한 결함이나 문제점을 제거할 필요가 있으며, 이를 위한 방법 중 하나가 소스 코드 심사, 즉 '''코드 리뷰'''이다.[26]

온라인 소프트웨어 저장소를 이용하면 여러 사람이 공동으로 코드 리뷰를 수행할 수 있다. 버전 관리 시스템 및 호스팅 서비스를 이용한 소프트웨어 개발에서는 코드 수정을 포함한 분기 대상 브랜치의 풀 리퀘스트(pull request)를 제출할 때 리뷰를 받고, 리뷰를 통과한 코드만 분기 원본 브랜치에 병합되도록 함으로써, 수정으로 인해 다른 결함이 혼입될 위험을 줄일 수 있다.

코드 리뷰를 자동화하는 소프트웨어를 사용하면 소프트웨어 개발자를 대신하여 전형적인 보안 허점을 찾는 작업을 수행한다. Flawfinder[27]나 Rough Auditing Tool for Security (RATS)[28] 등이 그러한 소프트웨어의 예시이다. GitHub와 연계하는 Sider와 같은 자동화 서비스도 있다.

코드 검토를 통해 다음과 같은 효과를 기대할 수 있다.


  • 리뷰에서 발견된 유사한 버그에 대해 리뷰 참가자 간의 공통 인식을 형성할 수 있다.
  • 버그 은폐를 감소시킬 수 있다.
  • 리뷰를 수행한다는 의식으로 인해, 타인에게 보여지는 코드를 작성하게 되어 가독성이 향상된다.
  • 코딩 규약 등에 대한 각자의 인식 차이를 수정할 수 있다.

6. 지원 도구

온라인 저장소 (익명의 CVS 등)를 이용하면 여러 사람이 공동으로 코드 검토를 수행할 수 있다. 버전 관리 시스템(VCS) 및 호스팅 서비스를 이용한 소프트웨어 개발에서는 코드 수정을 포함한 분기 대상 브랜치의 풀 리퀘스트(pull request)를 제출할 때 검토를 받고, 검토를 통과한 코드만 분기 원본 브랜치에 병합되도록 하여 수정으로 인해 다른 결함이 혼입될 위험을 줄일 수 있다.

6. 1. 정적 코드 분석 도구

정적 코드 분석 소프트웨어는 코드 검토자가 알려진 취약점과 결함 패턴을 소스 코드에서 자동으로 확인하도록 지원하며, 특히 대규모 코드 덩어리에 유용하다.[24] VDC 리서치의 2012년 연구에 따르면, 설문 조사에 참여한 임베디드 소프트웨어 엔지니어의 17.6%가 현재 동료 코드 검토를 지원하기 위해 자동화된 도구를 사용하고 있으며, 23.7%는 2년 안에 사용할 계획이라고 한다.[25]

코드 리뷰를 자동화하는 소프트웨어를 사용하면 소프트웨어 개발자를 대신하여 전형적인 보안 허점을 찾는 작업을 수행한다. 그러한 소프트웨어의 예로 Flawfinder[27]나 Rough Auditing Tool for Security (RATS)[28] 등이 있다. GitHub와 연계하는 Sider와 같은 자동화 서비스도 있다.

  • C/C++/JAVA : CODESCROLLTM code inspector, QAC, QACPP, PMD, Jlint, FindBugs, JsLint

7. 비판

코드 리뷰보다 코딩 규칙 및 방법론 정비가 더 중요하다는 시각도 있다. 익스트림 프로그래밍(XP)에서는 페어 프로그래밍을 권장하며, 코딩 중 코드 리뷰를 동시에 수행한다. XP 지지자들은 리팩토링이나 코드 작성 전 테스트 작성을 통해 리뷰/재작업 없는 코드를 생성하여 소프트웨어 개발 속도가 빨라진다고 주장한다. DOD-STD-2167A[29]에서는 코드 리뷰를 "노동력은 많고 이익은 적다"고 평가한다. Lausen과 Younessi는 라인 단위 코드 리뷰는 거의 가치가 없다고 결론짓는다. 프로그래머에게 라인 단위 코드 리뷰를 하게 하는 것은 다른 기법보다 생산성이 낮다.

코드 리뷰로 인해 담당 작업 지연이 발생할 수 있다는 비판도 있다.

리뷰의 정밀도와 세부 수준은 개인의 기술에도 의존한다. 또한, 리뷰의 지적 항목이나 내용을 조직 내에서 공유하지 못하면 같은 지적이 상대를 바꿔가며 반복될 우려가 있다. 사전에 리뷰의 목적과 도달점을 명확히 하고, 개발 멤버 간에 공유하는 것도 필요하다.[30]

컴파일러의 경고 및 정적 코드 분석의 결과는 잠재적인 문제점을 지적하는 경우가 많다. 경고 수준을 높이고, 이를 무시하지 않고 코드를 올바르게 수정해나가면, 개인적이고 시간이 많이 소요되는 코드 리뷰에 의존하지 않고도 문제점의 일부는 해결될 수 있다.[31]

참조

[1] 서적 2016 IEEE International Conference on Software Quality, Reliability and Security (QRS) 2016
[2] 서적 Automated Defect Prevention: Best Practices in Software Management http://www.wiley.com[...] Wiley-IEEE Computer Society Press
[3] 서적 Product-Focused Software Process Improvement 2017
[4] 서적 Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2016 2016
[5] 서적 IEEE Standard for Software Reviews and Audits https://ieeexplore.i[...] IEEE STD 1028-2008 2008-08
[6] 간행물 Design and code inspections to reduce errors in program development 1976
[7] 서적 Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering 2013
[8] 간행물 Code Reviewing in the Trenches: Challenges and Best Practices https://www.michaela[...] 2020-11-28
[9] 서적 Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice 2018
[10] 웹사이트 Measuring Defect Potentials and Defect Removal Efficiency http://www.crosstalk[...] Crosstalk, The Journal of Defense Software Engineering 2010-10-05
[11] 간행물 Embedded Software: Facts, Figures, and Future 2009-04
[12] 서적 Best Kept Secrets of Peer Code Review (Modern Approach. Practical Advice.) https://archive.org/[...] Smart Bear Inc.
[13] 서적 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering https://www.michaela[...] 2020-11-28
[14] 간행물 What Types of Defects Are Really Discovered in Code Reviews? http://lib.tkk.fi/Di[...] 2012-03-21
[15] 웹사이트 Expectations, outcomes, and challenges of modern code review http://sback.it/publ[...] Proceedings of the 35th IEEE/ACM International Conference On Software Engineering (ICSE 2013) 2015-09-02
[16] 웹사이트 Modern code reviews in open-source projects: which problems do they fix? http://sback.it/publ[...] Proceedings of the 11th Working Conference on Mining Software Repositories (MSR 2014) 2015-09-02
[17] 웹사이트 Does the Modern Code Inspection Have Value? http://csalpha.ist.u[...] 2015-02-17
[18] 웹사이트 Characteristics of Useful Code Reviews: An Empirical Study at Microsoft https://www.michaela[...] 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories 2020-11-28
[19] 간행물 The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data 2009-04-17
[20] 웹사이트 Code Review Metrics https://www.owasp.or[...] 2015-10-09
[21] 웹사이트 Best Practices for Peer Code Review http://smartbear.com[...] Smart Bear Software 2015-10-09
[22] 간행물 A Two-Person Inspection Method to Improve Programming Productivity http://dl.acm.org/ci[...] 2015-10-09
[23] 웹사이트 A Guide to Code Inspections http://www.ganssle.c[...] The Ganssle Group 2010-10-05
[24] 서적 2013 35th International Conference on Software Engineering (ICSE)
[25] 웹사이트 Automated Defect Prevention for Embedded Software Quality http://alm.parasoft.[...] VDC Research 2012-04-10
[26] 웹사이트 IPA ISEC　セキュア・プログラミング講座：C/C++言語編　第2章 脆弱性回避策とソフトウェア開発工程：ソースコードレビュー https://web.archive.[...] Internet Archive
[27] 웹사이트 Flawfinder Home Page https://dwheeler.com[...]
[28] 웹사이트 Rough Auditing Tool for Security http://www.securesof[...]
[29] 웹사이트 DOD-STD-2167A http://www2.umassd.e[...]
[30] 웹사이트 コードレビューを成功させるためにCTOが考えるべき7つのことー監修：高遠和也（株式会社LIG CTO） | FLEXY（フレキシー） https://flxy.jp/arti[...]
[31] 웹사이트 アプリケーション開発で質の高いコードレビューを実現するためのポイントとは ? ~ 後編~ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS https://aws.amazon.c[...]
[32] 서적 Automated Defect Prevention: Best Practices in Software Management http://www.wiley.com[...] Wiley-IEEE Computer Society Press


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com