11월 18일 (마스터 클래스, 금) - boostcampwm-2022/web33-Mildo GitHub Wiki
1교시
개발 환경이 달라서 문제가 생겼음 -> 통일을 시켜주어야 했음 (예시: CRLF 문제)
백엔드에서 단순한 CRUD -> unit test가 의미가 있나? e2e가 낫지 않나?
Docker vs 인스턴스 → 여러 가지 요인이 존재한다.
매년 리팩토링하면 좋을텐데.. 현실은 다르다 → 인프라 파편화가 되면 더 힘들어진다..
https로 설정을 해보자
합성 컴포넌트 관련 디자인 패턴 (범용 컴포넌트 / 비즈니스 컴포넌트의 분리) → 같은 관심사/디자인이나 약간씩 다른 상황에서 UI 재사용을 어떻게 하면 좋을까? → 같은 관심사인 것밖에 없는 경우에는 합성이 될 필요는 없다. 피드백박스 내부에서 지역적으로 컴포넌트를 가져가면 어떨까..
UI는 비슷하지만 관심사는 완전히 다를 때 관심사를 얼마나 더 분리할 수 있을까? 라는 생각을 가졌으면 좋겠다. 예를 들어, 비디오 재생시간에 맞춰서 피드백을 받기로 할 때, 피드백 리스트라는 ‘state’를 굳이 커스텀 훅을 통해서 parents에서 내려주어야 하는 지에 대해 고민을 해보자. → 조은 마스터님이라면, 관심사를 좀 더 잘 쪼갤 수 있을 것 같다
props drilling을 막고, 의도적으로 super 컴포넌트를 없애고자 노력을 해보자. (Recoil을 쓰고 있는데 왜 super 컴포넌트로 갔었지?) → 우리 팀도 jotai를 사용하고 있는데 명심하자
커스텀 훅을 만들려는 이유 → 관심사가 같은 경우 이를 묶기 위해서!
2교시
cherrypick? rebase(이것 깃허브 관련 내용)? 이게 뭔지 좀 봐야겠다.
지금은 계속 작업하면서 진행하고 있는 상황 → 그냥 계속 PR 집어넣자.. TODO
처음 짤 때부터 막 이러지는 않음.. 예를 들면 버튼 만들자마자 이건 무조건 재사용해야지… → 일단 다 때려박고, 추상화가 되어야 하겠다고 감이 올때쯤이면 그 때 리팩토링을 진행한다.
관심사 분리의 기준 → 데이터 분리를 어떻게 해야 되는가? → 중앙 상태관리는 편리하지만, 관심사 분리가 잘 되지 않는다는 단점이 존재한다.
처음부터 이것저것 고민하면 제품이 안나온다. 일단 제품이 나온 다음에 리팩토링을 진행하면 된다. 회사에서 진행되는 코드들 되게 이쁠거 같지? 아찔해… → 이건 일정이 급해질수록 이렇게 된다..
일정을 ‘시간’ 단위로 잡으면, 보통 그렇게 안된다.. → 오늘까지 / 내일까지
내가 직접 로그인 / 회원가입을 구현할 정도의 회사라면 대충 쿠키 쓰는 경우가 더 많다 → OAuth를 아는 것이 정말 도움이 될까? 어차피 로그인 구현 직접 안할 수도 있는데?
id/password → 이 작은 서비스를 만드는 회사에? DB 털릴 수 있다. → ‘소셜 로그인’ 붙여서 사용하자
Debounce와 Throttling에 대해서 설명해 주세요! → 보통 써봤으니까 질문을 한다 → 그런데 외우려고 하지 말고, 실제로 써본 경험과 사례에 대해서 이야기를 하자!! → 어 저는 이런 문제가 있었어서 이렇게 했더니 해결 되었다. 이런 개념으로 알고 있다 + 근거
기술 스택을 선택했을 때는 그 ‘이유’와 ‘근거’가 들어있어야 한다! → 남들도 써서요…. 이거 안됨!
잘 하는 사람이 이거 하자고 할 때, 근데 시간은 촉박할 때 빠르게 도달하기 위해서 기술을 선택했다고 말하는 것 정도는 좋음 → ‘자원’도 기술 선택의 근거가 될 수 있다. → 즉, 기술적인 부분 뿐만 아니라 여러 가지 상황과 환경을 고려한다.
이력서 볼 때 제일 중요한 것 → 프로젝트(뭐 했는지) → 면접을 보는 사람의 입장에서는 실력이 부족해서 탈락을 시켰다고 생각할 수 있다고 볼 수 있겠지만, 사실 여러 가지 변수가 존재한다. 낮은 연차여도 상관없다는 생각을 가지게 되었다. 또 면접관들의 성향에 따라서도 많이 달라질 수 있다. 따라서 운의 영역이 어느 정도 작용한다. 조직적인 환경에 따라 너무 다르다.
면접 봄 → 합격 → TO가 날라감 → 아찔하다.. (연봉 협상 과정 중에서도 합격하지 못하는 경우도 많음)