JIGGAG

5월 한달동안 로그

2021년 6월 3일

5/24 ~ 5/31

reduce

  • map + filter = reduce
  • 이런 상황이면 다 reduce로 한번에 처리하도록 신경을 써보았다
  • 나름 루프 한번으로 해결해보고자 했는데
  • 오히려 내부 변수 수두룩
  • push, set, get
  • 그러다보면 읽기 어려운, 다시 보기 힘든 코드가 되어버린다
  • 좋은 의도를 가지고 시도해보았는데
  • 결과는 좋기만 하지는 않다
  • 비슷한? 그런 고민거리 또 하나
  • 컴포넌트에 padding을 시안에 명시된 수치값을 정확하게 주고 다른 레이아웃을 맞추는게 좋을까
  • 레이아웃에 해당하는 수치를 나눠서 최대한 컴포넌트를 동일하게 만드는게 좋을까
  • 결국 디자인 시안과 다른 수치값이 들어가 있으면 나중에 관리하기 더 힘들다
  • 그리고 공통컴포넌트라고 만들었지만 그 내부에는 수많은 조건 처리가 되어갈뿐
  • 최대한 기본만 갖고 있도록 그리고 수치는 작게 쪼개지 말아야겠다

노션

  • 잘못눌러서 5월동안 기록이 날아가버렸다
  • 까아아아암짝 놀래서 실행취소했지만 핸드폰으로는 이미 돌이킬수없었다
  • 망했다 생각하고 와이파이 끄고 맥북으로 열었지만 어찌나 동기화가 잘 되어있던지...
  • 여기도 날아가버렸다
  • 정말 다행스럽게도.. 업데이트 기록이 남아있어서 날려버린 데이터 다시 긁어와서 살릴 수 있었다
  • 프로 요금제를 쓰라는 의미인가

realm

  • 마이그레이션하면서 기존에 사용하던 필드 삭제
  • 근데 해당 필드가 없는 버전에서 오류가 발생하였다
  • 없는 필든데 삭제하라고 하니 오류가 발생한다고?!
  • 이해는 되는데 그냥 유연하게 삭제해주면 좋을텐데
  • 안전하지 않은가보다

js bundle

  • 토스 컨퍼런스: js 번들 사이즈 줄이기
  • node_modules가 종종 거대해져서 프로젝트 폴더가 처음 받았을때보다 엄청 커진 것을 볼 수 있다
  • 프로젝트에서 사용하고 있는 dependency가 또 다른 dependency를 그리고 또 다른 dependency를 바라보면서 많이 본 블랙홀 보다 빠져나올 수 없는 node_module이 되어버린다
  • 같은 A라는 라이브러리를 의존하고 있더라도 semver가 다른 경우 각각의 라이브러리가 자신의 node_modules에 원하는 버전을 받아서 사용하게 된다
  • yarn dedupelicate으로 중복된 버전의 라이브러리를 최소화해본다
  • 그리고 꼭 필요한 부분만 import한다 (import * as all from 'lodash' 이런 형태를 지양한다)
  • lodash를 정말 잘 쓰고 있었는데 라이브러리의 사이즈가 크고 js 기본 함수로 구현이 가능한 것을 외부 라이브러리를 사용해서까지 할 필요가 없다라는 의견
  • 당연하지만 편리함에 고민하지 않은 부분들
  • 번들 사이즈를 이야기하다보니 ts를 js로 컴파일 했을떄 enum이 떠오른다
  • enum은 tree-shaking이 되지 않아 항상 js 번들에 포함된다
  • 이 또한 편리함이였는데 고민을 해봐야지

5/17 ~ 5/23

RN Timers

  • 일반적으로 알고 있는 setTimeout과 RN의 setTimeout이 다르다고? 왜!
  • 참고: setImmedate와 이벤트 루프
  • 애니메이션과 네이티브 이벤트가 얽혀있는 하나의 액션에서 setTimeout으로 지연시키고자하였다
  • 렌더 후 네이티브 이벤트가 발생하고 그 이벤트에서 애니메이션을 주고 이 작업이 mount/unmount 연속해서 발생한다
  • 당연히 이전 페이지의 unmount가 되면서 다음 페이지의 mount가 되면 좋겠지만 unmount가 fadeout으로 mount보다 더 늦게 발생하면서 문제가 생겼다
  • RN 내부 구현되어 있는 setTimeout
  • 따라가보니 setTimeout을 NativeTiming.createTimer에 있고 이건 BatchedBridge로 나아가는데..??
  • 왜 이게 이렇게 연결이 되는거지
  • RN Timers
  • setImmediate가 현재 실행되고 있는 js에서 native로 넘어가기 직전에 호출된다
  • 왜 native 넘어간다는 내용이 있을까?
  • 참고: RN thread
  • JS 스레드의 각 이벤트 루프 끝에서 네이티브 뷰 업데이트가 전달되며 마지막에 UI 스레드에서 실행된다
  • 그럼 우리가 마주했던 문제 js 이벤트 -> 네이티브 뷰 업데이트
  • setTimeout으로 보냈다면 js 렌더링이 끝나고 네이티브 뷰 업데이트까지 완료된 다음 이벤트 루프가 돌면서 처리되었을것이다
  • 이걸 setImmediate로 변경해서 네이티브 뷰 업데이트로 넘어가기 전에 코드를 실행해주는 것

그냥 그렇다

  • 자식같은 마음으로 듬뿍 애정 담아 시작한 프로젝트
  • 그것이 무슨 이유가 있어서 밀리게 되거나 중지 되거나 엎어지는 경우
  • 이유가 정말 이해는 가는데 그냥 마음이 슬프다
  • 공허한 느낌이랄까
  • 최근 어쩌다보니 겪었고 보았다
  • 그냥 마음 한편 애정을 쏟은 무언가가 떠나버리는 것 같아 아쉬울뿐
  • 있을때잘해줄걸
  • 다시하지뭐

5/10 ~ 5/16

iOS 인증서

  • 갑자기 질문을 받았는데 말끔한 대답을 못하는게 역시나 모르는게 분명하다
  • 키체인에 iOS Developer 인증서가 신뢰할 수 없다고 뜨는데 왜 그런거에요?
  • 분명 그런 메세지를 나도 전에 본 적이 있었다
  • 그러나 정리해두지 않았는지 결국 또 잊어버렸다
  • 인증서를 생성하고 등록하고 다운 받고 키체인에 던졌는데....
  • 그래서 돌아보는 나의 인증서
  • 애플 개발자 센터에는 Membership과 Certificates, Identifiers & Profiles을 보는데(내가 그렇게 본다)
  • Membership에는 개발자 계정 1년마다 등록하는 그것에 관련한 내용이 있다
  • 그리고 여기서 발급받은 나의 Team ID가 앱 빌드하고 배포하는데 따라다닌다
  • 가장 어려운.. 문제의 Certificates, Identifiers & Profiles에는 Certificates, Identifiers, Devices, Profiles, Keys, More 탭이 있다
  • Profiles에는 하나의 Provisioning Profile이 있는데 아마도 애플 로그인 기능을 사용하려고 만든 것 같다
  • Identifiers에서 앱의 기능을 추가하거나 변경하면? Profiles에서 Provisioning을 다시 만들고 다운받아서 xcode에 던진다!??? (기억이 안난다)
  • 참고: iOS 인증서

네이밍

  • 혼자 알아봐서 뭐하니!!!!!!!!!
  • 네이티브 하기 전에 네이밍 좀

5/3 ~ 5/9

rn kakao + fbsdk + flipper

  • package.json

    "@react-native-seoul/kakao-login": "^3.0.6",
"react-native-fbsdk-next": "^4.0.0",

  • 각자 자기 주장하느라 빌드 실패!

    • kakao 버전을 올리고 fbsdk를 붙였더니 시작된 오류

      • 안드로이드는 무사함

    • kakao → podfile platform minimum version 11.0 요구

      [!] The platform of the target `omf` (iOS 10.0) may not be compatible with `KakaoSDK (2.4.1)` which has a minimum requirement of iOS 11.0.

    • platform version 11.0 flipper에서 오류나길래 버전업 시도해봄

      "react-native-flipper": "^0.87.0",

  • 그래도 해결되지 않아서 차분하게 모든걸 정리해가면서 시도하고자함!

    • 모든 테스트는 Podfile.lock을 지우고 yarn pod + clean build

  • [v1] platform :ios, '11.0' + pod 'Alamofire'

    require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

platform :ios, '11.0'

target 'omf' do
  config = use_native_modules!
  use_react_native!(
    :path => config[:reactNativePath],
    :hermes_enabled => false
  )
  pod 'Alamofire'

  target 'omfTests' do
    inherit! :complete
  end

  use_flipper!()

  post_install do |installer|
    react_native_post_install(installer)
  end
end

    Compile FlipperRSocketResponder.cpp

Typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs 'enum clockid_t')
    • platform 10.0에서 해결하려고 했더니 Alamofire가 pod install이 안되서 직접 추가해주었으나 결국 kakao minimum verion으로 해결이 되지 않아서 11.0으로 올리고 재시도

  • [v2] platform :ios, '11.0'

    require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

platform :ios, '11.0'

target 'omf' do
  config = use_native_modules!
  use_react_native!(
    :path => config[:reactNativePath],
    :hermes_enabled => false
  )

  target 'omfTests' do
    inherit! :complete
  end

  use_flipper!()

  post_install do |installer|
    react_native_post_install(installer)
  end
end

    Compile FlipperRSocketResponder.cpp

Typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs 'enum clockid_t')
    • platform 11.0에서는 Alamofire가 잘 설치되니깐 직접 추가하지 않아도 된다고 생각해서 지우고 다시 시도

  • [v3] platform :ios, '11.0' + use_flipper

    • 계속 동일하게 flipper에서 오류가 나길래 찾아보니 최근 등록되어있는 깃헙 이슈 참고해서 flipper 버전을 명시하고 시도
    • flipper 오류 깃헙 이슈
    • flipper version 명시
    • 엥!?
      • build 성공하는가 싶더니!
      • AppDelegate 문법 오류를 뱉어낸다
      • 드디어.... 코드를 읽긴했구나 하는 기쁜마음으로 수정하고 다시 돌리니 성공!!!!

  • kakao 라이브러리를 업데이트하고 fbsdk를 추가하겠다고 처음 커밋한 2021-03-27...

  • 한달이 충분히 지나고 나서야 드디어 빌드 성공

  • 단순하게 platform 버전이 문제라고 생각했는데 범인은 flipper

    • 처음엔 오류메세지가 저게 아니였는데...
    • react-native-flipper를 업데이트해서 그런가!?
    • 어쨌든 최종 오류는 flipper!

클린코드

  • 클린코드 != 짧은코드
  • 원하는 목적을 빠르게 찾을 수 있도록
  • 목적에 따라 하나의 기능만 하도록 분리
  • 동일한 목적에 따른 상세 기능이 흩뿌려지지 않도록 응집
  • 핵심 정보를 뭉쳐서 hook으로 숨기면 다시 찾아야해서 오히려 안티패턴
  • 선언적 프로그래밍 => 이미 구현된 함수에 무엇을 해야하는지만 전달
  • 선언적 프로그래밍 내부는 결국 명령형으로 하나하나 전달하고 있긴한데...
  • 하나의 목적을 갖는
  • 이름만으로도 주요 목적을 알 수 있는 네이밍🙈
  • 중요 코드만 남기고 추상화
  • 동일한 레벨의 추상화 처리
  • 토스 slash21 클린코드

5/1 ~ 5/2

테스트 커버리지

  • 함수 하나를 여러 조건에 대해 모든 테스트를 작성했던적이 있다
  • 그리고 그 테스트 파일은 수천줄이 되었었다
  • 리팩터링을 통해 중복을 줄이고 조건들을 모두 플래그 값으로 반복시켜서 처리했던 기억이 있다
  • 이 테스트 코드는 이후 나의 든든한 지원군이 되어주었다
  • 운영하다가 추가되는 기능에 대해 사용자에게는 아주 사소한 변화이지만 내부적으로는 수많은 조건에 따른 영향이 있었다
  • 그럴때 이 테스트 코드가 나에게 안정감을 주면서 기능개발을 할 수 있도록 해주었다
  • 아마 테스트 코드가 없었다면 모든 조건을 전부 하나씩 테스트해야만 했을 것이다!
  • 지금 생각해보면 이게 단위테스트를 하고 TDD가 자연스럽게 이뤄진게 아닐까
  • 그 당시의 한달동안
  • 그리고 최근에 토스 slash21 테스트 커버리지 100% 를 정말 관심있게 보았다
  • 테스트 커버리지를 높여보고자 시도했지만 컴포넌트를 조건별로 테스트하기가 너무 까다로웠기에 100%를 원한다기보다는 중요한 함수에 대한 처리를 하고자하였다
  • 해당 내용에서는 테스트 커버리지가 낮아지는 경우 빌드 실패하도록 하여 항상 커버리지가 높아지도록 하였다고 한다
  • 멋진걸!
  • 그리고 테스트는 빨라야한다고 한다!
  • push hook으로 테스트를 실행하고 있는데 수천줄이 되는 테스트를 실행하는 것은 너무 느렸다...
  • 이걸 빌드 실패하도록?(더 후반부로 옮기기에는) 이미 테스트에 실패한 코드가 푸시가 되어버리는게 마음이 좋지 않다...
  • 어떻게 하면 코드가 안정적으로 유지되고 테스트가 빠르게 실행될 수 있을까
  • 변경된 파일에 연관된 테스트만 실행한다면?
©Jiggag, Built with Gatsby