[WHY 시리즈 1] E.007 — Pull Request를 통해 잡은 오류들
‘코드와 서비스 만들기를 좋아하는 소프트웨어 엔지니어’로 일하고 있다. 엔지니어는 문제를 해결하는 사람이다. 문제를 해결하는 과정에는 여러 가지 선택이 존재할 수 있다. 가능한 최선의 결과를 위해, 항상 내 선택의 Why에 답할 수 있는 사람이 되고자 한다. 매주, 한 주 동안 내가 결정한 선택의 Why에 대해 정리하고자 한다.
프로덕트의 첫 오픈을 위한 QA 전, 마지막 Phase가 종료됐다. 그만큼 정신없고 바쁜 일상을 보내고 있지만 빨리 우리 서비스가 출시되는 날을 기대하는 마음이 더 크다. (밑밥이었고) 사실 이번 주에 어떤 키워드로 글을 작성할지 매일 정리하지 못했다. 그래서 주말이 시작되는 토요일 아침, ‘아! Pull Request로 배포 전 미리 발견한 오류에 대해 이야기를 해볼까?’ 라는 생각이 들었고 이 글을 쓰게 되었다. 왜 Pull Request를 해야 하는 지에 대한 글이 될 수 있기 때문에 WHY 시리즈에 포함하는 것으로 결정. 토요일, 그리고 이 글을 쓰는 일요일 모두 틈틈이 일을 하면서 Pull Request를 통해 잡은 오류들에 대한 이야기를 적어본다.
What?
1. 거리 계산
두 지점 사이의 거리를 기반으로 배달비를 계산하는 로직이 포함된 Pull Request를 리뷰했다. 거릿값을 소수점 둘째 자리까지 처리하고, 계산된 배달비를 백의 자리까지 처리하는 코드였다. 코드를 리뷰하다가 문득 예전에 내가 작성한 두 지점 사이의 거리와 관련된 코드가 생각났다. 해당 부분에서도 동일한 로직으로 거릿값을 처리해야 할 것 같다고 피드백을 남겼다. 동일한 개념의 값을 다른 형식의 값으로 반환할 수 있었던 오류 상황을 예방할 수 있었다.
Pull Request의 author가 예측하지 못했던 부분을 reviewer가 (직접 작성했던 코드이기 때문에)발견한 좋은 사례라고 생각한다.
2. 시각 포맷
서비스 자체의 open 및 close 시간에 따라 서비스 이용 가능 여부를 확인하는 로직이 포함된 Pull Request를 생성했다. configuration에 open 및 close 시간 정보를 설정해 두었고, 내가 시각 포맷 자체를 다르게 생각하고 있었다는 사실을 동료의 피드백을 통해 알게 되었다. 물론 다른 포맷을 사용해도 서비스 이용 가능 여부를 정상적으로 반환할 수는 있겠지만, 당연히 우리 서버에서 사용하는 시각 포맷은 통일시키는 것이 좋다고 생각했다.
Pull Request의 author가 잘못 이해하고 있는 부분을 reviewer를 통해 발견한 좋은 사례라고 생각한다. (util 함수 작업도 얻고..)
3. 데이터 검증
외부 서비스로부터 webhook을 받아서 처리하는 로직이 포함된 Pull Request를 생성했다. 나는 해당 webhook에서 전달되는 데이터 구조와 동일한 인터페이스를 생성하여 서버 로직을 생성했다. 인터페이스를 통해 webhook에서 전달된 데이터를 검증하겠다는 의도도 포함되어 있었다. 동료는 webhook에서 전달되는 데이터가 약속된 포맷이 아니라면, 애초에 우리 서버 로직을 태우지 않고 거부하는게 옳은 방향 같다는 피드백을 주었고 동의했다. 내부 인터페이스로 관리하던 데이터를 request validation으로 처리하도록 수정했다.
사전에 설계 방향에 대해 피드백을 요청했으면 좋았겠지만, Pull Request의 reviewer를 통해 더 나은 설계 방향에 대한 피드백을 받을 수 있었던 좋은 사례라고 생각한다.
4. 응답 필드 오류
주문과 관련된 로직을 전반적으로 개선한 Pull Request를 리뷰했다. 주문 프로세스가 가장 핵심이며, 많은 기능을 필요로하기 때문에 볼륨이 더 커지기 전 프로세스를 다듬고 리팩토링하는 것이 필요하다고 판단하여 이루어진 작업이었다. 해당 Pull Request는 다양한 end point에 영향을 주기 때문에 reviewer인 나도 평소보다 많은 시간을 할애해서 꼼꼼하게 리뷰했다. 그러던 중, coupon 관련 end point에서 필요로 하는 필드가 포함되지 않는 오류를 발견했다. 평소 coupon 관련 로직은 내가 많은 부분 관여하고 구현했기 때문에 발견할 수 있었다.
2시간이 넘게 해당 Pull Request만 열심히 리뷰했던 기억이 있다. 누군가 놓칠 수 있는 부분을 서로의 리뷰를 통해 발견할 수 있는 경험은 언제나 옳고 좋다.
마지막으로 또 다른 재미를 주는 Pull Request 갈무리를 공개하고, 다음 주에도 여전히 행복한 Pull Request를 기대한다.