TIL-20210428~29

2021. 04. 30.
  • Sidedish와 Sidedish카테고리를 먼저 페어로 구현한 뒤 각자 분업을 시작했다. 관계테이블도 문제 없이 처리됐고, 이 때 까지만 해도 순조롭게 진행됐다. ㅎㅎ
  • 객체 설계를 끝낸 뒤 본격적인 구현에 들어갔는데, 관계테이블의 정보를 DTO로 변환하는 작업이 많이 까다로웠다. 다음 번에 하게 된다면 서비스에 DTO를 넣은 뒤, 관계 테이블에 사용할 용도로 꺼낸 다음 해당 결과를 바탕으로 엔티티를 만들어야 하는게 아닌가 싶다.
  • 위의 이유로 DB에 삽입하는 작업이 많이 까다로워졌는데, 어차피 안 되는건 어쩔 수 없다 판단하여 하드코딩 비슷하게 처리해버렸다.
  • 이외에 CORS나 recommend를 추가하는 등의 작업을 했다. 여기까진 괜찮았지만, 크나큰 실수가 있었는데 BestCategory와 Category의 성격이 조금 다르다는 것이다. 다시 하게 된다면 다 관계 테이블로 놓는게 좋을 것 같다. 처음에 Sidedish가 AggregateRoot로 나오지 않아서 살짝 느낌이 이상했는데 그게 이런 이유였던 것 같다. 덕분에 레포지토리가 하나만 나와야 하는 구조에서 두 개가 만들어졌다. 사실 두 개가 만들어지도록 해야 옳은 설계인 것 같은데, 어쨌든 설계와 구조가 잘못 되었던 것 같다.
  • 마무리 작업으로 DTO매핑과 리팩토링을 했다. 두 개의 작업을 분리하는게 맞지 않았을까 싶기도 하다. 하지만 그러면 작업량이 많아질 것이기 때문에 그냥 이렇게 했다. 양해를 조금 구해야겠다.
  • 내일은 OAuth구현을 하게 될 것 같다. 다른 분들도 난항을 겪었는지 DM으로 얘기를 나누게 됐는데, 의외의 수확을 얻었다. 채팅 일부를 발췌해서 기록해놓을 것이다. 나중에 내가 얼마나 잘못했는지 보는 것도 좋을 것 같다.... ㅎㅎㅎ...

    > 프레디 팀 로그인 구현하실 때 github access token이랑 프론트의 로그인 유지를 위해 로컬스토리지에 저장하는 용도로 보내주는 토큰이랑 같은걸 사용하신다고 들었는데 맞나요??
    > 깃헙 토큰과는 별개로 jwt 생성해서 프론트에 넘겨준다라고 들은 것 같아서요
    > 로그인 유지할때요 지난번 프로젝트에서 jwt 사용했던 것처럼??
    
    기본적으로 토큰이나 필요한 값을 프런트로 리턴해주잖아요 그걸 프런트에서 가지고 있다가 같이 보내줘야죠 
    세션도 보면 세션에 매핑되는 쿠키가 클라이언트로 넘어가잖아요
    
    > 아 그건 그런데 깃헙에서 보내준 토큰은 프론트에서 쓸일이 없을거라 생각해서요
    > 서버에서 깃헙으로 코드 보내서 토큰을 받아오면 그거 디비에 저장하고 별개로 토큰 만들어서 클라이언트로 보내줘야한다??
    > 라고 알고 있었는데 그럴필요는 없을까요??
    
    저도 아직 구현안해봐서 자세히는 모르겠는데 클라이언트가 누군지 확인할 구분값은 있어야될거에요 어떤 방식이든
    
    > 넵넵 그건 이해했습니다!!
    
    > 프레디 아까 질문했던거 너무 답답해서 디온에게 여쭤봤는뎈ㅋㅋㅋㅋㅋ
    > 깃헙 인증을 통해 받은 토큰은 외부로 나가지 않는게 좋대요 그러니까 서버랑 클라이언트랑 소통할 때는 저희 했던것처럼 세션이나 토큰이면 새로 만들어서 그걸로 소통하는게 좋다네요

    아마도 내가 제대로 모르는 내용이다보니 요를 파악하지 못해 말이 계속 빙글빙글 돌았던게 하닌가 하는 느낌이 든다. 내일 구현 다 하고 다시 확인해봐야겠다.

  • 글 옮기다 단저씨의 정규식 문제를 풀어드렸다. 범위 지정 조건이 잘못 돼 있었다. 케이스를 많이 주셔서 문제를 금방 찾을 수 있었다. 테스트 케이스를 활용하는 디버깅은 참 좋은 방법인 것 같다. 뿌듯하니까 링크 저장해놔야지. https://codesquad-members.slack.com/archives/C01JLFFQA9E/p1619721070113800
정대화
DaeHwa_Jeong@outlook.com

Powered with by Gatsby 2.0