04 - 16 일지

또 2주가 흘렀다. 기록을 남길 틈도 없이 진짜 장난아니게 바쁜 나날이었다. 4시에 자서 9시에 일어나는 것이 사치로 느껴질만큼 긴 시간이었는데, 중간발표하고 1주일 밖에 안 된 것 같았는데 2주나 지났다. 그동안에도 참 많은 일이 있었다.(그만큼 성장도)

 

당장 한 부분만 써보자면

 

메인, 그룹, 그룹 게시글 페이지(게시글, 과제, 설문, 투표), 어드민&프로필 페이지 제작

메인 페이지 그룹 개설 및 가입 모달 로직 구현

어드민&프로필 페이지 CRUD

그룹 게시글 페이지 과제, 투표, 설문 CURD, 그룹 게시글 페이지 댓글 기초 로직 구현

카카오톡 소셜 로그인 구현

출시 후 버그 관리와 유저 피드백 관리

 

이정도인데, 사용하고 있는 API의 갯수는 45개이고 그중 32개 가량을 내가 사용하고 있었다.(그에 맞는 CRUD 코드 구현도 전부 내가 했고)

벡 친구들이 DB를 어떻게 만들고 관리하는지 잘 모르겠다. 나도 정보처리기사 실기 준비하면서 SQL이나 자바를 찍먹 수준이지만 배워놨는데, 본격적으로 복잡한 파일을 넘겨받고 넘겨주니 도저히 어떻게 로직이 돌아가는지 짐작도 안간다. 너무 짐작이 안가서, 설문 분야를 만들 때에는 "아니 이렇게 넘겨준다고?" 싶은 상황들도 있었다. 물론 넘겨줄 때도 "이걸 이렇게 넘겨도되나?" 싶게 넘겼지만.....

 

예를 들어보면, 설문은 최대 3차 배열까지 파고 들어간다.

1차 배열 - 질문 항목

2차 배열 - 질문 항목의 질문과 (복수형일 경우)각 넘버링 항목

3차 배열 - 각 넘버링 항목의 질문명

 

설문 작성을 위해 받아오는 데이터는 여기서 끝나지만 설문 결과를 받아오는 부분에서는 로직이 위에 말한 것처럼 "아니 이렇게 넘겨준다고?"하는 상황이 벌어진다.

 

1차 배열 - 질문 항목

2차 배열 - 질문 항목의 응답 내역

 

배열 자체는 단순하지만 이는 배열 수를 줄이기 위해 넘겨오는 value를 전부 문자열(string)으로 해결한 것이다. 예를 들어 객관식 항목의 경우

["1번", "2번", "3번", "4번", " 5번"]

으로 넘겨오던 설문 작성에서의 배열이 여기서는

"1번, 2번, 3번, 4번, 5번"

문자열로 넘어오는 것이다! 처음 이걸 들으면 진짜 이상하다고 생각할 수 있지만, 위에 말한 것처럼 배열 수를 줄이기 위한 상황이었다. 호기롭게 "배열 좀 많아봐야 얼마나 복잡하겠어!" 했었는데....

 

배열을 돌리면서

배열의 배열의 값을 받아오는데

배열의 배열의 배열에서 추가 값을 받아와서

배열의 배열의 다른 배열에서 대응되는 추가 값을 연결한 다음

배열의 배열을 돌리는 부분에서 렌더링을 진행하고

이를 배열을 돌리면서 예외처리를 돌리는

 

그런 상황을 겪고 난 다음 최대한 타협의 타협을 거친 것이었다. 그래도 여전히 복잡하고, 넘어오는 값은 "아니 이렇게 넘겨준다고?"하는 상황의 연속이었다. 그래도 어쩌겠는가. 그렇게 안하면 수가 없는 걸.

 

배포 과정도 참 재미났었다. 비유적으로도, 실제적으로도.

우선 우리 사이트를 공유하겠다. 

http://navis.kro.kr/

Navis | 그룹 관리 플랫폼

NAVIS 사용자가이드 (notion.so)

NAVIS 사용자가이드

2번째 링크는 사용자 가이드에 대한 글이다. 더 자세한 가이드는 NAVIS에 가입하면 기본으로 제공되는 가이드 그룹에서 확인할 수 있다.

 

내일은 브로셔를 제출하고, 촬영 영상을 찍을 준비를 해야한다. 하루 안에 다 끝나면 좋겠지만, 그게 여의찮을 수 있다. 리팩토링도 해야하고, 유저 피드벡도 반영해야하고. 할 것들이 많다.

 

특히 리팩토링이 걱정인데, 흠.......한 페이지에 useState만 수십 개에 달하고 있다. 10개만 있어도 매니저께서 잔소리를 하셨는데 한 번 줄이고 남은 것이 20개다. 이를 도저히 어떻게 해야할 지.....