JIGGAG

8월 한달동안 로그

2022년 9월 2일

읽어보았던

  • 이번 한달은 읽어본 것이 있다고/없다고 할 수 없었다
  • 왜 그럴까
  • 무언가 헤딩이 부족했던 것 같다

8/29 ~ 8/31

8/22 ~ 8/28

안드로이드 컷아웃

  • 문서: 안드로이드 디스플레이 컷아웃
    • 기기에 컷아웃이 3개 이상 있을 수 없습니다.
    • 기기 양쪽의 긴 가장자리에는 컷아웃이 있을 수 없습니다.
  • ???????
  • 위/아래에만 컷아웃이 들어갈 수 있다는 것
  • 그럼 간단해질 것 같은데

8/15 ~ 8/21

RN 0.69.4

  • 미루던 + 잊고 있던 RN 올리기
    • 근데 벌써 0.70.0-rc가 나와있는데?
    • 절대... 릴리즈 되지 않은 버전을 올리지 않으리라 다짐하며
    • 0.69.4로 정한다
  • 근데 우연히?
    • 그동안 코틀린으로 마이그레이션 한 이후?
    • 안드 디버그 빌드를 하면 flipper가 연결이 제대로 안되고 앱이 죽어버리는 오류가 있었는데
    • ReactNativeFlipper 도 java > kotlin 으로 되었으니 이를 호출하는 부분도 변경했어야하는데...
    • 계속 자바 클래스 호출하는 방식으로 사용하고 있었다 (그러니 오류가 뻥)

잘못된 추상화

  • 컴포넌트를 여러 컴포넌트로 나눠야 할 때
  • 하나의 리액트 컴포넌트로 작성해도 된다
    • 그러나 가장 큰 단점
    • 상태 변화가 일어날 때마다 애플리케이션 전체를 새로 그리게 된다
    • 재사용이 어렵다
    • 관심사 분리가 되지 않았기 때문에 복잡하다
  • 이러한 문제점을 미리 예방하려고 컴포넌트를 잘게 쪼개는 추상화를 한다
    • 하지만 이런 잘못된 추상화로 오히려 불필요한 비용을 발생시킬 수 있다
    • 어떤 일이 있을까 생각을 해보면...
    • 쪼개둔 컴포넌트를 다시 합쳐야하는 일이 발생하는 것이 가장 손쉽게 경험하는 비용이지 않을까
    • 또는 쪼개는 위치가 여기가 아니였을때

  • 컴포넌트를 더 작은 크기로 쪼개는 것은 자유입니다. 하지만 진짜 문제를 경험하기 전까지는 크기가 커지는 컴포넌트에 대해 두려워하지 마세요. 너무 이르게 추상적으로 나누는 것보다 정말로 필요할 때까지 기다렸다가 적용하는 것이 코드 관리에 훨씬 편리합니다.

  • 분명 봤을것인데... 다시 봐도 새로운건 얼마나 매일 즐거울까

테스트 커버리지

  • (홍보글로 시작한 것 같지만...) 100% 코드 커버리지?!
  • 전에 커버리지를 100% 가까이 하려고 시도해본적이 있었다
  • 커버리지는 결국 그 코드 시나리오를 확인했는지 정도로 올릴 수 있었는데
  • 순간 중심을 잃어버리면 100%를 채운다가 테스트 목적이 되어버리게 되고
  • 코드 케이스를 검증하기 위한 테스트 시나리오가 아니라 단순히 코드를 테스트 시나리오에 끼워넣기 위한? 시나리오를 작성하고 있게 된다
  • 이것이 위 글에서 위험하게 생각하는 100%의 함정 아닐까

8/8 ~ 8/14

리액트 의존성

8/1 ~ 8/7

SOLID 원칙

  • React에 SOLID 원칙 적용하기
    • OOP에서만 적용될 수 있는게 아니다 😯
    • 클래스 > 컴포넌트, 훅이라고 생각하면 충분히 적용할 수 있는 것
  • 단일 책임 원칙 (SRP)
    • 하나의 컴포넌트는 하나의 목적을 갖는다
    • 데이터를 가져오고(1) 필터링 하고(2) 화면에 그리는 것(3) > 3가지 목적을 하나의 컴포너트에서 하도록 두지 않고
    • 1, 2를 훅으로 분리하고 3을 단순한 컴포넌트로 구성한다면!
    • 하지만 훅, 컴포넌트로 분리하는 과정에서 잘못 추상화를 진행한다면 역전된 의존성을 갖게 될 수 있고 오히려 복잡해지는...
  • 개방-폐쇄 원칙 (OCP)
    • 컴포넌트 내부에서 의존성을 갖고 처리하는 것이 아니라
    • 확장에 유연하도록 props, children으로 넘겨 받도록
  • 리스코프 치환 원칙 (LSP)
  • 인터페이스 분리 원칙 (ISP)
    • 컴포넌트 간 의존성을 낮춰서 재사용성을 높일 수 있도록 하는 것
    • A > B > C 로 넘어올수록 TargetAProps | TargetBProps > TargetProps > string 이런 느낌
    • 최종 컴포넌트에선 다른 인터페이스와의 의존성을 줄일 수 있도록 하는 것
  • 의존관계 역전 원칙 (DIP)
    • ISP와 이어지는 것 같은데
    • HOC로 서로 다른 컴포넌트가 서로를 의존하지 않고 공통된 부분만 의존하도록 추상화
©Jiggag, Built with Gatsby