학습 피라미드와 코드 리뷰 피라미드 비교해보기
금요안영회 - 7호
이번 글은 다소 맹목적인 느낌의 글인데, 매력적으로 보이는 두 개의 피라미드를 비교해보는 일이다. 최근 SNS를 통해 발견해 두 개의 작품을 비교하며 (뭘 얻을 수 있을지 모르지만) 그냥 써본다.
비교의 축은 학습 피라미드
학습 피라미드라는 이름은 내가 임의로 붙인 것이고 그림을 보면 학습의 적극성을 피라미드 구조로 구분하여 설명한 내용이다. 두 개의 피라미드 중에 이걸 기준으로 삼은 이유는 왼쪽에 백분율이 축을 만들어주기 때문이다.
두 번째 피라미드는 코드 리뷰 피라미드
두 번째는 코드 리뷰 피라미드인데, 아쉽게도 층 구분이 5개로 서로 맞지 않는다. (덕질스러운 결정을 해야 하는구만.)
출처: Gunnar Morling의 코드 리뷰 피라미드(https://www.morling.dev/blog/the-code-review-pyramid/)우리가 말하고 행동하는 것의 90%
학습 피라미드에서 우리가 말하고 행동하는 것의 90%를 세 가지 항목으로 설명한다. 무언가 구체적인 일을 하거나 경험을 쌓거나 상상으로 시뮬레이션 하는 일이다. 이걸 코드 리뷰 피라미드에 빗대어 보면 API Semantics 대응시켜볼 수 있다. 의미가 그런 것은 아니고 위상이 비슷하다고 해야 하나?
아래가 말하는 의미는 나중에 수정하기 어렵다(Larger effort for changes later on)는 의미에서 일종의 인프라 성격이 있다는 판단이다. API 라는 코드 유형 자체가 프로그램 사이의 통신을 위한 것이고, 의존성을 확대하는 통로란 점을 떠올리면 자연스럽다. 극단적으로 말하면 시간이 없을 때는 API Semantics만 코드 리뷰하라고 피라미드가 주는 교훈을 읽을 수도 있다.
우리가 말하는 것의 70%
설명하고(explaining) 토론(discussing)하기. 말하기의 절대다수를 차지하는 일이 설명과 토론이구나. 이번에도 코드 리뷰 피라미드 대응이 쉬워 보인다. Implementation Sematics와 1:1 대응이 자연스러워 보인다. 코드 리뷰 피라미드 저자는 8개의 친절한 질문도 올려두었다. 구현 전반에 대해 프로그램이 적절한지 다루는 일이다.
우리가 듣고 말하는 것의 50%
항목이 많긴 하지만 피라미드에서 50%로 학습 묶인 영역이 있다. 흔히 말하는 발표행위다. 코드 리뷰 피라미드에서 위상을 따지면 문서화(Documentation)인데, 둘이 묘하게 의미상으로 닮은 듯하다. 우연의 일치일텐데 매우 신기한 일이다.
30% 이하의 사람들이 읽는 것
자, 이제 피라미드의 나머지 상위 부분 대응시키는 일은 조금 어려워보인다. 학습 피라미드 셋, 코드 리뷰 피라미드 둘인 탓이다. 코드 리뷰 피라미드가 빠져나갈 구멍(?)을 주는 듯하다. 자동화 할 수 있는 부분과 없는 부분의 경계가 있어 이를 또 임의의 기준으로 쓴다.
위 그림에서 보라색 점선 아래는 코드 리뷰 피라미드 입장에서는 자동화 할 수 없는 즉, 사람의 판단이 필요한 테스트 관련 코드 리뷰다. 그 정도 위상에 해당하는 학습 피라미드의 활동은 슬라이드(tranparencies) 읽기다. 20%에 해당하는 학습은 강의 듣기, 10%만 책을 읽는다. 코드 리뷰 피라미드로 대응시켜 보면 최상위는 코드 스타일 리뷰이고, 이건 자동화를 권장할 수 있는 부분이다. 영향도는 낮고 주관성은 강해서 옳고 그름보다는 일관성이 필요한 영역이다. 코드 리뷰 피라미드에서 차상위는 테스트 중에서도 자동화가 가능한 부분이다.
지난 금요안영회 연재
1. 계획은 개나 주자
