[TickerBell] 백엔드 협업 구조

TickerBell 프로젝트를 진행하며 처음 백엔드 개발자와 협업을 진행했다. 프로젝트를 진행하다 보니 몇 가지 오류가 지속적으로 발생했고 원활하게 진행하기 위해 백엔드 개발 규칙이 필요했다.

 

가장 처음 정한건 깃 협업 규칙이었다. 한명의 개인 리포지토리를 포크해서 PR하는 방법도 있었지만 우린 Github의 organization을 이용해 협업을 했다. organization에 공용 프로젝트를 만든 뒤 서로 포크하여 작업을 한 뒤 PR을 진행하는 방식이었다.

 

그 다음 어떻게 해야 PR 또는 merge 시 코드간의 충돌을 방지할 수 있을지였다. 구글에 Git 브랜치 전략 등으로 검색하면 다양한 협업 방식이 나온다. 하지만 검색을 통해 살펴보면 master, feature, develop, release, hotfix 등등.. 많은 브랜치를 이용해 개발을 진행한다.

 

이 프로젝트는 백엔드 개발자가 나 포함 2명이었고 이렇게 많은 브랜치를 활용할 필요는 없다고 생각했다. 우린 master 브랜치 하나와 develop 브랜치를 만들어 개발을 진행하고 release 브랜치를 이용해 배포했다. 개발은 develop 브랜치를 이용해 각자 개발을 진행하고 개발이 완료되면 master 브랜치로 이동해 sync fork 와 git pull 을 이용해 develop 브랜치를 merge 하기 전 상대방의 변경사항을 main 브랜치에 가져온다 이 후 main 브랜치와 develop 브랜치를 merge하여 만약 충돌 사항이 있다면 나의 local pc 에서 해결하고 merge한 내용을 push하고 PR한다. 개발이 완료되면 상대방이 변경한 내용을 가져와 merge 해야 한다는 번거로움이 있지만 local pc 에서 충돌을 모두 해결할 수 있으므로 상대방에게 최대한 피해를 안끼칠 수 있었다. 마지막으로 merge 한 코드를 release 브랜치에도 merge 해준 뒤 CI / CD 트리거가 동작할 수 있도록 release 브랜치에 push 해준다. 앞서 언급한 협업 방식을 단순히 그림으로 나타내면 다음과 같다

세 번째로 협업 규칙을 정한건 DTO의 변수명을 일치화 시키는 것이다. 서로 다른 개발자가 API를 개발하니 같은 데이터의 변수명도 다르게 설정할 때가 많았다. 백엔드 개발자끼리는 서로 코드를 까보며 대략적인 흐름을 알기 때문에 해당 변수가 어떤 데이터를 뜻하는지 쉽게 파악할 수 있었지만 프론트엔드 개발자분들은 그럴 수 없었다. 프론트엔드 개발자분들은 스웨거와 같은 API 명세서만을 이용해 해당 DTO의 변수가 어떠한 흐름에 사용되는지 파악해야 하는데 두 서버개발자가 하나의 데이터로 다른 이름을 사용하면 프론트엔드 개발자는 헷갈릴 수 밖에 없었다.  해당 문제를 식별한 후 곧바로 DTO 변수명을 리팩토링 했고 이후 개발 시 서로의 DTO 변수명을 확인하며 개발하고 더 나은 변수명이 있는지 고민하게 되었다. (내가 생각한 흐름 위에서 작성한 코드를 다른사람도 똑같이 이해할 수 있을 것이라 생각한건 큰 착각이었다.)

 

DTO의 변수명은 DB의 데이터를 사용한다면 DB의 컬럼명과 일치시켰으며, Boolean 값으로 데이터가 송수신될 땐 변수명 앞에 is를 붙여 Boolean임을 쉽게 알 수 있도록 하였다. 또한, 개수를 나타내면 변수명 뒤에 Count를 붙여주었다.

 

네 번째로 해당 프로젝트는 테스트 코드를 꼼꼼히 짜는데 신경을 많이 썻다. 하지만 코드에 변경사항이 있을 경우 내가 작성한 테스트 코드는 오류가 발생하지 않게 잘 변경해놓지만 상대방의 코드에 영향을 끼쳤다고 생각하지 못 해 상대방의 테스트 코드가 깨진채로 Organization 에 올라온 경우가 많았다. 이 방식은 매우 잘못됐다는걸 깨닫고 백엔드 개발자분과 대화를 하여 Organization에 반영하기 전 꼭 모든 테스트를 수행해본 뒤 실패하는 테스트가 없도록 수정하자는 규칙을 만들었다. 이 규칙을 만드니 내가 코드를 수정했을 때 내가 생각하지 못 한 사이드 이펙트를 식별할 수 있었고 향후 개발 시 변경사항이 최소화되도록 고민하게 되었다. 

예를들어, 처음엔 클래스의 모든 변수를 사용하는 생성자를 이용해 객체를 생성했는데 클래스에 필드 하나를 추가하거나 삭제하면 해당 클래스를 생성한 모든 코드에 생성자를 변경해야했다. 이런 사이드 이펙트를 줄이고자 Builder 패턴을 이용해 객체를 생성했고 개발 중 클래스에 필드가 추가되어도 해당 객체를 생성한 모든 코드를 수정할 필요는 없어졌다.

 

개발을 진행함에 있어 적당한 제약들은 개발의 생산성과 효율을 많이 높일 수 있는 것 같다. 하지만 내 코드를 남도 보기 쉽게 하는건 여전히 어렵다..