42gg를 출시하고 이호준 멘토님께 받은 숙제가 있었다. phase1, 즉 서비스를 빌드하고 배포하는 단계를 완료했으니 phase2를 진행하라는 것이었다.
42byte 때는 어떤 멘토링도 받지 않고 진행했었기 때문에 사이트 출시에도 여러 단계가 있다는 것을 생각하지 못했었다. phase2는 도대체 무엇인가? 사실 조금만 생각해 보면 당연하게 필요한 단계들이다.
다음은 이호준 멘토님께서 설명해주신 서비스에 대한 내용이다.
"학생들의 프로젝트는
1.0
버전에서 그치는 경우가 많다. 하지만 phase2를 통해1.0
버전에 대한 내용을 정리하고 다음 업데이트에 대한 내용을 고민해야만1.1
버전이 나온다. 그것이 서비스 운영이다."
phase2를 완료하기 위해 멘토님께서 처음으로 내준 과제는 시퀀스 다이어그램을 만드는 것이었다. 우리가 작성한 코드를 시퀀스 다이어그램으로 그리면서 데이터의 흐름을 파악하고 더 효율적인 서비스를 고안하라는 것이다.
그렇게 무작정 덤벼본 시퀀스 다이어그램은 그렇게 호락호락하지 않았다. 시퀀스 다이어그램에 대한 정의는 이렇다.
문제 해결을 위한 객체를 정의하고 객체간의 상호작용 메시지 시퀀스를 시간의 흐름에 따라 나타내는 다이어그램
사실 프론트단에는 컴포넌트가 굉장히 많고 대부분이 비동기로 처리되며 recoil을 사용하여 상태를 처리하고 있기 때문에 절차 지향적인 시퀀스 다이어그램으로 표현하는 것이 맞는지에 대한 고민이 많았다. 하지만... 어떻게든 그려낸 나의 시퀀스 다이어그램...!
Match 페이지는 탁구 매칭을 등록하기 위한 시간별 슬롯이 보이는 페이지다. 페이지에 접속했을 때 서버에 매치 정보를 요청한 뒤 요청 성공 여부에 따른 반환 값을 다이어그램으로 나타냈다.
시퀀스 다이어그램에서 보이는 것처럼 42gg는 error 페이지에 대한 처리를 recoil
상태로 관리한다. recoil
의 errorMessage
에 값이 있다면 에러 페이지를 반환하고, 값이 없다면 에러 페이지를 반환하지 않는다.
매치 페이지의 각 슬롯은 MatchItem
이라는 컴포넌트를 통해 렌더링된다. 위의 이미지에서 9번 단계는 MatchItem
으로 이동하는 링크가 걸려있으며, 링크 안의 내용은 아래와 같다.
매치 시간별 슬롯을 클릭하면 위와 같은 처리가 이루어진다. 에러 상태와 마찬가지로 42gg의 모든 모달은 recoil
상태로 관리된다. reocoil
상태의 modalName
의 값이 지정된 모달의 이름과 같다면 해당 모달이 화면에 뜨는 형식이다. 값이 null
이라면 모달이 사라진다. 이를 관리하는 modalProvider
라는 컴포넌트가 아래에 있다.
ModalProvider
는 위에 설명했듯이 모달의 이름을 상태로 받아 해당 모달을 띄워주는 컴포넌트다. 모달 바깥을 클릭하면 modalName
의 상태를 null
로 변경하여 모달이 사라지게 된다. ModalProvider
에 속해 있는 모달들에 대한 상세 시퀀스 다이어그램은 다음 포스트에 올려보도록 하겠다.
아직 정리되지 않은 우리의 시퀀스 다이어그램을 보시고 멘토님께서 정답은 없다고 말씀해주셨다. 멘토님께서 서비스의 흐름을 보기 위해 가장 효율적이라고 판단한 것이 시퀀스 다이어그램이라고 생각하시기 때문에 우리에게도 그려보기를 권한 것이며, 실제로 각 회사에서 사용하는 시퀀스 다이어그램도 모두 다르다고 한다.
주니어들은 갈수록 속도가 느려지고, 시니어들은 갈수록 속도가 빨라진다. 시퀀스 다이어그램을 보고 컴포넌트를 어떻게 "나이스"하게 가져올 수 있는지를 고민해라. 그러면 각자의 파트를 효율적으로 나눠서 작업할 수 있다. 랜더링 타임을 줄이기 위해서 어떻게 해야하는지 시퀀스 다이어그램을 통해서 봐라.
다음 과제도 내주셨다! 바로바로~ 어드민 운영 툴 만들기! 어드민 툴의 간단한 구성 요소는 다음과 같다.
추석이 끝나면 코드 리뷰를 받으러 떠나기로 했다. 그 전까지 모든 시퀀스 다이어그램과 어드민 툴을 완성해야 한다!! 아직 끝나지 않은 42gg~~! 화이팅!!🤠
https://itwiki.kr/w/%EC%8B%9C%ED%80%80%EC%8A%A4_%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8