[스크랩] 코드리뷰, 꼭 해야 할까?
출처 : micro software vol.364
작성자 : 신현묵(supims@gmail.com)
삐딱한 아키텍트의 생각
코드리뷰, 꼭 해야 할까?
많은 소프트웨어 개발사들이 코드리뷰에 골머리를 앓고 있다. 코드리뷰의 어려움과 한계 체크 영역에 대한 모호함 때문에 많은 개발사들이
이 같이 느끼는 듯하다. 만약 스크래치처럼 시각화된 방법으로 소스 코드를 리뷰할 수 있다면 어떨까? 아마도 미래의 소프트웨어
개발은 스크래치처럼 완전한 형태를 재배치하는 형식으로 변화되지 않을까 생각한다. 이번 칼럼에서는 이러한 코드리뷰에 대해 알아보자.
필자는 전통적인 방식으로 큰 아들에게 소프트웨어 개발을 가르치다가 재미없는 교육 방식 때문에 실패한 적이 있다. 그래서 둘째 아들을
교육할 땐 '스크래치'로 흥미를 먼저 유발시키는 방법을 택했다. 스크래치는 에러나 실패가 없고 레고 블록 같은 재미를 느낄 수
있어 처음 코딩을 배우는 사람에게 좋은 교육 수단이다. 코드리뷰가 스크래치와 같은 방식으로 진행된다면 개발자들이 코드리뷰의
어려움을 조금 덜 수 있지 않을까?
코드리뷰가 어려운 이유
타인이 작성한 소스 코드를 리뷰하는 것이 왜 이토록 어려운 것일까? 소스 코드를 리뷰할 때는 소스 코드에 잇어서 완성형이란 없음을 먼저 인정해야 한다. 다양한 변화가 잠재돼 있고 그에 대한 준비도 이미 갖춘 것이 바로 소스 코드다. 그리고 소프트웨어의 품질이 무엇보다 중요한 시점인 요즘은 소프트웨어 개발에 있어서 핵심적인 행위가 바로 코드리뷰이다. 그런데 이 코드리뷰라는 것이 생각보다 수비지 않고 그 형태와 범위에 대해 정의하는 것도 상당히 모호한 점이 많다. 때문에 기업에서는 코드리뷰를 어떻게 할 것인지에 대해 명쾌한 판단 기준을 가지고 있어야 한다. 그래야 명확한 코드리뷰가 도리 수 있다. 업계에서는 종종 디자이너에게는 비평(critique)이 있고 개발자에게는 코드리뷰가 있다고 이야기 한다. 좋은 비평을 받고 좋은 리뷰를 하려면 다음의 세가지 원칙을 준수해야 한다.
-. 리뷰는 언제나 상호 합의된 상태에서 진행해야 한다. -. 리뷰어의 결과물에 대해 객관성을 가지고 서로 인정해야 한다. -. 객관적인 시각으로 비평할 수 있는 작성자가 선정돼야 한다. |
코드리뷰는 정량적인 검토와 정성적인 검토를 구분해야 한다. 이 영역의 구분이 모호해지면 리뷰의 방향성을 상실하게 된다. 특히 정량적인 검토와 기본적인 규칙들은 가능한 한 자동화화하고 형상관리 도구에서 기본적인 규칙이 지켜지도록 권장해야 한다. 최소한 이러한 것들만 이뤄져도 소프투에어의 품질은 급상승하게 된다. 하지만 코드에는 늘 논쟁거리가 있게 마련이다. 어떤 것이 우선이지 서술하기가 쉽지 않다. 이러한 점이 정성적인 부분에 대한 검토이다.
코드리뷰의 정도
몇 해 전부터 주목받는 개발 방법론은 '테스팅'을 주로 하고 SRS와 같은 요구사항에 집중하기 보다는 TDD와 같은 방법으로 산출물의 가치를 높이는 방법이다. 과거에는 요구사항을 통해 결과물이 완성되는 개발이 주로 행해졌다. 현재는 변화하는 요구사항을 계속 수용하면서 버그 없는 결과물을 도출하는 것이 중요해진 만큼 테스트를 얼마나 집중적으로 하느냐가 관건이다. 웹서비스의 시대로 변화하면서 소프트웨어 개발의 방향도 바뀌었다. 때문에 아쉽게도 당장의 성과물을 위해 코드리뷰보다는 테스팅에 집중하는 것이 더 효율적이다. 빠르게 개발하고 테스트를 통해 버그를 찾은 다음 이를 다시 수정하는 것이 특정 기능들을 나열하고 기능에 만족하는 소프트웨어를 개발할 때 가장 적합한 방법이기 때문이다.
물론 이러한 방향성이나 전체적인 틀에 대해 결정하는 것은 아키텍트의 몫이다. 내가 속한 개발팀의 결과물이 어떤 것이냐에 따라서 개발 방법을 혼용해 사용하기도 한다. 그러나 이번 컬럼의 주제는 코드리뷰다. SRS 중심이든, TDD 중심이든 코드리뷰가 매우 중요하다는 사실은 변함이 없다.
코드리뷰는 기능 나열 수준이 아닌 어느 정도 이상의 복잡도와 코드품질을 요하는 경우에 수행하는 것이 현명하다. 일반적으로 SI에서는 워크스루의 형태에만 이 방법이 적하하다. 일반적으로 SI에서는 우커스루의 형태에만 이 방법이 적합하다. 특정 도에밍네 애몰돼 있고 처리방법이 명쾌하기 때문에 경험을 공유하는 것만으로도 충분한 가치가 있기 때문이다. 그리고 자동화된 테스트 수행방법을 최대한 마련해 놓는 것이 좋다. 코드리뷰는 솔루션이나 서비스 등을 고려하고 있는 기업에게 더욱 적합하다고 할 수 있다. 특정 제품이나 서비스의 발전을 지향하는 경우라면 코드리뷰의 선택은 필수다. 그러나 어떤 제품이나 서비스는 굳이 발전을 지향할 필요가 없는 경우도 있다. 그러한 경우에는 선택적으로 코드리뷰를 지향하면 된다. 또 비용문제 때문에 억지로 코드리뷰를 진행할 필요는 없다. 대부분의 소프트웨어 개발은 테스트 케이스를 잘 만들어 해당 테스트를 통과하는 것만으로도 충분하다. 특히 시장이 고착 상태이거나 특별한 변화가 없는 경우라면 코드리뷰가 필요 없다. 다만 글로벌 서비스나 웹 서비스 등 지속적인 확장이 필효안 경우라면 코드리뷰가 필수다. 코드리뷰가 필요 없는 것은 어떤 경우인지 알아보자.
-. 특정 도메인만 다루는 개발팀 -. 지난 2 ~ 3년간 큰 변화가 없으며, 향후에도 투자가 없을 거으로 예상되는 솔루션 -. 현재의 개발자들이 5년 이상 해당 솔루션을 개발하고 있는 경우 -. 기능 위주의 SI 업무를 주로 처리하며, 복잡한 알고리즘이 존재하지 않는 기업 -. 비용과 일정상의 문제로 개발팀에게 리소스를 투자할 수 없는 기업
|
이중 1개 이상 해당된다면 코드리뷰가 필요치 않은 경우다. 이 경우라면 코드리뷰를 단념하고 TDD나 테스트 케이슬르 가능한한 많이 축적해 소프트웨어의 품질을 올리길 권장한다. 그렇다면 코드리뷰가 필요한 경우는 어떤 경우일까?
-. 다국어를 지원해야 하고 시장의 변화가 잦은 환경에서 소프트웨어가 구동돼야 한다. -. 코드가 복잡하고 단순히 기능을 나열하는 수준의 요구사항이 아니며, 소프트웨어 아키텍처가 별도로 구성되기 시작한 프로젝트 -. 사용자의 경험을 높이기 위한 다양한 시도(변화)가 예측된다. -. 현재 개발 중이며 서비스의 중단 없이 지속적으로 발전해야 하는 서비스 -. 요구 사항이 계속 변하며, 프레임워크를 지향해 소프트웨어의 품질에 대한 요구사항이 매우 중요하다. |
이 가운데 하나라도 해당된다면 코드리뷸르 추천한다. 의미 있는 결과물을 얻기 위한 최선의 방법이 될 것이다. 다음은 코드리뷰의 정도와 질에 대한 검토 리스트다.
-. 실험적인 코드인가? -. 1 ~ 2명 이상이 공동으로 작업하는 코드인가? -. 향후 버려질 가능성이 높은 코드인가? |
코드리뷰를 하지 않는 경우에는 해당 코드의 리포지터리(repository)나 디레터리를 완전히 분리함으로써 리뷰가 안 된 코드를 명확히 구분해야 한다. 그리고 그 정보는 팀 전체에 공유돼야 한다.
코딩 규칙의 준수 여부
개발자들이 협업으로 개발할 때 가장 중요한 것은 스타일가이드이다. 하지만 스타일가이드는 정말 준수하기가 어렵다. 그럴지라도 스타일가이드는 가능한 준수해야 한다. 물론 100% 준수하는 것은 비효율을 불러일으킬 수 있다. 최소한 리뷰어가 제시하는 기준이나 변경방향에 대해서는 따르는 것이 현명하며, 팀 내에 가장 경험이 풍부한 사람이 이를 리드하는 것이 좋다.
소프트웨어 개발에서는 경험이 풍부한 아키텍트와 선임 개발자의 역할이 매우 중요하다. 이런 경험이 풍부한 선임 개발자가 있다면 돈이 얼마가 들더라도 스카우트한다는 이야기가 SNS에서 종종 오가기도 한다. 이는 오직 '엔지니어링'과 '경험'에 의존 할 수 밖에 없는 부분이 소프트웨어 개발에 존재하기 때문이다.
주석의 경우 '가독성'이 충분한 코드에는 서술할 필요가 없다. 이 부분에 대해서는 팀원들이 코딩에 대해 충분히 커뮤니케이션 하면서 주석의 범위를 공론화하는 것이 좋다. 소프트웨어 개발의 대부분은 '커뮤니케이션'이라는 말이 있듯이 소프트웨어 개발에서 가장 중요한 것이 바로 '팀워크'다.
변수의 명칭에 대해서도 명확한 수준에서 합의해야 한다. 테스가 어려운 구조의 코드는 분명 다른 문제를 이야기한다. JUnit과 같은 단위테스트 도구로 손쉽게 정의할 수 있는 구조가 아니라면 변경하는 것이 맞다.
코드리뷰 후에 분명하고 합당한 지적에도 고집을 세우는 개발자가 있다면 포기하고 해당 코드를 격리해 관리하는 것이 현명하다. 팀원들 간에 감정이 상하는 것이 더 위험하기 때문이다.
UI가 중요한 코드는 해당 코드들이 급변할 가능성이 농후하다. 처음부터 공들여 추상화하지 않으면 해당 코드 때문에 프로젝트가 꼬일 수 있다. 사용자에게 더 좋으 경험을 전달하려고 하면 UI에 관한 코드는 계속 변화를 수반한다.
코드리뷰 체크 리스트
코드리뷰는 대부분 '직관'에 의존한다. 그렇기 때문에 경험이 풍부한 개발자가 필요하며 많은 개발자들이 어렵게 느끼는 것이다. 사전에 체크리스트를 만들면 코드리뷰에 도움이 된다. 최소한 다음의 두 가지는 반드시 지키는 것이 좋다.
-. 코드리뷰는 1시간 이내에 끝낼 수 있는 분량을 선정할 것 -. 코드는 200개 이상의 라인을 한번에 검토하지 말 것 |
이 기준을 어기면 리뷰어는 제대로 된 리뷰를 진행하기 어렵다. 다음은 기능 부분에 대한 체크리스트다. 리뷰를 진행하다 보면 대부분 이렇게 나열될 것이다.
-. 시스템의 요구사항이 제대로 반영됐는가? -. 시스템의 설계 규격대로 구현됐는가? -. 과도한 코딩을 하고 있지 않는가? -. 같은 기능 구현을 더 단순한게 할 수는 없는가? -. 함수의 입출력 값은 명확한가? -. 빌딩블록들(알고리즘, 자료구조, 데이터타입, 템플릿, 라이브러리, API)등이 적절할게 사용됏는가? -. 좋은 패턴과 추상화(상태도, 모듈화) 등을 사용해서 구현하고 있는가? -. 의존도가 높은 함수나 라이브러리 등의 의존관계에 대해 별도로 기술하고 있는가? -. 함수의 반환(exit)은 한 곳에서 이뤄지고 있는가? -. 모든 변수는 사용 전에 초기화하고 있는가? -. 사용하지 않는 변수가 있는가? -. 하나의 함수가 하나의 기능만을 수행하고 있는가? |
개발자의 코딩 스타일을 규격화할 가이드에 대햏서도 검토애햐 한다. 다음은 이와 관련도니 체크리스트다.
-. 코딩 스타일가이드를 준수하고 있는가? -. 각 파일의 헤더정보가 존재하는가? -. 각 함수의 정보는 코드를 설명하기에 충분한가? -. 주석은 적절하게 기술돼 있는가? -. 코드는 잘 구조화돼 있는가?(가독성, 기능적 측면) -. 헤더, 함수 정보를 도구로 추출해서 자동으로 문서화할 수 있는 구조인가? -. 변수와 함수의 이름이 일관되게 기술돼 있는가? -. 프로젝트의 가이드를 통한 네이밍 규칙을 준수하고 있는가? -. 숫자의 경우 단위에 대해서 기술하고 있는가? -. 숫자를 직접 서술하지 않고 기술하고 있는가? -. 어셈블리 코드를 사용했다면 이를 대체할 방법은 없는가? -. 수행되지 않는 코드는 없는가? -. 주석 처리된 코드는 삭제됐는가?(버전체크가 됐는가?) -. 간결하긴 하지만 지나치게 독특한 코드가 존재하지 않는가? -. 설명을 보거나 작성자에게 물어봐야만 이해할 수 있는 코드는 없나? -. 구현 예정인 기능이 ToDo 주석으로 표시돼 있는가? |
가장 중요한 아키텍처에 대한 검토도 잊어선 안된다. 다음은 아키텍처에 대한 체크리스트다.
-. 함수의 길이는 적당한가?(화면을 넘기면 안됨) -. 코드의 재사용이 가능한가? -. 전역변수를 최소화했는가? -. 변수의 범위는 적절하게 선언됐는가? -. 클래스와 함수가 관련된 기능끼리 그룹으로 묶여 있는가?(응집도는 어떤가?) -. 관련된 함수들이 흩어져 있지 않는가? -. 중복된 함수나 클래스가 있지 않는가? -. 이식성을 고려해 코드가 작성됐는가?(프로세스의 특성을 받는 변수타입이 고려됐는가?) -. 데이터에 맞게 타입이 구채적으로 선언됐는가? -. if / else 구분이 2단계 이상 중첩됐다면 이를 함수로 더 구분하라. -. switch / case 문이 중첩됐다면 이를 더 구분하라. -. 리소스에 lock이 있다면 unlock은 반드시 이루어지는가? -. 힙메모리 할당과 해제는 항상 짝을 이루는가? -. 스택변수를반호나하고 있는가? -. 외부 / 공개 라이브러리를 사용했을 경우 MIT 라이선스를 확인했는가?(GPL의 경우 관련된 영역에서만 사용해야 한다.) -. 블록킹 API 호출 시에 비동기적인 방식으로 처리하고 있지는 않는가? |
당연한 이야기지만 예외처리와 관련된 사항들도 확실히 검토해야 한다. 다음은 예외처리와 관련된 체크리스트다.
-. 입력 파라미터의 유효범위는 체크하고 있는가? -. 에러코드와 예외(exception)의 함수는 분명하게 반환되고 있는가? -. 호출함수가 에러와 예외처리 코드를 가지고 있는가? -. Null 포인트와 음수가 처리되는 구조인가? -. 에러코드에 대해 명쾌하게 선언하고 처리하는가? -. switch 문에 default가 존재하며, 예외처리하고 있는가? -. 배열을 사용할 때 index 범위를 체크하는가? -. 포인트 사용 시에 유효한 범위를 체크하는가? -. 가비지 컬렉션(garbage collection)을 제대로 수행하고 있는가? -. 수학계산 시에 오버플로우(overflow)나 언더플로우(underflow)가 발생할 가능성이 없는가? -. 에러 조건이 체크되고 에러 발생 시 로깅 정보는 남기는가? -. 에러메시지와 에러코드가 에러의 의미를 잘 전달하는가? -. try / catch 에러 핸들링 사용방법은 적절하게 구현됐는가? |
요즘은 프로그램들이 대부분 이벤트 형태로 구동되긴 하지만 시간의 흐름을 체크하면 프로그램의 뼈대를 더 단단하게 해줄 수 잇다. 때문에 이 부분에 대해서도 확실히 검토하는 것이 좋다. 다음은 이에 대한 체크리스트다.
-. 최악의 조건에 대해 고려했는가? -. 무한루프와 재귀함수는 특이사항이 아니라면 없어야 한다. -. 재귀함수 사용 시에 call stack 값이 최대값이 고정돼 있는가? -. 경쟁조건이 존재하는가? -. 스레드는 정상적으로 생성되고 동작하는 코드를 가지고 있는가? -. 불필요한 최적화를 위해 코드이 가독성을 희생하지 않았는가?(임베디드의 경우에도 최적화가 매우 중요한 사항이 아니라면 가독성을 더 중시해야 한다.) |
가장 중요한 검증과 시험에 대해서도 제대로 인지해야 한다. 그리고 테스트를 위해 자동화하는 방법을 최대한 동원하는 것이 좋다.
-. 코드는 시험하기 쉽게 작성됐는가? -. 단위테스트를 쉽게 할 수 있는가? -. 에러 핸들ㄹ이 코드도 잘 테스트됐는가? -. 컴파일, 링크 체크 시에 경고메시지도 100% 처리했는가? -. 경계값, 음수값 0 / 1 등의 가독성이 떨어지는 코드에 대해 충분히 경계하고 있는가? -. 테스트를 위한 fault 조건 재현을 쉽게 할 수 있는가? -. 모든 인터페이스와 예외 조건에 대한 테스트 코드가 있는가? -. 최악의 조건에서 리소슬르 사용할 때 문제는 없는가? -. 런타임 시의 오류와 로그에 대비한 시스템이 있는가? -. 테스틀 위한 주석 코드가 존재하는가? |
간혹 등장하는 하드웨어에 대한 테스트도 중요하긴 마찬가지다. 다음과 같은 기준들을 통해 검토해야 한다.
-. I/O 오퍼레이션 코드에 대한 테스트로 하드웨어의 정상적인 동작을 보장하는가? -. 최소 / 최대 타이밍 요구사항에 대해 하드웨어 인터페이스가 충족하는가? -. 멀티바이트 하드웨어 레지스터가 read / write 오퍼레이션 중에도 값이 바뀌지 않음을 보장하는가? -. 시스템이 잘 정의된 하드웨어 상태로 리셋하는 것을 소프트웨어가 보장하는가? -. 하드웨어 전압이 떨어지거 전원 차단된느 경우 이를 잘 처리하는가? -. 대기모드 진입과 퇴장 시 시스템이 옳게 동작하는가? -. 사용하지 않는 인터럽트 벡터가 에러 핸들러에 연결돼 잇는가? -. EEPRO 손상(데이터 깨짐)을 막기 위한 메커니즘이 있는가?(쓰기 동작 중 power loss 등) |
다양한 코드 리뷰 기법
이미 알려진 코드리뷰를 위한 몇 가지 방법들이 있다. 그 중 코드 인스펙션(inspection)은 가장 정형화된 기법으로, 전문화된 코드리뷰 팀을 통해 구분하는 방법이다. 이 방법은 리소스가 풍부하고 일정에 여유가 있는 경우에만 사용이 가능하다. 대부분 대기업이나 대형포털에서 구현 가능한 방법이라고 할 수 있다. 만약 비용과 일정 등의 문제가 없다면 이 방법이 가장 현명하다. 코드리뷰의 품질에 대해 정량적인 보고와 구성을 만들어 낼 수 잇다는 것은 코드 인스펙션의 갖아 큰 장점이다. 코드 인스펙션을 하기 위한 롤을 구분하면 <표 1>과 같이 네가지로 구분된다.
구분 |
역할 |
Moderator |
실질적인 매니저로 팀 간의 인터페이스와 리소스, 인프라를 확보하고 프로세스에 대한 정의와 산출물의 정리를 담당한다. |
Reader |
각 산출물을 읽고 리뷰하며 방향성을 젯한다. 보통 지식이 많은 사람이 담당한다. |
| Designer / Coder |
Reader의 지시에 따라 코드를 검증하고 잠재적인 문제에 대해 수정 방안을 만든다. |
| Tester |
진행 중인 코드와 수정 코드에 대해 검증한다. |
<표 1> 코드 인스펙션의 역할 구분
코드 인스펙션은 다음과 같이 6단계로 진행된다.
① Planning : 계획 수립 ② Overview : 교육과 역할 정의 ③ Preparation : 인터뷰와 필요한 문서 습득, 툴 환경 구축 ④ Meeting(Inspection) : 각자의 역할대로 임무 수행 ⑤ Rework : 보고된 Defect 수정 ⑥ Follow-up : 보고된 Defect가 수정됏는지 확인 |
이러한 절차를 통해 코드 인스펙션이 수행되면 꽤 명쾌한 리뷰가 진행될 것이다. 하지만 일정과 비용 문제 때문에 스타트업이 이 방법을 선택하기는 매우 어렵다. 그래서 사용하는 방법 중의 하나가 '팀리뷰'다.
팀리뷰는 일정한 계획과 프로세스를 따른느 방법으로, 코드 인스펙션보다 좀 덜 정형화된 방법으로 진행도니다. 보통은 일주일에 한 번 정도 팀리뷰를 수행하거나, 특정 모듈이나 기능이 완료되는 시점을 기준으로 테스트 결과를 가지고 리뷰를 진행한다. 또한 위험하거나 의견이 필요한 경우에도 팀리뷰는 매우 유용하다. 팀리뷰는 이처럼 일반적인 팀에서 사용하는 방법이다. 하지만 이 역시 리뷰에 대한 제대로 된 인식이 없다면 적용하기 어렵다.
과거 국내 SI업체들이 주로 사용하던 방법 중 하나로 '워크스루(Walkthrough)'라는 방법이 있다. 워크스루는 단체로 진행하는 코드리뷰 기법 중 비정형적인 방법으로, 발표자가 리뷰의 주제나 시간을 정해서 발표하고 동료들로부터 의견이나 아이더를 듣는 시간을 갖는 것이다. 주로 사례에 대한 정보 공유나 아이디어 수빚을 위해 사용되는 방법이다.
이 방법을 특정 도메인에 종속된코드를 만들거나, 비슷한 SI형태의 업무를 수행하는 경웨 적합하다. 국내의 SI업체에서 이 방법이 적극적으로 사용되면 좋으련만 이마저도 일정하게 진행되지 않는 경우가 많고, 갑을병정의 관계에 매여 있는 SI 업계에서 정보공유나 아이디어 수집을 위한 커뮤니케이션이 자유롭게 일어나는 것은 사실매우 어려운 일이다.
이 워크스루는 동일한 조직 내에서 동일한 목적의식을 가진 팀에서나 활용할 수 있는 방법이다. SI에서 이를 시도했다가 실패한 경우라면 대부분 팀의 목적의식이 달라 불분명한 결론이 도출됐기 때문일 것이다.
국내 스타트업이다 IT 전문기업들의 경우 상급관리자들이 리뷰에 대해 허락해주지 않는 경우가 대부분이다. 때문에 팀 내에서 어떻게든 자체적으로 코드리뷰를 진행하려고 노력하는 경우가 많다. 팀장의 권한 선에서 적절하게 리뷰하는 방법 중 하나가 'Peer revier or over the shoulder review'이다 이 방법은 보통 2 ~ 3명이 진행한느 코드리뷰로, 코드의 작성자가 모니터를 보면서 코드를 설명하고 다른 한 사람이 설명을 들으면서 아이디어를 제안하거나 Defect를 발견하는 방법이다. 이 방법은 신입사원이나 인턴사원의 경우 업무 이해도를 높이는 측면에서 매우 유용하다. 만약 신입사원이나 인턴사원이 이 과정을 통해 해당 코들르 사용할 수 있는 수준으로 성장한다면 상당히 의미있는 결과라고 할 수 있겠다.
문제는 이 방법에 개발자의 인력투입이 거의 2배 이상 증가하는 것이다. 고품질을 요하는 영역을 개발하거나 빠른 시간내에 신입 개발자의 업무이해도를 높여야 하는 경우가 아니라면 이 방법은 시행하지 않는 편이 났다.
앞서 설명한 방법으로 리뷰가 진행되지 않는다면 'Pass around'라는 돌려보기 방법이 있다. 사실 이 방법은 상세한 리뷰 방법은 아니다. 온라인이나 실시간성이 아닌 리파지토리나 이메일 등을 사용해 천천히 리뷰하는 방식이다. 이 방법은 속도는 느리지만 중요한 코드나 제품의 기능 개선이 필요한 경우에는 상당히 의미 있는 방법이 될 수 있다. 보통은 제품의 기능 개선을 위해 사용하는 방법이다.
코드리뷰와 아키텍트의 역할
이처럼 코드리뷰 방법은 여러가지가 있다. 결론적으로 개발조직이 커뮤니케이션을 통해 목적의식을 통일하고 코드리뷰 시간을 적절히 분배해 리뷰할 수 있는 일정한 시간을 만드는 것이리뷰의 핵심이라고 할 수 있다. 코드리뷰는 소프트웨어의 품질 개선, 소통을 통한 조직의 방향성 확립, 새로운 기능 개선작업 등을 위해 다양하게 활용된다. 어떤 관점으로 코드리뷰를 진행할 것인지, 코드리뷰라는 프로세스를 어떻게 개발 과정에 끼워 넣을 것인지를 진지하게 고민하는 것, 그것이 아키텍트의 첫 번째 역할이 아닌가 싶다.