프로젝트 PR 및 코드 리뷰 시작

아무래도 내가 쓴 코드는 그냥 내가 작성한 거라서 이해가 좀 되기 마련이다. 하지만 남이 작성한 코드를 읽고 그게 무슨 역할인지 이해를 하는 것은 좀 시간이 오래 걸릴 뿐 더러 이 코드가 왜 작성이 되었까라는 의문이 남을 수 도 있다. 추가로 남이 작성한 코드와 협력을 하기 위해서는 그 코드가 사용이 되는 이유, 그 코드가 역할을 하는 기능 등을 확실하게 이해를 해야지 결합도가 어느정도 있는 작업물에 대해서 충돌을 최대한 적게 내면서 진행을 할 수 있을 것이다. 그렇게 남이 작성한 코드를 좀 코드리뷰를 연습해보자

그림 1. PR Request

일단 내가 Repository에 대한 권한을 갖고 있기도하고, PR 관련된 전권한이 있다. 지금과 보면 새로운 PR요청에 대해서는 Open 부분에 Request 가 들어오게되고, 들어온 PR의 처리 완료 부분은 Closed 부분에 저장이 되게 된다. 

그림 2. PR Closed

빨간색으로 되어있는 부분은 PR 요청을 거절한 부분이다. 원하지 않는 방향의 PR이 들어와서 거절을 했던 기억이 있다. 이렇게 거절을 하는 이유도 작성을 하고, 요청에 대안은 요청자와 코드에 대한 방향성 토론이 필요하기도 하다. 

 

그림 3. 코드 추가 요청

이건 PR 된 코드의 일부분이다. 이외에도 DAO, DTO가 있었지만 무난하게 변수 선언 및 간단한 SQL 쿼리 작성되는거여서 이해하는데에는 그다지 어렵지 않았다. 작업내용을 저장하는데 도움을 주는 Transactional Annotation을 선언을 한 뒤 작성이 되는 Service 영역이다. 회원가입에 대해서 입력값 UserDto 값을 넣어서 이메일을 통해 존재 여부를 확인하고 암호화된 패스워드로 바꾼 후 데이터를 DB에 저장을 하게 되는 코드라고 정리해서 보면 될 거 같다. 아무래도 다른 주요 기능을 만들 때 임의로 만드는 기능이라 간소하게 작성된 면이 있다. 

그림 4. 다른 팀원의 PR 요청

자 이제 진짜로 큰일이 난 부분이다. git활동을 진행을 하다보면 충분한 대화를 나누었음에도 공통적인 부분의 코드를 간혹 작성을 하는 경우가 있는데, 지금이 그런 상황이다. 작성된 A 에 대해서 다른 팀원이 그 A와 conflict되는 코드를 더 작성을 했을 때이다. 이제 이 역량에 대해서는 git 관리자인 사람이 코드를 하나씩 읽고 필요한 부분과 겹치는 부분에 대해서 분석을 하고, 뺄건 빼고 넣을건 넣어야되는 상황이 오게 된다. 벌써 머리가 아픈 느낌이다. 심지어 내가 작성한 부분과도 겹치기 때문에 조속한 조치가 필요한 시점이라고 본다. 

그림 5. 코드 일부

입력 파라미터가 UserDao에서 profile_image가 추가된 상황이라서 입력 파라미터에 대해서 하나가 더 추가되서 수정이 된 형태이다. 추가로 아이디 중복검사, 이메일 중복검사, 닉네임 중복 검사도 실시를 하여 데이터의 유니크 성을 높이는 코드라고 볼 수 있다.

그림 6. UserDao

UserDao는 아무래도 쿼리를 적용해서 DB에 적용을 하는 코드라고 보면 되겠다. 근데 내가 기억하기로는 Mapper 작성을 하는 걸로 알고 있는데, 이 부분은 긴밀한 토론이 필요해 보이는 부분이다.

 

그림 7. merge...

이 부분은 일단 팀원 A,B,C 가 있다면 A가 메인인걸 감안해서, A,B에 대한 conflict를 최대한 없애는 방향으로 진행하고, C인 코드에 merge 하여 합치는 방향으로 가는게 맞을듯 하다. 

 

앞으로의 길도 좀 험난해보인다.