커피챗 질문

커피챗 질문 22/02/11

API 나오기 전, 뭘 하는 게 좋을까?

• 인증 로직

• 공통 api 모듈

프로젝트 3요소

• 일정이 제한

• 인력이 제한

• 금전적 제한

• 제한된 기간을 얼마나 잘 활용할 것인가?

• todo만 10 vs 내가 기획한 서비스(승)

• 클론 코딩 vs 기능 개선을 한 클론 코딩 (승)

리액트란?

React Hooks Vs. RxJS - React는 Fully Reactive할까?

약 1년간 전 회사에서 Angular로 개발을 하다가, 퇴사하고 나서 React로 넘어왔다. 보통 Angular는 프레임워크기 때문에 배우기 가장 어렵고, React는 그보다는 쉽다고 하던데 웬걸..React를 받아들이는 데 Angular보다 더 애먹었다. 기존에 갖고 있던 Angular에서의 사고방식과 충돌했던 것이다. 처음에 가장 이해가 안 갔던 건 Hooks를 통한 상태관리였다.

https://velog.io/@janeshin059/React-Hooks-Vs.-RxJS-React%EB%8A%94-Fully-Reactive%ED%95%A0%EA%B9%8C

패키지 매니저

• 얀 베리에 pnpm 적용?

• pnpm - 공통 스토어가 있다.

• 똑같은 라이브러리를 두 번 설치하지 않는다.

• 심볼릭 링크

• 윈도우에서는 못 씀 (심볼릭 링크가 안된다?)

• pnpm을 사용하는 이유에 대해서 공부하면 좋을듯?

• yarn vs npm 차이를 알고 사용하면 나중에 면접 질문으로 받아도 좋을듯

API가 나오기 전에 할 수 있는 일

• 공통적인 네트워크 API 모듈(axios 초기 설정 모델)에 대한 이야기를 해보면 좋을듯

• 인증 (유저 네임, 이메일, 패스워드) / 로직 검사부터 → API 통신 전까지
• 인증 기능은 모든 프젝에 들어가서 특징이 없다 → 하지만 다른 페이지 전체와 비슷한 노력이 필요하다.(보안, 인가, 페이지 정책과 같은 매우 난이도 높은 노력이 필요하다)
• 인증 기능 관련되서 깊이 파고 싶다. → 만약 그렇지 않다면 시간적인 여유가 없고 매리트가 없는 기능으로 보일 수 있다.

다른 다양한 린트는 설정했지만 커밋 린트도 설치해야 하나?

• 동영 멘토님은 커밋 린트를 디폴트로 사용한다. → 그렇지만 팀 프젝에서는 적용할 수 있는 사람이 있는 경우가 대다수일 경우에 사용한다. → 능률을 높이기 위해 사용하는 린트인데 다수가 사용할 수 없다면 사용하면 안된다.

• Feat, Fix, 등등의 커밋 스타일은 앵큘러에서 파생된 커밋 컨벤션이다!

커밋을 하는 기준이 무엇인가?

• 동영: 의미있는 변경(시점), 의미를 어디까지 가져가야하는지는 개발자 본인이 정해야 한다.

• 명재: 하나의 기능

• 혜준: 최소한의 작은 기능

커밋을 하는 이유

• 커밋을 왜 하세요? → 버전 관리르 하기 위해서 → 버전 관리 시스템은 무엇인가요? - 내가 나중에 찾아보기 위함(지금 기록하는 것은 미래의 나를 위한 것)

• 어떤 지점까지 커밋을 해두는 게 미래의 내가 봤을 때 이 포인트로 돌아오기 쉬우냐

• 여러가지 목적을 한 번에 가지면 안 됨

• 중요한 것은 의도임

• 최대한 잘게 쪼개는 게 좋음 (리베이스를 통해서 합칠 수도 있음)

• 패치 수정 -> fix

• 마이너 -> feat

• 메이저 -> breaking change - 중대한 변화

• 호환되지 않는 새로운 변화

angular/CONTRIBUTING.md at main · angular/angular

The modern web developer’s platform. Contribute to angular/angular development by creating an account on GitHub.

https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit

• commitizen

• cz-cli

• conventional commits

• commitlint

• standard version

• semantic release

커밋메시지

• 접두사를 붙여라 ! => 버저닝에 적용이 되니까 그걸 좀 더 나누고, 생각하면서 커밋을 하는 연습을 하라는 느낌 => 단위를 의식적으로 나눌 수 있음(?)

테스트 관련 로직을 작성해야하나?

• 우선 순위가 떨어지는 영역이다 -> 무조건 새로운 영역을 도입한다고 좋다고 생각하지 않는다.

• 적절한 수준을 지켜야 한다. 너무 배워야 할 것이 많으면 공부하다가 끝난다. 비율을 적절히 조절할 필요가 있다.

• 생산성을 높일 수 있는가 or 생산선이 떨어져도 코드 컬리티가 올라갈 수 있는가 or 가치 있는 영역인가?

• 스택을 선택할 때는 의도를 중시해라 (어떤 개발자로서의 역량을 보여주고 싶은지)

• 다음 스택에 대한 비중을 높여라(=우선순위를 정하자).
• Next, TypeScript
• React Query, Recoil
• MSW, StoryBook, Testing

가져다 쓰는 것이 좋을까, 라이브러리 등을 가져다 쓰는 것이 좋을까?

• 멘토님은 가져다 쓰는 것을 선호하신다. 다른 것(좋아하고, 잘하는 것)에 집중/투자를 함 (내가 더 효율을 낼 수 있는 것에) -> 내가 어떤 거에 강점있는 프론트엔드 개발자로 보이고 싶은지 생각해보기 (ex: 디자인에 강점 -> 디자인 UI 가져다쓰기보단 내가 직접 만들어봄)

전역 상태 관리가 필요한가?

• 대기업, 빅 테크에서는 사용해야 하지만,

• 시스템 레벨에서 다루는 상태(인증, 다크모드, 언어(다국어 페이지), 실시간 소켓 같이 전역 상태값이 꼭 필요한 경우인지, 관리가 필요할 정도로 많은 지를 고민해보자)

• 정말 사용하고 싶다면, 팀원들을 설득하고 가치 판단에 따라 사용해보자.

관심사 분리

• 리엑트는 따로 베스트 프랙티스가 존재하지 않고 우리가 정해야 한다.(라이브러리의 한계, 프레임워크은 best pratice(규칙)가 있음 - next.js엔 일부 존재-page)

• NextJS는 DDD 패턴을 사용, 그리고 NextJS 프레임워크 레벨에서 제공한다.
• NextJS도 React 기반이라서 Page 폴더 구조 외에는 베스트 프랙티스가 없다고 한다. (컴포넌트 폴더 구조는 우리가 정해야 한다네...)

• 도메인이 무엇인가? -> 기능 중심인가? ->

best pratice

• index.ts에 구현체가 들어가면 모든 구현체 파일이 index.ts로 파일이라서 파일을 찾을때 어려움을 겪는다.

• Article 밑에 Article.tsx.. 의도된 중복

• index.ts -> 타입이 반환될 수도 있고, jsx를 반환하지 않기 때문에 tsx가 아니라 ts
• ts프로젝트에선 allowJS 끄기