스몰토크
- 순요님
- 8주차 vue 과제를 제출하겠다.. 😬
- 주영님 딥다이브 발표 너무 잘들었어요~😁
(주영) 실무에서 코딩 컨벤션을 얼마나 강도높게 지키는지?
- 네이밍 규칙만 지키고, 변수명은 잘 읽히면 자유롭게 사용하자
- ex) list인 경우, s를 붙이거나 뒤에 list를 붙일 수 있는데..
- 컴포넌트 선언을 화살표 혹은 함수 선언?
- (멘토님) 엄청난 strict 룰러이다..
- 코드의 일관성을 굉장히 중요하게 여긴다.
- eslint를 가져올 때 사용하는 옵션 하나하나를 다 본다.
- rule 자체는 에러가 아니면 의미가 없다고 생각한다.
- warning은 필수가 아닌 것들 (상황에 따라 생략할 수 있는 부분) 이고, 95%는 에러이다.
- 다른 사람과 함께 사용하지 못한다.. 다른 사람들 광광 울거다…
- 프로젝트도 인간이 추론할 수 있도록 만들어야한다고 생각한다.
- 어떤 컴포넌트를 수정한다고 할 때, 바로 이 친구도 수정해야겠는걸? 라는 생각이 바로 떠오를 수 있도록 만드는 것을 선호한다.
- 하지만 이런 것들을 선호하는, 지향하는 사람들이 모여있는 경우에만 하면 된다.
- 이런 것들까지 감당할 정도의 실력이 안되는 경우가 있을 수 있다.
- but.. 내 한계를 뛰어넘으려 도전하지 않는 사람은 성장할 수 없다.
- 구조적인 것들을 고민해본적이 없는 사람이 좋은 구조를 만들 수 없다.
- 이런 경우, ‘어디까지 rule로써 통용할건지 효율을 따져야한다.’
- 위의 list 예시의 경우, 비용은 높은데 효율은 없는 rule이다.
- react 컴포넌트 함수 정의 스타일의 경우, 효율이 높은 작업이라고 할 수 있다.
- 팀원들의 성향( 코드 결과물에 대한 욕심..), 수준을 고려해서 rule을 정해라.
- 팀원들의 최소 과반수가 감당할 수 있어야 기술, 문화가 자리잡을 수 있다.
- 출근해서 이런 작업들을 했다.
- python package manager - poetry
- git hook(local), github actions(push 시) 수행되도록 자동화 작업했음!
- 욕심이 있다면, 자동화도 도전해보길 바란다!
- 실제 자주 사용될 스타일들을 중점적으로 잡아라!
- interface? type alias?
- 컴포넌트 정의 방식
- 폴더 구조
- 나중에 하다보다 이거 통용하면 더 좋을 것 같다 의견을 내서 rule을 추가해도 좋다!
- react는 너무 규칙이 없어서, 오히려 너무 스타일이 다른 코드들이 나올 확률이 많다.
- 그래서 vue로 넘어가는 회사들(특히 스타트업)이 많다.
- next, remix를 쓰면 라우팅 처리를 안해도 된다는 큰 장점이 있다. 다이나믹 라우팅은 정말 편하다! 다만.. react라는건 변하지 않는다.. 코드 스타일이 어디로 가는거 아니다…ㅋ
로그에 관하여
- 데이터 택소노미
- mau, daily page 방문 등의 지표들을 알아내기 위해 페이지를 언제 방문했고 떠났는지 체류시간 등을 알 수 있게 구조를 잡아야 한다.
- 로그는 기록이다.
- 어떤 것들을 기록할건지 등을 파악할 수 있는 구조를 잡는다.
- 로그는 항상 목표가 있어야 하고, 그래야 분석할 수 있다.
- ex
- 프론트 입장에서는 마우스 움직이는 위치를 어디에 가장 많이 머물렀는지 등..
- hotjar (행동 기반 분석도구)
- google analytics / Amplitude
- 마우스 이벤트, 클릭 이벤트 발생 등
- 백엔드 입장에서는 구매 전환율 등의 목적을 위해 로그를 쌓는다.