찰쓰 코치님, 병현님, 나 3명 참여
1시간 토론

주제 1: 창발적 코드 규칙 생성하기

책 216페이지
착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙 네 가지가 있다면?

발제자 제안

책의 규칙 외에 각자가 추가하고 싶은 창발적 규칙 하나씩 말해보기

나눈 의견

• 코드를 최대한 나누기
• 단순 표현하기에서 좀 더 분리
• 모든 코드를 테스트? (x)
  • 현실적으로 무리
• 모든 중복을 제거? (x)
  • 어떤 경우에는 중복이 필요하기도
• 어느 정도 중복이 필요한 경우
  • 예) 1번 버전을 기반으로 (거의 똑같이) 2번 버전을 만드는 경우
  • 1번을 개선해서 모듈 분리 등
• 라이브러리 사용 여부에 대해
• 선배 개발자 왈: 리액트는 쌩으로 짜는 게 맞다 (리액트만 가지고 짜는 게 맞다)
  • 근거: 리액트 내에서 어느 정도 제공해주는 것이 있음
• 하지만 react-query의 도움을 받았을 때 훨씬 깔끔하게 해결할 수 있는 경우가 많음
  • 외부에서 도움을 받을 수 있는 건 최대한 쓰자

추가 토론: 코딩에서 '설계'라는 게 어디까지의 범위를 말하는 걸까?

• 의견 1: 코드 단에서의 설계 (상태나 API를 어떻게 구조화할 것인가)
• 의견 2: 디자인 패턴 (=> 설계에 도움되는 지식), DDD 등의 아키텍처 (도메인 주도), 함수지향/객체지향 (아키텍처 = 코드에서가 아닌 시스템 단에서의 설계)

주제 2: 책임을 통해 클래스의 크기를 파악한다고 했을 때 '책임'이 가리키는 것?

책 172페이지
클래스는 작아야 한다.
함수는 물리적인 행 수로 크기를 측정했다. 클래스는 다른 척도를 사용한다. 클래스가 맡은 책임을 센다.

발제자 제안

책임을 통해 클래스의 크기를 파악한다. 그러면 책임이란 무엇을 내포할까?

• 책임을 어디까지로 봐야할까?
  • 코드 구조상의 책임
  • 도메인 상의 책임
  • 의존성의 책임 등
• 여러 책임들이 섞이면 무엇이 문제일까?
• 클래스 작성 시에 책임의 종류와 범위를 알 수 있는 상태일까?

나눈 의견

• 의견: 추상화나 관심사의 분리 정도
  • 추상화를 높이면 책임이 많아지고 추상화 정도를 낮추면 그만큼 구체적인 클래스 생성
• 책임을 줄이다 보면 물리적 행 수도 자연히 줄어들 것
• 정확히 뭘 하는지 모르겠는 클래스라면 더 나눠야 하는 클래스이고
• 구체적으로 뭘 하는 건지 정확히 알 수 있는 클래스라면 잘 분리된 클래스

영속성

• 백엔드에서 자주 나온 개념
• 특정 장소에서만 사용할 수 있는 것은 영속성이 거의 없는 것
• 스토리지만 바꿀 수 있고 인터페이스는 그대로 둘 수 있다면 횡단 관심사처럼 영속성 있게 관리될 수 있는 것
• 프론트의 Indexed DB - 브라우저에서 제공하는 DB (이것도 영속성 개념이지만 프론트에서 잘 안 쓰는 듯함)
• 영속성은 백엔드적 지식인 듯 하나 프론트도 DB가 점점 생기면서 고민해볼 문제일 것 같다

횡단 관심사

관심사란?

• 예) '은행'의 관심사 종류: 입금, 출금, 이체 등

• 횡단 관심사의 정의: 여러 군데서 쓰일 수 있는 관심사
  • 로그인 useAuth 등의 커스텀 훅뿐만 아니라 프론트의 로컬 스토리지도 해당

Global store : 전역 상태 관리(?)

• react-query
  • DB에서 가져와서 프론트에서 잠깐 갖고 있음 (캐싱)
• 중간 레이어 표현 (실제 DB랑 거리가 있으나 브라우저가 확실히 갖고 있는 것도 아닌 것)
• 웹 API (setTimeout, setInterval 등) 해당!

웹뷰

• 배포가 편함

• 버전 업그레이드 부담 없음 / 웹과 앱만 통신하면 됨

  • 앱은 버전 업그레이드 부담 있음 (심사 기간 + 사용자가 직접 업데이트를 해야 적용)

• BUT 나중에 Native 코드도 만져야 한다

• 큰 회사에선 native 팀이 따로 있고 나머지는 웹 개발자인 경우가 많음

• 앱은 디바이스에 딱 붙어서 돌아감 (성능적 이점)

• 요즘은 웹뷰 추세이나 나중에는 결국 native단 코드로 개발해야

• RN의 expo는 원래 교육용

• 카카오는 native SDK를 따로 제공 X