Ideveloper's software blog

React - When to useMemo and useCallback (번역 글)

Ideveloper2 — Sat, 15 Jun 2019 15:47:46 +0900

본 글은 원작자 Kent C. Dodds의 허락을 맡고 진행한 번역입니다. 원 글은 https://kentcdodds.com/blog/usememo-and-usecallback 입니다.

useMemo와 useCallback을 어떻게 사용해야하고 주의할점은 무엇인지 파악해 봅시다.

https://ideveloper2.dev/blog/2019-06-14--when-to-use-memo-and-use-callback/ (옆의 리뉴얼된 블로그글 링크에서 확인하시기 바랍니다)

Steady Study

Ideveloper Front end Developer who steadily study

ideveloper2.dev

frontend - 프론트엔드 성능 최적화 기본

Ideveloper2 — Sun, 19 May 2019 01:25:21 +0900

프론트엔드 성능 최적화의 기본(?!)이 될만한 개념들에 대해 조사하여 개편한 블로그에 정리해 보았습니다.

포스팅 링크 : https://ideveloper2.dev/blog/2019-05-18--front-end-%EC%84%B1%EB%8A%A5%EC%B5%9C%EC%A0%81%ED%99%94-%EA%B8%B0%EB%B3%B8/

React - Thinking about emotion js vs styled component

Ideveloper2 — Mon, 6 May 2019 01:55:56 +0900

React (Thinking about emotion js vs styled component)

emotion.js와 styled component를 비교하고, 관련 예시로 면밀히 분석해보는 글을 새롭게 개편한 블로그에 포스팅 해보았습니다.

https://ideveloper2.dev/blog/2019-05-05--thinking-about-emotion-js-vs-styled-component/

React - How Are Function Components Different from Classes? (함수형 컴포넌트와 클래스 컴포넌트는 어떻게 다른가?) 번역

Ideveloper2 — Sun, 17 Mar 2019 18:14:54 +0900

React

:How Are Function Components Different from Classes? (함수형 컴포넌트와 클래스 컴포넌트는 어떻게 다른가?) 번역

새롭게 개편한 블로그에 글을 작성하였습니다. :) 의역이 들어간 부분이 있어 피드백 주시면 감사하겠습니다

링크: https://ideveloper2.dev/blog/2019-03-12--how-are-function-components-different-from-classes/

React - React Concurrent Mode

Ideveloper2 — Sat, 9 Feb 2019 22:44:20 +0900

React

:React - React Concurrent Mode

| React Concurrent Mode?

최근 리액트 16.8이 릴리즈 되고 React hook이 정식으로 포함 되면서 React Hook이 매우 핫한데요, 리액트팀의 React Hook 다음 로드맵인 react의 concurrent mode에 대해서 미리 살펴보고자, 사내 스터디에서 관련 자료를 조사하고 정리했던 내용을 블로그에 정리해 보았습니다:)

아직 정식으로 발표 된 내용이 많이 없어 관련 자료를 조사하며, 의역이 들어간 부분이 있을거라 참고하고 보시고 틀린 부분은 피드백 주시면 될 것 같습니다.! 그리고, React Concurrent mode와 관련해 아직은 정식으로 확정된 내용이 많이 없어, 변경될 가능성이 충분하니 참고만 하시고 읽으시길 바랍니다 :)

리액트 로드맵 : https://reactjs.org/blog/2018/11/27/react-16-roadmap.html

Concurrent React는 많은 작업들을 한번에, 그들의 우선순위를 바꿔 가면서 동작하게 할 수 있게 한다.
-Concurrent Rendering in React - Andrew Clark - React Conf 2018 -

| 시작하기에 앞서

우선 react concurrent mode에 대한 언급은 2018년 4월경 아이슬란드에서 있었던 jsconf 에서의 Dan Abramov의 Beyond React 16 에서(https://www.youtube.com/watch?v=nLF0n9SACd4) 시작되었습니다.

또한, 2018년 10월경에 있었던 React Conf 에서 리액트 팀의 코어 개발자인 Andrew Clark가 (https://www.youtube.com/watch?v=ByBPyMBTzM0&t) 관련 내용을 발표하기도 하였습니다.

먼저 Concurrent 라는 단어는 병행성 이라는 의미를 가지고 있습니다.

React의 Concurrent mode는 초기에는async mode라고 종종 불리곤 했었는데, 추후에 리액트팀에서는 리액트가 가지는 다른 우선순위 (priority of dom update, priorty of api) 에서의 task들에 대한 리액트의 수행능력을 강조하기 위해서, concurrent mode라고 이름을 바꾸었습니다.

" Concurrent React는 많은 작업을 한번에, 그들의 우선순위를 바꿔 가면서 동작하게 할 수 있게 한다." 라고 위에서 Andrew Clark 이 말한 내용을 곱씹어 보면 왜 Concurrent 라는 단어를 선택했는지도 엿볼수 있게 됩니다.

> 핵심

우선 react concurrent mode의 지향점을 먼저 살펴보면 아래와 같습니다.

Concurrent React 는 위와 같은 특징들 덕분에 유저의 디바이스와 네트워크를 리액트 앱에 적응 시키고, 빠른 인터렉션인 상황에는 즉각적인 느낌을 주고, 느린 인터렉션은 그럴만한 이유가 있다는 느낌을 주게 합니다. (adapt to the user's device and network, allowing for fast interactions to feel instant while slower interactions feel responsive)

> 리액트 공식문서에 소개된 react concurrent mode

Link: https://reactjs.org/blog/2018/11/27/react-16-roadmap.html#react-16x-q2-2019-the-one-with-concurrent-mode

위의 링크에 들어가면 리액트 팀의 공식 사이트에 로드맵상 react concurrent mode에 대해 설명한 내용을 확인 할 수 있는데요, 그중 일부를 발췌해 아래에 적은 내용입니다.

Concurrent Mode는 리액트 앱이 조금더 메인 thread에 blocking 없이 컴포넌트 tree상에서 rendering 하는데에 책임을 가집니다. cpu관점에서는 리액트를 긴 시간동안 render 할때, 높은 우선순위의 이벤트들을 dom update의 우선순위를 핸들링하는데에 끼어들수 있도록 허락해줍니다.그리고 i/o관점에서는 Concurrent mode는 또한 Suspense라는 feature를 통해 빠른 연결을 통해 불필요한 로딩을 skip하고 사용자 경험을 증대시킵니다.
Concurrent 리액트는 Time Slicing, 그리고 React Suspense 같은 feature들을 포함하고 있습니다. scheduler 그리고 react-cache 같은 새로운 라이브러리 들도 소개 되고 있습니다.
Concurrent mode는 리액트의 비전 중 큰 부분을 차지합니다. CPU-영역의 작업에서는, non-blocking rendering을 허가하고, application을 복잡한 구조의 컴포넌트 트리에서 책임을 갖게 합니다. IO-영역에서는, Concurrent mode는 Suspense를 더 좋게 만듭니다. 만약 네트워크가 충분히 빠르다면, 로딩 인디케이터를 보여주는것을 피하게 합니다. 또한 Concurrent mode는 협력적인 main thread scheduler에 의존하고 있고, 리액트팀은 크롬 팀과 이러한 기능들을 브라우저에게 옮기기 위해 협업하고 있습니다.

| Time slicing and Suspense

우선 React concurrent mode는 Time slicing (CPU bound) 그리고 Suspense (IO bound) 이 두가지의 feature로 나뉘게 됩니다.

CPU Bound 는 프로세스가 진행되는 속도가 CPU 속도에 의해 제한되는 것을 의미합니다.
I / O Bound 는 프로세스가 진행되는 속도가 I / O 하위 시스템의 속도에 의해 제한됨을 의미합니다.

CPU bound와 IO bound에 대한 설명은 아래 첨부한 링크를 참고하면 더 쉽게 알수 있을것입니다.

https://stackoverflow.com/questions/868568/what-do-the-terms-cpu-bound-and-i-o-bound-mean

결론적으로 Concurrent React에서의 Time Slicing 그리고 Suspense 의 특징은 아래 첨부한 React conf 발표 중 캡쳐한 사진 에서 살펴볼수 있는데요, 뒤에 그 각각의 특징들을 더 자세히 살펴 보겠습니다.

| Time Slicing

Time Slicing 기법은 rendering 프로세스가 진행되는 속도가 CPU 속도에 의해 제한되는 상황일때 높은 우선순위의 업데이트가 낮은 우선순위의 업데이트에 의해 block 되지 않는 일반적인 기법입니다.

Time Slicing is a generic way to ensure that high-priority updates don’t get blocked by a low-priority update. Problems it solves: When rendering is CPU-bound.
High Priority: Updates involving user input (e.g. text inputs)
Low Priority: Updates involving data loading or expensive calculation

우선 Time Slicing 기법이 적용 될수 있는건 react 16으로 업데이트 되면서 성능이 최적화 될수 있었던 큰 특징인 React Fiber라는 context안에서 돈다는 점 덕분인데요, 요약 해서 말하자면 컴포넌트 업데이트가 되는 과정을 Render Reconciliation, Commit 두가지 phase 로 분리하면서 Interruptible한 시점이 생기고, 이 과정 속에서 우선순위를 핸들링 할수 있게 되는 것입니다.

(React Fiber 관련 링크 https://tech.wanted.co.kr/frontend/2018/01/07/react-fiber.html )

아래는 react concuurent 에 대한 내용이 잘 정리 되어 있는 https://github.com/sw-yx/fresh-concurrent-react/blob/master/apis/time-slicing.md 에서 발췌한 time slicing 관련 내용입니다.

Time slicing을 통해, 리액트는 이제 여러개의 frame으로 퍼져나가는 렌더링 작업들, idle callback등의 작업이 이뤄지는 동안 자식 컴포넌트들의 업데이트 계산을 chunk로 나누어서 하였다. 이것은 느린 device들의 UI responsiveness 를 향상 시켰다. Time slice는 모든 어려운 cpu 스케쥴링 작업을 개발자가 신경쓸 필요없이 훌륭한 작업을 해낸다.

> Time slicing 의 특징

리액트는 렌더링 되는 동안 thread를 block하지 않는다.
디바이스가 빠르면 synchronous하게 작동하는것 처럼 느끼게 한다.
디바이스가 느리면 그럴만한 이유가 있는것 처럼 느끼게 한다.
오직, 마지막으로 렌더링 된 상태만 display 된다.

> Time slicing 관련 Demo

Time slicing과 관련한 Demo는 Dan abramov가 js conf 에서 발표한 Beyond React 16 영상에서 가장 잘 확인 할 수 있는데요,(https://www.youtube.com/watch?v=nLF0n9SACd4 3분 부터 시작), 아래 관련 예제 코드를 첨부하긴 하지만 그렇게 긴 시간은 아니니, 영상을 보는것을 추천 드립니다.

https://codesandbox.io/s/xl3rjr9mjo 이 링크를 들어가면 관련 코드와 예제를 보실 수 있고, 예제 자체는 https://timeslicing-unstable-demo.surge.sh/ 이 링크로 가시면 확인 할 수 있습니다.

아래는 Dan abramov의 영상 내용을 요약한 내용입니다. (앞에서 말씀 드렸듯 영상을 보는것을 추천드립니다.)

예제에서는 유저가 입력한 인풋값에 따라 그래프상의 노드들이 무한정 늘어나는 예제인데요, 이 때 Synchronous, Debounce, Asynchronous(concurrnet) 세가지 모드를 인풋값을 무한정 늘려나갔을때의 상황을 비교함으로써, synchronous mode일때는 인풋을 늘려나갔을때 렌더링이 blocking (화면 상 빨간색, 노란색으로 보이는 것은 rendering이 blocking 되는 상황을 보여줍니다.) 되면서 한참뒤에 인풋값이 변경된 화면과, 그래프가 업데이트된 화면이 한참 뒤에 반영되고,

이러한 사용자가 입력한 input이 많아지고, 빠르게 input을 늘려나가고 node가 많아진 상황에 rendering blocking을 해결 하기 위해, 차선책으로 debouce를 통해 최종적으로 업데이트 된 화면을 볼수있게 적용할 순 있지만, Computing power가 충분하고, 불필요한 상황 ( debounce가 적용되어 인풋값이 적은 상황에서 값을 입력하면 debounce 때문에 한참뒤에 그래프가 그려지는 걸 기다려야 하는 상황) 이 발생합니다.

최종적으로 Asynchronous mode일때는 input 값의 입력으로 인한 렌더링의 변화가 그래프가 업데이트 되는 렌더링에 큰 영향을 주지 않으면서, 렌더링이 blocking 되지않는 time slicing 기법의 우위를 확인 할수 있습니다. 심지어 computing power 가 낮은 상황에서도 렌더링 blocking이 최적화 된 상황이므로, 유사하게 동작하게 됩니다.

| React Suspense

React Suspense 는 렌더링이 I/O bound일때 cache 에서 데이터를 불러올 때 렌더링을 suspend 하는 방식입니다.

React Suspense is a generic way for components to suspend rendering while they load data from a cache. Problems it solves: When rendering is I/O-bound.

간단히 설명하자면, 빠른 네트워크 상황에서는 굳이 fallback ui를 보여줄 필요가 없으므로 (로딩 인디케이터) ,data를 fetch 하는 동안 컴포넌트를 background에서 렌더링 하고, tree가 모두 준비되면 display하는 방식입니다.

그러나 느린 네트워크 상황에서는 데이터를 불러올때 보여주는 fallback UI (place holder) 를 각각 data를 불러오는 영역(컴포넌트에)에 정확히 배치(precisely control) 함으로써 다른 영역에서의 data fetch 때문에 페이지 전체가 로딩되는 것을 기다리는 것을 방지 하게 되는 것입니다.

It is a fundamentally new capability that lets you render a component tree “in background” while components are fetching data, and display them only after the whole tree is ready.
For slow connections, it gives you full control over where and when to show a placeholder. It doesn’t destroy the previous view while this is happening.

> Suspense 의 특징

data가 준비될때까지 state update를 멈춘다.
add async data to any component without "plumbing"
빠른 네트워크에서는, 모든 tree가 준비 된 후에 render 한다.
느린 네트워크에서는, 정확하게 로딩 스테이트를 control한다.
high-level api와 low-level api가 있다.

> Suspense 관련 demo

이 역시, Dan Abramov의 js conf 영상을 확인하면 쉽게 관련 demo 를 살펴 볼수 있습니다.

( https://www.youtube.com/watch?v=nLF0n9SACd4 13분 24초~)

그리고 Andrew Clark의 2018 React Conf 에서도 역시 관련 demo 영상을 살펴 볼수있습니다.

( https://www.youtube.com/watch?v=ByBPyMBTzM0&t=1305s)

영상에서는 react -cache를 활용해 기존에 data를 받아온 페이지는 빠르게 그 페이지를 보여주고, Suspense에 해당하는Placeholder 컴포넌트에 "maxDuration" prop을 넘겨, 해당하는 duration을 넘겼을때는 느린 네트워크로 감지하여 로딩 인디케이터를 보여주고, 아닐시에는 보여주지 않는 등, 다른 네트워크 상황에 유연하게 대처하고 있는 것을 확인 할 수 있었습니다.

https://github.com/sw-yx/fresh-concurrent-react/blob/master/apis/react-suspense.md 에서 이와 관련한 feature 들을 빠르게 확인 할수 있습니다.

영상에서 확인할 수 있듯이, 네트워크가 충분히 빠른 상황이면 불필요한 로딩 인디케이터를 보여주지 않고, 바로 tree가 준비되는대로 보여주고, (+ cache) 네트워크가 느린 상황에서만 fallback ui (로딩 인디케이터)를 보여주게 됩니다.

아래 gif 파일에서의 latency는 네트워크 상황을 뜻합니다.

latency 1초일때와 3초일때 비교

또한, 각각의 영역에 로딩 관련 인디케이터를 배치 함으로써 하나의 data fetch때문에 전체 페이지가 로딩 되는 듯이 보여주는게 아닌, 먼저 fetch 된 부분은 먼저 보여주고 나중에 data가 fetch 되는 부분은 나중에 보여줌으로써 사용자에게 더 나은 경험을 제공하고 있습니다.

Suspense 관련 DEMO 코드

https://codesandbox.io/s/k3m2rq627o

| 느낀점

아직은 많은 개발자 들이 react hook에 관심을 가지고 있고, react concurrent mode가 정식 릴리즈 되려면 많은 기간이 남아 있긴 하지만, 언젠간 거쳐 가야 할 react concurrent mode에 대해 조사하면서 리액트 팀의 방향성에 대해서 미리 파악해 볼 수 있었고, 또한 크게 느꼈던 점은, React concurrent mode는 사용자의 computing power가 어떻든 (time slicing) , 네트워크 상황이 어떻든 (Suspense) 이에 맞게 유연하게 대처하는 feature들을 추가 함으로써, 이러한 기술적인 발전은 결국엔 사용자의 ux를 고려한 feature들인것 임을 보고, 맹목적인 기술 발전에만 목매는 팀이 아닌것 같다는 점이 정말 감명깊었던 것 같습니다.

| References

Javascript - 객체와 객체지향 프로그래밍

Ideveloper2 — Sun, 3 Feb 2019 16:07:27 +0900

Javascript

:객체와 객체지향 프로그래밍

이 내용은 러닝 자바스크립트 의 내용을 참고해서 정리된 포스팅 글입니다. 그리고, 본인의 의견을 담아 내용을 더 추가하여 작성했습니다.

| 프로퍼티 나열

어떤 컨테이너의 콘텐츠를 리스트로 나열하면, 배열이 바로 떠오르지만 객체를 생각하는 사람은 많이 없습니다. 객체도 배열과 같은 컨테이너 이며, 요소들의 나열을 지원 합니다.
단, 프로퍼티 나열에서 중요한점은 순서가 보장되지 않는다는 점입니다. 자바스크립트가 순서를 명시적으로 보장하는 것도 아니고, 브라우저나 노드등의 프로그램에서 속도나 효율 향상을 목적으로 언제든 바꿀 수 있다고도 합니다.

> for ...in

아래에서의 hasOwnProperty 는, 상속 된 property가 for .. in에 나타날 위험을 제거 하기 위해 사용합니다. 다른 타입의 객체, 다른 사람이 만든 객체의 프로퍼티를 나열하다 보면 예상치 못한 상황이 생길 수 있으므로 hasOwnProperty를 쓴느것은 매우 중요하다고 합니다.


const obj = {a:1 , b:2 , c:3};

for(let prop in obj){
  if(obj.hasOwnProperty(prop)) continue;
  console.log(`${prop}` : `${obj[prop]}``)
}

> Object.keys

Object.keys 는 객체에서 나열 가능한 문자열 프로퍼티를 배열로 반환합니다. 아래 예제의 결과 값은 for ... in 루프를 썻을때와 같은 결과이고, hasOwnProperty를 체크할 필요는 없습니다. 그리고, 객체의 프로퍼티 키를 배열로 가져와야 할때 편리하게 쓰일수 있습니다.

const obj = {a:1 , b:2 , c:3};

Object.keys(o).forEach(prop => console.log(`${prop}: ${obj[prop]}`));

| 객체지향 프로그래밍
객체지향 프로그래밍 (OOP)는 컴퓨터 과학에서 전통적인 패러다임 입니다. OOP의 기본 아이디어는 단순하고 직관적입니다. 객체는 데이터와 기능을 논리적으로 묶어 놓은 것입니다. OOP는 우리가 사물을 이해하는 자연스러운 방식을 반영하도록 설계되었습니다.
자동차가 객체라면 그 데이터에는 제조사, 모델, 차량번호 등이 있을 것입니다. 그리고 그 기능으로는 가속,변속, 문 열기 등등이 있을것입니다. 또한 OOP는 이러한 사물에 관해 추상적으로(어떤 자동차), 구체적으로(특정 자동차) 생각 할 수 있게 합니다.
본격적으로 시작하기 전에 OOP의 기본용어에 대해 살펴봅시다.
클래스는 어떤 자동차처럼, 추상적이고 범용적인 것입니다. 인스턴스는 특정 자동차 처럼 구체적이고 한정적인 것입니다. 기능은 메서드 라고 불립니다. 클래스에 속하지만 특정 인스턴스에는 묶이지 않는 기능을 클래스 메서드라고 합니다. 시동을 거는 기능은 클래스 메서드라고 할 수 있는 것입니다. 인스턴스를 처음 만들 때는 생성자가 실행되고, 생성자는 객체 인스턴스를 초기화 합니다.
OOP는 클래스를 계층적으로 분류하는 수단도 제공합니다. 예를 들어, 자동차보다 더 범용적인 운송수단 클래스가 있다치면, 운송수단을 자동차의 슈퍼클래스라 부르고 , 자동차를 운송 수단의 서브클래스 라 부르게 됩니다. 서브클래스 역시 서브클래스를 가질 수 있습니다. 예를들어 보트 서브클래스에는 요트, 카누 등의 서브클래스가 있을 수 있습니다.
> 클래스와 인스턴스 생성
ES6 이전에 자바스크립트에서 클래스를 만드는 건 직관적이지도 않고, 무척 번거러운 일이었다고 합니다. ES6에서는 클래스를 만드는 간편한 새 문법을 도입했다고 합니다.

class Car {
  constructor(){
    
  }
}

앞의 코드는 새 클래스 Car를 만들고, 인스턴스는 아래와 같이 new 키워드를 통해 만들 수 있습니다.

const car1 = new Car();
const car2 = new Car();

> 클래스는 함수다.
ES6에서 class 키워드를 도입하기 전까지, 클래스를 만든다는 것은 곧 클래스 생성자로 사용할 함수를 만든다는 의미였습니다. class 문법이 훨씬 더 직관적이고 단순하지만 class는 단축 문법일 뿐이며 자바스크립트의 클래스 자체가 바뀐 것은 아닙니다. 따라서 자바스크립트의 클래스 자체를 이해하는 것이 매우 중요하다고 합니다.

#ES5
function ES5Car(make , model){
  this.make = make;
  this.model = model;
  this._userGears = ['P','N','R','D'];
  this._userGear= this.userGears[0];
}

#ES6
class ES6Car {
  constructor(make,model){
    this.make = make;
    this.model = model;
    this.userGears = ['P','N','R','D'];
    this.userGear = this.userGears[0];
  }
}

typeof ES5Car 와 typeof ES6Car 역시 결과가 "function"으로 같을 것입니다.
> 프로토타입
자바스크립트에서의 프로토타입에 관해 이해가 필요한데요, 이에 관해서는 http://www.nextree.co.kr/p7323/ 이블로그를 추천해 드립니다.
클래스의 인스턴스에서 사용 할 수 있는 매서드라고 하면 그건 프로토타입 메서드를 말하는 것입니다. 예를 들어 Car의 인스턴스에서 사용할수 있는 shift라는 메서드는 프로토타입 메서드입니다. 프로토타입 메서드는 Car.prototype.shift 처럼 표기하기도 합니다. Array.forEach를 Array.prototype.forEach라고 쓰는것과 마찬가지인 개념입니다. 많은 배열들에서 forEach 메서드를 쓸수 있는것 역시 상위 Array의 forEach 메서드를 쓰는 것이죠.

모든 함수에는 prototype이라는 특별한 프로퍼티가 있습니다. 일반적인 함수 에서는 프로토타입을 사용할 일이 없지만, 객체 생성자로 동작하는 함수에서는 프로토타입이 대단히 중요합니다.
함수의 prototype은 프로퍼티가 중요해지는 시점은 new 키워드로 새 인스턴스를 만들었을 때 입니다. new 키워드로 만든 새 객체는 생성자의 prototype 프로퍼티에 접근할 수 있습니다.
객체 인스턴스는 생성자의 prototype 프로퍼티를 __proto__ 프로퍼티에 저장합니다.
객체의 프로퍼티나 메서드에 접근하려 할때, 그런 프로퍼티나 메서드가 존재하지 않으면, 자바스크립트는 객체의 프로토타입에서 해당 프로퍼티나 메서드를 찾습니다. 클래스의 인스턴스는 모두 같은 프로토타입을 공유하므로, 프로토타입에 프로퍼티나 메서드가 있다면, 해당 클래스의 인스턴스는 모두 그 프로퍼티나 메서드에 접근할 수 있습니다.
> 정적 메서드 (static method)
메서드에는 인스턴스 메서드 외에도, 정적메서드 ( class method , static method) 가 있습니다. 이 메서드는 특정 인스턴스에 적용되지 않습니다.정적 메서드에서 this는 인스턴스가 아니라 클래스 자체에 묶입니다.
정적 메서드는 클래스에 관련되지만 인스턴스와는 관련이 없는 범용적인 작업에 사용됩니다. 예제로 자동차 식별 번호 (VIN)을 붙이는 메서드를 생각해 봅시다. 개별 자동차가 자신만의 VIN을 붙이는것은 불가능하니, 이러한 상황에서는 정적 메서드를 사용하는 것이라고 합니다. 그리고 이러한 정적 메서드는 여러 인스턴스를 대상으로 하는 작업에도 종종 쓰인다고 합니다.

class Car {
  constructor(){
    this.vin = Car.getNextVin();
  }
  
  static getNextVin(){
    return Car.nextVin++;
  }
  ...
  
  static areSame(car1,car2){
    return car1.vin === car2.vin;
  }
}

> 상속
클래스의 인스턴스는 클래스의 기능을 모두 상속합니다. 상속은 한단계로, 끝나지 않습니다. 객체의 프로토 타입에서 메서드를 찾지 못하면, 자바스크립트는 프로토타입의 프로토타입을 검색합니다. 프로토타입 체인은 이런식으로 만들어 집니다. 그러다 조건에 맞는 프로토 타입을 찾지 못하면 에러가 납니다.
클래스의 계층 구조를 만들 때 프로토타입 체인을 염두해 도면 효율적인 구조를 만들 수 있습니다. 즉, 프로토 타입 체인에서 적절한 위치에 메서드를 정의하는 것입니다.

class Vehicle {
  constructor(){
    this.passengers = [];
    console.log('vehicle created');
  }
  
  addPassenger(p){
    this.passengers.push(p);
  }
}

class Car extends Vehicle {
  constructor(){
    super();
    console.log('car created');
  }
  deployAirbags(){
    console.log('BWOOSH');
  }
}

위의 예제에서, extends 키워드는 Car를 Vehicle의 서브클래스로 만듭니다. super( )는 슈퍼클래스의 생성자를 호출하는 특별한 함수입니다. 서브클래스에서는 이 함수를 반드시 호출해야 합니다. 호출하지 않으면 에러가 일어납니다.
리액트를 사용해서, 프론트개발을 하시는 분이면, Dan Abramov 가 쓴 https://overreacted.io/how-does-react-tell-a-class-from-a-function/ 를 한번 읽어보는 것을 추천드립니다. 리액트팀이 리액트 내에서 어떻게 function 기반 컴포넌트와 class 기반 컴포넌트를 분류하는지, 리액트내에의 new 키워드에 대한설명, 그리고 위에서 말한 상속과 관련된 extends.React.component에 대한 설명 등등 아주 흥미로운 내용들이 많이 있습니다.
> 다형성
다형성이라는 단어는 객체지향 언어에서 여러 슈퍼클래스의 멤버인 인스턴스를 가리키는 말입니다. 대부분의 객체지향 언어에서 다형성은 특별한 경우에 속합니다. 자바스크립트는 느슨한 타입을 사용하고 어디서든 객체를 쓸 수 있으므로, 어떤 면에서는 자바스크립트의 객체는 모두 다형성을 갖고 있다고 할 수 있습니다.
> 객체 프로퍼티 나열 다시보기
ES6 클래스를 설계 의도대로 사용한다면 데이터 프로퍼티는 항상 프로토타입 체인이 아니라 인스턴스에 정의해야 합니다. 하지만 프로퍼티를 프로토타입에 정의하지 못하도록 강제하는 장치는 없으므로 확인하려면 항상 hasOwnProperty를 사용하는 편이 좋습니다.

class Super{
  constructor(){
    this.name = 'Super';
    this.isSuper = true;
  }
}

Super.prototype.sneaky = 'not recommended';

class Sub extends Super {
  constructor(){
    super();
    this.name = 'Sub';
    this.isSub = true;
  }
}

name, isSuper, isSub 프로퍼티는 모두 프로토타입 체인이 아니라 인스턴스에 정의됐습니다. (슈퍼클래스 생성자에서 선언한 프로퍼티는 서브클래스 인스턴스에도 정의됩니다.
Object.keys 를 사용하면, 프로토타입 체인에 정의된 프로퍼티를 나열하는 문제를 피할 수 있습니다.
| 다중 상속, 믹스인, 인터페이스
일부 객체지향 언어에서는 다중 상속이란 기능을 지원합니다. 이는 클래스가 슈퍼클래스 두개를 가지는 기능입니다. 그러나 다중 상속에는 충돌의 위험이 있다고 합니다. 예를 들어 어떤 클래스에 두개의 슈퍼 클래스가 있고, 두 슈퍼클래스에 모두 greet메서드가 있을때 어떤 메서드를 상속해야 할까?와 같은 문제입니다. 다중 상속 언어가 많은 이유는 이러한 문제를 피하기 위헤서라고 합니다.
다중상속을 지원하지 않는 언어 중에는 그 대신 인터페이스 개념을 도입해서 이런 상황에 대처하는 언어가 많습니다.
자바스크립트는 흥미로운 방식으로 이들을 절충했다고 합니다. 자바스크립트는 프로트타입 체인에서 야러 부모를 검색하지는 않으므로 단일 상속 언어라고 해야 하지만, 어떤 면에서는 다중 상속이나 인터페이스보다 더나은 방법을 제공합니다. (더 못할때도 있습니다.)
자바스크립트가 다중 상속이 필요한 문제에 대한 해답으로 내놓은 개념이 믹스인입니다. 믹스인이란 기능을 필요한 만큼 섞어 놓은 것입니다. 자바스크립트는 느슨한 타입을 사용하고 관대한 언어이므로, 그어떤 기능이라도 언제든, 어떤 객체에든, 추가 할 수 있습니다.아래는 makeInsurable 이라는 보험가입과 관련된 믹스인 예제입니다.

class InsurancePolicy{}
function makeInsurable(o){
  o.addInsurancePolicy = function(p){ this.insurancePolicy = p; }
  o.getInsurancePolicy = function() {return this.insurancePolicy; }
  o.isInsured = function(){return !!this.insurancePolicy; }
}

makeInsurable(Car.prototype);
const car1 = new Car();
car1.addInsurancePolicy(new InsurancePolicy());

위와 같이 해주면, addInsurancePolicy 같은 메서드들은 모두 Car 클래스에 정의된 것 처럼 동작합니다. 개발자의 관점에서는 중요한 두 클래스를 관리 쉽게 만들었습니다. 자동차 회사에서 Car 클래스의 개발과 관리를 담당하고, 보험회사에서 InsurancePolicy 클래스와 makeInsurable 믹스인을 관리하게 됩니다.
| 요약
객체지향 프로그래밍은 대단히 널리 쓰이는 패러다임이며, 그럴만한 이유가 있다고 합니다. 객체지향 프로그래밍을 사용하다보면 자연스레 관리하고, 디버그하고, 수저아기 쉬운 정리되고 캡슐화된 코드를 작성하게 됩니다. 자바스크립트의 OOP 구현은 비판을 자주 받는 편이지만, 자바스크립트의 OOP는 사실 매우 유연하고 강력하다고 합니다. 이로인해, 다른 객체지향 언어에서 하기 어려운 일도 할수 있기 때문입니다.

css - 스켈레톤 UI css 만으로 구성하기 with react

Ideveloper2 — Thu, 24 Jan 2019 01:31:14 +0900

css

:스켈레톤 UI css 만으로 구성하기

| Why ?

특정 페이지를 개발할때, 로딩 스켈레톤을 구현해야 하는 상황이 있었습니다. 이 ui를 구현하기 위해 여러 라이브러리를 사용할 순 있겠지만, 이런 라이브러리들로 인해 프로젝트의 크기가 늘어나고, 불필요한 리소스 낭비가 될 수 있다는 생각도 들었습니다. 따라서, css만으로도 충분히 스켈레톤 ui를 구성 할수 있다 생각되어 css로 스켈레톤 ui, 그리고 그에대한 애니메이션을 구현해 보았었습니다.

아래는 구현한 여러 스켈레톤 ui중 특정 페이지의 모바일 리스트 뷰에 해당하는 디자인 시안에 맞춰 본인이 구성한 UI입니다. UI를 구성하는 방식은 background-image 와 background-size css 속성을 활용해 임의의 스켈레톤 ui를 구성하여 수정해 사용하면 됩니다.

background-image 로 각각 요소들의 크기를 정해줌
background size로는 그 요소들의 위치를 정해줌

| How ?

1. 아래와 같이 구성할 뼈대를 만듭니다.

2. 반복되는 부분이 있다면 반복해 줍니다.

3. 뭔가 아쉬우니 효과를 넣어 봅시다.

위와 같이 html과 css 만으로 스켈레톤 ui를 구현하면, 리액트 프로젝트의 번들사이즈 역시 다른 라이브러리를 사용해서 스켈레톤을 구현할때와 비교해 줄어들었고, 처음에는 레이아웃을 구성하는데 학습 비용이 있긴 하겠지만 익숙해지면 어떠한 스켈레톤 ui라도 유연하게 구현할 수 있겠다는 생각이 들었습니다.

위 예시로는 모바일 특정 화면에서만 구현한 스켈레톤 ui를 예시로 보여주었는데요, 같은 화면에 대한 여러 반응형 뷰에대한 스켈레톤 UI 역시 css 단에서 미디어 쿼리로 반응형 대응만 한다면 한 화면의 해상도에 따른 여러 스켈레톤 ui도 html파일 하나와 css 파일 하나로도 충분히 대응이 가능하였었습니다.

또한 , 다른 여러 페이지에서도 같은 방식으로 스켈레톤 ui를 쉽게 구현할 수 있었습니다. :)

Javascript - 자식 element가 여럿 있을때 event 전파 막는 효과적인 방법

Ideveloper2 — Wed, 16 Jan 2019 00:24:56 +0900

Javascript

:자식 element가 여럿있을때 event 전파 막는 효과적인 방법

| Why?

> 상황:

모바일 웹에서, Modal의 overlay 영역의 scroll을 방지하기 위해 overlay 영역을 touch 햇을때 touchEvent 리스너에 모달을 닫는 function을 넣어, 모달을 닫게 하는 기능을 구현해야 하는 상황이 생겼었습니다.

> 어려움이 있었던점:

모달의 overlay 영역은 부모 영역에 생기고 그 하위에 모달 컴포넌트의 자식 요소들이 있는 상황이였는데요,

이때자식 element에는 onClick 이벤트로 새로운 모달을 띄우는 이벤트가 걸려있는 상황이였습니다.

따라서,

기존의 모달안의 자식 요소들에 걸려있는 클릭시 새로운 모달창이 뜨는 onClick event
부모 (모달 overlay 영역)에게 걸려있는 화면 touch시 모달창이 꺼지는 touch event

이벤트 전파로 자식 요소를 클릭했을때 위와 같은 두 이벤트가 동시에 실행되는 상황을 막아서, (react 모달의 overlay 영역) 부모 엘리먼트 터치시에만 모달 창이 닫히는 이벤트를 발생시켜야 하는 상황이였습니다.

그렇지 않으면 이벤트 전파로 인해, 유저는 자식 엘리먼트를 클릭해 새로운 창을 뜨는 상황을 기대했지만, 자식을 클릭했더라도 부모 이벤트에 걸려있는 touch시 모달 창이 닫히는 이벤트가 발생해서, 모달 창이 닫혀버려 원하는 상황을 구현할 수 없었습니다.

그 이유는 모두 아시다시피, event는 dom tree 내에서 캡쳐링- 버블링의 과정을 거치기 때문에, 부모 element에만 touch 와 관련한 이벤트를 걸어 놓았더라도, 이벤트 전파가 되어 자식 엘리먼트에 이벤트가 발생해도 부모의 event 역시 실행되기 때문입니다.

요약: 부모 요소 안에 있는 여러 자식 요소들의 클릭으로 인한 이벤트 전파를 막아야 하는 상황

| HOW TO SOLVE

부모의 이벤트 영역 touch시에만, 발생시켜야해서, e.target이 e.cuurentTarget과 같을시에만 실행하도록
if (e.target !== e.currentTarget) return; 과 같이 부모 node touch시에만 touch 이벤트가 실행되도록 하여, 자식 node 클릭 시 이벤트 전파로 인해 모달이 꺼지는 경우를 방지 하는 방식으로 코드를 작성하여 문제를 해결했습니다.

물론, 많이들 사용하는 e.stopPropagtion 을 활용하여, 자식 엘리먼트에서 전파를 막아도 되지만, 부모 엘리먼트 단에서 if (e.target !== e.currentTarget) return; 과 같은 코드로 막을 수 있으면, 각각의 자식요소들에서 e.stopPropagtion 로 처리를 해줄 필요가 없어, 자식요소들에서 중복된 여러 코드들을 사용하지 않아도 됩니다.

e.stopPropagtion 의 예제

위 예는 stopPropogation 메소드로 이벤트 전파를 막는 간단한 예제였고,

아래는 문제 해결 상황에서 if (e.target !== e.currentTarget) return;를 활용해 부모쪽에만 코드를 추가하여, 자식 엘리먼트들의 이벤트 전파를 막은 코드입니다.


handleTouch = e => {
 // 부모 touch 시에만 동작하도록 하기 위한 부분입니다.
 if (e.target !== e.currentTarget) return;
   this.closeSearchForm();
 };

handleTouchEnd = e => {
 // 부모 touch 시에만 동작하도록 하기 위한 부분입니다.
 if (e.target !== e.currentTarget) return;
   e.preventDefault();
   this.closeSearchForm();
};

handleOverlayTouch = () => {
 const el = document.querySelector('.ReactModal__Overlay');
   el.addEventListener('touchstart', this.handleTouch);
   el.addEventListener('touchend', this.handleTouchEnd);
};

...

# 모달 컴포넌트
<Modal
  onAfterOpen={this.handleOverlayTouch}
  isOpen={isSearchFormOpen}
  onClose={this.closeSearchForm}
  position={modalPositionEnum.top}
>

ETC - transpile (트랜스파일) 과 compile (컴파일) 의 비교

Ideveloper2 — Sun, 6 Jan 2019 17:03:00 +0900

ETC

:transpile 과 compile의 비교

잘못된 내용이나, 오타 피드백 환영합니다!

| 시작하기에 앞서

transpile과 compile 이라는 두 용어를 헷갈린 적이 한두번이 아니고 잘못 사용하고 있는 케이스들을 봐서, 내용을 다시 한번 되짚어 보려합니다.

프론트엔드 개발을 하다보면 자주 babel이나 typescript를 자주 언급하게 됩니다. 또한, 이들을 설명할때는 compile 혹은 transplie이라는 용어를 종종 사용 하게 됩니다.

우선, babel은 javascript transpiler 입니다. 또한 그다음으로, 타입스크립트 역시도 많이 접하실 텐데요, 타입스크립트가 자바스크립트로 컴파일 되는것인가, 트랜스파일 되는것인가는 아래에서 다시 언급하겠습니다.

| transpile vs compile

트랜스 파일과 컴파일을 같은 개념으로 사용하기도 하는데, 약간의 차이가 있습니다.

> compile

컴파일의 경우는, 한 언어로 작성된 소스 코드를 다른 언어로 변환하는 것을 의미 합니다.

예를 들어, 컴파일 하는 경우는 아래와 같습니다.

Java -> bytecode
c -> assembly

> transpile

트랜스파일 의 경우는 한언어로 작성된 소스 코드를 비슷한 수준의 추상화를 가진 다른 언어로 변환하는 것을 말합니다.

예를 들어, 트랜스파일하는 경우는 아래와 같습니다.

es6 코드 -> es5 코드로 변환하는 경우
c++ -> c
coffescript -> javascript

Q) 그럼 transpile 하는 상황에서 compile 한다고 설명하는 것은 옳지 않은 설명인가?

저는 정답은 NO 라고 말하고 싶습니다.

https://en.wikipedia.org/wiki/Source-to-source_compiler 옆의 링크를 참조해보면, transpiler는 다른 말로 source to source compiler 라고도 설명하기도 하며, 컴파일러의 일종으로 트랜스파일러를 설명하고 있습니다. 따라서 compile이라는 용어가 더 큰 범주에 속하게 되고, 그 안에 transpile이라는 개념이 있게 되는것이죠.

| 더 생각해보기

> typescript (transpiler or compiler?)

그리고 많이 언급되는 typescript 의 경우는 javascript로 변환되는데, 뭉뚱 그려 많은 사이트에서는 컴파일링 된다고는 하지만, 거의 같은 수준의 추상화가 되는것이라 더 정확히 말하면 트랜스파일링 된다고 말할 수 있습니다.

> sass 에 쓰인 transpile (or compile )개념

sass는 웹에서 직접 동작할 수 없습니다. 따라서 전처리기로 작성 후 css로 compile (or transpile )하는 과정을 거쳐야 사용할수 있게 되는 것입니다. 다양한 방법으로 컴파일이 가능하지만 자바스크립트 개발환경에서는 node-sass를 활용하여 주로 컴파일을 하게 됩니다. 따라서 scss 코드를 작성할때 node-sass npm을 설치했던 것입니다.

| 결론

위 글을 읽어보면 알 수 있듯 서로 개념 상 차이가 있긴 하지만, 혼용하여 사용할수도 있는 케이스 들이 존재하여, 사실 컴파일이냐 트랜스파일이냐를 구분 짓는것은 크게 중요하지는 않은 것 같습니다. 하지만, 컴파일과 트랜스파일을 많이 혼용하여 사용하는 만큼, 적절한 상황에 맞춰 용어를 사용하는 것이 좋을 것 같습니다 :)

일상 - 1년차 병아리 개발자 2018년 회고

Ideveloper2 — Sat, 29 Dec 2018 23:29:33 +0900

일상 :

1년차 병아리 개발자 2018년 회고

| 회고에 앞서..

올해 2018년은 병역특례를 시작하면서, 처음 개발자로 발을 내딛은 해였습니다.

또 학교에서 듣는 수업을 듣고 과제를 하는게 아니라, 사회에 나와서 개발자로 일하는 만큼 많은 점들이 낯설었고, 또한 여러 결정들을 하고 책임들을 가져야 하는 부분들을 겪으며 힘들었던 적도 많았고, 또 그러한 만큼 뿌듯했던 적도 많았습니다. 그만큼 제게 많은 일들이 올해 일어났던 것 같습니다. 그리고 처음 개발자로 발을 내딛는 해였던 만큼, 더 알차게 보내고 싶었고, 어떻게 하면 좋은 개발자로써 성장할 수 있을까, 이시점에서 어떠한 공부를 해야 훗날 내게 도움이 될까 등등 유난히 많은 생각을 했던 올 한해였고 이러한 올 한해를 헛되이 보내지 않기 위해 치열하게 노력했던 것 같습니다.

아래는 올해 저 혼자 생각했던 저만의 좌우명이었습니다.

많은 경험을 통해 여러 사람들을 만나 동기부여를 받고, 나도 이러한 동기부여를 주는 사람이 되자.

| 회고 시작!

블로그

가장 많이 기억에 남고, 가장 뿌듯한 부분입니다. 약 150여개의 글을 올해 썼는데, 최근에는 많이는 작성 못하고, 매주 하나씩은 주말에 작성중입니다. 많이 작성할때는 한달에 10개씩 작성하던 때도 있었습니다. 하지만 이제는 많은글을 쓰기보다는, 좋은 글을 쓰기 위해 노력하려 합니다. 또, 좋은 정보를 전달하기 위해 항상 노력중입니다. 현재는 블로그 방문자 통계나, 여러 플러그인들을 티스토리에서 지원해주고있어서 쓰고 있긴하지만, 많은 분들이 블로그를 개발해 사용하고 계신것처럼, 내년에는 개인 블로그를 직접 만들어서 쓸 예정입니다. 100일 일일커밋, 6개월 일일커밋등의 값진경험을 통해, 이 경험을 포스팅을 해보기도 하고, 프론트엔드 개발자로 첫발을 내딛은 주니어개발자로써 FECONF 2018을 다녀와 후기를 작성해 보는등, 이외에도 많은 제 경험과 학습내용들을 블로그에 기록함으로써, 제가 한해동안 겪었던 경험들을 블로그안에 녹여 나갈 수 있었고, 또 이러한 발자취들을 뒤돌아보며 뿌듯함을 느낄 수 있었던 것 같습니다. 내년에는 더욱더 열심히 블로깅을 할 예정입니다.

그 중 가장 기억에 남는 블로그 포스팅 글들

- 100일 일일 커밋

https://ideveloper2.tistory.com/129

- 6개월 일일커밋

https://ideveloper2.tistory.com/153

- FECONF 2018 후기

https://ideveloper2.tistory.com/157

위에서 작성한 후기로, 프론트엔드개발그룹에서 상품을 보내주기도 하였습니다..ㅎㅎㅎ

커뮤니티 활동

멋쟁이 사자처럼 6기 운영진 활동

멋쟁이 사자처럼은 전국 100여개 대학에서 진행중인, 비전공자를 위한 프로그래밍 교육단체입니다.

3월~6월 동안 매주 주말이나 평일에 퇴근하여 세미나 발표 자료를 만들고, 매주 수요일 퇴근하여 학교를 찾아가 학습을 진행하고, 격주로 발표를 진행 했습니다. 개발자로 첫발을 내딛기 전 많은 선배 개발자 분들에게 도움을 받았던 만큼, 저 역시도 그런것들을 돌려주기 위해, 6기 운영진으로 활동하며 루비온 레일스나 웹 전반적인 것에 대해 학습을 선행하고 이 내용들을 발표를 진행 했었습니다.

또한 중간에, 전체 세미나에서 (깃헙 A TO Z ) 레일즈 이외에 다른 개발 정보공유를 위해 힘쓰기도 했습니다.

- 매주 화요일 전체 세미나

- 매주 수요일 팀 세미나(발표 격주)

- 멋사 중앙대 미니 해커톤 멘토로 참가

발표

https://festa.io/events/92

- GDG 라이트닝 토크 : 떡잎부터 다른 인싸 개발자 되기

떡잎부터 다른 인싸 개발자 되기(제가 그렇다는건 아닙니다ㅎ)라는 주제로, 본인이 어떻게 개발을 해나갔는지, 1년차 개발자로써 어떻게 성장해 나가고 있는지, 올해 10월 경에 많지는 않은 사람들 앞에서 GDG 라이트닝 토크에서 발표를 진행 했었습니다. 기록, 성취, 사람, 도전 이라는 네가지 키워드로 발표를 했습니다. 원래 계획보다는 훨씬 빠르게 GDG에서 어쩌다보니 발표를 하게 되었는데, 좋은 경험을 미리 해보았다 생각하고, 제가 했던 노력들을 남들에게 보여줌으로써 그러한 노력들이 더 값지게 느껴졌고 보상받은 기분이었습니다. 앞으로는 좀 더 기술적 역량을 쌓는데 집중하고, 다음에는 더 기술적인 내용이나 제가 쌓은 내공들을 보여줄수 있는 발표 기회가 먼 훗날 생기면 발표해보고싶습니다.

slideshare 링크: https://www.slideshare.net/ssuser77af35/ss-119214431

컨퍼런스, 밋업

많은 컨퍼런스를 참가했지만 좋은 기억이 있는 컨퍼런스를 나열하면 아래와 같습니다. 작년 GDG DEVFEST를 갔을때는 멍만 때리다 왔는데, 올해에는 나름 고개를 끄덕이며 발표를 이해하며 들었던 세션들이 많았고 공감하며 들을 수 있다는 사실이 제 자신이 성장했다는 사실을 몸소 깨달을 수 있었고, 많은 발표자 분들을 보며 동기부여도 되는 계기가 되었던 것 같습니다. 하지만 이러한 컨퍼런스에가서 알지도 못하는 기술정보들을 무조건적으로 들으러 다니지 않고, 관심있는 주제가 있을 때만 신청했으며, 여기서 들은 정보들을 제 지식인 마냥 떠들지 않고, 이러한 기술들에 휩쓸리지 않기 위해 본인의 학습을 게을리 하지 않도록 항상 경계했습니다.

- GDG 2월 MEETUP

올해 처음 갔던 밋업입니다. 대단한 분들이 많은 것을 알게 되었고, 처음 이런 밋업의 네트워킹 자리를 참여했는데 많은 얘기들을 들을 수 있었고, 여러 이야기들을 공유하면서 좋은 경험을 갖고, 후에 많은 밋업들을 가게 되는 계기가 되기도 한 것 같습니다.

https://ideveloper2.tistory.com/22 (밋업을 가고 처음 써본 블로그 글인데, 블로깅을 시작한지 얼마 안되서인지 내용이 정리가 잘 안된것 같은 느낌이 듭니다..ㅎㅎ)

- FECONF 2018

좋은 세션들을 많이 듣고, 오래 기억하고 싶어, 후기를 써서 프론트엔드개발그룹에 공유를 한 컨퍼런스 이기도 합니다. 내년에도 꼭 참여할 예정입니다.

https://ideveloper2.tistory.com/157

- GDG DEVFEST

작년에도 참여했었던 컨퍼런스인데, 작년과는 다르게 많은 세션들을 이해할 수 있었고, 또 이 때문에 주의 깊게 들을 수 있었고, 먼 훗날 저런 자리에서 발표를 해보고 싶다는 생각도 들었습니다.

- GOOGLE IO EXTENDED SEOUL

https://ideveloper2.tistory.com/98

- NAVER DEVIEW

올 해 가본 개발자 행사중 가장 큰 행사였던것 같은데, 좋은 동기부여를 많이 받았습니다.

https://ideveloper2.tistory.com/154

회사

리액트로 시작해서 리액트로 끝..

첫번째 회사

한달만에 React, Redux, Redux saga를 학습하여 리액트로 처음 웹 구조를 설계 해보고 개발해 내기도 하였습니다.
프론트 개발 뿐 아니라, 다른 회사의 개발팀과의 커뮤니케이션을 통해 외부 API 연동으로 node.js로 api를 개발해보기도하며, 외주사와 커뮤니케이션을 통해서 업무의 시급도를 판단하여 업무를 할당하기도 하며, 사용하지 않는 서버를 정리하여 기술부채를 해결해보기도 하는 많은 경험을 할 수 있었던 것 같습니다.

스타트업 신입 3개월차 회고
https://ideveloper2.tistory.com/70
스타트업 신입 2018년 상반기 및 5개월 회고
https://ideveloper2.tistory.com/96?category=646723

두번째 회사 (현재 회사)

기존 레거시 코드들을 걷어내고, 상품상세 페이지 뷰를 루비온레일즈에서 리액트로 마이그레이션하는 작업을 진행했습니다. 현재도 많은 페이지에서 리액트 리뉴얼 작업을 진행중인데, 상품 상세 페이지가 처음으로 한페이지가 모두 리액트로 리뉴얼 되는 첫 페이지 였고, 또한 많은 레거시들이 있고 중요한 페이지 였는데, 들어가자마자 큰 프로젝트를 맡아 우여곡절이 많긴 했지만 이러한 작업을 진행해 봄으로써 제 역량을 증명해 내기도 했던 것 같고, 크게 성장했던 것 같습니다.
위의 큰 프로젝트 말고도, 사내의 기존 서스테이닝 이슈들을 중간중간 해결하였습니다. 이전회사에서 혼자 디버깅을 하여 레거시 코드들과 분투했던 경험이 크게 도움이 되어 문제해결능력을 길렀는지, 회사에 들어간지 얼마 되진 않았지만 서스테이닝 이슈들을 해결해 나갈수있었습니다.
그리고 회사내에서 값진 경험들을 많이 할 수 있었는데, 경력이 많으신 PM분들, QA분이나 디자인팀 분들과 커뮤니케이션하며 프로젝트를 진행해보면서, 회사 PRODUCT 팀 내의 work-flow안에서 한 구성원으로써 어떻게 개발을 진행하는지에 대해 몸소 체득하면서, 정말 크게 발전할 수 있었던것 같습니다.

대회

회사일에도 집중하면서, 제 자기계발을 멈추지 않고, 많은 사람들과 만나 동기부여를 얻기 위해, 대회 참여에도 소홀히 하지 않았던 것 같습니다.

삼성서울병원 해커톤 디지털 헬스 해커톤

토-일 주말동안 무박2일로 진행되었어서, 회사가 끝나고 평일에 이어 주말까지 쉬지 못해, 그 다음주에는 매우 힘들긴 했었지만 큰 뿌듯함이 남는 대회이기도 합니다. 하루만에, 결과물로 낼수 있는 서비스하나 정도는 프로토타이핑 하여 만들 수 있다는 자신감이 생겼습니다. 발표하는 기회도 있었기 때문에 그러한 점도 큰 도움이 되었습니다. 제가 만든 서비스를 직접 개발하고, 왜 이러한 서비스를 만들게 되었는지 소개하는등의 일련의 과정을 거치며 작게나마 창업을 해본것과 같은 경험이었습니다. 또한 다른 팀들의 아이디어를 보며 동기부여도 되고 여러 인사이트들을 얻는 큰 경험이 되었습니다. 또한 팀장으로써 팀을 꾸리고 팀을 리딩하고 대회전 오프라인 미팅을 가지며 플래닝을 하면서 개발 외적으로도 리더쉽이나, 프로젝트를 리딩할 수 있는 점들을 배울 수 있었습니다.

후기: https://ideveloper2.tistory.com/156

깃헙: https://github.com/N-M-C

컨트리뷰톤 -크로미움

글로벌 오픈소스인 크로미움에 컨트리뷰트 해보는 대회였습니다. 오프라인 미팅에 참여하거나, 멘토님이 발표하시는 세미나에 찾아가기도 하며 노력은 했지만, 이번에는 열심히 참여하지 못해 정말 아쉽고 팀원들에게 미안한 대회인것 같습니다. 같은 팀원들이 정말 열심히 해주신 덕에 대회에서 큰상을 받을 수 있었고, 이러한 훌륭한 팀원들 덕에 같은 팀원들에게 큰 동기부여를 받을 수 있었습니다. 작년에는 다른 주제로 참여 했었지만 ,이러한 대회 참여는 언제나 큰 동기부여를 불러 오는것 같습니다.

토이 프로젝트, 학습

대부분 주니어 개발자들은 이미 다 완성되어있는 설계나 구조안에서 작업을 거의 하기 때문에, 서비스를 직접 처음부터 끝까지 구축해보는 경험을 갖기가 어렵습니다. 따라서 이러한 경험을 갖기 위해 React+ Firebase 조합으로, 시작했던 펜션 사이트 제작 프로젝트입니다. 확실히, 개발자들은 사이드 프로젝트를 하는것이나, 학습하여 얻은 인사이트나 지식들이 사내에서 개발을 진행할때도 큰 도움이 되는것이 확실하기에, 1차적으로 개발을 한 이후에도 계속 이 사이트를 유지보수 해나가고, 기능을 추가해 나갔었습니다. 리액트를 시작한지 얼마 안되서 개발해 본 프로젝트이기도 하고 디자인에 큰 신경을 쓰지못하여, 내년에는 디자인을 수정해나가고 불필요한 코드들을 제거하고, 리팩토링을 중점적으로 하여 개발할 예정입니다.

https://github.com/zx6658/react-pension-template

항상 영화를 예매하려고 할때 대부분 근처에있는 가장 시간대가 가까운 영화를 예매하기 마련이라 이를 위치기반의 웹사이트로 구축하여, 가장가까운 영화관의, 가장 지금 시간대와 가까운 영화들을 한 사이트에서 볼수 있도록 한 프로젝트입니다. next.js나, mobx 같은 스펙도 사용해보고싶고, 그리고 위치기반 웹앱을 제작해보고 싶었기 때문에 시작한 프로젝트이기도 합니다.ㅎㅎ

https://github.com/zx6658/easyMovieSearch

저만의 리액트 보일러 플레이트를 제작해 보았었습니다.

https://github.com/zx6658/react-project-kit

js알고리즘을 틈나는대로 programmers 사이트에서 풀고 깃헙에 기록중입니다.

https://github.com/zx6658/JS-Algorithm_TIL

스터디

구글 머신러닝 단기집중과정 스터디

https://developers.google.com/machine-learning/crash-course/?hl=ko

- 머신러닝이란 놈이 도대체 어떤놈인지 배워보고자 신청한 스터디입니다. 매주 월요일 퇴근후에 진행했던 스터디이고, 7~8월 경에 진행했던 스터디입니다. 더해보고 싶었지만 다른 프로젝트 준비로 인해 심화과정은 듣지않아 아쉬움이 많이 남은 스터디입니다. 그러나 머신러닝의 기본 개념과 이러한 개념들이 실제로 어떻게 적용되는지 알게 되고, 머신러닝이라는 것에 첫발을 내딛을 수 있었던 좋은 기회였습니다.

프론트엔드 스터디

- 전 회사 사수분을 멘토로 해서 여름부터 시작한 스터디입니다, 웹팩, 바벨부터, 함수형프로그래밍 등등 프론트엔드 개발자로써 발전해 나가기 위해 도움이 될만한 것들을 공유하고 학습하고자 시작한 스터디입니다. 현재도 매주 수요일 퇴근후에 진행중입니다.

프론트엔드 전반적인 내용 스터디(웹팩, 바벨)
https://github.com/zx6658/jsWebStudy

함수형 프로그래밍 스터디
https://github.com/ToBeFrontEndMaster/seungkyu

책

생각보다 책은 그렇게 많이 읽은 것 같지는 않습니다. 주로 리액트나 자바스크립트를 주제로만 한 책을 읽었던것 같습니다. js나 리액트 말고도 보다 다양한 스펙트럼의 책을 읽어볼걸 하는 생각도 듭니다.

React

리액트 교과서
리액트를 다루는 기술

https://ideveloper2.tistory.com/145 (책 리뷰)

Javascript

속깊은 javascript

학습 관련 포스팅글
https://ideveloper2.tistory.com/76
https://ideveloper2.tistory.com/77
https://ideveloper2.tistory.com/78
https://ideveloper2.tistory.com/84

함수형 자바스크립트 프로그래밍

학습 관련 포스팅글
https://github.com/ToBeFrontEndMaster/seungkyu

자바스크립트 핵심 가이드

오픈소스

주니어 개발자의 Open Source 컨트리뷰트 내역 정리 포스팅 글 : https://ideveloper2.tistory.com/137

오픈소스 컨트리뷰트 내역은 아래와 같습니다. 올해 상반기에 대부분 진행했던 컨트리뷰트이고 하반기에는 진행하지 못한점이 크게 아쉽고 반성을 하게 되었습니다.

React

https://github.com/facebook/react/pull/13169

create-react-app

https://github.com/facebook/create-react-app/pull/4703

React.org

Chromium

몇몇 컨트리뷰트를 하긴 했지만 한장으로 요약합니다 ㅎ (후...뿌듯)

올해 아쉬웠던 점

올해 초반에는 많은 의욕을 가지고 개발이나 학습을 회사일과 병행 했던 것 같습니다. 하지만, 올해 후반기에는 이직준비 이후에 너무 지쳤던 탓인지, 올해 초반보다는 치열하게 하지 못했던 것 같습니다. 하지만 페이스는 잃지 않기 위해, 꾸준히는 하도록 노력했던 것 같습니다. 그리고, 내년에는 리프레쉬 해서 올해보다 더욱 열심히 하여 남들에게 동기부여가 되는 사람이 되기 위해 노력할 것입니다.
남들이 쓸수 없는 나만의 글을 쓰지 못했던 적이 많았던 것 같습니다. 블로깅을 많이 하는것도 좋지만, 좋은 글을 쓸수 있도록 노력할 것입니다.
올 한해 여러가지 개발을 해보는 경험은 했지만, 기능을 구현하는데에만 급급하고 그러한 개발에 쓰이는 기술들이 어떠한 원리로 작동하는지, 또 그런 기술들의 Docs들을 제대로 읽지 않았던 것 같습니다.
계획했던것 보다, 많은 토이프로젝트들을 진행하지 못했고 끝마무리를 하지 못했던 것 같습니다.
더많은 해커톤을 나가지 못한점이 아쉽습니다.

내년 목표

무조건적으로 많은 글을 쓰기 보다는, 정확한 정보를 전달하고, 많은 사람들에게 도움이 될 수 있는 양질의 블로그 글 쓰기
더많은 해커톤 참여하기
개발에 쓰이는 기술을 사용하기 이전에 먼저 사용하는 기술들을 이해하고, 그러한 기능들이 어떻게 동작 하는지 동작 원리에 대한 이해를 선행시 하기
개발을 할때도 생각나는대로 코드를 짜는게 아니라, 다시한번 그러한 생각들을 곱씹어보고, 많은 생각을 가지고 개발하도록 노력해보기
올해보다 훨씬 성장하여 남들에게 더 동기부여를 주는 사람이 되어있기
오픈소스 컨트리뷰트 중요한 부분(기능)에 해보기 (문서 수정 x, 오타 수정 x)