TIL 29

👊 내일부터 실전 프로젝트 시작 기대 반 걱정 반!!

집중도 1~5 (4.3)

'집중력의 깊이로 따지자면 평범했지만, 길이로 따지자면 현재 시작 03:45분 오늘 하루 한 번도 딴 짓 안 하고 해야 할 일이라고 생각한 일들을 했다. 오늘 팀 과제가 끝났고 어제 잠을 몇 시간 못 잤지만 내일 실전 프로젝트 시작이라 빨리 잘 수가 없었다.

항해 기간 중 마음 잘 맞는 사람을 만나서 '리더, 부리더' 로 팀을 꾸리기로 4주 전에 얘기 했었고 오늘 00:00 그 팀이 나왔다.

책임감이 아주 무겁다. 그걸 알고도 신청했다. 과연 그 책임감을 떠안고 6주 후에 어떤 결과를 가져 올까?'

6/22 수

---

기억할 것

1. !! 중요한 / 무한 스크롤, 검색, 카테고리 ( 아직도 안 해본 것들...) / ( 랜덤이 아닌 유저가 선호하는 거 위주로 보여주면 더 좋겠다. )

---

오늘 할 일

1. 오디오 이미지 이쁘게

2. 모달 보이는 거 이쁘게

3. 디테일 페이지 ( 이 안의 값은 좀 다름 )

---

고민, 궁금한 것

1. [ 문제 ] 캐시가 다른 페이지로 옮겨도 남아 있어서 그게 먼저 보여짐. useMutation을 이때 써야하는 게 아닐까?

   만약 노래 없는 페이지로 넘어갔을 때 또한 기존의 캐시에 의해 기존 노래가 보여짐. 이걸 어케 할지.. 고민중

   시간 너무 뺏겼다.

2. [ 문제 ] 각 디테일 페이지 마다 노래 바껴야 하는데 기존 캐시 값을 useMutation으로 업데이트 하는 법 모르....ㅠ

3. 우븐투란?

4. nextJs

5. ?? 리액트에서 불변성? ...state 그 부분 알아보기 !

6. ?? Button 컴포넌트 만들기에 대해서

7. ?? 리소스란?

---

...님 에게

1. [ 광민님 ] 제가 얘기할 때 어떤 느낌인지 궁금하다. 전 항상 좋은 , 친절한만 전해드리고 싶은데 내가 대화 할 때를 떠올리면 항상 그런 거 같지 않음을 느낀다.

---

아이디어

1. 우리 또한 벨로그처럼 업그레이드 하는 걸 목표로 한다.

2. 이번 버전, 다음 버전 이런 식.

3. 많게 보이거나 딥한 거를 해야한다. (그치만 딥한 것 한 두가지 선택하는 걸 추천 / 가장 중요한 것 자기가 할 것. )

   팀 분위기 좋게 할 것

   중간 중간 계속 계획 확인하고 앞으로 나아가자.

   디자이너 분들과 소통 !!!!!!!!

실전 프로젝트 시 필요한 것

1. [ 발제 요약본 ] 많게 보이거나 딥한 거를 해야한다. (그치만 딥한 것 한 두가지 선택하는 걸 추천 / 가장 중요한 것 자기가 할 것. )

   팀 분위기 좋게 할 것

   중간 중간 계속 계획 확인하고 앞으로 나아가자.

   디자이너 분들과 소통 !!!!!!!! ( 뭔가 정해지면 디자이너 분에게 빠르게 카톡이나 연락하자 )

   마케팅 비용 떼서 팀원들 모여서 치킨 먹어도 됌. ( 분위기가 아주 중요하니 )

   배포는 4주차( 마케팅이 진행되는 ) 초반에 되야함.!!!

   아이디어에 대한 컨펌도 있다!

////

1. 팀의 룰 정할 것. ( 팀의 좋은 룰을 가지고 움직이자! )

2. api 명세서

3. 매일 자신이 해야할 것. < 팀이 해야 할 것 / 프론트 목표 / 백의 목표 > 를 아침에 적고 시작하는 게 좋겠다.

   ( 그러한 페이지를 만들자. ) ( 매주, 그리고 매일 우리가 할 수 있는 정도를 체크 해나가며 3주, 마지막 6 주때의 미래를 그려 볼 수 있다. )

---

리더, 부리더

1. 결제 사업자등록 해야하는 걸로 암 그래서 아마 안 하는 게 좋음

2. 커뮤니티, 모임, 결제는 지양한다. ( 앞의 둘은 너무 단순함, 대신 뻔하지 않으면 된다. /

3. 사업성이 아니고 기술성 ( 보다 중요함, 딥하거나 ) < 여러가지 기술보다 한 두가지 기술을 깊게 파는 걸 추천한다. >

// 리더...

1. 테크니컬 서포트 해줘야함 ( 지금은 실력이 안 뛰어나도 책임감을 갖고 하기에 제일 열심히 하니까 제일 잘해질 것임 )

2. 가장 중요한 기능은 본인이 해라 ( 무조건 책임감 있게.

3. 팀의 분위기 메이커 ( 어차피 무조건 벽을 마주 할 것임 6~7번 / 분위기가 좋다면 벽 앞에서도 뚫고 넘어감! )

   ( 우리 같이 해보자 ! 이 분위기를 만들어야지 . 아 .. 또 이거네... 이 분위기면 안 된다 )

4. 우리 팀은 이렇게 하자는 룰을 정해주면 좋다.

5. 카리스마 있게 리더하는 건 별로 인 것 같다. ( 시니어 개발자가 아니라면 그러지 말아라 , 굉장히 많이 설득하고 북 돋아 주어라 )

6. 가장 중요한 건 태도이다. 리더 부리더의 태도가 아주 중요!!! 팀워크 !!! 팀워크!!! 나이스함!!! 아주 중요!!!!

7. 중간 발표회가 있다. 6주를 두 번 나눔 ( 3주, 3주 ) < 첫 3주는 이것만 있으면 굴러간다. 그 mvp를 집중해줄 것. >

8. 팀별로 우리 토요일까지 이거 하자!! 라고 했는데 분명 한 명씩 못 하는 사람이 생긴다. 그럴 때 토요일 이전에 화요일 한 번, 목요일 한 번 만나자가

   되야한다. < 그러지 않으면 상대방이 왜 자꾸 나를 쪼지 ? 이런 기분을 느낀다. 우리가 그런 분위기를 주지 않았다 하더래도 말이다. >

9. 디자이너 분은 오시면 자신이 외부인이다 라는 느낌을 받을 것임. ( 오버하면서 더 환영해주고 해주면 좋겠다. )

   디자이너 분과 소통은 프론트의 장과 해야 한다. ( 프론트 리더 or 부리더 분 )

   다른 분들이 디자이너 분과 산발적으로 대화를 하면 안 된다.

10. 디자이너 분이 css 할 줄 알아도 css 하면 안 되고 프론트가 디자인을 할 줄 알아도 하면 안 됨. ( 서로의 선을 지켜야 한다. )

11. 디자이너 분들은 항해 소속이 아니니, 우리와 다르게 목숨 걸고 하는 느낌이 아니다. 이해하자. ( 주 20-30 시간 정도 투자하시더라 )

12. 많게 보이거나 딥한 거를 해야한다. (그치만 딥한 것 한 두가지 선택하는 걸 추천 / 가장 중요한 것 자기가 할 것. )

    팀 분위기 좋게 할 것

    중간 중간 계속 계획 확인하고 앞으로 나아가자.

    디자이너 분들과 소통 !!!!!!!!

---

장희성 매니저님 말씀

1. 깃헙에 올릴 때 base 주소 , env 파일들 올리면 안 됨. ( gitnore에 무조건 넣고 올려야 하는 파일들이 있다. ) / 고민해볼 것

2. 위 처럼 하면 실전프로젝트 해킹 당하는 경우가 생김 ( api 키 다 올라가서 ) ( 무조건 gitnore을 미리 서로 간에 정해야함!!!!!!!)

//

3. 면접 때 코드를 잘 짰네 보다. 실전프로젝트를 하면서 그 날에 어떤 트러블 슈팅이 있었고 ( 백 / 프론트 ) 그걸 어떻게 해결 했는지에 대해서 매일 매일

   쓰면 아주 좋다!!!! 그리고 api 파일 올리지 말아야 하는데 올렸음

4. 컴포넌트 안에서 모든 걸 거의 해결 가능 / 리듀서 파일은 우리가 올렸으나 사용 안 했음 취지가 아주 좋았음!

5. !! 공부할 때 트러블 슈팅이 나면 계속 적자 / 트러블 슈팅을 해결 했으면 어떻게 해결 했는지도 매일 적을 것.

   ( 해야할것 이 메모장에 트러블 슈팅에 대한 칸을 만들자 !! )

   api 명세를 확실히 하고 erd를 작성하기 전에 기획을 미리 아주 정확하게 하는 게 이후에 프론트, 백엔드 의논하는 시간이 줄어들고 좋다.

6. 이윤님 처럼 파일을 하나 빼서 색상을 디자이너가 넘겨주면 바로 정리해서 토큰화 시켜서 사용하자 ! bgColor5 : 이런 식!

7. css 쉽지 않다. 일단 시간을 들여서 한 번 공부 해보는 게 좋다. 안 그러면 간단하게 할 수 있는 걸 자바스크립트를 써가면서 뒤로 돌아갈 수 있음

8. !! 전 기수들 깃헙 많이 참고해라 !! 우아한 테크도 실전프로젝트 있으니 그런 거 보고 구조를 어떻게 잡을지 도움이 많이 될 것이다 !!

---

예상기 매니저님 말씀

1. 와이어 프레임을 디자이너가 할지 우리가 할지 정한다. ( 와이어 프레임을 먼저 하려는 사람이 있을 수도 아닐 수도 있기에. )

   ( 프론트는 꼭 디자이너에게 그거 먼저 얘기해서 하는 게 좋다. )

2. 기획한 사람이 대략적인 와이어 프레임을 가지고 있어야 하지 않나 싶다! ( 대략 소개는 해야하지 않겠나? )

3. 프론트 역할분담은 기능별로 분담하셨나요 ? --> 네 기능 별로 했습니다.

4. 리덕스 모듈 별로 역할 분담할 것 그래야 컴플릭이 안 난다.

5. 메인이면 상세페이지 가져가고 , 로그인이면 회원가입 같이 가져가고 그런 식으로 ( 기능 별로 유사한 것들을 묶어서 했다. )

   채팅이면 채팅의 소켓을 다 가져 오고

6. !!!! 서로의 코드는 절대 건드리지 않겠다는 약속을 지키는 게 좋다. 안 그럼 오류남

7. !! 엘리먼트 컴포넌트 , 버튼 컴포넌트 같은 거 한 사람이 다 만들어두면 됨. ( 그럼 머지할 때마다 컴플릭 안 나고 버튼이 자동으로 바뀜 )

8. 예상기 매니저님 이전 실전프로젝트를 보자 . ( 기여도 또한 나온다. )

9. !! 자기 전에 내일을 위한 CRA 완성하고 자자. and 와이어프레임

10. !! rafce 로 일단 판을 짜고 시작하는 거임 button ( 그 안에서 버튼을 담당하는 사람이 정해져야함. ) / 녹화 5분 부분 부터 따라 만들어 두자.

11. !! 10번을 처음에 안 하면 버튼이 10개가 생긴다. 무조건 계속 쓰는 것들은 button 같은 건 컴포넌트 만들어서 Button으로 가져와서 쓴다.

12. !!?? 8분 button 컴포넌트의 엘리먼트 관리는 한 명이 했다고 함. ( 컴포넌트의 엘리먼트 속에 그런 걸 넣으면 뭐가 어찌 바뀌는 거지..? )

13. !! 하면서 스택 어떤 걸 쓸지 정하는 게 좋다! 리덕스를 쓸 거냐, 쿼리를 쓸거냐 , 타입스크립트를 쓸거냐?

14. !! mvp가 나올 떄까지 화면을 못 봤다. ( mvp가 뭔가? )

15. !! 전체회의 하고, 프론트와 디자이너의 회의를 해야함 , 그 다음 프론트끼리 회의도 해야 한다. ( 프론트는 회의를 항상 3번 해야함 )

16. !! 기획서와 와이어프레임을 보고 디자이너가 해주는 것.... 하... 완전 큰일인데? 디자이너는 그 틀 안의 별이나, 등등 모양을 정해주는 것.

    그것의 전권이 이제 디자이너에게 생기는 것. 대신 피드백을 해야한다.

17. !! 매니저님은 디자인에 대한 태클은 안 했고 프론트로 구현하기 힘든 것만 태클을 거셨다고 함.

18. !! 디자이너분들이 폰트, 아이콘, 색깔 다 만들어주고 정해쥼. 제목은 어떤 폰트 쓰고 내용은 어떤 폰트 쓰고 등 그런 것까지.

19. !! 매니저님은 피그마로 소통을 하셨다. ( 피그마에 어떤 디자인 한 것 위에 글 쓰고 거기에 디자이너분들 답변 달아주시고 등 )

20. !! 디자이너님 카드에서 500자가 되면 어떡하죠? 글이 계속 늘어나면서 카드가 커지게 하는 건가? ( 프론트는 동적으로 생각해야함 . 100글자면 어떻게 하고 1000글자면 어떻게 할 건지 )

21. !! 버튼, 폼 등 또한 피그마에 다 미리 정해둔다. 디자이너 분은 간단한 보이는 인풋만 만드심, 그럼 우리는 올렸을 때 글씨 썼을 때는 어떻게 해야할지에 대해서 여러 상황에 따른 디자인을 하셔야 한다고 보여줘야함.

( 꼮 !!!!!!! 예상기 매니저님꺼의 피그마를 꼭 보자 흐름이 보인다. !!!!!!!!)

22. !! 디자이너에게 컴포넌트를 받아야함 !!! (button, input 등... dropdown 등....) 항상 넓게 봐야한다. 뭐가 많아졌을 떈 어떻게 보여야 할까 등 멀리 멀리 생각 해야함...

23. !! 다들 라이브러리를 막 쓰시니까 도움이 되기 힘들었다ㅏ.

//

24. 신입을 뽑는다고 했을 때 블로그를 운영하면 확실히 플러스가 많이 됌! 신입은 거의 비슷하므로 내가 지금 공부하고 쓰는 formdata ! 이런 걸 따로 어는 곳에 모아두자

25. github yurim45 매니저님 아시는 분꺼 꼭 봐볼 것.

26. 리액트를 다루는 기술이라는 책 진짜 아주 좋음 ! 꼮 살 것.

27. 타입스크립트는 인프런에서 제로초꺼 봤음 ( 리액트 타입스크립트가 있고, 그냥 타입스크립트가 있음 < 결국 둘다 알아야함...>

28. 리액트에 타입스크립트 적용하기 - 리액트 타입스크립트 < 제로초 인프런 강의 >

29. 타입스크립트를 꼭 해라.... ( 자바스크립트의 상위개념이 아님. 그냥 같이 해라 ) 적응하면 자바스크립트가 불편해서 안 쓰게 됌.

30. 타입스크립트 다른 언어가 아닌 자바스크립트에 하나의 라이브러리가 추가 된 느낌.

31. !! react-number-format 라이브러리 ( input을 다루는 것 . )

    실전 때 부트스트랩 이런 거 제외하고 좋은 라이브러리 많으니 재밌게 사용하라

32. !! lootieFiles 라이브러리도 좋다 ! ( 동적인 이모티콘들, 에어비엔비가 만듬... ! ) 활용해라!! 로딩중에 쓰면 좋겠다.

33. !! react- hook - form 이건 워낙 유명..!

34. !! lottie-react 등 npm 사이트에 떙땡 react 치면 다 나옴.

35. 나중에 이미지 쓸 때 svg라는 파일명으로 써야함 아니면 확대 했을 떄 화면 깨짐 아주 중요한 디테일 !!

36. 드래그 는 라이브러리없이 너무어려워보이던뎀

37. 라이브러리 안 쓰면 좋은 게 용량이 적어지니 좋은 것. ( 그럼 용량 최적화는 어떻게 보면 좋냐? )

38. !! 크롬에 Lighthouse 검사 안의 이걸로 우리가 만든 페이지의 용량 등의 몇점인지 보여준다. 최적화. 등 프론트 하시는 분들 다 이걸로 돌린다고 함.

    < lighthouse 점수 높이는 법 구글에 쳐서 알아볼 것 ! 프로젝트 제출할 때 저걸로 검사해서 점수 보는 회사가 많다고 함 !!!!!!!!!>

39. !!?? 불변성 유지를 해야함 immer가 좋다함 / 불변성 유지를 왜 하는 건가??? / ...state 이거 왜 하냐?

40. !! useMemo도 이제 써야함 / 최적화 관련된 것... / 주니어와 최적화랑 어울리지 않는 말이긴 함..

41. !! 최적화는 문제가 없으면 할 필요가 없다고, 시니어가 말한다고 함. 우리께 무겁지 않으면 굳이..? 생각 한 번 고민 좀 / 예상기 매니저님도 아직 그리 고민하고 있지 않다함 .

42. !!!! 1시간 40분 부분에 써 있는 코드의 의미 전부 다 이해 할 것. title의 의미는? 그 부분 state 얘기 아주 중요 < useMemo 언제 쓰는지 강의 >

43. !!!! state 변경시 렌더링 계속 됨 ( 부모 컴포넌트가 렌더링하면 자식도 렌더링함 )

44. !!!! 1시간 50분 부분 console.log로 자식이 재랜더링이 되는지 안 되는지 확인한다 !! 꿀팁 !!

45. !!!! 그럼 element같은거 만들어놓은데 변함이 없는/ 말단 놈들 애들이면 react.memo를 쓰면되나용? < 그렇다고 함 !! 아주 꿀팁 >

46. !!!! useCallback 강의 1:51:00 부분 우리가 props를 함수로 넘길 떄가 있음 그때... 이어서 영상 보기 대박!!! ( 함수를 프랍스로 내려줬을 때 useCallback 씌어서 보내주면 한 번만 작용 함 )

47. !! 리액트 memo를 쓰는데 변동이 있어 그러면 그건 프롭스를 함수로 내려줬을 가능성이 높음 그럼 그 함수는 useCallback 씌어서 프랍스로 보내면 useMemo의 역할 처럼 한 번만 작용함

    useMemo는 변수에 씌우는 것 / useCallback은 함수에 씌우는 것 재랜더링 안 되는 것을 막기 위한 것 ( 한 번만 돌아가면 되는 것들 )

48. !! 1시간 58분 부분 또 보기....! 어렵 useMemo 단 ! props에 변동이 없을 때....... useMemo는 역효과 날 수 있다고 들었는데 콜백이나 React.memo도 쓰면 안좋은 상황도 있나요? 이거에 대한 내용도 있음

49. !! mvp 다 완성되고 lighthouse 찍어 본 후 마지막에 useMemo, useCallback으로 바꿔라 그게 아닌 처음부터 그러면 곤란하다.

50. !! 새로운 영상부터 useQuery에 대한 내용 !

51. !! mock API 안 만들고 리액트 js인가? 써서 그 API랑 소통하면서 했다고 들음 맞나요? mock 서버를 굳이 만들 필요없는 게?

52. !! input 쓸 때 꼭 form으로 감싸주세요 그래야 enter 쳐서 로그인이 됩니다.!!!

53. !! useQuery는 get 요청만 !!

54. !! hookform도 devtool이 있다 !

55. !! 리덕스 하면 무조건 리덕스 뎁툴 사용할 것 / 그러면 오류 찾기가 쉽다.

---

우리 프로젝트

0. 회의 1주

0-1. 블로그들 다 모아서 대충 머리로 원하는 페이지 각 페이지 당 형태 생각해야함.

0-2. 다들 라이브러리를 막 쓰시니까 도움이 되기 힘들었다. 아 그러고 보니 라이브러리로 대충 턱턱 만들면 되겠구나

0-3. 깃헙이 있으므로 자유도를 줘야겠구나... 오픈소스 형식으로 가는 게 맞는 듯...

0-4. 블로그가 너무 많다. 너무 많아서 우리 것도 플러스로 쓰는 느낌을 쓰게 만드는 이유를 만들어야함..

0-5. 우리가 이게 끝나고 지속 가능한 무언가를 했으면 한다. 근데 다른 아이디어들은 이걸로써 끝날 것 같다. 각자의 아이디어, 흥미가 다르니.

0-6. react - jouride 튜토리얼 만들 수 있는 라이브러리임. !

0-7. 서비스 만들면 제일 많이 들어오는 말이 어렵다! 너희가 만든 거 어케 쓰는지 모르겠따

0-8. 실전프로젝트 하신 분들 package에 어떤 라이브러리 쓰는 지 꼭 볼 것 !

0-9.

//

0-5. 깃헙에 그냥 올리기가 아닌 코드 올리고 오늘 뭐 했고 뭐 썼는지 정리... 다음에 그걸 또 사용 할 수 있으니.

0-6. 아 트러블 슈팅 존을 내 블로그에 만들면 좋겠다 TIL 처럼 트러블 슈팅1, 2 매일의 TIL

0-7. 여기 저기 강의 사이트 가서 내 프로젝트에 쓰일 것들을 찾아서 강의를 사자 !!!! ( 지름길이겠다. !! 노마드 코코아 무조건 !!

0-8. 리액트 js 중급 클래스

0-9. 프론트 통일해서 하는 게 좋다 !!!

< 유데미, 노머드 , 인프런

================

1. 실시간 채팅 ( 화상 채팅 + 대화 )

===========

트러블 슈팅 틀

1.무슨 문제

2. 해결

//

1.개인 계획 1일

2.팀( 프론트 / 백 ) 1주 계획

3.전체 팀 1주 단위