[TIL] 코드스쿼드 팀 프로젝트 23일차 (roach)

Published: 2023-07-26
Updated: 2023-07-26

오늘의 활동

오늘 새벽 늦게까지 못 자서 그런지는 몰라도 아침에 5분만 더 자야겠다고 생각했던 게 30분 지각을 낳았다. 수면 리듬이 계속 이렇게 유지되면 안 되는데 빨리 특단의 조치를 취하던가 뭐든 해야 될 것 같다.
오늘은 어제 작성하던 API 명세서를 마저 쓰는 시간을 가졌다. 각자 맡았던 부분들을 서로 공유하면서 어디 어디가 틀렸는지 지적해 주었다. 내가 맡은 부분은 마일스톤이었는데 open이냐 closed냐에 따라서 은근 생각해야 할 것들이 많았다. default, open, closed 상태로 API를 분리하여 해결했다.
이슈 부분이 제일 중요한 부분이다 보니 다 같이 짜게 됐는데 이슈 수정을 할 때 PATCH 요청으로 넘기니 API를 분리해야 될 필요가 있었다. 이슈 수정은 분리를 했는데 이슈 상세 보기에서 한꺼번에 합친다면 오히려 혼란스러울 수 있기 때문에 상세 보기인 GET 요청에서도 분리하는 작업을 진행했다.

PATCH나 PUT에서 Response에 id를 넘겨줘야 하는지
- 프론트가 원하는 방향으로 하는 게 맞음 (Jello가 원하지 않았으므로 안 넘기도록 결정됨)
현업에서는 Response에 success 여부를 넘기는지
- 이건 그렇게 중요하지 않고 가장 중요한 것은 error 표시임
- 이번 같은 경우에는 success도 넣고, error도 넣었지만 결국 중요한 건 error임
- 물론 상황에 따라 success를 사용하는 경우도 있음
- 똑같은 말이지만 제일 중요한 건 결국 error
StatusCode 커스텀으로 하는 게 좋은지?
- 현업에서 사실 잘 신경 안 씀..
- 대부분의 사람들은 정말 신경 안 씀
- 특히 선임에 따라서 다를 듯
- 200이랑 500만 쓰는 거 같음
- 하지만 공부 목적으로는 잘 알아두는 거 좋음
GET 요청을 잘게 쪼개는 경우는 어떤 경우가 좋은지?
- 이것도 상황에 따라 다름
  - 하지만 정석은 분리하는 것이 맞다는 거임
- GET 요청이 많으면 로딩이 더 많이 걸리는 것은 사실이긴 함
  - 하지만 이를 해결하기 위해 현업에서는 프론트엔드 서버를 하나 둠
- 그럼 프론트엔드 서버를 두지 않는 경우에는 한꺼번에 보내는 게 좋을 수도 있음

프로젝트 스토리 (진짜 중요)
- 프로젝트 스토리가 없다면 -> 면접관이 할 질문이 없으므로 기술적인 질문을 많이 받게 됨 -> 그럼 99퍼 떨어짐
Why?라는 서사가 중요함
- 스토리라는 것은 결국 왜? -> 이러한 문제에 봉착 -> 이렇게 해서 해결 -> 뭘 깨달음임
- 굳이 기술적인 부분이 아니라 협업에 대한 부분이어도 괜찮음
  - CI/CD 자동 배포도 면접관이 좋아함
~~개발자는 자소서 잘 안 봄..!~~
- 스토리는 이력서에 녹여야 함
  - 당연하지만 1쪽에서 2쪽 정도로 짧게 자신 있는(재밌는) 부분만

알고리즘은 절대 포기하지 말아야 됨
- 알고리즘을 포기하는 것만으로도 선택지는 엄청 좁아짐
알고리즘은 천재가 아닌 이상 당연히 이해도 안 되고 어려울 수밖에 없음
- 30분 풀고 답을 보는 건 괜찮음
  - 하지만 답을 보더라도 확실하게 이해하고 넘어가야 함
    - 답을 다시 안 보고 똑같이 풀 수 있을 정도로
  - 그 후 비슷한 문제를 풀면서 감을 확실하게 익혀나가야 함