당근 게임을 만들면서 아래의 코드를 실행했을 때 undefined가 출력되었다.

this.field.addEventListener('click',this.onClick)

this.onClick은 할당이 되어있는 상태였는데 왜..?
이유는 click의 콜백으로 전달할 때 클래스의 정보는 안 넘어가기 때문이었다.

그래서 this를 공부하고 정리했다.

this는 함수가 호출될 때 결정된다.

전역공간에서 this는 전역 객체를 가리킨다

함수 호출시 : 전역객체

  • 함수를 호출하는 순간 함수를 실행하는 주체는 전역객체이기 때문

    function a(){
          console.log(this); //window
    }
    
      a()
    

function b(){
function c(){
console.log(this)
}

c()
}

b();// window

### 메서드 호출시 : 호출한 대상 객체가 바인딩 됨

``` javascript
var d = {
    e:function(){
        function f(){
            console.log(this);
        }
      f(); // window
    }
}

d.e() // d

callback 호출시 기본적으로는 함수내부에서와 동일하다.

  • 기본적으로 함수의 this과 같다.
  • 제어권을 가진 함수가 콜백의 this를 지정해둔 경우도 있다.(call, apply,bind)

call,apply,bind

function a(x,y,z){
    console.log(this,x,y,z);
}

var b = {
    bb:'bbb'
};

a.call(b,1,2,3) // {bb:"bbb"} 1 2 3

a.apply(b,[1,2,3]); // // {bb:"bbb"} 1 2 3

var c= a.bind(b);
c(1,2,3); // {bb:"bbb"} 1 2 3

var d = a.bind(b,1,2);
d(3) //{bb:"bbb"} 1 2 3

생성자함수 호출시

function Person(n,a){
    this.name = n;
      this.age = a;
}

var gisele1 = Person('나다',30);
console.log(window.name, window.age); // 나다, 30

var gisele2 = new Person('나다',30);
console.log(gisele); //Person{age:30,name:'나다'}

ES6의 Arrow function은 this를 바인딩하지 않고, 스코프 체인상의 this에 바로 접근할 수 있다.

다시 맨 처음 문제로 돌아와서 콜백 함수에 class를 바인딩하기 위해서는 세 가지 방법이 있다.

// 1. bind 함수로 this바인딩 해주기
this.onClick = this.onClick.bind(this);

// 2. 콜백함수 내부에서 화살표 함수로 event 넘겨주기
this.field.addEventListener('click', (event) => this.onClick(event));

// 3. onClick 함수를 화살표 함수로 선언하기

this.field.addEventListener('click', this.onClick);
...
onClick = (event) => {
    // arrow function은 자동으로 this바인딩
    const target = event.target;
    if (target.matches('.carrot')) {
      target.remove();
      playCarrot();
      this.onItemClick && this.onItemClick('carrot');
    } else if (target.matches('.bug')) {
      this.onItemClick && this.onItemClick('bug');
      playBug();
    }
  };

'Javascript' 카테고리의 다른 글

파일 업로드 / 다운로드  (0) 2021.11.30
실행 컨텍스트  (0) 2021.11.28
자바스크립트 런타임환경  (0) 2021.09.11
이벤트  (0) 2021.08.28
CRP(Critical render path, 브라우저 렌더링 순서)  (0) 2021.08.21

실행컨텍스트란?

  • context : 이 자리에서 어떤 역할을 수행하는지 알기 위해서는 그 코드에 영향을 주는 주변 코드나 변수들을 파악해야 한다. 그렇게 영향을 주는 환경을 일컬어 context라고 한다. 해당 코드의 배경이 되는 조건/환경
  • 실행 컨텍스트 : 어떤 조건/환경을 지니는 코드 뭉치를 실행할 때 필요한 조건/환경정보
  • 자바스크립트에서 동일한 조건을 지닐 수 있는 조건 : 전역공간, 함수, eval, module
  • 자바스크립트는 함수에 의해서만 context를 구분할 수 있다. 즉, 함수를 실행할 때 필요한 조건, 환경정보를 담은 객체

실행 컨텍스트의 내부의 환경정보

  • 현재 환경과 관련된 식별자 정보들
  • VariableEnvironment : 식별자 정보 수집, 변화 반영x
  • LexicalEnvironment(Environment Record, outer Environment Reference)
    • 각 식별자의 데이터 추적, 변화 반영ㅇ
    • 어떤 실행 컨텍스트의 환경정보가 담긴 사전이라고 생각하면 됨
    • 실행컨텍스트를 구성하는 환경정보들을 모아 사전처럼 구성한 객체를 의미한다
    • Environment Record: 현재 문맥의 식별자 정보, 실행 컨텍스트가 최초 실행될 때 하는 일,
      • hoising : 현재 컨텍스트의 식별자 정보들을 수집해서 environmentRecord에 담는 과정, 실제 일어나는 현상이 아니고 environment Record 과정을 좀 더 쉽게 이해하기 위해서 만든 허구의 개념
    • outer Environment Reference : 외부 환경에 대한 참조, scope chain 현상, 실행 컨텍스트가 수집해 놓은 정보만 접근을 할 수가 있음 -> 변수의 유효범위(스코프)

reference

  • 정재남 - 코어자바스크립트

'Javascript' 카테고리의 다른 글

파일 업로드 / 다운로드  (0) 2021.11.30
this  (0) 2021.11.28
자바스크립트 런타임환경  (0) 2021.09.11
이벤트  (0) 2021.08.28
CRP(Critical render path, 브라우저 렌더링 순서)  (0) 2021.08.21

정산, 이것이 애자일이다

10월의 메인은 정산이었다. 베타 버전을 최대한 빨리 만들어서 실 사용자의 피드백을 반영해 수정하기로 하고 개발을 진행했다. 상세한 기획과 정확한 요구사항을 정의하기 어려운 상황이었기 때문이었는데, 가장 큰 이유는 실제 사용자인 베트남 정산 담당자가 정산 시스템 개발 의도와 시스템 자체에 대해서 이해가 조금 부족했기 때문이었다. 담당자 입장에서는 지금까지 해 오던 방식이 있는데 아직 있지도 않은 시스템을 들이밀며 일하는 방식을 바꾸라고 강요당하는 식이었기 때문에 우선 핵심 기능을 빠르게 만들어 사용하게 하며 요구 사항을 반영하자는 의도였다.

베타 버전의 목표는 휴먼 에러를 최소한으로 줄이기 위해 데이터를 직접 입력하던 부분을 API로 땡겨와 수정을 할 수 있게끔하고, 정산 처리 과정을 담당자들이 따로 연락하지 않아도 시스템상에서 바로 확인해 처리할 수 있게하는 것이었다. 그걸 목표로 2주 일정으로 조금 타이트하게 개발을 진행했다. 타이트한 일정과 베타버전의 개발 범위를 잘 못 알아 나에게 베타버전의 일감 대부분이 몰리고, 다른 팀원들이 개발한건 사용하지도 못한 일이 있었다.

아무튼 베타 버전에 대한 피드백을 받았는데 시스템에 대한 사용상의 피드백이 아닌, 전달한 문서에 엑셀 업로드 기능이 필요하다고 했는데 그 기능이 없어서 사용할 수 없다는 뉘앙스의 피드백이 돌아왔다. 우리 입장에서는 개발한게 사용조차 하지 않았다는 것에 답답함을 느꼈고, 베트남 측에서는 피드백을 보냈는데 전혀 반영이 되지 않아 답답함을 느낀 것 같다. 격앙된 분위기에서 회의가 끝났고 베트남측 요구사항을 다시 반영해 감마버전을 개발하기로 했다.

이 과정에서 느낀 것은 역시 소통의 중요성...상대방의 의도를 정확히 파악해야 하고, 내 의도도 정확히 전달해야 한다. 그리고 그 과정에서 당연히 워딩과 뉘앙스를 신경써야 한다. 시스템, API, 데이터 같은 개발 용어 대신 이해하기 쉬운 단어를 써서 전달할 필요도 있다. 감마 버전이 그들에게 유용한 시스템이 되고, 그걸 전달하는 과정 역시 이번보다는 더 매끄러웠으면 좋겠다.

베타에 있던 많은 기능이 없어지고, 새로운 기능이 추가되어서 고생했던 시간이 좀 허무하기도 했는데, 팀원이 이게 바로 애자일이라는 이야기를 해주었다. 우리는 일주일 주기로 스프린트를 진행하고 매일 데일리 스크럼을 하는데, 애자일의 핵심은 프로토 타입을 빠르게 만들고 빠르게 바꿔가는 것이라고 했다. 그렇구나..! 앞으로도 프로토 타입이 두 세번 정도 크게 바뀔 수 있겠지만 원래 그것을 목적으로 한다는 걸 염두에 두고 개발해야겠다. 그리고 애자일 방법론에 대한 공부로 따로 필요할 것 같다.

도메인에 대한 이해와 회사 내에서의 정체성

지금까지 개발자는 개발을 하는 사람이라고 생각했지, 뭘 개발하는 사람이라는 정의가 없었다. 이번 정산 시스템을 만들고, 최근 우리 팀의 정체성과 로드맵에 대해 고민을 회의를 자주 하면서 그 부분에 대해 많은 생각을 하게 됐다.

회사에서 개발을 하는 이유는 결국 회사에 이익을 가져다주기 위해서다. 기존 시스템의 불편함을 개선해 내부 직원들의 업무 효율을 높이거나, 제공하는 데이터의 정확성과 다양성을 높이고, 비즈니스적으로 더 발전할 수 있는 것을 찾고 개발하는 것이라는 것이라는 생각을 하게됐다.

우리 회사에서처럼 막 확장을 시작한 회사에서는 시스템에 대한 개선 사항이 많다. 그러기 위해서는 회사의 도메인과 다른 팀들이 하는 일에 대해서도 파악해야 한다. 그리고 파트너사에게 제공할 수 있는 것에 대해서도 고민을 해야한다.

그러기 위해서 당장 내가 할 수 있는 일은 우선 주간 회의 때 공유하는 다른 팀의 업무 진행 상황에 대해 더 관심을 가지고, 개발 이외에 비즈니스나 마케팅, 광고 등에 관련된 책도 읽는 것이다.

회복

길었던 두달이었다. 아무것도 할 수 없었던 9월을 지나 10월에는 컨디션을 슬슬 회복했고, 다시 공부를 시작했다. 목표와 로드맵에 대해 고민하고 뭘 공부할지에 대해서도 어느 정도는 정했다. 우선은 스스로 간지러운 부분들을 긁어가고, 구글링 한것들 중에 골라서 깊에 파보기로 했다.

우선은 javascript로 게임을 만들고 있다.

  • 할 시간을 만들기 위해 출근을 더 빨리해 퇴근 시간을 앞당겼다.
  • 하는 이유는 자바스크립트의 기능과 동작원리를 더 잘 알고 싶어서, 그리고 어떤 회사들 과제 테스트로 나오는 문제들이니까 못하면 안된다고 생각해서다.
  • 결과물은 게임프로젝트가 하나 나오고, 자바스크립트에 아는 것이 더 생길 것이다.
  • 방법으로 우선 browser101의 과제 게임을 만들고, 게임을 만든 후에 코어 자바스크립트 강의를 들어 사용했던 개념을 다시 정립할 것이다.

두 달 동안 개발 공부는 안했다고 생각했는데, 일하는 방법과 회사 내에서의 정체성 등을 개발 외적인 부분에 대해 많이 배운 것 같다. 조급해하지말고 천천히 꾸준히 나아가야지.

MIL

  • Henrry의 불편한 코드가 있으면 바로 개선하려고 하는 자세
  • Intl
  • 다국어처리
  • Presentation-view 패턴
  • unstated-next 상태 관리 라이브러리
  • 권한별 로그인, 라우터 처리
  • 파일 업로드

'성장 > 월간 회고' 카테고리의 다른 글

2021년 회고  (0) 2022.01.18
2021년 12월 회고  (0) 2022.01.18
2021년 11월 회고  (0) 2021.11.29
9월 회고  (0) 2021.10.14
8월 회고  (0) 2021.09.06

회사에서 Presentational&container 패턴을 적용하게 되어, 정확한 개념을 공부하고, 공부하면서 알게된 사실을 정리한 글입니다.

Presentaional&container 패턴이란?

개념

  • Hook이 존재하기 전에 컴포넌트 재사용성을 높이기 위해 컴포넌트 내에서 추가적으로 레이어를 나눠 컴포넌트 간 의존도를 낮추기 위한 방법으로 등장했다.
  • 즉, 로직을 수행하는 컴포넌트와 UI를 보여주는 컴포넌트가 분리된 패턴이다.

Presentational component

  • 사용자가 직접 보고, 조작하는 컴포넌트
  • stateless : state를 직접 조작하지 않고 container component가 내려준 prop의 함수에 의해 state를 변경한다.
  • 작은 레고 블럭처럼 가능한 작게 만들어야 한다.
  • 상태를 거의 가지지 않으며, UI에 관련된 상태만 가질 수 있다.

Container component
- 어떠한 동작을 할 것인가에 대해 책임진다.
- statefull : 주로 상태를 가지고 있다.
- side effects를 만들 수 있다.
- 절대로 DOM 마크업 구조나 스타일을 가져서는 안된다.

이점

  1. presentational component의 재사용성이 뛰어나다.
    로직이 포함되어 있지 않기 때문에 다른 컴포넌트와의 의존도가 낮아 다양한 container와 조합해 재사용하기 쉽다.
  2. 앱의 기능과 UI에 대한 구분이 쉬워지므로 구조에 대한 이해가 쉬워진다.
  3. 반복되는 마크업 작업을 줄일 수 있다.
  4. 같은 state를 다른 container에게 props로 전달함으로써 상태를 공유할 수 있다.

코드예시

사용하지 않는 걸 추천합니다


이 패턴의 창시자인 Dan Abramov님이 2019년에 더 이상 이렇게 구성 요소를 분할하지 않는 것이 좋다는 말을 남기셨다. 잘 쓰고 있어서 찬양하려고 글을 쓰는 중이었는데..?

코드베이스에서 자연스럽다면 이 패턴이 유용할 수도 있지만, Hooks를 사용하면 임의의 분할 없이 동일한 작업(Hook은 로직과 표현의 분리를 가능하게 한다)을 수행할 수 있고, 필요에 의해서가 아닌 맹목적으로 사용하는 경우를 많이봤기 때문이라고 한다.

여전히 중요하다고요?

하지만 2021년에도 해당패턴이 중요한 이유를 설명한 글을 찾았다!

컴포넌트 안에서 데이터를 처리하는 로직을 사용하는 경우 컴포넌트의 재사용성이 떨어지는 것은 사실이다. 특히 특정 라이브러리와 프로그램의 아키텍처에 강하게 의존성이 생긴다. 예를 들어 react-intl 라이브러리에서 제공하는 hook을 쓰다가, react-i18n으로 라이브러리를 바꾼다면? 라이브러리리에서 제공하는 로직을 사용하는 모든 컴포넌트를 찾아 수정해야할 것이다.

presentatation 계층의 컴포넌트라면 스타일이나 Bootstrap, Material UI와 같은 라이브러리와 연결하는 것이 좋다.

Presentainal Component

  1. html, css 및 기타 프리젠테이션 구성요소만 사용할 수 있다.
  2. 다른 App에서도 사용할 수 있어야 한다. (App의 설계나 framework에 종속되지 않음)
  3. style 관련된 hook만 포함해야 한다.
  4. 고차 컴포넌트로 래핑되지 않는다. 예를 들어 리덕스를 사용한다면, 더 높은 순서의 연결 컴포넌트가 컨테이너 컴포넌트에 추가되어야 한다.
  5. 컴포넌트의 시각적 특성을 변경하는 props를 종종 허용한다.
  6. 완전히 다른 스타일 시트를 로드하는 props를 종종 허용한다.

Container Component

  1. html이나 style에 관한 것은 포함하지 않는다.
  2. presentation component나 다른 container component를 사용할 수 있다.
  3. 로직은 hook file에 들어간다. (reacdt-hooks-testing-library를 사용해 test하기 위함)
  4. Props를 받을 수 있다.
  5. Context를 사용하고, side effect를 만들고, db에 CRUD 작업을 요청할 수 있다.
  6. CRUD 작업이 성공했을 때 UI에 즉시 반영하고, 실패했을 때는 UI를 롤백한다.
  7. 항상 cotnainer 구성 요소에서 테스트 ID를 선언하고 구성 요소에 테스트 ID를 전달한다.

정리

회사에서도 함수형 컴포넌트와 Hook을 사용했고, container도 unstated-next가 제공하는 hook을 이용해 container를 만들었다.
개념적으로 view와 데이터 관련 로직을 분리했지만, container component가 아닌 context에 관련 로직을 작성했다.

그렇게 함으로써 컴포넌트의 재사용성이 높아졌고, 불필요한 컴포넌트의 수를 줄일 수 있었다. 예를 들어 영화목록 페이지라고 하면
Movie Page > Movie Table 컴포넌트 = 데이터 로직 + table 컴포넌트 로직 으로 구성했다면
Movie Page + Container --props--> table 컴포넌트 로 구성을 할 수 있다.

그리고 구조적으로도 파악하기 쉽고 presentatonal component가 깔끔해졌다.
Container가 복잡해지는 문제가 있지만 관심사에 따라 Container를 분리하면 될 것 같다.

이번 내용을 정리하면서 Presentational - container pattern의 개념과 등장배경에 대해 알 수 있었고, Hook과 ContextAPI에 대해 더 공부해야겠다고 느꼈다.


reference

'React' 카테고리의 다른 글

나만의 React 라이브러리 만들기  (0) 2022.01.18
리액트에서 Variable과 State의 차이가 뭘까?  (0) 2022.01.13
React Query  (0) 2021.07.09

내가 이 웨비나를 들은 이유와 얻고자 하는 것

급격한 체력저하와 구체적인 목표 상실로 성장이라는 단어에 신물이 나고, 공부에 흥미를 잃었고, 공부에 대한 방향성도 잃은 요즘. 동기부여가 필요했고, 구체적인 계획을 세우고 싶어서 웨비나를 신청했다.

이번 코드 리뷰의 주제는 크게 개발자의 성장, 오픈소스, 해외 취업, 발표였다.
나의 주된 니즈는 성장을 어떻게 해야하는지, 오픈소스 공부는 어떤 식으로 해야하는지, 해외 취업을 하려면 어떤 것을 준비해야하는지였고, 결과적으로 가려운 부분을 잘 긁어주는 시간이었다.

세션별로 기억에 남는 부분을 정리했고, 마지막에 생각을 정리했다.

Session 1. 성장하는 개발자의 '공유의 기술' - 탈잉 박미정님

  • 내가 개발자로서 성장하기 위해 어떤 행위들을 어떻게 해오고 있는지.
  • 개발자로서 성장?
    • 개발자로서의 나의 능력
    • 개발자로서 다른 개발자에게 끼치는 영향력이 커지는것

💡 시작하기 전에 고민해야할 것
1. 나 지금 이거 할 시간있어?
2. 왜 하는건데?
3. 그래서 결과물이 뭐야?
4. 그럼 어떻게 할까?

1. 스터디 모임/공부

  • 왜? 업무를 숙지하고, 업무를 더 잘하기 위함
  • 결과물 ? 일정과 품질을 가져가며 업무를 해내는 것
  • 어떻게? 계획 된 프로젝트 내에서 필요한 기술을 리스트업, 업무 계획을 세울 때 공부 계획도 세우기
  • 기존의 것을 더 정확히 이해하기 >>> 새로운 것을 학습
  • 업무를 할 때 모호하게 알고 있던 것들, 필요한 것들 위주로 공부를 하는게 효과적이었다 -> 결과가 가시적으로 나오기 때문

2. 블로그 글쓰기

  • 왜? 문제 해결을 통해 깨달은 것을 온전한 내 것으로 만들기 위함
  • 결과물? 차곡차곡 쌓인 나의 글과 경험, 깨달음
  • 어떻게?
    • 내가 겪은 문제 상황을 자유롭게 노트에 적음
    • 2주에 한 번 돌아보고 키워드 선정 후 작성
    • 내용 구성: 문제 상황에 대한 설명 -> 해결책 -> 그 해결책을 선택한 이유
    • 본인이 잘 읽히는 글의 포맷을 따라 쓰기

3. 집필

  • 왜? : 내 가치관을 녹여서 책의 형태로 필요한 것을 제공하기 위함

  • 결과물? : 내 이름으로 된 책!

  • 어떻게?

    • 평소에 왜 없지?라고 생각햇던 주제 리스트 업
    • 내가 그 주제를 경험했거나, 곧 경험할 예정인지 판단
    • 출판사에 제안
    • 집필 시간 계획
  • 이타적으로 필요하다고 판단 한 것, 그리고 스스로가 묻어나는 것

  • 정말 많은 고민과 시간이 필요한 일!

4. 발표

  • 왜? 하드스킬-동기부여가 필요할 때, 소프트스킬-개발 문화에 기여하고자 할 때

  • 결과물? 필요한 기술에 대한 학습

  • 어떻게?

    • 주제 선정
    • 데드라인 공표

명확하고 구체적인 목표를 정하고, 결과물을 만들어, 공유를 통해 피드백을 수집한다.

Session 2. 혼자서 오픈소스로 성장하기

  • 개발자에게 필요한 능력 : 업무 태도, 커뮤니케이션, 협업, 업무 파악, 문제해결, 코딩능력

    좋은 코드를 작성하려면 우선 코드를 많이 작성해야한다. 많이 시도 하기. 좋은 소스, 나쁜 소스 다 많이 작성해본다.

1. 오픈 소스로 개인 프로젝트를 만든다

  • 공부할 기술을 활용해 볼 소프트웨어를 만든다.
    • 직접 써보면서 특징을 익혀서 어떤 상황에 적합한지를 몸소 배우기.
  • 요구사항을 직접 정의할 수 있다.
  • 게으른 사람 : 힘든 일을 쉽게 해결하려고 하는 사람.

2. 기존의 소프트웨어를 다시 만든다

  • 아이디어 고민을 하지 않아도 되고 요구사항이 이미 정해져 있다
  • ex) 웹서버, 랜덤 워드 제너레이터, HTTP 클라이언트, 날짜/시간 관련, 라이브러리
  • 장점 : 참고할 소스코드가 있다. 오픈소스 안에 어떻게 구현되어 있는지 나와있다. 내부 구조를 이해할 수 있다.

3. 오픈소스 프로젝트의 코드를 읽는다.

  • 조엘 스폴스키(스택 오버플로우) : 코드를 작성하는 것보다 읽는 것이 더 어렵습니다.
  • 많이 읽어볼수록 더 빨리 잘 읽을 수 있다.
  • 방법 : 자주 사용하는 프로젝트의 코드를 본다, 버그나 이슈가 잇을 때 코드를 본다, 문서가 잘 이해 안 될 때 코드를 본다. 내부 동작이 궁금해지면 코드를 본다.
  • 눈으로 읽는 것이 아니라, 실행 해보고, 로그를 찍거나 디버거도 돌려보고 학습 테스트를 작성해 보기도 한다.
  • 작은 프로젝트부터 보기!, 아니면 프로젝트가 크다면 0.1 버전을 본다.

4. 협업하는 방법을 배운다.🌟

  • 대부분의 오픈소스도 협업으로 만들어진다.
  • 메인테이너의 입장에서 보기
    • 어떤 이슈가이해하기가 좋은지
    • 어떤 이슈가 문제 파악이 쉬운지
    • 어떤 이슈가 처리가 안되는지
    • 어떤 Pull Request가 리뷰하기 좋은지
    • 어떤 Pull Reqeust가 막혀있는지
    • 예 : requirement, description of the change, alternate design, why should this be in core?(이게 왜 중요한지?), benifits, possible drawbacks(상상되는 문제), applicable issues - 코드리뷰할 때 해보기

5. 오픈 소스의 생태계의 시스템을 학습한다.🌟

  • 실수를 막기 위한 다양한 시스템이 있음.
  • 그 절차와 도구가왜 필요하고, 협업을 하는데 뭐가 좋은지
  • 예)CI, Formatting, Linting, Unit Test, Code Coverage(coveralls, codecov), changelog, relase notes

Session 3. 개발자의 슬기로운 발표생활 : 발표기회를 만드는 방법, 그리고 놓치지 않는 방법

발표를 하는 것은 자기 브랜딩과 커리어의 기회가 된다.

발표 기회를 만드는 방법?

발표할게 없다?뭘해야할지 모르겠다?

  • 발표는 내 견해/관점을 공유하는 것
  • 나의 경험을! 나의 관점에서!
  • 평소에 발표할 생각으로 정리해두기
  • 우려먹어도 괜찮다! 같은 소재라도 컨퍼런스의 주제와 대상에 따라 다른 내용이 될 수 있다.

성장은 항상 불편함과 고통 속에서 이루어진다.

발표 기회를 놓치지 않는 방법

  • 짧게! 핵심 먼저 전달!
  • 모든 이야기 전달 < 중요한 내용 전달. = 내가 전달하고자 하는 것을!!
  • 장표는 한눈에, 발표자에게 전달, 속도감
  • 발표를 잘하려면 연습 또 연습

공유의 즐거움

  • 내가 뭘 모르는지 모를 때 힘들었다.
  • 다른 사람들의 발표를 많이 듣고 정리하기.
  • 공유는 나의 성장과 함께 성장하는 방법
  • 누군가의 발표로 내가 거인의 어깨에 올라갔듯, 누군가도 제 어깨에 올라왔으면

Session 4. 오픈소스 프로젝트 키우기 : 파종부터 추수까지! 오픈소스 재배 일기

파종 - 어떤 오픈 소스 프로젝트를 만들까?

  • 좋아하는 기술? 잘하는 기술? 좋아하는 언어? 잘하는 언어? => 하고싶은 걸 하세요

발아 - 프로토타입 만들기

  • 프로토타입을 만을 때 고려해야 할 사항
  • 오랜시간이 걸리면 의욕이 떨어진다.
  • 꼭 필요한 기능만 구현해서 프로토타입을 출시한다.
  • 큰 프로젝트를 만들려고 하면 의욕이 떨어져 결국 방치하게 됨. 연사님께도 이런 프로젝트가 있음!

써레질 - 빌드/배포 자동화 및 각종 툴 설치

  • 지속적인 통합 : 여러 개발자가 작성하거나 수정한 소스를 지속적으로 통합하고 테스트하는 것
    • GitHub Actions, Jenkins, Travis CI, CircleCI, appVeyor, ...
  • 지속적인 배포 : 개발, 통합, 배포, 릴리즈, 테스트를 자동화해 지속적으로 배포하는 것
  • 코드 커버리지
  • 정적 코드 분석 : 코드 내에서 발견될 수 있는 보안 취약점, 잠재적인 결함, 위험 등을 찾는 과정

(더 있지만 정리를 못했다)

Session 5. Zero to Hero : 비개발자에서 Be개발자로 성장하기까지의 과정

1. 나만의 커리어 로드맵을 그려라

  • IT업계 커리어는 사다리가 아닌 정글짐. 신기술, 회사 내 업무, 관심사에 따른 커리어 변환이 잦음

  • 내 관심사와 성향에 맞는 개발 분야 및 직무 찾기

  • 나는 xx 개발자로 성장하기 위해 어떤 노력을 할 것인가?

    • Discovery : 현재 나의 상황을 객관적으로 진단하고 필요한 지식과 역량을 발견
    • Plan : 구체적인 목표와 액션 플랜을 설정
  • 커리어 : 향후 12년, 35년 후 나의 모습은? 나의 현재 어느 위치에 잇는가?

  • 개발 : 내가 개발해야 할 역량은? 이를 성취하기 위해 해야할 일은?

  • 관심있는 회사와 채용 공고를 3개 이상 찾아보고 필요한 소프트스킬, 하드스킬을 정리해보기

  • 관련 업계 롤모델을 찾아보고 배울 점을 정리해보기

  • Career Ladder 기준으로 개인 역량 진단

  • 역량 개발 목표 설정

    • 분기별 로드맵
    • 단 시간에 성취할 수 있는 아주 작은 것부터 시작하기
    • 기본기에서 탁월함이 나온다(프로그래밍 기초의 중요)
    • 소프트스킬(커뮤니케이션 능력, 리더십)도 역량이며 경쟁력
  • 70:20:10의 학습 법칙 : 학습의 70프로는 업무 경험을 통해서, 20프로는 타인과의 상호작용을 통해서, 10프로는 교육을 통해서 일어난다

2. 영어로 개발 지식을 쌓자

  • 영어로 강의 듣고, 개발문서 읽기
  • 3~5개월 들으니 귀가 트이고, 문서가 술술 읽히기 시작함
  • 영어는 내 세상을 넓힐 수 있는 수단

3. 학습과 취업을 동시에 잡는 개발 프로젝트를 만들자

  • 회사 업무 중 만난 문제를 발전시켜 프로젝트를 해도됨

4. 커뮤니티와 함께 성장하자

  • 공통의 관심사를 가진 사람들과 만남을 통해 좋은 개발자로 빨리 성장하고 있다.

Fact, Feeling, Finding

우선 발표 자체가 좋았다. 내용과 구성, 톤이 매끄러웠고, 일잘러의 기운이 느껴졌다. 나도 저런 사람이 되고싶다고 생각했다. 그래서 어떻게하면 될 수 있을까, 지금 내게 부족한 것은 무엇일까에 대해 생각해 봤다.

✔ 실력 ㅠㅠ
✔ 정확한 의사소통 - 간결하고 정확한 내용을 똑똑한 톤으로.
✔ 지레짐작하지 말고 끝까지 듣고, 의도를 파악한 후 말하기.!!

웨비나를 통해 얻은 것중 실력을 올리기 위해 내가 당장 하고싶은 것을 정리하자면

모든 일을 하기 전에 우선 왜? 결과물은? 어떻게?을 생각해 볼 것. 행위를 의식의 수준으로 끌어올릴 수 있고, 결과물이 손에 잡히기 때문에 동기부여도 될 것 같다.

오픈 소스 코드를 많이 읽어볼 것이다. 요즘은 안 하고 있는 매주 개발 글쓰기 주제가 없을 때는 오픈 소스를 읽어본 내용을 정리해야지! 라고 생각하는 중이다. 오픈 소스를 읽을 때는 코드만 읽는다고 생각했는데, 그 협업하는 방법이나 시스템을 배울 수도 있다는 점을 새로 알게 되었다.

PR 올릴 때 : requirement, description of the change, alternate design, why should this be in core?(이게 왜 중요한지?), benifits, possible drawbacks(상상되는 문제), applicable issues에 대해 먼저 생각해보기.

뭘 공부해야할지 모르겠고, 하기 싫을 때는 개발자 커리어 로드맵 생각해보고, 가고싶은 회사 채용공고 확인하는 게 도움이 많이 될 것 같다.

마지막으로...VOD를 보다가 요청 리소스 과다로 실행할 수 없습니다.라는 에러메시지가 떴는데 지나치게 개발자의 언어로 쓰인게 아닌가싶었다 ㅎㅎㅎ

'성장' 카테고리의 다른 글

Udemy 프론트엔드 개발자 성장 가이드  (0) 2022.01.18
Input  (0) 2022.01.13
요즘 고민  (0) 2021.12.01

레거시 코드 이사하기

지금 운영하고 있는 서비스를 새로 만든 admin 프로젝트에 합치는 작업을 했다.

  • redux + redux-saga 사용하고 있는 코드에서 redux를 걷어내고 react-query를 사용해 api 호출을 하고, 상태관리 라이브러리는 zustand라는 것을 도입했다.
  • react-bootstrap을 사용하던 UI를 antd로 바꿨다.
  • 권한이 추가되어 권한에 따라 다른 로그인 화면을 보여주고 메뉴, 라우터에도 권한을 적용했다.

로그인을 했는데 페이지가 안보이네요?

로그인을 하고 랜딩페이지에 들어갔는데 하얀 화면이 뜨고 아무것도 안 나오는 버그가 있었다.

라우터에 해당 url이 없을 때 나오는 화면이었다. 라우터를 권한 별로 처리를 했는데 왜 화면이 안나오지?

기존 코드에서는 로그인했을 때 토큰을 lcoalStorage에 저장하고, 토큰 정보를 디코딩해 Role을 얻어 낸 다음, role을 키로 routerList 객체를 불러온다.

원인을 찾아보니 로그인하기 전 라우터가 role이 없는 상태로 셋팅이 되는데, 로그인을 해도 리렌더링이 일어나지 않아 계속 role이 없는 상태의 라우터만 있기때문이었다.

문제를 해결하려면 로그인 후에 리렌더링을 일으키는 액션이 필요했다. toggle state를 만들어서 로그인을 할 때마다 상태를 바꿀까, 정보를 가져오는 api를 호출할까 등의 방법을 고민하다가 결국 zustand라는 상태관리 라이브러리를 도입하기로 했다.

앞으로 더 다양한 도메인이 추가되고, 권한처리도 복잡해질텐데 상태관리 라이브러리를 쓰는게 편할 것 같다는 판단과 컴포넌트를 잘게 쪼개다보니 3단계 이상 데이터를 드릴링하는 경우도 많고, 새로고침할 때 사용자 정보를 가지고오는 api를 호출하는 로직이 거의 모든 페이지에 들어있어, 너무 자주 호출을 하는 문제가 있었기 때문이다.

zustand를 선택한 이유는 redux 보다 코드량이 현저히! 짧기 때문이었다. zustand를 적용하니 위의 버그는 당연히 사라졌고, 사용자 정보를 관리하니 라우터나 메뉴, 헤더의 처리가 훨씬 간편해졌다.

리팩토링 2판 스터디 마무리

2달정도 했던 리팩토링 2판 읽기 스터디를 마무리했다.

스터디 진행방법은 시간을 정해 각자 읽고 싶은 부분을 읽고, 정리하고, 다른 사람들에게 간단히 설명하는 방식이었다.

이 책을 선정한 이유는 매일 하는 코드리뷰와 리팩토링을 더 잘하기 위해, 안 좋은 코드의 예는 구체적으로 어떤 것이 있는지를 알고 싶어서였고, 책 내용을 바로 적용해볼 수 있을거라는 기대 때문이었다.

우선 진행방식에 대해 이야기하자면 개인적으로는 집중해서 읽고, 다른 사람에게 설명하기 위해 내용을 정리하면서 읽고, 설명하면서 또 내용을 한 번 더 정리할 수 있어서 효과적이었다. 다른 사람들의 설명을 듣는 것은 내용을 이해한다기보다 이런 내용이 있구나~하고 옅게 점을 찍고, 나와 같은 부분을 읽었을 때 다른 부분을 인식하는데에 더 의미가 있었던 것 같다.

책을 읽고나서 Pull reqeust 하기 전에 한 번 더 코드를 읽어보고 리팩토링을 하려고 신경쓰고 있고, 목적과 기능이 잘 드러나는 이름을 짓기 위해 노력하고 있다. 그리고 여러 기능이 섞여있는 함수는 각각 기능을 분리하려고 하고 있다.

다음 이 책을 펼 때는 조금 더 많은 부분이 보여서, 더 많이 익힐 수 있으면 좋겠다.

조금 긴 휴식

9월은 체력도 의욕도 없어서 따로 시간내서 공부를 하지 않았다. 일주일에 한 개씩 개발 글쓰기로 정했는데 한달동안 한 개 썼다. 하하하하하 그럴 수 있지.

그동안 푹 쉬고, 아무것도 안 하면서 지겨움도 느끼고, 약도 챙겨먹으면서 체력도 보강했더니 10월 중순인 지금은 다시 의욕도 생기고, 퇴근하고 남은 에너지도 있다. 9월의 휴식 덕분에 또 앞으로 나아갈 힘이 솟아나고 있다.

지금까지는 성장이라는 단어에 신물이 나는... 뭘하고 싶은지 모르는... 뭐가 필요한지도 모르는... 어디서부터 손을 대야할지 모르는... 혹은 알고싶지 않은..? 그런 상태였다. 하지만 아무것도 안 하는 게 슬슬 지겹고, 무능력하고 못하는 건 또 싫으니까 또 무언가를 해가겠지.

'성장 > 월간 회고' 카테고리의 다른 글

2021년 회고  (0) 2022.01.18
2021년 12월 회고  (0) 2022.01.18
2021년 11월 회고  (0) 2021.11.29
2021년 10월 회고  (0) 2021.11.06
8월 회고  (0) 2021.09.06

자바스크립트 런타임 환경


출처 https://blog.sessionstack.com/how-does-javascript-actually-work-part-1-b0bacc073cf

자바스크립트가 구동되는 환경을 이해하기 위해 공부하며 정리한 포스트입니다.

자바스크립트는 기본적으로 싱글 쓰레드 기반 언어이기 때문에 호출 스택이 하나입니다. 따라서 한 번에 한 작업만 처리할 수 있습니다. 만약 호출 스택에 처리 시간이 오래 걸리는 함수가 있으면 그 작업을 처리하는 동안 브라우저는 멈추게 됩니다. 하지만 자바스크립트는 런타임 환경인 브라우저가 제공하는 멀티쓰레딩을 이용해 다양한 작업을 동시에 할 수 있습니다. 자바스크립트는 V8 엔진(Memory Heap + Call stack) + 브라우저가 제공하는 Web API + 이벤트루프 + 콜백 큐로 구성된 환경에서 동작합니다.

자바스크립트 엔진 (V8)

크롬브라우저가 javascript 코드나 스크립트를 받으면 V8 엔진이 코드를 파싱합니다. 먼저 문법 오류를 먼저 검사합니다. 위에서부터 아래로 코드를 읽으며 JS 코드를 컴퓨터가 이해할 수 있는 기계어로 번역합니다.

V8 엔진은 메모리힙과 콜스택을 가지고 있습니다.

Memory Heap(메모리 힙)

변수나 함수 선언은 메모리 힙에 올라갑니다.

Call stack(호출 스택)

호출 스택에는 실행되는 코드가 쌓입니다. 스택에 함수가 추가되면 엔진은 그 코드를 파싱하고, 변수들을 힙에 올립니다. 현재 실행되고 있는 함수가 호출 스택의 가장 상단에 위치하는데, 함수가 값을 return하거나 web api를 호출하면 스택에서 제거(pop)되고, 그 다음 함수를 실행합니다. 호출 스택이 완전히 빌 때까지 이 과정을 반복합니다. 스택이 하나이기 때문에(싱글 스레드) 이 동기적이고, 한 번에 한 동작만 수행합니다.

Web APIs

Web API는 event listner, HTTP/AJAX request, timing function(setTimeout) 등의 기능을 제공합니다. call stack에서 함수가 Web API를 실행하면 스택에서 제거되며, Web API의 콜백 함수는 큐에 저장됩니다.

Callback Queue

콜백큐에는 콜백함수가 저장됩니다. Queue이기 때문에 먼저 들어온 것이 먼저 실행됩니다.(FIFO) 콜백큐에도 두 가지가 있습니다.

Microtask Queue

Promise나 Mutation Observer의 콜백이 들어옵니다. Task Queue보다 우선순위가 높고, Event Loop는 빌 때까지 call stack에 콜백함수를 넣습니다.

Task Queue

일반적인 콜백함수가 들어옵니다. Microtask Queue보다 우선 순위가 낮고, 가장 앞에 있는 콜백 함수만 Call Stack에 들어갑니다.

Microtask Queue Task Queue
Promise, Mutation Observer의 콜백 함수 이외의 콜백함수
우선 순위 높음 우선 순위 낮음
큐가 빌 때까지 event loop가 실행 제일 앞의 task만 실행

Render Seqeunce

변형한 코드를 화면에 업데이트하 위해 주기적으로 호출합니다. Request Animation Frame의 콜백이 전부 실행되면 Render Tree를 그리고 Layout, Paint 과정이 일어납니다.
예를 들어 아래와 같은 코드를 실행했을 때, 배경 색상이 노란색 되는 이유는 각각의 콜백을 모두 실행한 결과를 화면에 그리기 때문입니다.

body.style.backgroundColor = 'red'
body.style.backgroundColor = 'blue'
body.style.backgroundColor = 'yellow'

Event Loop

이벤트루프는 Call Stack이 비면 Task Queue의 콜백함수를 Call stack에 넣는 역할을 합니다. 이벤트루프가 아래의 그림처럼 순회합니다. Call stack의 function이 실행하는데 오래걸릴 때 화면에서 아무 변화가 없는 이유는 event loop가 Call stack에 머물러있어 다음 과정인 Render Sequene를 실행하지 못하기 때문입니다.


출처 드림코딩 - 프론트엔드 필수 브라우저101


📑 referece

'Javascript' 카테고리의 다른 글

this  (0) 2021.11.28
실행 컨텍스트  (0) 2021.11.28
이벤트  (0) 2021.08.28
CRP(Critical render path, 브라우저 렌더링 순서)  (0) 2021.08.21
Web API  (0) 2021.08.12

GPM Admin 프로젝트

GPM은 pixel이라는 페이스북의 분석툴을 입력하고 관리하는 백오피스다. 레거시 없이 새로 빌드해 7월 중순부터 지금까지 약 6주정도 개발을 했다.

폴더 구조에 대한 고민

POC 기간부터 폴더 구조에 대한 고민이 많았다. 나는 아토믹 디자인 패턴에서 발전시켜 나가려고 했는데 한계가 있었고, 회사에 있던 기존 구조를 따라서 작업을 하다 아래의 구조로 정착하게 되었다.

공통으로 사용하는 로직은 최상단에서 관리하고, features라는 하위 폴더 안에 각 도메인에 관련된 로직을 작성하는 방식이다. 이렇게하면 도메인이나 기능이 추가될 때 확장하기 쉽고, 도메인간 결합도가 낮아져 유지 보수가 쉬울거라고 판단했다. 이렇게 작업을 해보니 더 직관적이었고, 리팩토링이나 추가 기능을 구현할 때도메인은 전혀 상관하지 않고 해당 폴더 내부에서만 작업할 수 있었다. 꽤 마음에 드는 구조라 회사 프로젝트나 개인프로젝트나 당분간은 이 구조로 작업할 것 같다.

https://github.com/alan2207/bulletproof-react?fbclid=IwAR0Q3gck2B9CZyPaU5bEsA96NADfd0AA1t79uc_ZvN1C80JuAAN1w3ScvsQ

├── assets
├── components
│   ├── Elements
│   ├── Form
│   └── Head
│   └── Layout
├── features
│   ├── auth
│   │   ├── api
│   │   ├── components
│   │   ├── routes
│   │   ├── types
│   │   ├── hooks
│   │   └── index.ts
│   ├── comments
│   ├── teams
│   └── user
├── hooks
│   └── useHooook.ts
├── lib
│   ├── auth.tsx
│   ├── axios.ts
│   ├── react-query.ts
├── store
├── types
└── utils
    ├── format.ts
    ├── lazyImport.ts
    └──  storage.ts

react query 도입

api 요청은 일반적으로 redux middleware를 이용했는데 이번에 react-query를 도입했다.
사용해보니

  • 미들웨어를 사용했을 때 보다 로직이 많이 줄어든다
  • loading, error 등의 상태 처리가 용이하다
  • redux를 쓰지 않고도 서버에서 받아온 데이터를 여러 컴포넌트에서 사용할 수 있다
    단점은
  • click이벤트 등을 이용해 refetch를 할 때 useEffect를 이용해야 한다

자세한 사용기는 따로 포스팅을 할 예정이다!

redux 안 쓰기

api 호출을 제외하고 공통 상태 관리를 할 필요 없을 것 같아 이번 프로젝트에서 리덕스를 안 쓰기로 했다. redux로 주로 처리하던 로그인에서 애를 많이 먹었는데 어찌어찌 처리를 했다.(어찌를 다시 확인하기)

내가 작업한 컴포넌트에서 다른 도메인으로 분리해놓은 두 가지를 한 모달에서 사용하는 케이스가 있어서 최상위 컴포넌트에 서로 공유하는 데이터를 넣어두고 props로 전달하며 구현을 했는데 context 사용했으면 어땠을까요라는 피드백을 뒤늦게 받았다. 상태관리 라이브러리를 무조건 쓰면 안된다는 컨셉이라고 생각을 했기 때문에 리덕스의 필요성만 간절히 느끼며 작업을 했는데....그런게 아니었다....context는 생각도 못했다. 리덕스를 사용하지 않았지만, 사용하지 않았기 때문에 오히려 리덕스와 상태관리, context 등등에 대한 전반적인 이해가 부족하다고 느꼈다. 요즘 왜 리덕스가 미움을 받는지, 다른 새로운 상태 관리 라이브러리는 무엇이 있는지, 왜 나왔는지에 대해 공부할 예정이다.

JIRA

JIRA를 이용한 스프린트 애자일 방식으로 프로젝트를 진행했다. 프로젝트를 하며 스스로 가장 발전한 부분이 이 부분이라고 생각한다. 집중이라는 스프린트의 컨셉을 이해하고, 잘 실행했다고 생각한다. 티켓을 잘게 쪼개서 작업하니 내가 해야할 것, 하고 있는 것을 직관적으로 파악하고, 그것에 집중할 수 있었다. 작업하는 중에 다른 수정 사항이 보이면, 바로바로 처리하고 싶은 욕구가 생겼지만 티켓을 새로 만들고 하던 작업을 마친 다음 작업을 하는게 효율이 훨씬 좋았다. 그리고 PR했을 때 리뷰어들이 코드를 파악하기도 수월하다. 일하는 방식에 익숙해지고 있는중이다. 추가적으로 애자일 방식이 뭔지 공부가 필요하다.

코드 리뷰와 리팩토링 그리고 페어 프로그래밍

프로젝트 중 가장 힘들고! 가장 보람있었던 것이! 페어 프로그래밍을 통한 리팩토링이었다. 우리의 페어 프로그래밍의 목적은 각자 다른 코딩 스타일을 맞춰 앞으로의 프로젝트에서도 일관된 스타일을 유지하고, 리팩토링을 통해 코드 품질을 높이기 위해서였다. 내가 짠 코드를 상대에게 이해시키고, 나와 생각이 다른 부분을 맞춰가고, 내가 고수하던 스타일을 버리는 과정이 쉽지는 않았지만, 다른 관점, 다른 방식을 많이 배울 수 있었고, 리팩토링을 통해 더 나은 결과물을 만들 수 있었다. 다만 과정이 힘들어서 좀 더 즐겁게 할 수 있는 다른 방식이 있는지는 궁금하다. 그리고 antd 사용법을 통일하거나 사용하는 방법이나 랩핑 레벨 등을 맞추고 싶었는데 못해서 아쉽다.

맥락에 대하여

맥락없이 일하고 있다는 것을 요즘 많이 느낀다. 분명 1주일 스프린트 단위로 일을 잘 쳐냈는데 릴리즈가 많이 늦어졌다. 구현은 2~3주 만에 빨리했는데...? 전체 프로젝트 일정에 대한 인식이 없었다고 생각한다. 그리고 벌써 일한지 두 달인데 회사 도메인이나 프로덕트에 대한 이해가 많이 부족하다. 나는 아직 신입이니까라는 생각으로 깊이 이해하려고 하지 않았던 것 같다. 또 반성... 일을 할 때 전체 맥락을 항상 생각하면서 일하기!!!

공부 + 읽은 것

리팩터링 2판

리팩터링 말만 많이 듣고, 하는 시늉만 했지 왜 하는건지 어떻게 하는 건지는 잘 몰랐다. 그걸 알기 위해 주 2회 스터디를 하고 있다. 이번 달에는 리팩터링이 무엇인지, 왜 하는지에 대해서 그리고 코드의 어떤 부분을 리팩토링 해야하는지에 대해 읽었다. (ch 1,2,3)

왜 개발자 일의 8할이 이름짓기인지 이해했다. 피알하기 전에 리팩토링을 하자는 원칙을 세우고 실천중인데 자꾸 까먹는다..^^;

브라우저 101

자바스크립트와 브라우저 작동 방식을 더 잘 이해하기 위해서 듣고 있는 강의다. 강의 내용은 내 목적에 부합하는데 진도가 너무 안 나간다. 어쨌든 이번 달에는

  • web api
  • 이벤트
  • crp에 대해 공부하고 정리했다.

다음 달 목표

  • 정산 프로젝트 화이팅
  • browser 101 강의 다 듣기
  • 운동 일주일에 3번 꼭하기
  • 운전면허 따기
  • 리팩토링 부지런히 읽기

'성장 > 월간 회고' 카테고리의 다른 글

2021년 회고  (0) 2022.01.18
2021년 12월 회고  (0) 2022.01.18
2021년 11월 회고  (0) 2021.11.29
2021년 10월 회고  (0) 2021.11.06
9월 회고  (0) 2021.10.14

+ Recent posts