5/31

package.json

• 개발할때만 쓰는거 -> devDependencies
• 인줄알았는데
• flipper 플러그인 설치하다보니 devDependencies에 넣으면 안되는걸 보며 왜?? 의문점
• 개발할때만 쓸거고 __DEV__ 조건도 걸려있어서 배포될때는 필요없는 패키지인데 왜 설치하면 안되는걸까
• 해당 코드를 어디서 사용하는지 확인해보자
• flipper plugin을 app.js에서 사용하고 있다 -> 번들링 된다 -> 필수 패키지
• eslint 같은 경우 index.js 아래로 어디에서도 사용하고 있지않다 -> 번들링되지 않는다 -> 개발 패키지

5/25 - 5/30

귀찮아서

• 하나의 액션에 모든것을 넣어두었다
• 그리고 이제 그 중 일부분만 필요로한다
• 분리하기 귀찮아서 전부 새로 호출했다
• 하루를 되돌아보니 가장 못난 순간이었다
• 내일 당장 분리해야지

zsh

• bash_profile을 계속 읽지 못하고 터미널 마다 source .bash_profile을 해줘야했다
• 이상하네
• 하다보니 터미널이 bash 에서 zsh로 변경되었다
• 터미널은 zsh를 바라보고 있는데 bash를 설정해주면 무슨 소용...

이번주도

• 가끔 이렇게 아무것도 하지 않은듯 일주일이 지나가버린다
• 아주 작은 사소한 것이라도 나중에 크게 될 거야
• 잊어버리지말고

5/18 - 5/24

불필요한

• 응답 객체가 있다
• 객체가 유효한지 체크하기 위해 객체 안에 있는 값(res.name)이 유효한지 체크한다면?
• 나중에 객체 모양이 변경되었을때 혹은 네이밍이 변경되었을때(name -> firstName) 해당 값을 사용한 모든 곳을 찾아 변경해주어야한다
• 단순히 지금 값을 체크하는데 쉬울지 몰라도 언젠가 불필요한 코드가 될 수 있다
• 유지보수를 간결하게 하기 위해 지금 작성하고 있는 코드를 생각한다
• 불필요한 메모리, 자원을 사용하는 것을 줄이자

투두 컴포넌트

• 나만의 컴포넌트
• 색상 디폴트를 지정하면 디자인된 컴포넌트를 반환
• 빅버튼, 라디오버튼, 엑스...
• 기본적인 스타일이 적용되어있고 커스텀 가능

redux-saga

• react-native-firebase/messaging의 requestPermission 를 saga에서 호출하여 사용하고 싶다
• 비동기니깐 yield만 붙이면 되겠지
• yield call(messaging.requestPermission) 안된다
• yield messaging.requestPermission() 된다
• 왜?
• call에서는 messaging는 존재한다 그러나 requestPermission는 없다
• 그렇다면 call에서 바라보고 있는 context는 어디일까?
• call을 사용하는 이유가 있을까? -> context를 지정해줄 수 있기 때문에
• 곧 context를 바꿔서 사용하고 싶으면 call을 사용하면 된다는 것

물음표

• 하고 싶은 것
• 기회가 많은 것

5/10 - 5/17

• 한 주가 길게 느껴졌다 그리고 생각이 많았다
• 아직 한참 멀었다

toy server

• 크롤링하고 GraphQL까지
• 이제 필요한 정보를 API

심플 소프트웨어

• 구현 < 유지보수 -> 구현보다 유지보수가 어렵다
• 유지보수 = 소프트웨어 -> 유지보수하는게 복잡하면 소프트웨어 설계가 복잡하게 되어있는것
• 버그는 언제든 나타날 수 있다 -> 내가 아닌 누가 와도 버그를 수정할 수 있도록

5/3 - 5/9

오브젝트

• 객체 설계
  • 데이터와 프로세스를 한 덩어리로
  • 책임에 따라 응집을 높이고 결합을 낮춰서
  • 데이터 보다 책임 중심 설계: 어떤 책임을 가지는지 우선적으로 생각하고 캡슐화
  • 데이터 중심 설계 -> 리팩터링 -> 책임 중심 설계
  • 묻지말고 시켜라
  • 절차지향에서는 원하는것을 묻고 나서 시작하지만 객체지향에서는 그냥 이거해달라고 시켜버린다
  • 정보를 가져오고 가져온것에 또 계산을 들어가기보다 이거 계산해줘라고 요청하므로써 불필요하게 정보를 알게되는것을 최소화하고 응집도 높임
  • DRY: 중복을 최소화
• 객체 지향 프로그래밍
  • 책임, 역할, 협력
  • 응집, 결합, 캡슐
  • 디자인패턴, 리팩터링, TDD
  • 트레이드오프를 겪으며 시도

override

• 사용하던 라이브러리에서 초기화하는 함수가 promise 형태를 반환한다
• 그리고 언제 초기화를 호출하게 되는지 정해진 위치가 없다
• 그래서 처음 라이브러리를 사용하고자 할 때 초기화를 시키고 원래 호출하려고 하던 함수를 실행시켜주려고 하였다
• 여기서 발생한 이슈로 초기화가 되지 않은 상태에서 여러번의 호출이 발생했을때 여러개의 객체가 생성되어 버리는 문제를 막고 싶었다
• 이에 대한 해결 방안으로 라이브러리에 초기화된 객체 상태를 반환하는 함수 PR (흥미로웠다), 내부적으로 라이브러리를 재정의하고 객체를 싱글톤으로 구현이 떠올랐는데 두번째 방법을 시도하게 되었다
• 우선 라이브러리가 호출되기 전 내부적으로 초기화하는 함수를 호출하고 promise로 콜백함수로 초기화 상태값을 바꿔주었다 (이때 싱글톤으로 객체를 생성하고 싶었으나 이 방법이 잘 구현되지 않았다)
• 생성된 객체의 하위 메서드로 라이브러리의 함수들을 재정의하여 다시 넣어주었다
• 앱 내에서는 재정의된 라이브러리를 사용하게 되었다

redux-saga

• 너무 쉽게 생각했다
• takeEvery로 모든 액션을 응답받고 takeLatest로 마지막 액션만 가져오면 된다고 생각했는데
• 더 단순하게 멱등성을 가지는건 takeEvery, 그렇지 않은건 takeLatest를 사용하면 된다고 생각하고 get, post로 구분하고 끝내버렸다
• 그럼 다른 이펙트들은 왜 존재하겠어?
• takeLeading이라는 이펙트가 있다. 이름에서 알 수 있는 takeLatest와는 반대로 처음 호출된 액션만 유지하고 응답한다
• all로 여러 액션들을 비동기로 날려보내고 모두 응답이 왔을때에만 다음으로 넘어가게 된다