[WHY 시리즈 1] E.006 — 커밋 그래프, mongoose virtual, Pull Request
‘코드와 서비스 만들기를 좋아하는 소프트웨어 엔지니어’로 일하고 있다. 엔지니어는 문제를 해결하는 사람이다. 문제를 해결하는 과정에는 여러 가지 선택이 존재할 수 있다. 가능한 최선의 결과를 위해, 항상 내 선택의 Why에 답할 수 있는 사람이 되고자 한다. 매주, 한 주 동안 내가 결정한 선택의 Why에 대해 정리하고자 한다.
어느덧, 팀 내부 QA가 2주 앞으로 다가왔다. 프로덕트 팀의 PM, 개발자, 디자이너 모두 바쁘지만 즐겁게(?) 하루하루를 보내고 있다. 개발 프로젝트에도 많은 기능이 코드로 담기면서 소스 코드 관리를 더욱 신경 쓰게 되고, 자칫 복잡도가 높아질 수 있는 상황을 경계하며, 바쁜 와중에도 서로의 코드를 정성껏 리뷰하는 시간을 보냈다. 정신없이 지나간 이번 주에도 Why를 던져본다.
Why?
1. git 커밋 그래프
프로덕트의 Phase 3 종료가 다가오면서 하루에 Pull Request 올라오는 양이 점점 많아지고 있다. 서버를 함께 개발하는 동료와 나는 매일 잊지 않고 서로의 코드를 리뷰하고, merge 시키는 작업을 하고 있다. 서버 프로젝트는 기본적으로 커밋 내역을 squash 하지 않고 merge 커밋을 생성하고 있다. (클라이언트 프로젝트는 커밋 내역을 하나의 커밋으로 묶는 squash 전략을 채택하고 있다.) 그러다 몇 번, 예쁘게 그려나가고 있었던 서버 프로젝트의 커밋 그래프가 못생겨지는 경험을 했다. 예측되겠지만, rebase and merge를 수행하지 않았기 때문이었다. 동료와 나는 항상 rebase and merge를 수행하면서 커밋 그래프를 예쁘게 유지하기로 다짐했다.
- Why? 작업 내용과 흐름을 파악하기에 좋다. ‘커밋 그래프가 못생겨지면 어때, 코드가 잘 merge 돼서 동작하기만 하면 되지’ 라고 생각할 수도 있다. 하지만 예쁜 커밋 그래프는 하나의 프로젝트에서 여러 명의 개발자가 진행하는 작업의 내용과 흐름을 파악하기에 좋다.
- Why? 이슈 발생 시, 기능을 rollback 하기에 좋다. 어떠한 이유로 기능을 rollback 하고자 했을 때, (Pull Request의 단위가 적절한 범위의 기능이라는 전제하에)다른 기능에 영향을 주지 않으면서 특정 commit 시점으로 깔끔하게 reset 할 수 있다.
- Why? 심리적 안정감을 준다. 예쁜 커밋 그래프가 개발자에게 주는 심리적 안정감은 무시할 수 없다.
아직은 명확하게 우리만의 전략이 수립되지는 않았지만, 각 프로젝트별로 하나의 공감대를 형성하고 조금씩 완성해나가고 있다. 우리의 프로젝트 성격과 상황에 맞는 전략이 계속해서 자리 잡기를 기대한다.
Note: Visual Studio Code를 사용해 Git 커밋 메시지 작성하기 확인 (commit 메시지에 대한 이야기지만, 역시 소스 코드 관리를 위해 읽어보면 좋을 글이다.)
Note: 우린 Git-flow를 사용하고 있어요 확인
2. mongoose virtual
현재 서버는 도메인의 분리가 명확히 되지 않고, 하나의 Monolithic 시스템으로 동작하고 있다. 이후에 실행하게 될 도메인 분리를 위해, 데이터 컬렉션은 가능한 단순하게 그리고 복잡도가 낮은 구조로 가져가자는 철학으로 개발을 진행하고 있다. 그러던 중, 현재 데이터 모델에는 존재하지 않지만 추가적으로 필요한 필드가 생겼고, 처리 방법에 대해 고민했다. 결론은, 컬렉션에 새로운 컬럼을 추가하는 대신 mongoose에서 제공하는 virtual 키워드로 모델 계층에서 처리하는 것으로 결정했다.
- Why? 해당 필드는 조회 요청 시 마다 동적으로 변경되는 값이며, 데이터 베이스에 지속할 필요가 없다. 이 필드는 요청 조건에 따라 동적으로 계산되어 응답으로 반환되어야 한다. 또한, 논리적으로 특정 데이터 컬렉션에 포함되는 것이 명확하기 때문에 virtual 키워드를 이용하여 데이터베이스에 지속하지는 않으면서, 데이터 모델 계층에서 처리가 가능하다.
하지만, 무분별하게 virtual 키워드를 사용하다 보면 데이터 컬렉션은 가능한 단순하게 복잡도 낮은 구조로 가져가겠다는 철학에 위배될 수 있겠다는 생각이 들었다. 만능은 없다.
Note: Mongoose — Virtuals
3. 이번 주의 Pull Request
흥미로웠던 Pull Request가 있었다. 두 지점 사이의 거리를 계산하는 로직 개선에 대한 Pull Request 였고, 나의 Pull Request를 리뷰해 준 동료와 많은 댓글 쓰레드를 통해 피드백을 주고받았다. 좌표가 매개변수로 넘어올 때와 넘어오지 않을 때 분기하는 코드에서 논의가 시작됐다.
- Why? 동료: 좌표가 넘어오는 경우 불필요하게 쿼리가 2번 실행된다.
- Why? 나: side effect의 원인이 될 수 있는 let 변수를 사용하고 싶지 않다. 쿼리가 1번 혹은 2번 실행될 수 있는 현재 상황이 성능에 큰 영향을 준다고 생각하지 않으며 오히려 let 변수를 제거하는 방향이 맞다고 생각한다.
- Why? 동료: 쿼리가 1번 실행되면서 let 변수를 제거한 코드로 만들어 보았다. (미정 개이득)
- Why? 나: 가독성이 조금 떨어지는 것 같은데, 작성해주신 코드에서 쿼리하는 부분을 별도의 모듈로 분리하고 개선해 보았다.
결국 우리는 성능, side effect, 가독성 관점에서 서로 피드백을 주고받다가 함께 만족할 수 있는 코드로 개선했다. 이건, 동료와 나의 Pull Request 리뷰에 대한 자랑이 맞다.
