2024 10월 3째 주 (촉박한 프로젝트 일정속에서)

일정이 너무 촉박해 놓치는 것들 

최근에 일정이 빠듯한 프로젝트에 중간에 투입되어 바쁘게 개발 중에 있다. (이번주엔 야근을 3번 정도 했다..)

바쁘게 개발하다보니 지켜왔던 것들을 조금 놓치게 되는 것들 그리고 어떻게 개선하면 좋을지 혹은 개선했는지를 정리해 보려고 한다. 

 

1. 코드 리뷰

일정이 바쁘다 보니 각 기능들이 특정 브랜치에서 연속적으로 작업된게 아닌 부모 브랜치에서 병렬적으로 작업되었다. 
이렇게 했을 때, 보다 상위 기능에 추가 작업이 이뤄졌을 때, 직접접인 영향도가 하위 브랜치엔 없다는 장점이 있을 수 있는데, 
병렬적으로 작업되다보니 서로의 개발 내용을 몰라 중복 코드가 왕왕 생긴 점

각 PR 에서 개발된 기능들이 꽤나 의존적이었던 관계로 병합 과정 및 기능 재점검을 위한 통합 테스트가 진행되어야 했다.

PR 들을 부모 브랜치에 머지 이전에 통합 테스트 용 브랜치에 병합하여 통합 테스트를 진행하면서 기능 별 경계가 모호한 수정사항이 발생했다. 이런 경우, 시간 상 책임을 따지기 보단 우선 통합 테스트 용 브랜치에 수정 작업이 진행됐다.

이렇게 되다보니, 기능 별 PR 을 리뷰받기가 애매해졌다. 

통합 테스트 과정에서 발생한 수정사항이 책임 소재도 모호하다보니 통합 브랜치에 수정사항이 반영됐으나, 각각의 PR 에는 반영이 안됐는데, 각각을 리뷰받는게 맞는지? 

그래서 결국 각각의 PR을 합친 통합 PR을 리뷰 요청하기로 했다. 

일단은 이런 상황들을 지양하기 위해 크게 3가지가 중요한 것 같다.  

1. 개발 기능의  분리
   • 서로가 최대한 독립적으로 개발을 가져갈 수 있도록 기능을 분배 해야할 것.
2. 의존성이 강한 기능들을 개발하더라도 영향을 덜 받을 수 있는 방법에 대한 고민이 필요
   • 예를 들면, 이 기능 구현을 위해선 어떤 기능은 무조건 받겠다를 미리 정의 (외부 API 소통을 위한 인터페이스도 포함될 수 있음)
   • 이후, 앞단 개발이 완료되면, 해당 부분만 수정하는 등
3. 개발된 기능에 대한 검증 
   • 테스트 중 예외 발생 시, 책임 소재가 상대적으로 분명하기 때문에 분석 비용을 줄일 수 있을 것. 
   • 이미 검증된 부분들이 있음으로 예외 발생률도 낮출 수 있다. 
   • 또, 기능에 대한 수정사항인지 병합 과정에서 발생한 수정사항인지 구분도 쉬울 것. 

 

2. 추상화

현재, 서로 다른 팀에서 관리하는 상품들을 묶음으로 구매하는 서비스를 개발 하고 있다. 
사용자는 상품들(상품 A, 상품 B)을 묶어서 구매 요청하고, 결제 플랫폼에서는 각 재화를 제공하는 서비스에 질의를 해서 관련 정보들을 얻고, 이를 기반으로 과금 및 결제를 진행한다. 

이렇게 결제 플랫폼은 각 재화에 대한 지식은 몰라도 된다. 담당 서비스에 질의를 하면 되니깐 
하지만, 프로젝트 개발을 진행하면서 가장 큰 걸림돌이 깔끔한 추상화가 어려운 상태였다는 점이었다. 

동일한 목적을 가진 기능들(상품 정보 조회, 사용 가능 쿠폰 조회 등)이 서비스 별로 각자의 입맛에 맞게 구현되어 있었다. 
그렇다보니 다음과 같은 문제들이 있었다. 
1. 서로 다른 응답들을 내부적으로 사용하는 포맷으로 변환하는 작업들을 해줘야 했다. 코드의 복잡도를 증가시킨다.
2. 변한과정에서 서비스 관련 정책을 포함한 지식들을 알아야 한다
3. 서비스 정책이 변경되면, 플랫폼 수정이 발생한다. 

이런 문제들은 바쁜일정에 기름을 부었다.
점점 좋지 않은 구조에 마음도 불편해졌다. 

바쁘더라도 부채를 쌓아갈 수는 없다는 생각이 들어(나중에 바꾸는게 더 어렵다는 걸 안다..) 우선 핵심 기능들 먼저 인터페이스 만들어 제공하는 방향으로 변경을 요청드렸다. 
우리는 우리가 필요한 데이터만을 전달받고, 인터페이스에 맞게 데이터를 제공하는 건 서비스 몫이다. 

서비스는 정책이 변경되더라도 플랫폼 팀에 알릴 필요도 없고, 서비스만 신경쓰면 되고, 소통 비용도 준다.
플랫폼 코드도 훨씬 단순하게 개선될 수 있다. 

3. 테스트 코드

To Be Continued..