2019-08-18 TIL

2019-08-18

별 거 없는 하루..

함수 호출 with backtick

const Foo = (some) => some + "!!";

Foo`Wow`;  // return "Wow!!"
Foo("Wow"); //  return "Wow!!" 즉, 같은 결과

StyledComponent에서 백틱 이용하는게 신기했는데 함수를 이렇게 호출할 수 있다니.. 다만 인자는 string 타입으로 고정된다.

좋은 깃북

파덕님 추천으로 실용주의 프런트 엔드 개발이라는 깃북을 좀 읽음. 리팩터링 관련된 권장사항을 읽어볼 수 있고, 그외 다양한 프로그래밍 패턴들도 담고있음. 방법론, 책 발췌까지..

얼마 전에 선태랑도 얘기했지만 리팩터링이 주기적으로 필요한게 분명하다. 긴 기간을 잡고 차근차근..

리팩토링과 기능 추가는 동시에 진행되면 안된다. 동시에 진행하게 된다면 이슈 발생시 리팩토링으로 인한 이슈인지 기능상의 이슈인지 파악하기 어렵기 때문이다. 기능 추가시에 테스트 코드를 같이 추가하여 추후에 리팩토링 시 기능상의 이슈가 발생하지 않도록 해야 한다.

페이지 통으로 발췌

리팩토링을 하면 어떤게 좋을까

코드 설계가 깔끔해짐

소프트웨어 설계 개선 단기적인 목적 때문에 코드를 수정하거나 코드의 설계를 완벽히 이해하지 않고 코드를 수정하면, 코드 구조가 뒤죽박죽되어 그 코드를 보고 설계를 파악하기가 어려워져 프로그램 설계가 점점 노후 된다. 정기적으로 리팩토링을 실시하면 코드 설계가 깔끔해진다.

이해가 쉬워짐

기능을 추가하면서 설계한 것들을 모두 기억할 수 없기 때문에 코드를 깔끔하게 만들지 않으면 복잡한 내용을 이해할 수 없다.

버그 찾기 쉬워짐

코드 리팩토링하면 구조가 명료하게 만들어서 디버그 시 쉽게 버그를 찾을 수 있다.

프로그래밍 속도 빨라짐

리팩토링을 하지 않으면 소프트웨어 개발이 진행되면서 개발 속도가 현저히 줄어들게 된다. 설계가 정돈되지 않으면 기능 추가 시 시간이 오래 걸릴 수 밖에 없으며, 버그 찾기에 많은 시간을 낭비하게 된다. 프로그래밍 속도를 빠르게 하려면 깔끔한 설계를 유지해 설계가 노후화되지 않게 해야 한다.

흥미없으면 글이 잘 안읽히는 편인데 리팩터링 글이 눈에 들어왔던 이유가 있다..

요즘 리액트 componentWillReceiveProps를 걷어내는 작업을 하고 있는데, 공식 문서에서 이걸 static getDerivedStateFromProps로 대체하도록 안내하고 있다.

그런데 워낙 쓰임새가 다양한 메서드가 사라지는 것이라, 로직을 여러 적재 적소로 분배해야 하는 어려움을 겪고 있다. 그러기 위해서는 기존 로직과 코드 구조를 이해해야 하고, 어떻게 쪼개 보내는게 좋을지 고민이 많이 된다.

그러던 중 리액트 github의 issue의 토론글을 조금 보게 되었는데 반발도 은근히 있고, 새로 렌더하지 않고 state를 변경한다는 이점을 포기하기 싫어 하는 의견이 많이 보인다. 기존 코드를 어떻게 고치면 좋을지 묻는 사람들도 있고..

Dan Abramov가 직접 등판해서 사람들에게 답변을 해주는데, 읽어보며 내린 결론은 재렌더를 두려워하지 말고 componentDidMount를 활용해야 겠다는 것임. side effect들 특히 서버 API 호출이나 AsyncStorage에서 데이터를 가져오는 작업들을 렌더 전에 처리하기 보다는, 한 번 렌더한 후 데이터를 가져와 그 결과에 따라 다시한번 렌더하는것을 권장하고 있다.

그리고 side effect를 별도의 컴포넌트로 쪼개 사용하는 것도 추천하고있다.

토론글을 본 후 아직 회사 코드를 안봤는데, 내일은 코드가 조금 다른 시각으로 보이길 바란다.

그리고 휴일엔 기필코 회사 코드는 안볼것임!

아 그리고 모든 컴포넌트를 한번에 작업할 생각 말고, 한 브랜치의 작업 단위를 작게 가져가자. 작업 규모가 생각보다 크고, 작게 쪼개야 PR 리뷰하기도 좋다.