[Week3] 멘토링

DB 고민

• 인덱싱을 걸어주는 것이 어떨까.
• 확장성을 너무 고려하지는 말고, 일단은 보편적인 케이스를 생각해서 적용하는 편이 더 좋아보임.
  • 지금은 각 워크스페이스 각각에 Object 테이블을 두기 보다는, 하나의 Table에 모든 워크스페이스의 객체를 넣어두고, 인덱싱을 해서 최적화하는 것이 더 좋아보인다.
• 만약 어떤 이유로 특정 서비스를 위해 다른 DBMS 사용을 고려한다면, 현업에서는 DBMS를 여럿 쓰는 것이 흔한 일이기에 여러개를 한꺼번에 쓰는 것도 고려할 것.
  • 대신 설정에서 권한 관리를 잘 해주어야 한다.
• MongoDB는 인덱싱을 알아서 해준다고 알고 있음.
• 실시간 수정으로 DB에 꽂을 때는 NoSQL을 사용하는 것이 더 적절할 것이다.

만약 실시간으로 모든 입력을 서버에게 넘기면 힘들까?

• 디바운싱과 스로틀링을 생각해보자.
• 실시간으로 사용자가 타이핑하는 것을 서버에게 바로 넘기면 서버 뿐만 아니라 브라우저도 힘들어할 것이다.

전역 상태로 관리하기 위한 기준은?

• 전역상태 관리 기준은 개발자보다 각기 다름.
• 부모가 자식에게 전달할 경우는 그냥 주곤 하는데,
• 드릴링을 2번 이상 하게될 경우 그냥 전역 상태로 넘기는 편임.
• 자식이 부모의 값을 바꾸거나, 형제의 값을 바꿔야하는 경우, 전역 상태로 빼는 것이 좋음. (함수형 프로그래밍에 어긋나는 상황임.)
• Context API의 측면에서 형제의 값을 변경하는 경우 전역으로 두는 경우보다 퍼포먼스가 느려짐.
  • 42%의 차이가 남. (6.8ms의 차이긴 함. 어라…?)
• 전역변수가 많으면 오히려 안좋음. 적당히 빼는 것이 좋음.

빨리 배포해보자.

• 최대한 빨리 제작해보고, 캠퍼들에게 뿌리자.
• 한번 뿌릴 때 구글 폼으로 한번 조사해보자.

GitFlow 전략에서 Release는?

• 버전관리 측면에서는 유용하게 쓰이긴 함.
• 근데 굳이 필요할까…? (PR 하나 더 늘어나는 느낌임.)

서버 인스턴스를 따로 뺴주는 것이 좋을까?

• 백업 DB의 역할밖에 안됨. 지금 상황에서는 그다지 도움은 안될 것임.
• 커를 쓰면 Nest와 Redis와 MySQL를 Container로 말아서 각자 띄우는 것이 가능함.

인턴십?

• 보이저X (추천), 당근 → 인턴들에게 실제로 프로젝트를 줌.
• 학생 신분이라면 인턴을 많이 해보는 것이 좋음.
• 학생 신분으로 학교에서 뽑아먹을 수 있는 것들을 최대한 많이 해보는 걸 추천한다.
• 정직원 채용은 학생 신분으로는 많이 힘듦. (애초에 회사에서 거부할 수도.)

이력서

• 이력서를 쓴다는 것은 한번씩 자신의 성과를 정리하는 것.
• 미래의 자신의 연봉을 위해, 자신이 한 일을 정리하기 위해.
• 만약 이력서를 작성한다면 순서와 문구, 포맷을 잘 조절하는 것이 좋음.