대망의 머지 날이 찾아왔다. 막상 내가 조장이라 제안은 했지만 잘 풀릴까? 어떤 방법을 써서 배워야 이해가 편할까?를 고민하다보니 잠도 살짝 설칠 정도였던지라 머지하기로 한 오후를 기다렸다.
Firestore 설계하기
Index 관리하기
Firestore는 NoSQL이라 굳이 싶지만 SQL 기반 RDBMS는 경험이 미숙하고 미니 프로젝트를 빠르게 마감하는게 우선이었기에 웹 개발 종합반 강의에서 쓴 대로 Firestore를 쓰되 인덱스 관리가 가능하게끔 진행하기로 했다.
(관련해서 찾아보니 Firestore 설정 내에서 규칙을 관리하는 방식 또한 유효해 보였는데 아주 가볍게 다룰거라 설계 부분은 이해가 느려 진행하지 않았다.)
처음에 쓴 방법은 index field를 지속적으로 관리하기였다. 나름 잘 되기도 했고 Index 순서대로 문서 관리를 하기에도 뛰어났지만 Field가 Firestore에선 너무나도 작은 단위같아서 다른 방법도 채용했다.
두 번째 방법은 문서 이름 자체를 인덱스로 관리하는 방법이었는데 문서 이름은 문자열로만 관리가 돼서 Index가 10이 된 순간 1 다음이 10이 되는 현상이 일어나버려서 원하는 바가 아니었다.
결국 그냥 Index를 문서 이름과 Field로 같이 사용하며 관리를 했는데 억지로 쓴 거긴 하지만 어느정도 감을 잡을 수 있었다.
문서의 Status 관리하기
실무중에 어깨 너머로 배운 DB구조에서 status 또한 많이 봤었는데 삭제된 상태 또한 저장하길래 무엇일까 했더니 가급적 레코드를 Delete하는 것보단 관리할 수 있는 상태가 좋다고 들었던 것 같아 그 노하우를 Firestore에 반영했다.
팀 목표 칸에서 삭제 버튼을 구현하는데 Delete를 하는게 아니라 문서의 Status를 업데이트해서 처리해 콜렉션엔 남아있지만 조회할 땐 구분하는 식으로 짰다. ("A"는 Alive라서 조회되고 삭제하면 해당 문서 인덱스의 status를 Deleted라서 "D"로 업데이트했다.)
개인적으론 처음 하는 설계치곤 마음에 들었는데 실제 RDBMS였다면 더욱 신경써서 레코드 관리를 해야할 테니 deleted_at 도 저장했으면 좋았을텐데 이제서야 생각났다.
랜딩 페이지 전부 main에 합치기
"간단한 기본정도는 알만큼 아는 것 같으니 랜딩 페이지를 각자 만들어 뽐내자!"
어제 TIL에도 적은 것 같긴한데 이게 실무에선 터무니 없고 억지로 충돌내는 좋지 않은 flow인건 알지만 다들 Conflict 해결도 해보고 Branch도 써보기에 좋은 기회같아 제안한 거였지만 걱정이 태산이었다.
데이터의 소멸은 딱히 걱정하지 않지만 일단 나부터 git은 계속 배워야 하는 입장이고 합리적인 프로세스의 merge를 할 자신이 없었기에 제안해놓고 최대한 열심히 해봐야했다.
오전까지 모든 팀원분들이 멋지게 자신만의 랜딩 페이지를 작성하셨고 점심 먹고나서 오후가 되자마자 코드리뷰부터 진행했는데 확실히 다들 자기 코드를 이해하고 계셔서 리뷰가 편한 분위기가 됐다.
그러고 나서 Merge를 하는 부분이 참 문제였는데 모두가 기초를 index.html 파일에서 작업을 했기 때문에 첫 Merge 이후엔 Conflict가 대량발생했고 한 번 resolve 후 테스트해서 성공시켜보고 또 하나 더 Merge해서 reselove하고 테스트해보고 하니 코드가 정신이 없었다.
그래도 각자 의도했던 바를 여쭤보며 리뷰를 진행했고 고생을 하긴 했지만 기능 테스트까지 무사히 마치며 Merge가 마무리됐다.
완성된 결과물은 꽤 보기 좋았고 모두가 리뷰를 하며 코드를 이해하고 있기에 큰 성과로 남았다.
뭔가 더 세부적으로 적었던 내용이 있었는데 실수로 임시글로 적던 맥북의 탭이 로딩되면서 오늘 TIL 내용에 덮어씌워져서 출간된게 날아갔고 내용도 꽤 유실되어 생각나는대로 복구했다.
