개요
스스로의 Story Point
이제 업무가 내려졌을 때, 어떤 작업을 우선순위로 작업을 해야하고,
해당 작업에 접근하기 전에 어떤 것들을 작업해야하는지 리스트업하고,
이를 통해 업무 시간을 단축하다보니 스스로의 스토리 포인트가 짐작이 가기 시작했다.
개발자로 일하기
Admin에 상품 유입 경로와 각종 정보들을 볼 수 있는 보고서가 기능이 추가 됐다.
해당 월에 대한 정보를 수집하도록 API를 쏘면
수집해야할 데이터가 너무 많아 서버에 무리가 가서 일별로 수집해야했는데,
CTO님께서 이를 스크립트로 작성하여 자동화를 하는 것을 보고
개발자가 이런식으로 일하는구나 싶었다❗️❗️❗️
앞으로 구현하고 싶은 기능이 있다면,
이번에 만들어진 상품보고서와 같은 것을 참고하여
데이터로서 기능 구현 필요성에 대해 설득하고 직접 구현해보라고 하셨다.
데이터로 설명하고 데이터로 입증해보라는 말이 괜히 마음을 설레게 했다🐳
7차 스프린트 기간: 24.10.04(금) ~ 24.10.21(월)
업무
상품 일정 변경 기능
새로운 데이터 파악
일정을 변경하는 것은 단순한 기능들 중 하나라고 생각했다.
하지만 일정을 변경하기 위해서는 서비스 전체 구조를 이해하고 있어야했다.
일정을 변경하기 위해서는,
변경하고자 하는 상품 옵션의 재고가 있는지 알고 있어야해,
상품 옵션을 나타내는 컬렉션을 이해하고 있어야했다.
상품 옵션 컬렉션을 이해하기 위해서는,
상품이 어떻게 만들어지는지 상품 컬렉션을 이해하고 있어야했다.
그리고 변경된 일자와 예약 알림톡이 가도록 하기 위해서,
해당 데이터를 담고 있는 수강증 및 스케줄 컬렉션을 이해하고 있어야했다.
처음 데이터 구조 파악을 할 때, 제대로 파악해야 코드를 짜는데 있어 수월할 것 같아
데이터 구조 파악에 많은 시간을 쏟았던 것 같다.
데이터 구조 파악을 한 뒤에는,
현재 코드에서 해당 데이터를 어떻게 가공하는지 파악에 나섰다.
그러다가 운이 좋게 버그도 찾아냈다.
뜨문뜨문 알림이 안 온다는 CS가 있었는데,
해당 문제에 대해 정확한 원인을 파악하지 못하고 있었는데, 이를 발견하여 찾은 것이었다.
CTO님께 칭찬을 들을 때는 짜릿한 것 같다😎
코드를 작성하기 전에, 데이터를 파악하고 어떻게 가공이 되어있는지 파악하니,
코드를 작성하는 것은 어렵지 않았다.
이를 새롭게 파트너 어드민에 적용하기 전에,
우리 어드민에 먼저 기능을 적용하여 사용할 수 있도록 했고,
그 이후에 이를 파트너 어드민에도 사용할 수 있도록 했다.
터득한 Point.
- 새로운 데이터에 접근하기 전에,
데이터 구조를 파악하고 어떻게 가공되는지를 먼저 확인하자.- 유저가 사용할 수 있는 기능은 어드민도 사용할 수 있어야한다!!!
스케줄 예약 알림톡 버그 수정
예약 일정을 저장하고 있는 곳에서 오류가 나고 있었다.
우리 서비스는 모든 시간대를 UTC로 저장하고 있었다.
때문에 KST 시간에 대해 UTC시간으로의 변환이 필요했다.
예약시간에 대한 저장도 마찬가지였다.
해당 일정에 대하여 당일 오전 10시에 알람이 가도록 예약시간을 설정한 뒤에,
AWS Lambda를 이용하여 스케줄링을 실행시키고 있었다.
한국 시간대의 10시로 저장하고 UTC로 변환하여 저장해야하는 것을,
setUTCHours 메소드를 이용하여 UTC 시간의 10시로 저장하고 있었다.
때문에 KST기준 아침 7시로 저장이 되고 있었다.
다행히도 해당 로직은 일정을 업데이트하는 경우에만 해당 함수를 타고,
그 이외에는 각자의 메소드에서 정의하여 실행하고 있었다. 불행중 다행(?)
하지만 어떤 메소드에서는 UTC로 저장할 때,
UTC로 변환하고 우리나라 기준 10시로 저장을 하고 있어,
시차를 기준으로 이전날인지 다음날인지를 계산하지 않고 있어서,
Date에 대해 KST로 변환하고 해당 시간을 10시로 변환한 다음,
UTC로 저장하도록 한 뒤에, 모든 곳에서 해당 공통 함수를 타도록 수정했다.
터득한 Point.
- 나의 코드를 의심하고 또 의심하자
- 비슷한 로직에 쓰일 것 같은 함수라면 존재하는지 찾아보고 개선하기
상품 일정 커스텀 변경 기능
Admin에 내가 작업한 상품 일정 변경 기능을 추가하고,
이를 어떻게 사용하는지 간단하게 운영팀에게 전달했다.
운영팀에서 현재 주어진 상품 옵션 외에도,
프라이빗으로 현재 나와 있지 않은 일정에 바뀔 수도 있다고 말해주셨다.
그래서 우리 어드민에서는 현재 존재하는 일정 외에도,
특정 날짜로 수정할 수 있는 기능이 있어야 할 것 같다고 하셨다.
현재 파트너에 일정 변경 기능을 넣고 있었는데,
어느 것을 먼저 작업해야하는지 중요도를 CTO님께 여쭤봤다.
일의 중요도에 있어,
새로운 기능을 작업하는 것보다
우리 팀원에게 필요한 기능을 만드는 것이 더 중요하다고 하셨다.
인턴을 하면서 개발적인 기술들을 배워가는 것도 재밌지만,
이렇게 회사의 프로세스를 알아나가는 것도 매우 즐거운 것 같다😄
그래서 현재 작업하고 있는 것을 잠시 접어두고,
현재 바꿀 수 있는 상품 옵션을 Select 바로 보여주고,
해당 Select 바에 커스텀해서 내용을 추가하여 선택할 수 있도록 기능을 추가했다.
antd의 Select 컴포넌트의 option props에 추가하면 되는일이라 어렵지 않았다.
처음에는 직접 구현하지 못하고 antd를 써야해서 아쉬웠지만,
라이브러리를 통해 시간을 아끼고, 아낀 리소스를 바탕으로 다른 기능 구현이나,
공부에 더 많은 시간을 쓸 수 있었고,
무엇보다 다른 사람은 어떤 구조로 컴포넌트를 만드는지 배울 수 있어,
지금은 최대한 다른 사람들의 코드를 많이 보고 배우고 싶어졌다.
터득한 Point.
- 하드 스킬뿐만이 아니라, 소프트 스킬도 중요하다.
- 다른 사람의 코드가 내 코드보다 좋을 수도 있다는 것을 인정하고,
다른 사람의 코드를 통해 배워가자!!!
Admin 공지사항 작성페이지 버튼 활성화 오류
공지사항에서 체크박스에 defaultValue로 이전 값을 넣어주고 있었다.
하지만 공지사항에서 내용을 수정했음에도 checkbox가 refresh 되지않아,
invalidQuery로 cache를 초기화는데도, 상태가 업데이트 되지 않았다.
antd의 Checkbox를 사용하고 있어, antd의 문제인가 하여 코드를 확인했지만,
문제가 없어보였고, 이것은 내 코드에서 잘못됐다고 생각했다.
어떤 것을 수정해야할까 하다가, 한가지 가설을 세웠다.
공지사항 상세페이지는 모달로 구현이 되어있는데,
해당 캐시가 초기화되었다고 해도 모달은 언마운트가 되지 않았고,
defaultValue에 처음 바뀌기전 값이 계속 들어가고 있는 것은 아닐까?
정답이었다.
해서 이 문제를 Checkbox에 key값에 해당 상태값을 넣어줘,
해당 상태값이 바뀌었을 때, Checkbox만 리렌더링 되도록 했다.
Modal의 destroyOnClose 속성을 true로 하는 방법도 있었지만,
공지사항 수정의 경우 전체가 바뀌는 경우는 없고,
상태값 정도만 수정이 되서 불필요한 리렌더링을 할 필요가 없다고 판단되었다.
하지만 key값을 이 용도로 써도 되는지 의문이 들어 더 알아볼 필요성을 느꼈다.
터득한 Point.
- 리액트의 동작방식에 대해 더 공부하자! 오늘과 같이 도움이 될 길이 많다.
- 안된다고 부여잡기보다, '나는 컴퓨터다'라 생각하고
코드를 논리적으로 이해해보자. 안될 때는 잠깐 머리 비워두기
