원래 앞단이 제일 중요함 다른거 다 필요 없음
화면 봐바 그럴싸 하잖아?
프론트 분들이 고생 많으셨다.
클론 코딩이므로 기획단계의 대부분을 건너 뛴다.
와이어프레임은 귀찮아서 안했음. 그래서 프론트 코드 칠게 꽤 많았던거 같다.
백단이야 뭐 대충 기능 보고 만들면 되니까 쉽다.
따지면 개나소나 다 만드는 Todo App에서 크게 변하는게 없다.
아마 포인트로 뭘 사고 파는 간단한 쇼핑몰일 경우 트랜잭션이나 기본적인 쿼리 공부에 도움이 됐을건데,
이 로직은 그냥 페치 조인이나 날리고 몇 번 그러면 대부분의 쿼리 최적화는 끝난다.
우선 프젝 전에 내가 생각한 내 원칙은
- 프론트가 달라는 json은 바로바로 만들어준다.
- 앵간하면 프론트가 원하는 json 모양으로 하자.
- 프론트에게 감놔라 배놔라 하지 말자
- 뭐가 리스크 생길 일 있으면 내가 하자 (aws 같은거)
1번은 뭐 당연한거고, 2번의 경우는 나와 프론트 분의 의견이 갈렸는데, 1번의 대원칙에 의거 내가 바로 꼬리 내렸다. (뿌듯)
솔직히 1 ~ 3번 다 프론트 분들 심기 거슬리게 안할라고 생각한거임 ㅋㅋㅋ
3번 빼고는 나름 잘 된거 같다. 성격이 급해질 때가 있어서 가끔 감놔라고 했던듯.
잘 안된거
1. api 문서
생각과 다른 부분이 있다면 api문서
기본적으로 테스트를 통해 작성하는 rest docs를 이용했다.
다만 아직 내 실력으론 목 테스트를 하더라도 머릿속에 로직을 만들고 해야 하므로
실제로 대충 만든 목 테스트가 아니라 서비스 계층을 얼추 구현해 두고 했다.
그래서 문서가 굉장히 늦게 나옴
2. 쿼리 최적화
질문 상세보기 화면에 띄울 json 모양세는 대충 이렇다.
{
"questionId" : 1,
"createdAt" : "2022-09-02T16:26:17.3060106",
"modifiedAt" : "2022-09-02T16:26:17.3060106",
"title" : "this is title",
"body" : "this is body",
"username" : "초보 개발자",
"voteNumber" : 0,
"like" : false,
"hate" : false,
"answers" : [ {
"answerId" : 1,
"body" : "근데 그건 아닌거 같습니다. 그렇게 하면 코드 잘못 짜신거에요",
"username" : "성난 개발자",
"voteNumber" : 0,
"like" : true,
"hate" : false,
"createdAt" : "2022-09-02T16:26:17.3040116",
"modifiedAt" : "2022-09-02T16:26:17.3040116"
}, {
"answerId" : 2,
"body" : "잘했는데 왜 그르죠",
"username" : "초보 개발자",
"voteNumber" : 1,
"like" : true,
"hate" : false,
"createdAt" : "2022-09-02T16:26:17.3040116",
"modifiedAt" : "2022-09-02T16:26:17.3040116"
} ]
}척 봐도 굉장히 많은 데이터가 나감
차라리 랜더링을 다시 하는 부분을 조금씩 나눠서 api를 비동기적으로 쐇다면 더 좋았을 것인데,
통으로 보내다보니 쿼리가 많이 꼬였다. 우선 question의 상세보기인데, 그 question에 내용 (제목, 본문 등) 과 그에 딸린 추천 테이블이 딸려와야 하고, question에 연결 된 answer의 list들을 뜯어와야 한다. 여기까지만 하면 문제 없는데, answer 내부에 또 추천 로직이 있어서 answer의 vote 테이블도 뜯어와야 하는 상황.
우선 question의 작성자나 추천수는 fetch join으로 뜯어올 수 있다. 얘네는 null일 수 없으니까!
대신 answer의 경우 fetch join을 활용하기 어려운데, 답변이 없는 question이 있을 수 있으므로 fetch join시 답변이 없다면 null을 받아온다. answer는 또 따로 뽑아야 하는 지경 뭐 어찌저찌 쿼리 성능 생각 안하면 (죄 다 jpa를 통해 부른다고 했을 때) 만들 수 있는데, answer의 갯수만큼 쿼리가 + 나간다. N+1 문제가 터지는 거다.
쿼리를 계획대로 잘 짰다면 그래도 3~4개의 쿼리로 다 불렀을건데, 그거 마지막까지 시도하다가 걍 포기해버림.
시간이 없으니 main 때 잘 설계해야 하겠다. 그래도 다른 쿼리들은 대부분 1방 쿼리로 해결함.
물론 추천 로직은 마지막에 급박하게 짜서 쿼리가 많이 나가지만, 최적화는 금방 할 듯?
3. 뒷단 코드 동시 작업
아니 아무래도 기능 구현 막바지엔 내 컴터로 서버를 열어놨기 때문에 나만 작업을 하게 됐다.
다른 백 팀원은 소외되는 상황, 차라리 인텔리제이의 라이브코딩 기능을 적극 활용해서 같은 파일을 고쳤으면 어떨까 싶다.
솔직히 구현할 기능이 적어서 벌어진 상황이기도함.
4. 자동배포를 구현하자
깃헙 액션을 안씀. 대충 정적인 배포만 하고 끝낼라고 했다. 그러니까 3번 이슈가 발생한 것엔 이 4번을 안한 탓도 있음.
깃헙 액션을 써서 자동 배포로 테스트 서버를 만들었다면, 아마 이럴 일 없을듯. 다만 aws에 적용되기 까지가 좀 걸려서 문제지...
잘된 거
1. 서로 뽜이팅 한거
디코에서 아침인사 하면서 서로 뽜이팅 잘했다.
나름 기운 없는데 의무감에라도 아침인사 하니까 뭔가 엔진스타터에 전기 넣는 느낌이었음
2. 어찌됐든 엉성하게나마 첫번째 프젝을 끝낸 것
거의 10일 밖에 안되는 시간에 그래도 뭔갈 만들긴 했다. 엉성해도 매우 재밌었음.
뭔가 시연하는데 예쁘게 보일거면 진짜 데이터를 넣자.
저런거 넣으니까 좀 덜 예뻐 보이긴 함. ㅋㅋㅋㅋㅋ
