23.07.30~23.08.06

업무

1. 앱 테스트 코드 작성

어찌나 기쁘던지...

지난주부터 끙끙거렸던, 컴포넌트 테스트 코드를 작성했다.

여느 문제가 그렇듯 다 해결하고 나니 별 게 없는 것처럼 느껴지지만...

어찌 됐던 현 앱 서비스 내에 테스트 코드를 작성하기 시작했다는 게 꽤나 뿌듯했던 한 주.

 

앱 내 현존하는 모든 요구사항과 기능들에 대한 테스트 코드를 한 번에 작성할 수는 없기 때문에,

가장 최근에 개발했던 리뷰 관련 페이지 테스트 코드를 작성했다.

 

테스트가 필요한 항목은

1) 샵이 보유한 모든 리뷰가 뜬다.

2) 각 리뷰는, 해당 리뷰 상태에 알맞은 라벨이 뜬다.

3) 페이지 접속 시 구독 여부와 토글 여부에 알맞은 라벨 문구가 뜬다.

4) 관리 버튼 클릭 시 관리 페이지로 이동한다.

가 있었고, 각 항목에 맞는 테스트 코드를 작성!

 

그 과정에서 느낀 테스트 코드의 강력함(이자 필요성)은...

1. 개발 경험 향상

그전까지 구현 사항을 테스트하기 위해서는

UI를 대략적으로 작성하고, 시뮬레이터를 켜고, 해당 기능을 직접 누르고, 서버 데이터를 직접 조작해야만 했다.

그 모든 작업들이 테스트 코드로 이뤄졌다면 → 훨씬 더 생산적인 작업이 가능했으리라!

 

2. 결과물에 대한 확신

현 앱은 테스트 코드가 없을 뿐만 아니라 Javascript로 작성되어 있었기 때문에

컴파일 단계에서 에러가 발생한다 하더라도, 이를 알아차릴 방법조차 없었다!

 

덕분에 코드량이 늘어나면 늘어날수록 기존 코드를 수정하기 두려워졌고

이는 자연스레 소프트웨어 품질 저하(코드를 작성할 때마다, 직접 기존 기능들을 모두 사용해 볼 순 없으니),

소극적인 변경 사항 수용, 결과물에 대한 불확실성 증대로 이어졌다.

 

3. 개발 패러다임 변경

 

테스트 코드와 관련된 유명한 문장이 있다.

테스트 코드를 작성하기가 어려운 게 아니라, 당신의 코드가 테스트하기 어려운 것뿐이다.

직접 테스트 코드를 작성하다 보니, 이 말이 더더욱 뼈저리게 다가왔다.

 

이번에는 이미 작성되어 있는 코드에 대한 테스트 코드를 작성했는데,

그 과정에서 테스트를 힘들게 만드는 요인들을 몸소 체험할 수 있었고

이를 반대로 말하자면... 해당 요인들이 제거된 코드가 바로 테스트하기 쉬운 코드임을 느꼈다!

 

앞으로는 구현보다 테스트를 먼저 작성하라는 원칙(TDD)을 따라

1) 요구 사항을 명확하게 정리하고 (테스트 항목 파악)

2) 해당 요구 사항을 어떻게 구현할지 고민한 후

3) 테스트 코드를 작성하고

4) 실제 구현 코드를 작성하는 형태로 개발을 진행하게 될 테다.

 

2. 토스 페이먼츠 결제 서비스 계약

앱 내 결제를 붙일 계획이 생기면서, 미리 PG사 연동을 해두고자 했다.

 

사실 한 1년 전쯤 계약이 다 끝났었는데... 

그때는 KG이니시스와 계약을 해 둔 상태였고, 보증 보험 기간이 끝나면서 PG사를 변경하기로 했다.

 

직관적인 관리자 페이지 UI + 사용자에게 익숙함 의 이유로 토스페이먼츠를 선택했고,

서류 제출 및 심사 신청까지 완료해 둔 상태!

그 과정에서 이전에 작성해 둔 노션 문서를 많이 참고했는데,

잘 만든 문서의 유용함을 다시 한번 느낄 수 있었다!

 

3. PC 버전 VOC 처리

지난 1월 새로운 FE 개발자 분이 합류하신 후 열심히 개발해온 PC 버전.

물론 기존에도 PC 버전이 있긴 했지만, 워낙에 사용성이 불편했던 탓에 새로 개발을 진행하기로 했었고...

그 결과물을 드디어 배포하게 되었다.

 

배포한 직후 내부적으로 발견한 이슈들부터, 채널톡을 통해 들어온 VOC까지.

여러 버그들을 수정하고 재배포했다.

 

그 과정에서 느낀 점은...

개발 환경 - 배포 환경과의 간극 줄이기

웹 버전은 크게 feature / dev / release / production 으로 git flow를 관리했다.

각 기능들은 다음과 같은 역할!

feature : 각 기능별 개발 사항 관리
dev : 개발된 feature 단위들을 병합
release : dev 브랜치를 빌드, 개발 server에 연결해 팀원들과 공유
production : 배포

이 때 relese에서는 발견되지 않던 버그들이 production에서 발생하는 경우가 왕왕 있었다.

대부분 원인은 CORS, S3, Next-image origin 등 도메인 허용과 관련된 문제였다.

 

일차적으로 이를 담당한 개발자가 빠짐없이 체크하는 것이 맞지만

중요하면서도 빠뜨리기 쉬운 사안이니 만큼... 조금 더 신경 써야 했다는(그럴 수 있었을 것 같은데) 아쉬움이 남았다.