[SW 정글 113일차] 나만의 무기 21일차 (기획 고민=∞)

오늘의 어제의 작업을 이어서하고 오후 3시에 멘토링에 참여했다.

프론트엔드 현직자분이여서 우리의 화면 구성에 대한 문제점들에 대한 좋은 말씀을 해주셨다.

가장 큰 문제는 사용자가 이 서비스를 이용한다고 했을 때, 어떠한 행동을 많이할지에 대한 생각을 해봤는지와 해당 문제를 해결하려고했는가?이다.

로그인 후에 사용자가 가장 많이 할 것은 오늘 어떠한 챌린지를 해야하는지와 챌린지를 했으면 인증요청을 하는 것이다.

하지만, 우리는 이를 생각하고 있어도 서비스에는 묻어나지 않았다.

가령 파워포인트 프로그램을 들어가면 첫 화면이 최근 작성한 ppt파일과 새로 만들기 버튼이 나온다.

이유는 파워포인트 서비스를 이용하는 사용자들이 가장 많이할 행동이 최근 작성한 ppt를 이어 작업하거나 새로운 ppt를 만들기 때문..

 

그래서 조장님이 깊은 고민을 하셨고 다른 팀원들과 같이 고민을 하기 시작했다.

결론은 화면 구성을 바꿈과 동시에 더 자연스러운 서비스를 제공하기 위해서 기획도 약간 수정됐다.

수정된 부분은 생명체(챌린지 참여자가 키우는 것)가 원래는 사용자가 기점일(챌린지를 시작하는 일)을 정해서 일주일 단위(매일 챌린지는 매일 단위)로 챌린지를 성공적으로 완료했는지와 안했는지를 판단했다.

하지만, 이러한 기획은 사용자나 이 서비스를 봤을 때 자연스럽지 않은 부분이였고 화면 구성 변화를 가지면서 걸림돌이 되는 부분이였다.

 

이에 따라 우리는 기점일을 정하는 것이 아닌 챌린지가 주 3회라면 사용자가 '나는 월, 수, 금' 혹은 '나는 화, 목, 토'이렇게 정하도록 하기로 했다.

그리고 매일을 기점으로 챌린지를 했는지 안했는지를 판단하기로 했다.

이러한 기획 변경으로 DB 수정과 api코드 수정이 필요했다.

새벽 1시가 다 되서 내린 결정이여서 모든 것을 수정하지는 못했고 테이블 설계와 간단한 api 수정을 하고 하루를 마무리 했다.

 

 

<ERD 수정본 2021.11.23 오후 10시>

수정이유: 인증요청수락하기에서 인증요청자의 닉네임과 인증수락자의 닉네임 데이터를 원함.

이전에는 유저의 id만 저장한 상태.

join을 통해 데이터를 줄 수 있지만 join은 무거운 로직이여서 컬럼으로 추가해야겠다는 생각을 함.

 

- 더 수정할 사항

1) 졸업, 사망 생명체, 인증기록을 각각 테이블을 나누었는데 멘토링에서 굳이 3개의 테이블로 관리하는 것보다 one table로 관리해서 상태정보 column을 추가하는 것이 낫다고 함.

몇 십만, 몇 백만 row가 된다고 조회계산 성능에 크게 영향을 주지 않음.

 

2) 트리거 제거 후 sql문으로 처리해야함. 트리거가 좋은 기능이지만 블랙박스처럼 프로그래머 입장에서는 직접 트리거를 설정한 사람만 알 수 있는 것이고 트리거를 설정한 사람이 팀에서 나가면 다른 사람에게 계속해서 공유되지 않은 이상 관리되기 힘듬.

현업에서도 DB에게 어떠한 기능을 맡기기보다는 코드로 로직을 해결하려고 함.

우리도 트리거 제거하고 고쳐야 함.

 

 

 

 

<ERD 수정본 2021.11.24 새벽 2시>

새벽 1시에 기획이 변경됨에 따라 백엔드팀의 회의를 걸쳐 테이블 설계를 변경했다.

변경하는 김에 죽은 생명체, 졸업한 생명체, 살아있는 생명체를 한 테이블에 관리하도록 하는 것도 반영했다.

 

<알아봐야 할 것>

CI/CD 툴 (젠킨스, github actions 등..)

도커

테스트 코드(라이브러리는 Mocha, Jest 등..)

Express vs nestJs (Express가 자유성이 높고 참고할 커뮤니티가 nestJs보다 더 잘되어있어서 선택했지만 조금 더 기술적인 차이점을 알아봐야할듯)

npm vs yarn vs .. (패키지관리소프트웨어로 그냥 npm을 썼는데 다른 것과 비교해볼 필요성이 있음)

pm2 (현재 AWS EC2에 배포 후에 pm2로 서버를 실행 중에 있는데 pm2의 특징과 다른 방법을 없는지 확인해봐야함)

동시성에 대한 고민(예시로는 챌린지 참여인원 관리, 누군가 빠지고 누군가 들어왔을 때 데이터가 정확히 유지되도록 해야함)