[지속적인 통합] 7장. 지속적인 검사

지속적인 통합 스터디 메인 페이지

목차

* 주의 : 책(폴M 듀발 저 - 지속적인 통합) 내용 중 기억하고 싶은 내용 및 제 생각을 적은 글 입니다. 책이 나온지 오래되어 설명에 나온 기술스택이 현재 사용되지 않는게 많아 기술스택보다는 이론이나 책의 조언들 위주로 작성할 것 같고, 기술스택은 제가 알고있는대로 수정해서 작성합니다. 따라서 책에서 말하고자 하는 바와 다를 수 있습니다.

* 별도로 표기되어 있지 않다면 이미지 출처는 '지속적인 통합 (폴M 듀발 저)' 책 입니다.

 

 

CHAPTER 7. 지속적인 검사

• 코드를 분석하는 '코드 검토, 짝 프로그래밍, 정적 코드 분석'은 모두 엄격히 적용하지 않으면 그다지 유용하지 않다.
  • 코드 검토(코드 리뷰인듯)나 짝 프로그래밍의 경우, 코드에서 악취가 나더라도 동료끼리 서로에게 사실을 말할 수 없을 수 있다.
  • 반면 정적 분석 도구는 컴퓨터의 단호하고 무자비한 객관성을 이용한다. 또한 저렴해서 자주 돌릴 수 있다. 환경 설정하고 실행할 때 한 번만 사람의 손이 필요하고 이후론 자동화되어 사람이 매시간 돌려주는 노력을 덜어준다.

 

• 자동화된 정적 코드 분석
  • 지역적으로 분산된 팀에 매우 잘 맞음
  • 코드 베이스가 클 때 사람보다 훨씬 효율적임

 

• 물론 둘 중 하나만 선택하라는 얘긴 아니다.
  • 자동화된 검사 도구는 사람끼리의 검토를 증진시킬 뿐더러, 코드가 한없이 길어지고 조밀해지기 때문에 필수적이다.

 

 

검사와 테스트

• 테스트 : 동적인 활동이며, 소프트웨어를 직접 실행시켜서 그 기능을 확인하는 활동
• 검사 : 미리 정의한 규칙 집합에 따라 코드를 분석하는 활동
• 둘 다 테스트와 검사만 해선 의미가 없고, 테스트와 검사가 보고한 문제에 대해 조치를 취할 때 그 가치가 드러난다.

 

 

검사기를 얼마나 자주 돌려야 할까요?

• 코드를 작성하고 곧바로 자동화된 검사기(테스트도)를 돌리면, 수분 내에 결함을 발견하고 고칠 여지가 많아진다.

 

 

코드 복잡도 줄이기

• 긴 메소드와 경로가 아주 많은 메소드는 이해하기 어렵다.
  • 또한 그런 메소드가 결함과 직접적인 연관이 있다는게 증명되었다고 한다.
  • IntelliJ의 경우 code metrics 플러그인을 설치하면 짜면서  바로바로 확인 가능하다.

 

• 큰 값의 순환 복잡도는 결함과 연관 있을 수 있으므로
  • 우선 이 코드와 관련된 테스트가 하나라도 있는지 검증해야 한다.
  • 만약 테스트가 없다면 이 메소드는 정말 위험에 놓인 것이고 즉시 테스트를 작성해야 한다.
  • 이 때 주의점은 바로 리팩토링하면 안되고, 뭐든 바꾸기 전에 테스트부터 작성해야 한다.

 

• 순환 복잡도를 줄이는 효과적인 방법은 더 작고 더 관리하기 좋고 더 테스트하기 좋은 메소드들로 분산시키는 것
  • 코드 베이스의 복잡도 값과 그 경향을 감시하고, 테스트 케이스와 리팩토링으로 결함이 발생할 위험을 낮춰야 한다.

 

 

설계 검토를 지속적으로 수행하기

• 다른 객체에 대한 의존성이 높은 객체는 깨지기 쉽다
  • 예를들어 시스템 내의 다른 모든 객체가 의존하는 객체를 하나라도 바꾸면 다른 곳에서도 문제가 발생한다.

 

• 결함도가 증가하는 경향이 있다면
  • 찾아낸 위험 요소에 맞춰 그 즉시 테스트를 작성
  • 높은 결합도 값이 장기적으로 어떤 곳을 깨먹을지 그 영향력을 평가
  • 테스트를 돌리고 나서, 리팩토링을 하면 향후 변경하기 쉬워질지 생각해본다.

 

 

코드 심사(Audit)를 하여 조직에서 정한 표준을 잘 지키게 하기

• 코드 베이스의 '구조'를 표준화하면 다양한 개인이 코드의 행동을 재빨리 평가하고 때에 따라선 바꿀 수 있게 된다.
  • 예를들어 조건문에 들어가는 문장이 한줄 일 때도 괄호 넣기, 명명 규칙 같은 것들.

 

 

중복 코드를 줄이기

• 중복된 코드의 문제점
  • 버그를 발견하고 보고하고 분석하며 고치는 시간이 배로 든다. -> 유지보수 비용 증가
  • 다른 버그가 없는지 확신하지 못한다 (중복 코드를 아직 발견 못한 것일 수 있다)
  • 추가로 작성한 콛으까지 테스트해야한다 -> 비용 증가

 

 

코드 적용범위를 평가하기

• 테스트 커버리지 검사!

 

 

코드 품질을 지속적으로 평가하기

• 적용범위 보고서를 감시하면 개발 팀이 그에 상응하는 테스트도 없이 커져가는 코드를 신속하게 발견하는 데 도움이 된다.
  • 사람들은 마감일이 촉박하거나 일이 고되면 품질 원칙에서 벗어날 수 있다.
  • 품질이 떨어지는 징후를 알고 미리 대처하는 편이 고객이 먼저 결함을 발견하거나, 나중에 손가락질 받는 것보다 훨씬 낫다.

 

 

질문

• 단위 테스트를 어쩌다 한 번 수행하나요? 아니면 주기적으로 수행하나요? 그렇지 않으면 지속적으로 수행하나요? 얼마나 자주 단위, 컴포넌트 그리고 시스템 테스트 적용범위 검토를 전부 다 돌려보나요?
• 코드 복잡도를 감시합니까?
• 자동화된 설계 검토를 지속적으로 수행하나요?
• 코드 심사를 자동화했나요?
• 코드 중복을 감시합니까?
• 테스트 커버리지를 평가할 수 있습니까? 그 결과에 어떻게 대응하나요?
• 그에 상응하는 테스트를 가진 코드가 몇 퍼센트나 되는지 압니까?
• 테스트 커버리지 보고서를 만들도록 빌드를 적절히 설정했나요?