-
Notifications
You must be signed in to change notification settings - Fork 1
1주차 멘토링
멘토링 이후 결론과 챙길 것을 정리하여 업데이트합니다.
- [ ]
- [ ]
- [ ]
- [ ]
- [ ]
멘토링 24시간 전에 준비하여 멘토에게 공유합니다.
- eslint로 코드 스타일을 다 같이 통일 하려고 하는데 ‘이런건 이야기 해보면 좋을 것 같다’ 하는 팁이 있을까요?
- 기획이 어떤지 바로가기
- 게임처럼 하기 위해서 아이템 관련 기능을 추가하고 친구와의 대결 기능을 추가해보았는데 이외에도 추가해보면 좋을 기능이 있을까요?
- 소프트웨어 아키텍쳐 디자인 괜찮은가요? 바로가기
- 기술적 목표를 세워봤는데 추가적으로 시도해보면 좋을 기술적 목표가 있을까요? 바로가기
- 현재 사용하는 devOps(slack, git, github action ) 이외에 사용해보면 좋을 devOps 추천해주실 수 있을까요? 바로가기
- 프로덕트 백로그 바로가기
- 지금 봐도 다 못할 것 같은데 안될 것 같은 기능은 지금부터 확실히 없애고 될 것 같은 기능만 남겨놔야 할까요?
- 소켓 통신할 때 주의해야할 부분이 있을까요?
- 피그마 디자인은 어떻게 진행하셨었나요?
- 프론트엔드 테스트코드에 대해 어떻게 생각하시나요?
- tdd에 대해 어떻게 생각하시나요?
- 굳이 tdd를 하지 않고 꾸준한 테스트 코드 작성만 해도 괜찮을지 궁금합니다.
- TS 처음 써봐서 걱정이 되는데 학습 팁이나 좋은 자료가 있을까요?
- 주식 차트를 그리는데 chart.js 라는 도구가 있는데 이런 도구를 사용하는게 좋을지 직접 구현하는 방식이 좋을지 고민됩니다.
- 주식 테이블이 주가 변화할 때마다 업데이트 되기 때문에 관리할 때 어려움이 있을 것 같은데, 대용량 데이터 관리에 있어서 팁이 있을까요?
- DB 설계와 관련해서…
- 사용하게 된다면… Redis는 어떤 상황에서 사용하는 것이 좋을까요?
멘토링을 진행하며 나눈 이야기가 휘발되지 않게 기록해보세요.
- lint 같은건 개인 취향, 누군가는 불편하다 or 괜찮다 하는 부분이 다 다를 것
- option을 많이 넣어서 써보긴 했는지?
- eslint 규칙? 우아한 형제들이었는지, 그런데서 나온 걸 가져와서 이용해본 경험이 있음(진명님)
- 취향을 타기 때문에 기존에 사용했던 게 있으면 같이 써보고, 막상 써보면 생산성이 저해가 될 수 있는 애들도 있음. (에어비엔비 같은거 적용해놓고 하나씩 빼 본 적이 있음..)
- 순서가 바뀌어서 에러나는 경우도 존재
- 쓰다가 너무 불편하거나 하면 빼도 되니까 잘 논의하면서 빼고 넣고 하면서 써보기
- lint 옵션 뭐가 있는지 정확히 알 필요는 없지만 한번쯤은 읽어보는 것도 괜찮음.
- 깃모지와 비슷한 느낌?? 깃모지보다는 조금 낫긴 하지만 호불호가 갈려서 은근 불편할 수는 있다는 점.
- 랭킹
-
주간, 월간 랭킹을 해도 되는데 텀을 짧게짧게 가져가야해서 추가 기능으로 넣는 것이 좋을듯
(Priority를 낮추는 것도 좋을 것 같다.)
- 주간은 랭킹 5번, 월간은 1번밖에 못하니까.. 추가 기능으로 넘기자는 뜻. 당장은 급하지 않는 기능이다. (아이디어 자체는 괜찮, 프로젝트 기간이 짧은거 특성상)
-
- 주식 아이디어에 대해서..
- 주식에 대한 공부가 필요..
-
주식 공부에 대한 열정을 높게 살 것 같다.
- 문서 보면서 했다고 했더니 문서 진짜로 보면서 했는지 확인해보는 그런 면접 질문도 나왔었음.
- 수학 관련된 기술을 코드로 표현하는 과정이 필요할 것. 잘 구현해보자
-
주식 공부에 대한 열정을 높게 살 것 같다.
- 차트 등 다양한 정보를 담은 걸 넣으면 좋을 것 같음. 완성도를 위해서
- 여러 추세선과 같은 것
- 단순히 막대그래프만 나타내는게 아닌 것!
- 주식에 관심을 갖고 구현한 정도에 따라 완성도가 많이 갈릴 듯 하다.
- 실제로 반영되게 할 수는 없을까? 하는 아이디어
- 일주일 전 데이터를 불러와서 주가에 영향을 줄 수 있는지 등….
- 금액이 많아지면(1억원어치, 10억원어치 등…) 당연히 영향을 줄 수 있는건데 게임 내에서는 영향을 주지 못하니까.. 고려가 된다면 고려해보는 것도 괜찮을 것 같다
- 주식으로 대결은 어떤 방식으로 하는가?
- 초기에는 대결이 시작한 시점부터 끝나는 시점까지 수익률이나, 금액 등을 가지고 하려고 했으나 대결 시작 전 가지고 있는 자산 등에 영향을 미칠 수 있다고 생각해서 변경.
- 특정 회사를 골라서 거기에 대한 수익률로 비교하는 방식
- 그렇다면 대결 머니를 지급해서 그 돈으로만 할 수 있게 해보는 방식은 어떨까?
- 주식에 대한 공부가 필요..
- 비기능적 요구사항?
- 암호화 BE에서 신경 많이 쓰고
- 모듈화 진짜 어려울테니 잘 고민해보자!
- 여유가 된다면 반응형까지 고려해보기
- 데이터는 무조건 데이터가 많을 때로 고려해보기. 주식 같은 경우 웬만한 구조를 버티지 못할 거 같으니 부하 테스트 많이 해보는 것도 괜찮을듯.
- 아이템은 부가기능이니, 여건이 안된다면 배제하는 것도 괜찮다. 아이디어 자체는 괜찮
- priority 다시 생각해보기 ⭐⭐⭐⭐
- 주식에 대한 완성도를 올릴 건지 게임을 위한 부가 기능에 집중할 것인지
- (멘토님 개인생각) 완성도를 올릴 것을 추천하긴 함. 아이템 부가기능보다 반응형 웹을 생각해보는 것도 괜찮은 선택이 될 지도
⇒ 재미는 있을 것 같지만, 테트리스 하는데만 2주가 걸려서 기간 판단을 잘 해봐야 할 듯. 웹 소켓 관련해서… 이벤트 주고 받는 개념 자체가 있던 상태로 해서 수월했지만 그런게 아니라면! 판단을 더 잘해보자.
⇒ 진짜 필수기능을 더 나눠가지고, 더 확실하게 해보자. . 우선순위 나눈 대로 진행해보되 아까 기획 관련 피드백 준거로 우선순위 조금은 다시 생각해보기!
⇒ 추가는 애매, 지금 있는 것도 적지 않다. // 담당자 정하는 건 도메인 별로 나누는 것도 괜찮.
- 괜찮은데!! 부하를 가해보면 아주 높은 확률로 터질 것이다. 이거에 대한 고민을 해야 한다. 서버를 아마 여러 개 띄워야 한다.
- 사람이 얼마 없으니까 서버 한 대로 해도 되긴 하겠지만~ 여러 개 할 때는 어떻게 할 건지도 고민해보기. (예상 가능한 구조 잡아보기) 그런 관련 기능을 NCloud에서 지원해줄테니까.. (로드 밸런서 같은거) 고민해보면 좋을 것 같다. // 발전 시켜서 할 수 있는 버전 고민해보기.
- 적어도 두대 정도 띄워보는 걸 추천 (멘토님은 pim2 두개 띄워서 했음, 웹소켓 신경 써보려고)
⇒ 지금은 너무 무난한! 사이드 프로젝트용 구조다.
-
FE
- 최적화가 정말 중요할 것 같음.
- 정말로 부드러운지, 버벅임이 조금 있는지.. 등등
- 상태 관리가 빡셀 수 있다. 얼마나 깔끔하게 설계하느냐가 중요할 듯
⇒ 라이트하우스 다 찍어보고 (개발자 도구에 Lighthouse 있음, 퍼포먼스 측정 도구 / 반응형 고려할 거면 모바일로도 꼭 측정해보기) 나오는 개선사항을 다 개선해보는 것도 좋을 것 같다. 빌드 개념 등 다양한 개념도 같이 익혀보기. 100점 찍기는 어렵지만~ 상향 시켜보는 방향으로 해보기!
과정을 다 기록하기(초기에 몇점이었는데 어떤 거 개선해서 몇점까지 올렸다~)
-
BE
- 아까 말했던 대용량 처리! 부하테스트는 꼭 해보기
-
common
- 문서화는 커먼에 넣어도 되는데 다른 CI/CD 이런건 인프라로 빼도 될듯!
- slack, git, github action 슬랙봇 써서 pr 알림도 다 날라오게 하고 할 수 있으니까… 되게 무난함.
- 노션만 써서 할 수도는 있음~ (멘토님네 회사는 그렇다네요)
- 습관화 하는 것 필요!
- 회사에서도 개인이 직접 카드 옮기거나 하는 것처럼 해서.. 좀 귀찮지만~ 협업을 위해 적응한다고 생각하고 열심히 해보자!
- 못할 것 같은거 없앨 필요까진 없지만! 한번 걸러내는 것도 괜찮다.
- 일차로 무조건 여기까지 되어야 한다! 하는 애들은 판단하기.
- 대결 기능도 약간 부가 기능이라고 생각하긴 함.
- 일 통계 내는 기능(랭킹)이랑 주식 관련 기능(검색, 정보확인, 거래 등), 로그인은 필수인 것 같고, 이제 친구 추가 같은 거부터는 다 부가 기능 같다.
- 아이템은 75점까지는 아닐 것 같다. . . 근데 게임이 주제라서 어떻게 하면 게임을 잘 녹일 수 있을까?! 멘토님의 고민이었네요..ㅎㅎ
- 일단 6번까지는 무조건 하고!(멘토님이 느끼기에 메인 기능), 밑에는 부가로 생각해보자.
- 꿈을 펼치라고 말하고 싶지만~ 메인 기능은 다 해야 하는 건 맞으니.. 기능이 어느 정도 자리를 잡았다하면 추가 기능 붙이는거 무조건 좋다~
⇒ 지울 필요는 당연히 없고!! 우선순위 한번 더 생각해서 잘 정해보자
- 은근히 이벤트 관리가 어려움. 꼬이지 않게 하는게 중요하다.
- 소켓이라는게… (테트리스로 설명) 블럭 회전해서 좌표 하나하나 다 이벤트로 다 쏘고, 블럭 내려오는거 1초마다 하나씩 다 쏘고.. 그런 식으로 했음. 안꼬이게 하는 것만 해도 잘하는 거임
- 웹 소켓도 있지만 [socket.io](http://socket.io) 써도 됨! 구현하라고 말하고 싶지만 멘토님도 socket.io를 썼다고 하시네요~
- 소켓은 실시간이긴하나, 시간차로 갔을 때 어떻게 처리할 건지?? 이런 고민 해보는 것도 괜찮을 것 같다.
- 자료 찾아보기. toss나 우아콘 이런거 보면 소켓 관련 내용이 있던 것 같음. 관심 있으면 찾아보는 것도 좋을 것 같다. ⇒ 트랜잭션 이런 것도 필요할 것 같다. 잘 걸어야 하는데 이거는 토스 컨퍼런스에 있으니 한번 봐도 괜찮을 듯!
- 여러 컨퍼런스 찾아보면서 기술적인 내용이 있는 레퍼런스 찾아보는 게 좋음
Kafka 이런거 써볼만은 한데 .. 이 프로젝트에서 쓸 필요가 있나?? (멘토님 프로젝트) 메시지 할 때 썼던 것 같음
- 디자인 잘하는 사람이 있어서 그 사람이 해줬던 것 같다.
- 디자인은 요새 AI 툴도 있으니까~ 참고해보는 것도 좋을 것 같다!
- 디자인 가이드 만들고…
- 실제 증권 사이트 레퍼런스로 참고해서 해보는 것도 좋다!
- 여건이 되면 컴포넌트화해서 margin 이런거 주는 건 괜찮지만…. 시간은 없을 것 같음. 크기같은거는 4의 배수로 하는게 좋을듯(회사 디자이너분들이 이렇게 하신다네요// rem 기본 단위가 16px인데.. 이런거 생각해서 하는걸까요? 갑자기 궁금하네요.)
- 테스트 코드를 잘 안 짜는 편…
- 테스트 코드 때문에 개발이 늦어지거나 많은 고민은 하지 말자. → 양날의 검 느낌
- 신입에게 테스트 코드를 잘 기대하지 않을 수도 있음…! (얼마나 잘 짜겠어! 하는 사람도 있음)
- 어느 정도 기능이 나온 이후에 적용해보는 것도 괜찮을 것 같다.
- 아니면 진짜 불편함을 겪어서(배포 나갈 때마다/로직이 바뀌어서 자꾸 에러가 나서) 이래서 테스트 적용해본거면 괜찮을듯
- TDD 쉽지 않음.
- 백엔드는 핵심 로직에 대해서는(계산 로직) 작성해도 괜찮다! 그렇지만 덕지덕지 할 필요는 없다.
- 단위 테스트. 특정 모듈만 테스트 해보고 잘 되는 지 그런 식으로만 해도 괜찮다!
- 당장 엄청 많은 테스트를 해볼 필요는 없고, 코어 기능만 테스트 해봐라~
- 찍먹은 나쁘지 않지만 시간을 잡아먹히지 않았으면 좋겠다.
- 직접 써보면서 공부하는 타입이라… 따로 공부를 해보진 않음. 쓰다보면서 알게 된 케이스
- 이해가 안가더라도 조금씩 읽어보는게 좋다.
- 자바스크립트로만 개발하다보면 뭐가 터짐. 타입이 없어서 이유를 알 수 없다..ㅎㅎㅎ 진짜 불편함.
- api 응답이 왔는데 왜 터졌는지 전혀 모름..ㅎ
- 원인 알려면 하나씩 타고타고 들어가야해서… 타입이 있으면 무조건 좋은 거 같음.
- 타스를 잘 쓰기 위해서 많이 써보고 자료도 종종 보고… 그게 좋은 것 같음
- any/unknown 남발하지 않기. 언노운은 진짜 쓸 일 없고 애니도 웬만해서 쓰지 말자.
- 타입 너무 모르겠으면 질문해도 좋고, 생활 코딩 강의 봐도 좋다!
-
as
왜 지양??- 쓰면 타입스크립트 사용하는 의미가 없다! 이런 느낌이었음
- 이펙티브 타입스크립트 책인데.. 이유가 나올 것 같음
- 타입 단언하면 타입 체크 할 수 없음.
- 타입 선언으로 하면 객체 안에 필요한 name 같은 거 없으면 타입 체크로 에러 걸러주는데 타입 단언해버리면 name 없어도 오류 없다고 뜸! ⇒ 타입스크립트의 이점을 잃어버린 것
- 속성 추가할 때도 타입 선언은 없는거라고 추가 안된다고 에러 잡아주지만, 타입 단언은 그냥 봐주고 넘어감.
- 그럼에도 as를 써야 할 때가 있음
- 라이브러리 타입을 도저히 유추할 수 없는 경우 등…
- 타입 같은 경우에 무조건 다 붙여줄 필요는 없고 타입 추론 가능한 경우에는 생략해도 괜찮다~
- 예전의 멘토님이었으면 무조건 구현해보라했을 것 같다.
-
이 부분이 어려운데 이 라이브러리는 어떻게 구현했을까? 하면서 참고하면서 공부할 수도 있지만, 안 써가지고 일주일 붙잡고 있고 이러면 안된다!(팀 협업에 영향을 주면 쓰는 게 낫다.) 2, 3일만에 구현 가능하다하면 구현해봐도 좋을 것 같다. (구현력 기르는 이점은 얻어갈 수 있다.)
⇒ 마지노선을 잘 정해서, 하고 싶으면 해봐도 좋다~
⇒ 회사에서는 라이브러리를 잘 사용하지 않음. 내부에서만 쓰고(어드민) 디자인 라이브러리는 잘 사용하지 않음.(커스텀의 문제 때문에)
⇒ 우리가 나타내려는 디자인의 차트를 잘 구현해주는지 잘 알아보고 쓰면 될듯
⇒ chart.js 가 니즈 충족 너무 잘된다? 아니면 시간 상 문제 때문이다? 그런 것도 충분한 답변이 되기 때문에 잘 논의해보자~
-
라이브러리 쓰는 거 괜찮다. 내가 원하는 대로 예쁘게 커스텀되고 하면 써도 상관 없을 것 같다!
-
- 주가가 변할 때마다 정확히 어떻게 구현되어있는진 모르겠지만… 주가가 변하는 모든 걸 저장할 필요는 없고, 뭐 5분이다! 그런거면 그 5분에 대한 데이터만 저장하면 됨. 설계에 따라 달라질 것 같다. (매분, 매초는 DB에 저장할 필요 당연히 없다.)
- 데이터가 얼마나 쌓일 지 모르겠다, (주식 장이 열리는 6시간 30분 ⇒ 390분이니까.. 1분씩 저장한다치면 하루치가 390개인데.. 회사 10개 한다치면 3900개. 이러면 많은 편은 아니라 DB에 저장해도 되긴함)
- 1년에 한 회사당 14만개 정도(물론 주말이나 공휴일도 빼야 하긴함) * 상장 회사 약 2700건이니까 데이터 1년에 3.8억 정도. 이러면 괜찮을 수 있음 DB에 넣을만 한 것 같다. 엄청 많은 건 아니니까 DB에 넣어도 될 것 같다.
- 처음에는 유명한 기업 몇 개만 넣어도 될 것 같다. . 비용따라 갈릴 만한 내용
- 1분 단위 아니고 5분 단위로 해도 괜찮다! 이런 우리만의 제약 사항을 걸어도 괜찮다.
- Redis는 휘발성이니까, 날아가도 괜찮은 데이터를 넣어야 함! (로그인 세션 처리하면 필요)
- 서버가 여러 개 나뉘게 될 때 정보를 모아줄 하나의 공간으로 Redis를 많이 사용
- 랭킹 테이블
- 스케쥴러 돌려서 하루에 특정 시간에 랭킹 딱! 계산해서 정보 따다닥 올리는 그런거 만들어도 괜찮다.
- 게임 랭킹 시스템(메이플은 새벽 2시 업데이트인거 같더라고요.. 제가 해봐서 앎)도 스케쥴러로 돌아가는 것 같음. 그런 식으로 해보는 것도 좋다!
- 스케쥴러 돌려서 하루에 특정 시간에 랭킹 딱! 계산해서 정보 따다닥 올리는 그런거 만들어도 괜찮다.
- 채팅은 NoSql 써보는 거 좋음. MongoDB 같은거.. 로그성 데이터는 관계형 DB랑은 크게 안어울려서.. 채팅 같은건 따로 관리하자
- 데이터 베이스 여러 개 충분히 많이 씀!!
- 알림도 회사에서는 로그 썼던 것 같은데..
- 주문하고 거래하고 이런거 멘토님 생각으로는 NoSql에 넣을 것 같음. 한번 더 찾아보는게 좋을 것 같음. 로그성 데이터로 생각한다면 생각할 수 있는 부분이니까!!
⇒ RDB 써보고 좀 느린 거 같다? 이러면 NoSql 써보면 괜찮을 것 같다.
1주차 멘토링에서 이야기 나누면 좋을 주제입니다. 우리 팀의 상황은 어떤가요? 팀원 및 멘토와 함께 셀프 체크하고, 그 이유를 작성해보세요. 추가하고 싶은 항목이 있다면 직접 추가해도 좋습니다.
- 프로젝트 기획과 설계의 뼈대가 나왔다.
- 프로덕트 backlog가 제작되었다.
- 서비스 핵심 기능에 대한 완성도의 기준 또는 기술적 목표가 수립되었다.
- 현실성 있는 계획이 수립되었다.
- [FE] 프론트엔드 기술스택
- [FE] 라이브러리 없이 차트 구현 이유
- [FE] Canvas API 사용방법
- [FE] 네비게이션 바 애니메이션 구현
- [FE] Socket.io 사용방법
- [FE] Tanstack Router에 대하여...
- [FE] Intl(Internationalization) API
- [FE] React Suspense 적용
- [FE] 한글 입력 방식의 유연성을 높인 검색 시스템 구현하기
- [BE] 백엔드 기술 스택
- [BE] SSE vs Socket.io
- [BE] Redis를 도입하게 된 계기
- [BE] ACG Rule을 활용한 Secure CI CD 파이프라인 구현
- [BE] Nginx 로드밸런싱을 통해 한국 투자 API 소켓 제한 극복
- [BE] 주가 지수 기능 개발 과정
- [BE] 매수 및 매도 기능 개발 과정
- [BE] 실시간 자산 조회 기능 개발 과정
- [BE] 단위 테스트
- [BE] redis를 이용한 한국투자 Open API 세션 관리
- [BE] 데이터베이스 인덱싱
- [FE] React에서의 DOM 요소 접근 (useRef vs getElementById)
- [FE] Outlet을 활용한 공통 레이아웃 관리
- [FE] react hooks가 특정 조건에서 실행되면 안되는 이유 & useQuery에 query function 매개변수가 undefined일 수도 있을 때 어떻게 해결할까
- [FE] cross‐domain 로컬 환경에서 cookie로 인증 처리하기 with vite proxy
- [FE] 크롬&사파리 Composition 차이
- [FE] useEffect 의존성 배열
- [BE] Naver Cloud Platform HTTPS 무응답 현상
- [BE] 한국투자 Open API에서 access token을 발급받지 못하는 문제
- [BE] 한국투자 Open API와 웹소켓 연결이 되지 않던 문제
- [BE] 한국투자 Open API 웹소켓 연결이 중단되는 문제
- [BE] 같은 주식 주문이 동시에 여러 번 체결되는 문제
- [BE] 한국투자 Open API Websocket 세션을 두 개에서 한 개로 변경하기
- [BE] Nginx 로드 밸런싱 중 Socket bad Request 발생하는 현상
- [BE] 매수/매도 체결 로직에 의해 redis pub/sub이 정상적으로 동작하지 않는 문제