
## 일에서 만족감을 얻는 사람들

- 만족하며 일하는 사람들은 일을 하면서 도전정신이 샘솟는다. 일은 그들의 능력을 최대한 발휘하게 하여,
한계를 벗어나 편안한 영역 밖으로 나가게끔 밀어붙인다. 이러한 운 좋은 사람들은 일이 재미있다고 생각한다. (p.12)
- 그들은 업무시간에 어느 정도의 자율성과 재량권을 갖는다. 그리고 그 자율성과 재량권을 이용하여 전문지식을 쌓거나
정통함의 경지로 나아간다. 그들은 근로자로서 또 인간으로서 두 역량을 모두 계발하며 새로운 것을 배운다. (p.12)
- 일을 하는 대가로 봉급을 받는 한, 사람들은 자신이 하는 일이 가져올 결과를 그다지 중요하게 생각하지 않는다. (p.20)

## 텔로스와 소명의식

- 루크가 자신의 일에서 추구한 것은 철학자 아리스토텔레스가 `텔로스(telos)`라고 불렀던 것,
바로 그가 속한 조직의 '목적'에 의해 형성되었다. 환자들의 건강을 증진하고, 질병을 치료하고, 고통을 줄이는
그 병원의 목적이 루크가 자신의 일을 바라보는 방식에 깊이 내재해 있었다. (p.38)
- 루크는 자신이 속한 조직의 목적을 믿었다. 이 믿음은 그의 일을 의미 있게 만들었다. (p.39)

자신의 일에 만족하려면 자신이 하는 일의 목적에 대한 신념이 있어야한다.
소명(calling)은 생업(job)이나 직업(career)과는 다르다. 생업, 직업, 소명 순으로 일에 만족감을 느낀다.
루크는 환자와의 상호작용을 통해 자신을 가장 쓸모 있고, 중요하며, 능력있다고 느꼈다.

## Job Crafting

자신의 직무 그 이상, 그 너머를 일하는 사람들은 자신이 속한 곳의 목적을 내재화해 그에 맞추어 일한다.
병원 청소 노동자 루크는 자신의 공식 업무 너머 '환자와 보호자 케어'라는 목적을 내면화한 채 일했다.
병원의 핵심 목적을 마음속에 담아둔 채 자신의 일을 재창조한 것이다.

소명의식을 가진 미용사들은 자기 기술에 자부심을 가지고 있으며,
겉보기에는 단순해보이는 머리 자르기 같은 행동의 복잡한 특성을 한껏 즐기고 있었다.
또 사람들을 상대하며 이야기를 나누고 그들을 이해하는 스스로를 자랑스러워했다. (p.53)

### 일은 언제 의미를 지닐까?

```text
1. 모든 일은 다양성, 복잡성, 기술계발, 발전이라는 요소를 포함하도록 구성될 수 있다.
2. 그 일을 하는 사람에게 상당한 자율권을 부여하도록 조직될 수 있다.
3. 사람들을 다른 이의 행복에 기여하도록 하면서 일은 의미를 지닐 수 있다.
```

- 자신의 일이 다른 사람들에게 미치는 잠재적 영향력을 아주 중요시하는 것만으로도 직원들에게 영감을 줄 수 있다. (p.55)
대학 기부금 아웃바운드 노동자들에게 장학금 수혜자를 만나게 해주면 그들은 영감을 받은 후, 더 효율적으로 변한다.

### 만족스러운 일은

```text
1. 그 일 자체가 조금 어렵고 다양한 특성을 지니며 매력적이어야 도움이 된다.
2. 그 일이 당신에게 기술을 사용하고 더 많은 기술을 계발할 기회를 준다면 도움이 된다.
3. 일하는 방식에서 재량권을 지니면 도움이 된다.
4. 존경하는 동료들과 한 팀을 이루고 있다고 느끼면 도움이 된다.
5. 일이 아주 중요한 목표를 갖고 있으며 당신이 하는 일에 의미와 목적의식을 부여한다면 큰 도움이 된다.
```

## 효율적인 조직들의 공통 요소

1. 높은 수준의 고용안정성 -> 직원들의 충성심과 신뢰 형성
2. 자율관리팀과 권력이 분산된 의사결정 과정 -> 직원들의 재량권과 자율권. 다른 직원을 감독하는 일이
주 업무인 직원의 필요성을 줄이고 직원들 사이 신뢰를 강화
3. 업계 평균 급여보다 더 높은 급여 & 개인적인 인센티브에 의존하지 않음 -> 회사가 성과를 잘 내면 모든 직원들이 이득을 본다.
4. 지속적으로 광범위한 교육 제공 -> 직원들은 새로운 도전을 마주하고 새로운 기술을 계발
5. 직원의 수행력을 과도하게 평가하지 않음
6. 회사의 사명을 굉장히 강조 -> 조직 곳곳에서 날마다 실행

## 인센티브와 동기 밀어내기

- 돈같은 외발적 동기는 내발적 동기를 약화('동기 밀어내기')시킨다. 금전 제안은 사람들로 하여금
`이 일에 내 시간과 노력을 들일 가치가 있는가?`라는 질문을 하도록 만든다.

## 이데올로기는 어떻게 진실이 되는가

- 사람들이 자신의 행동에 대한 생각을 바꾸면서다.
우리가 과거 행동들을 이해하는 방식은 우리의 미래 행동들에 영향을 미칠 가능성이 크다. (p.142)
- 자기 충족적 예언을 통해서다. 이때 이데올로기는 다른 사람들이 행위자에 반응하는 방식을 변화시키고,
다시 이것은 그 행위자가 미래에 하는 행동을 변화시킨다.
예를 들어 교사들에게 임의로 '학습속도가 더 빠른 아이'를 알려준다면, 그들을 대하는 교사의 교육방식이 달라지고
그 학생들은 더 나은 학업 성과를 낸다. 자기 충족적 예언이 실현된 것이다.

### 피그말리온 효과

아이들의 지능이 '고정되어있다는 사고'가 있는 문화보다 '개발된다는 사고'를 지닌 문화에서 아이들이 더 많은 지적 발달을 이룬다.
회사에서도 경영주들이 근로자들이 급여를 통해서만 동기 부여를 받는다고 생각하면, 임금 외에는 일할 이유가 없도록 만드는
의미없는 조립라인을 만든다.

## 결론

일에서 재량권, 몰입, 의미를 박탈하면 사람들은 만족감을 덜 느끼고, 그 일을 잘 못하게 된다.
그들이 일을 잘 못할 수록 감독들은 그들에게서 더 많은 재량권을 앗아간다.

사회구조 속에 스며있는 이데올로기는 인간의 본성을 디자인했다. 그렇기에 우리는
**사람들이 가치있다고 여기는 일을 하도록 만드는 업무환경**과 **사람들이 자신의 일에서 의미를 발견하도록 하는 환경**을
디자인해야한다. 훌륭한 업무환경은 사람들로 하여금 훌륭한 일을 하도록 만들고,
노동자와 고객, 고용주에게도 좋은 영향을 미치는 포지티브 섬(Positive sum)을 이뤄낸다.

사람들은 행복할수록 더욱 유능하고 똑똑하게 일한다. 마음 상태가 긍정적일 때 대범하고 창의적으로 생각한다.
행복의 관점에서 효율성을 정의하고 업무환경을 변화시키자.

## 내 생각

나는 개발을 통해 만족감을 얻고, 내 쓸모를 느끼며, 행복하다. 내 삶의 모든 행복이 일을 통해 오는 건 아니지만 회사에서 소소한 기쁨을 마주칠 때가 많다.
지금 내가 다니고 있는 파스토와 나의 업무들은 거시적으로 볼 때 소상공인들의 경제활동을 돕고 우리나라 풀필먼트 산업의 디지털 포메이션에 기여한다.
내가 짜는 코드 한 줄 한 줄은 이 시스템을 안정화하고, 성능을 개선한다.
직원으로서 내가 하는 일의 목적에 신념을 갖고, 조직의 구석구석에서 창의적인 파트너십을 이끌어내자.


내가 하는 일의 목적에 신념을 갖고, 조직의 구석구석에서 창의적인 파트너십을 이끌어내자.

책 '우리는 왜 일하는가'를 읽고

 

## 1, 2분기

올 1, 2분기에는 직접 블로그를 만들고, 공부를 더 해서 개발자 인생 처음으로 이직을 했다.
스터디 2개와 사이드 프로젝트를 같이 해서 정말 바빴는데 하다보니 일종의 루틴이 생겨 할 만 했다.
이직을 하기 위해서만은 아니었고 프론트엔드 개발에 집중을 하기로 마음을 먹으면서였다.
저질러 놓은 스케줄이 많다보니 몇달 간 퇴근 후에는 개발만 했다. 스스로를 압박하고 강제한 건 아니었는데 만들고 싶은 게 있고 원하는 게 있었다보니 자연스레 몰입할 수 있었다.
(당시에는 몰랐는데 지금 와서 생각해보면 ‘몰입’이라 부르기에 충분한 것 같다.)
또 회사가 집 5분 거리 지식산업센터로 이전하면서 출퇴근 스트레스가 확 줄었고, 룸메이트가 간간히 응원해준 게 큰 힘이 되었다.

6월 즈음에 지금의 회사에 합격했다. 자세한 이직 후기는 [이 글](https://haeun.vercel.app/blog/2207-move)에 있으니 생략한다.
합격 통보를 받는 순간 친구랑 통화를 하고 있었는데, 이 친구도 면접 합격을 기다리고 있었다.
내 합격 소식을 전하자마자 친구가 ‘좋은 기운 나눠줘서 고마워’라고 해서 마음이 찡했던 기억이 있다.
또 전 회사 생활을 마무리하면서 동기들과 저녁을 함께 했었다. 몰랐는데 우리가 생각보다 서로에게 유대감이 있었구나 느꼈다.
같이 일했던 동료들이 좋은 분들이었어서 마지막 퇴근을 하면서 아쉬운 마음과 후련한 마음 등 복합적인 감정이 들었었다.
아무튼 이 시기는 첫 이직 연봉협상도 해보고 설렘이 넘쳤던 시간이었다.

## 3분기

7월 중순 새 회사에 본격적으로 합류해서 회사와 팀에 적응했다.
팀에 리액트를 써본 사람이 별로 없어서 리액트와 TS로 진행한 통합회원 프로젝트의 꽤 많은 부분을 맡아 작업했다.  
API 연동 외에도 ERP에서 쓰일 공통 컴포넌트를 만드는 게 주 업무였는데
한 컴포넌트가 가지는 view, 밸리데이션, 로직 관련된 프로퍼티들을 잘 관리하고 또 여러곳에서 불러 쓸 수 있도록
개발하는 게 가장 어려웠다.

이전 회사는 SI 회사라 프로젝트 단위로 팀이었기 때문에 풀스택 업무를 해야했는데 이번 회사에서는 프론트엔드에 집중할 수 있어 좋았다.
또 팀에 시니어 프론트엔드 개발자가 계셔서 내가 원하는 미래를 걷고 있는 사람이 근처에 있다는 게 꽤 든든했다.

## 4분기

4분기 초에 위에서 언급한, 꽤 많은 부분을 맡아 열심히 개발했던 프로젝트가 회사 사정으로 내년으로 미뤄졌다.
약간의 멘붕과 무력감을 느꼈었는데 우리 팀 동료들과의 일대일 면담이 큰 도움이 되었다.

또 팀에 테스트를 도입하고자 테스트 관련 컨벤션 문서들을 작성하고 예시로 돌려볼 수 있는 테스트 케이스 문서와 코드를 작성했다.

회사가 자율 재택 근무에서 주 1회로 재택할 수 있는 날을 줄이면서
통근하느라 체력적으로 힘들어지기는 했지만 팀원들이랑 더 자주 만나고 서로 알아갈 수 있어서 좋았다.
회식 끝나고 집에 돌아갈 때마다 `우리 팀 진짜 좋다…`는 생각을 하곤 했다.
새로운 팀원이 두분이나 오셔서 더 재밌고 복작복작했던 4분기였다.

## 2023년에는

2023년에 더 공부하고 싶은 건 이것들이다.

- 유연하고 단단한 컴포넌트 설계, 함수형 프로그래밍
- 자바스크립트 철학
- JS, 리액트, 타입스크립트 더더더

그럼 이만 2023년도 화이팅! 🦭


벌써 2022년을 마무리할 때가 되었다. 개발보다는 내 경험과 감정에 관한 내용이다.

2022년, 개발 경력 2년을 채우면서의 회고

 

## 시간을 효율적으로 쓰면서 시간의 밀도를 높여라

### 시간의 밀도를 높이는 법

**하나의 행위가 2-3개의 의미가 있게 만들어라.**

- 즉, 하나의 행위를 여러 목적을 위해 이용하라.
- 만약 공인 중개사 자격을 위해 공부한다면 다른 부동산 임대업이나 강연, 집필도 할 수 있게 준비한다고 생각하라.

이렇게 목적이 추가되면 같은 공부를 해도 성과가 2배가 되고 의욕도 높아진다. 

### 바쁜데 할 수 있을까?

- 바쁠 때 `공부`를 하면 오히려 마음의 여유가 생긴다. (행동함으로써 불안이 줄어든다.)
- 바쁠 때 `타인`을 만나라. 세상에는 타인과의 만남으로만 얻을 수 있는 경험과 지식이 있고, 오히려 덧셈의 발상으로 시간 밀도를 높이게 된다.
물론 내 시간을 쓸 가치가 있는 사람을 만나라.

### 시간관리의 최대 장점 2가지

일과 인생이 즐거워지고, 좋은 사람이 될 수 있다.
시간 밀도를 높이고 시간을 유용하게 써서 해야할 일을 바로바로 마무리하고, 하고 싶은 일에 계속 도전할 수 있다.

### 커뮤니케이션을 할 때 시간을 낭비하지 않는 법

1. 열심히, 상세하게 이야기할 수록 상대에게는 전달되지 않는다. 장황하게 늘어놓으면 상대는 제대로 이해하지 못한다. 상대의 시간도 소중하다.
2. 포인트만 추려서 이야기하면 상대에게 잘 전달된다.
3. 남을 혼내거나 조언할 때는 여러 문제를 나열하지 않는다.
4. 상대를 설득하려면 밀어붙이는 것보다 질문 형식으로 말한다.
5. 사실과 의견을 나눠서 말한다.

### 생각하는 시간은 15분으로 제한

아직 준비가 되지 않았어도 일단 시작해버리는 각오도 필요하다. 막상 해보면 의외로 간단히 결되는 경우도 있다. 실패하더라도 그 경험을 발판 삼아 다음 행동을 하면 된다. 
주저된다면 `지금 안 움직이면 기회를 놓치는 건 아닐까` 스스로 질문해본다.


시간을 효율적으로 쓰면서 시간의 밀도를 높여라

책 '일주일은 금요일부터 시작하라' 요약

 

## 프론트엔드 테스트의 종류

[프론트엔드 개발 시 할 수 있는 테스트는 크게 4개가 있습니다](https://www.youtube.com/watch?v=pkYUcKWOqPs).  
첫 째로 구문 오류나 나쁜 코드 스타일 등을 검증하는 정적 테스트(ESLint, TypeScript),  
작은 단위만 떼어내어 분리된 환경에서 알고리즘이 제대로 동작하는지 확인하는 유닛 테스트(Jest),  
어플리케이션의 여러 부분을 통합해 올바른 상호작용을 하는지 테스트하는 통합 테스트(Jest, RTL, Enzyme),  
API 서버, DB 등 모두 연결된 실제 사용자의 조건에서 전체 서비스(시스템)를 검증하는 E2E 테스트(Cypress, Selenium)가 있습니다.

## Cypress 소개 

오늘 글에서 다룰 테스트는 종단간 테스트라고도 불리는 End-to-End(E2E) 테스트입니다.
프론트엔드 E2E 테스트시 사용할 수 있는 [Cypress](https://docs.cypress.io/)는 오픈소스 **모던 웹 앱 테스팅 툴**이고, 
리액트/뷰 등 상관없이 **웹앱 브라우저에서 돌아가는 거면 뭐든 테스트가 가능**합니다.
개발자가 테스트 코드를 작성해두면 Cypress가 자동으로 테스트를 진행합니다.

## Cypress 기능

- Cypress는 **모든 테스트가 행해질때마다 DOM 스냅샷을 찍어, 시간 여행을 하듯 해당 단계에서 일어난 일을 다시 볼 수 있습니다.**
- 네트워크 트래픽을 조절해 테스트할 수 있습니다.
- 크로스 브라우저 테스트가 가능합니다.

## 명령어 사용하기

[Cypress가 제공하는 명령어들](https://docs.cypress.io/api/commands/and)은 다양합니다.
`and`나 `should`로 DOM 요소의 클래스나 스타일을 확인(assertion)할 수도 있고, 브라우저 쿠키를 지우거나(`clearCookie`) 
마우스 우클릭(`rightClick`)을 할 수도 있습니다.  
예시 코드입니다.

```javascript
cy.visit(firstUrl)
cy.get(nameTextInput).type('hailey')
cy.location(redirectedUrl)
```

위 코드는 `firstUrl`에 방문해서, `nameTextInput`에 'hailey'라는 값을 입력하고,
redirect된 location이 `redirectedUrl`이 맞나 확인합니다.

`cy.task` 커맨드로 자바스크립트를 시스템 레벨에서 실행할 수도 있습니다.

```javascript
const userSeed = 유저정보;

context('User setup', ()=> {
	beforeEach(()=> {
		cy.task('clear:db')
		cy.task('seed:db', userSeed.data)
	})

	it('login user', () => {
		cy.visit('localhost:8080/login')
		cy.login('hailey@cypress.io', '1234')
		cy.location('pathname').should('eq', '/board')
	})
})
```

위 코드는 `task` 커맨드를 사용해 모든 login user 테스트 전에 `clear:db`, `seed:db`를 수행합니다.

## 커스텀 커맨드

*Cypress has direct programmatic access to my app*.

Cypress 커스텀 커맨드를 사용하면 프로그램적으로 앱에 접근할 수 있습니다. 
UI를 통하지 않고, 프로그램 자체에서 액션을 실행하게 하는 겁니다.
예를 들자면 **로그인 버튼을 눌러** 로그인 함수가 실행되게 하는게 아니라, 
프로그램 내 **login() 함수를 직접 실행**시키는 거죠!
예시 코드는 이렇습니다.

```javascript
Cypress.Commands.add('login', (email, password) => {
	return cy.window().then(win => {
		return win.app.$store.dispatch('login', {
			email: 'hailey@cypress.io',
			password: '1234'
		})
	})`
});
```

웹앱을 테스트할때, 로그인 이후의 페이지를 테스트하려면 테스트할때마다 로그인을 계속 거쳐야합니다.
위 코드처럼 로그인을 하는 커스텀 커맨드를 만들면 로그인처럼 반복되는 액션을 
UI를 거치지 않고 더 빠르고, 덜 번거롭게 원하는 페이지를 테스트할 수 있습니다.

저는 테스트 코드를 좀 더 쉽게 작성하고 관리하기 위해 POM 디자인 패턴을 사용했습니다.

## POM

POM이란 **Page Object Model**의 약자로, 테스트 자동화를 위해 사용하면 좋은 디자인 패턴입니다. 
이 패턴에서 Page 객체는 객체 지향형 클래스고, 테스트하려는 페이지 하나가 한 Page 객체가 됩니다. 
또 POM 클래스를 상속해 테스트 케이스의 길이를 줄일 수 있습니다.
그렇기에 POM은 여러 페이지가 있는 앱에서 사용하면 제일 좋습니다.

POM에서는 테스트와 DOM 요소를 찾는 Element Locator를 분리합니다. 
한 페이지의 UI가 바뀐다고 해서 그 부분을 사용하는 모든 테스트를 바꿀 필요 없이, 
페이지 객체 안의 Element Locator만 바꾸면 됩니다. 

또 중요한 점은 페이지 객체 저장소(Page Object Repository)가 테스트로부터 독립적이라는 겁니다. 
페이지 객체들을 담아두는 저장소를 분리함으로써 사용자가 원하는 툴, 프레임워크와 함께 사용할 수 있습니다.

## Page 객체를 사용한 테스트 예시

**Best Practice: Use `data-*` attributes to provide context 
to your selectors and isolate them from CSS or JS changes.**

[Cypress에서 제공하는 Best Practice](https://docs.cypress.io/guides/references/best-practices)
중 하나가 테스트할 HTML 요소를 지정할 때 `data-cy` 속성을 사용하는 겁니다.
동적 ID나 클래스, CSS 속성처럼 자주 변하는 값 말고 테스트할 HTML 태그에 `data-cy` 값을 넣어두는 거죠.
아래 예시를 보면 됩니다. (가독성을 위해 `data-cy` 속성을 제외하곤 생략합니다.)

```HTML
<article data-cy='post'>
	<h1 data-cy='title'>페이지 객체를 만드는 방법<h1>
	<article>
		<p>내용</p>
	</article>
</article>
<button data-cy='write-new'>새 글 쓰기</button>
```

이 페이지는 렌더링 후 결과물이 위와 같이 만들어집니다. 
글 하나를 상세조회할 수 있는 페이지고, 아래에는 '새 글 쓰기' 버튼이 있다고 합시다.
그러면 아래와 같이 `PostPage` 클래스를 만들 수 있습니다.

```javascript
// PostPage.js
class PostPage {
  constructor() {}

  // 글의 제목 요소를 가져온다.
  getPostTitle() {
	return cy.get('[data-cy="title"]')
  }

  // 새로 글쓰기 버튼 요소를 가져온다.
  getWriteNewButton() {
	return cy.get('[data-cy="write-new"]')
  }
}
export const postPage = new PostPage();
```

`PostPage` 클래스로 만든 인스턴스 `postPage`를 cypress 테스트 코드인 `post.cy.js`에서 사용합니다.

```javascript
// post.cy.js
describe('게시글 상세조회 테스트', () => {
	context('게시글 상세조회', () => {
		it('새 글 쓰기 버튼을 클릭하면 글쓰기 페이지로 이동한다.', () => {
			postPage.getWriteNewButton().click();
			cy.location('pathname').should('eq', '/new')
		})
	})
})
```

이렇게 글쓰기 버튼을 클릭하고, `cy.location()`으로 이동한 페이지가 
글쓰기 페이지의 pathname과 동일한지 테스트할 수 있습니다.

짜잔~ 이렇게 POM 패턴으로 코드를 구성하면 이후에 로그인 버튼 마크업이 바뀌어도
모든 테스트코드에서 수정할 필요 없이 `PostPage.js`에서만 수정하면 됩니다.

POM 패턴에 대한 자세한 설명은 [이 글](https://medium.com/tech-tajawal/page-object-model-pom-design-pattern-f9588630800b)을 
참고하세요.

## Cypress 테스트 구현 시 주의할 점

### 화살표함수와 this

테스트 코드에서 반복적으로 사용되는 데이터를 변수로 지정할 때 테스트 케이스 it(this)의 프로퍼티(`this.data`)로 넣을 경우
화살표 함수를 사용하면 `this`를 갖지 않는 화살표 함수의 특성상 `An outer value of 'this' is shadowed by this container.`라는
타입스크립트 에러가 뜰 수 있습니다.

이러한 에러 메시지를 만날 경우 화살표 함수를 function 함수로 바꿔주면 됩니다.

### 쿠키 초기화

Cypress는 **각 테스트마다 브라우저의 상태를 초기화**합니다. 모든 `it()`마다 쿠키가 깨끗히 지워집니다. 
테스트중인 앱이 인증 토큰을 저장하는데 쿠키를 사용한다면 로그아웃이 되어버립니다. 

이럴 땐 맨 처음 로그인을 하면서 `SESSIONID` 또는 기억해야할 데이터 값을 전역 변수에 할당해두고, `beforeEach`로 쿠키에 해당 데이터를 넣어주도록 하면 됩니다.

끝 🔎


Cypress와 POM 패턴으로 E2E 테스트를 자동화한 경험과 주의해야할 점을 공유합니다. (작성중)

POM 방식과 Cypress로 프론트엔드 E2E 테스트하기


Toss Slash 2022 를 들으며 적은 것들.  
실제로 나의 개발에 적용할 수 있는게 많아 여러번 반복해 들었다.  
더 나은 코드를 짜고 싶은 개발자라면 꼭 한번씩 보시길 추천해요.
이 글에 나오는 모든 코드/이미지의 권리는 Toss Slash 2022에 있습니다.

[한재엽 님 발표](https://www.youtube.com/watch?v=fR8tsJ2r7Eg)

## 서론 

제품은 변화를 겪으면서 **성장**한다. 변경이 필요하다는 건 고객의 니즈를 발견했다는 것. 우리는 사용자를 잘 모르기 때문에 변경을 예측하지 말고, 대응해야한다.

아래 코드의 문제점은 뭘까?

```jsx
<Item
	item={{
	data...
	}}
/>
```

문제점
1. Item 컴포넌트가 정확히 어떤 아이템을 의미하는지 알기 힘들다.
2. Item 컴포넌트 안에 item 속성이 또 있다.

이런 컴포넌트는 만들다보니 페이지가 커졌고, 적당히 덜어내며 만들어졌을 것이다. 이런 문제점을 발견한 이후 잘 변경할 수 있는 컴포넌트를 만들어야한다.

### 변경에 유연하게 대응할 수 있는 컴포넌트의 특징

1. Headless 기반의 추상화하기
: 변하는 것 vs. 상대적으로 변하지 않는 것
2. 한가지 역할만 하기
: 또는 한가지 역할만 하는 컴포넌트의 조합으로 구성하기
3. 도메인 분리하기
: 도메인을 포함하는 컴포넌트와 그렇지 않은 컴포넌트 분리하기

## Headless 기반의 추상화하기

### 컴포넌트가 하는 일

1. 데이터 관리: 외부에서 주입받은 데이터 & 내부 데이터(상태)
2. UI: 데이터가 사용자에게 어떻게 보여질지를 정의 (e.g. `HTML`)
3. 사용자와 어떻게 상호작용할 지 정의 (e.g. `onClick`)

이 중 UI는 디자인에 의존한다. 그러면 컴포넌트의 데이터와 분리하는 게 좋다.

### Headless한 달력 컴포넌트

달력 컴포넌트의 경우 달력을 구성하는 데이터는 달라지지 않지만, 달력의 UI는 언제든 바뀔 수 있다.

headless한 컴포넌트를 만들기 위해선
1. 달력을 2x2 배열의 데이터로 추상화 (년, 월, 일), 배열의 요소는 `Date` 객체로 관리한다.
2. 현재 날짜값을 추상화한다.

```js
const {headers, body, view} = useCalendar()
```

**달력에 필요한 데이터 계산을 useCalendar hooks에 위임**한 셈이다. 
이렇게 UI를 관심사에서 제외하고 데이터에만 집중해 모듈화할 수 있다. (=headless)  
그 결과, 한가지 문제에만 집중하고 더 많은 곳에서 사용하고, 다른 변경으로부터 격리할 수 있다.

### 동작(상호작용) 추상화

```js
// useLongPress hook

interface Props extends ComponentProps<typeof Button>{
	onLongPress?: (event: LongPressEvent) => void;
}

export function PressButton(props: Props) {
	const longPressProps = useLongPress();
	// 생략...
}
```
컴포넌트에서는 hooks의 리턴값을 UI에 적용만 하고, 어떻게 보일지에만 집중할 수 있다. 다른 컴포넌트에서도 hook만 가져다 사용할 수 있다.

**변경에 유연해지려면 각 모듈이 한가지 역할만 하는게 중요하다.**

## Composition

작은 컴포넌트들을 조합해 구성해야하는 컴포넌트가 있다.   
예를 들어 `Selector`의 경우

![한가지 역할만 하기 발표자료](/images/blog/2210/one-role.png)

1. Selector가 열린 경우 `isOpen` -> `Dropdown` 컴포넌트로 관리
2. `isOpen` 상태를 바꾸기 위한 상호작용 -> `Dropdown.Trigger`
3. Menu -> `Dropdown.Menu`
4. Menu 내부 Item -> `Dropdowm.Item`

Toss Slash 2022 한재엽 님 발표를 들으며 정리한 것

Effective Component 지속 가능한 성장과 컴포넌트 (작성중)


*가독성을 위해 문제와 관련없는 부분은 최대한 생략한 코드입니다.*

## 문제 
아래 코드는 유저가 여러 소셜 로그인 방법 중 **카카오 로그인을 선택**한 경우 동작합니다.
순서는 이렇습니다. (코드 내 주석 참고)

```javascript
const [kakaoId, setKakaoId] = useState('');

const snsLogin = (id: string, isChecked: boolean) => {
    switch (SNS) {
		case '카카오':
		    kakaoLogin(() => {
				// (4)
		        updateSNS(kakaoId)
		        .then(resp => (...))
		        .catch(err => (...))
		        )
		      })
		   }
		    break;
		case '네이버':
		// 생략...
	}
};

async const kakaoLogin = (successCallback) => {
	// (1)
	await Kakao.Auth.login({
		success: async function (response: any) {
			// (2)
			await Kakao.API.request({
				success: function (profile: any) {
				    // (3)
				    setKakaoId(profile.id);  
				    successCallback();
				},
			});
		},
	  });
}

```

1. `Kakao.Auth.login`로 카카오 소셜 **로그인**을 한다.
2. 성공시 `Kakao.API.request`로 유저의 카카오 **프로필을 GET한다**.
3. response에서 `profile.id` 값을 컴포넌트 상태 `kakaoId`에 저장한다.
4. 저장한 `kakaoId`를 파라미터로, 서버에 POST 요청을 보낸다.

제가 겪은 문제는 `(3)`에서 setState을 하면 결과적으로 state가 바뀌긴 하지만, `(4)`에서는 아직 kakaoId가 변하지 않았다는 거였습니다.

즉, `(3)`에서 setState가 바로 업데이트를 실행하지 않았다는 거죠.  
왤까요?

## 원인

왜냐면 **setState는 이벤트핸들러 안에서 비동기적으로 호출**되기 때문입니다.
setState는 컴포넌트를 바로바로 리렌더링하지 않고, 변경 사항을 대기열에 넣어두고 한번에 일괄적으로 갱신합니다. 
이 결과 setState을 여러번 호출해도 동일한 키에 대해서는 가장 마지막 값으로만 상태가 갱신되기도 합니다.

### 왜 굳이?

비동기 객체라는 setState의 특징 때문에 아무 생각없이 `setState = 상태 바꿔주는 함수` 로만 알고 있으면 뒤통수를 맞기 쉽상입니다.  
왜 setState는 `XMLHttpRequest`, `콜백`, `setTimeOut`처럼 비동기 객체로 만들어졌을까요?

그 이유는 바로 *불필요한* 렌더링을 방지한 성능향상입니다.

하나의 이벤트핸들러에서 setState가 **여러번** 호출되면 이벤트가 끝날 때 **변경이 필요한 상태들을 일괄적으로 업데이트하고 렌더링**합니다.
그래서 setState를 호출하자마자 state에 접근하면 값이 안 바뀌어있는 겁니다.

## 즉각적으로 state 바꾸는 법

예시와 함께 **리액트에서 상태를 그때그때 바꾸는 방법** 몇가지를 알려드리겠습니다.

### 방법 1. useState: setState의 updater 인자에 함수 사용

```javascript
add() {
	setCount((prevState, prevProps) => {
		return {count: prevState +1}
	})
}
```

첫째로, prevState를 사용해 새로운 객체를 return하면 됩니다.

아래 예시에서 저는 ` fruits 배열의 원소가 객체의 key로 담긴 fruitState 객체`를 만들고 싶었습니다. 
그래서 이런 코드를 짰어요.

```javascript
const [fruitState, setFruitState] = useState({});
const fruits = ['orange', 'apple'];

fruits.map((val, idx) => {    
	setFruitState({ ...fruitState, [val]: true });

```

fruits 배열의 map() 메서드를 써서 setState를 하도록 했습니다. 
하지만 이 코드를 실행하니 예상한 결과물은 `{orange: true, apple: true}`이었는데, 실제 결과물은 `{apple: true}`였습니다.  

처음 `orange`가 `[val]`이었을 때 `fruitState`가 변하지 않은 상태에서 setFruitState를 한번 더 실행했기 때문에 마지막 setState만 빼고 이전의 setState 실행은 다 무시되어버린겁니다!!!

그래서 updater 인자에 prevState를 사용한 함수를 직접 넣어주었습니다.

```javascript
fruits.map((val, idx) => {    
    setFruitState(prevState => ({ ...prevState, [val]: true }));  
});
```

이렇게 고치면  `{orange: true, apple: true}`가 나옵니다.

### 방법 2. 클래스 컴포넌트: setState 콜백 사용

```javascript
const [count, setCount] = useState(0);

add() {
	this.setState({ count : this.state.count+1 },  // arg1
	() => {	console.log(this.state.count)})   // arg2
}

handleClick() {
  this.add();
}
```

두번째 방법은 useState 훅을 사용하지 않고, 클래스 컴포넌트의 setState를 사용하는 방법입니다.  
클래스 컴포넌트의 setState은 **두번째 인자(`arg2`)로 콜백함수**를 받아서 setState가 실행된 이후 콜백 함수를 실행합니다.

0인 count를 1씩 더해주는 예시입니다. 원래 값에 1씩 더해준다기보다 1을 더한 새로운 값을 count로 지정해주고 있습니다.
`arg1`인 setState가 실행되면, `arg2`가 새로운 count를 콘솔에 표시합니다.


이 두 방법 중 저는 첫번째 방법을 주로 씁니다.  
또 이외에도 useCallback 안에 setState을 넣어 처리할 수도 있습니다.

![setState Thumbnail](/images/blog/2209/setstate_thumbnail.png)

setState는 비동기적으로 동작한다

setState 제대로 사용하기 (feat. setState 값이 바로 안 바뀔 때)


## 서론

많은 개발자분들이 C++나 파이썬, 자바로 알고리즘 테스트를 준비합니다.  
하지만 이 경우는 백엔드 개발자가 많고, 요즘엔 많은 회사들이 프론트엔드 직군을 뽑을 때 
알고리즘 테스트 언어를 자바스크립트로 제한하죠. 

그래서 프론트엔드 개발자라면 실무 능력치도 키울 겸 자바스크립트로 코딩테스트를 준비하는게 좋아보입니다.  
다른 언어들보다 유저가 적은 만큼 문제와 best practices를 찾기 힘든 건 사실이지만요.  
오늘은 제가 자바스크립트로 알고리즘 문제를 풀어보면서 느낀 것과 배운 것을 적어보겠습니다.

## 자바스크립트 숫자 배열 정렬하기

```JavaScript
const arr = [1, 20, 3, 100, undefined]
console.log(arr.sort())     // 이 때의 값은?
```

위 코드에서 주석에 찍히는 배열은 어떤 모습일까요?  
배열의 원소를 올림차순으로 배열해 `[undefined,1,3,20,100]`일까요? 

정답은 `[1, 100, 20, 3, undefined]`입니다.  
자바스크립트 배열 기본 `sort()` 메서드는 파라미터로 콜백함수를 넣어주지 않을 경우, 
**배열 내 숫자를 문자열로 변환하고, UTF-16의 문자 순서대로** 배열을 정렬하기 때문입니다.  
그리고 모든 undefined는 배열의 뒷부분으로 정렬됩니다. 

그러면 자바스크립트에서 배열을 유니코드 말고 다른 기준으로 정렬하려면 어떻게 해야할까요?  
`Array.sort()` 의 옵셔널 파라미터인 `compareFn` 즉 **콜백함수**를 넘겨주면 됩니다.

`Array.sort()`는 `compareFn(a,b)`의 **리턴값**에 따라 배열의 원소를 정렬합니다.  
`compareFn(a,b)`의 리턴값이 0보다 크면 `b,a`  
`compareFn(a,b)`의 리턴값이 0보다 작으면 `a,b`  
`compareFn(a,b)`의 리턴값이 0이면 a와 b의 순서를 유지합니다.  
코드로 짜보면 이렇습니다.

```JavaScript
function compareFn(a, b) {
  if (a가 b보다 앞으로 와야하는 경우) {
    return -1;
  }
  if (b가 a보다 앞으로 와야하는 경우) {
    return 1;
  }
  
  return 0;
}
```

이렇게 **두 원소를 비교해 경우에 따라 -1과 0, 1을 반환하도록** 함수를 짜면  
커스터마이징된 정렬을 수행할 수 있게 됩니다.  
이 때 1,0만 반환하거나 -1,0만 반환한다면 정렬이 제대로 되지 않는다는 점 유의하세요!

문자열 배열 말고 숫자 배열의 원소를 비교할 땐 위 공식을 이용해 
a에서 b를 빼거나 b에서 a를 빼도록 하면 됩니다.  
a-b가 음수면 a가 b보다 앞으로 오고, 양수면 뒤로 정렬되는 거죠.  
(원소 중 `Infinity`, `NaN`이 없어야합니다.)

```JavaScript
const arr = [1, 20, 3, 100, undefined];

// 1: 함수 표현식
arr.sort(function (a,b) {
  return a-b;
})

// 2: 화살표 함수
arr.sort((a, b) => a-b)
```

이렇게요!



자바스크립트로 알고리즘 문제 풀때 주의해야할 것들

자바스크립트로 코딩테스트 준비하기


![마이크로소프트에서 바라보는 종로 전경](/images/blog/2209/main.jpg)

걸스인텍과 마이크로소프트에서 주최한 `CODE;WITHOUT BARRIERS MEETUP`에 다녀왔다.  
많은 여성 IT 종사자들을 만나볼 수 있다는 생각에 냉큼 신청했었는데 선정되어서 정말 기뻤다!
종로 놀러올 때마다 마이크로소프트 본사를 우러러봤었는데 오피스에 들어가볼 기회가 생겨 꿈만 같았다.

![다과](/images/blog/2209/cookies1.jpg)

2022년 9월 3일 10시 마이크로소프트에 도착해서는 다과를 나누면서 주변에 앉은 분들과
인사, 명함을 나눴다. 개발자도 있고 데이터 엔지니어나 PM 등 다양한 개발직군의 사람들이 있었다.  
(폴바셋 에그타르트 짱 맛있었다!)

## IT 업계의 유리천장

영국 이코노미스트 발표에 따르면 한국은 `2022년까지 10년 연속으로
OECD 29개국 중 유리천장이 가장 심한 국가`라고 한다.  
다른 분야에 비하면 IT 업계는 유리천장이 덜할 것 같지만, 통계에 따르면
시니어로 일하는 여성 IT 종사자 비율은 현저히 적었다. 
그 외에도 여러 지표들이 국내 IT 업계의 젠더 갭들을 나타내고 있었다.

## MS의 Diversity and Inclusion

그래서 MS에서는 전 세계의 남성과 여성이 기술을 배울 수 있는 접근성의 차이가 있다고 보았다.
인종, 성별, 종교, 국가 등 다양성을 높이고 배제되는 사람이 없는 생태계를 만들기 위해
접근성의 격차를 메우고자 D&I(`Diversity and Inclusion`) 미션을 세웠다. 

마이크로소프트의 과거 미션은 '전 세계 모든 가정이 PC에 MS 소프트웨어를 하나씩 가지도록 하는 것'이었지만 
지금은 '**지구상의 모든 사람과 조직이 더 많은 것을 성취하도록 역량을 지원하는 것**'이라고 한다.

## Truths and Insights

그래서 팀별로 개발자 커뮤니티 내 D&I를 활성화하기 위한 게임 `Truths and Insights`를 진행했다.
주어진 문장의 빈 칸을 채우면서 의견을 공유하는 게임인데, 
같은 IT 업계 종사자끼리 개발자로서 드는 고민이나 경험을 나눌 수 있었다.  

우리 조는 다 주니어 개발자였는데, 내가 입사 1년차 때 했던 고민을 하는 조원들이 많았다. 
그래서 내가 나눈 팁은 이와 같았다.

1. **구글링을 30분 이상 한다면 그건 내가 모르는 것**이다. 
**충분히** 고민하고 찾아봤는데도 모르겠다면 도움을 청하는 걸 두려워말자.
2. 동료에게 조언을 구할 때는 **문제 상황과 그 문제를 해결하기 위해 내가 해본 것, 결과**를 자세히 이야기하자.
3. 나이차가 많은 사수에게 어떻게 질문을 해야할지 모르겠다면 `저 고민이 있어요...`라고 물꼬를 틀자.

마지막 소감을 이야기할때 내가 나눈 팁이 큰 도움이 되었다고 한 조원이 있어 기뻤다.
시간이 좀 더 길었다면 더 깊은 이야기를 할 수 있었을 텐데 게임 시간이 약 2-30분밖에 안 돼서 아쉬웠다.

그럼에도 임파워링되는 자리였고, 
기술에의 접근성 격차를 줄이는 게 유리천장을 얇게 하는데 정말 중요한 요소라는 걸 깨달았다.
굳이 성별이 아니어도 서울과 비서울 지역의 개발자들이 얻는 기회와 인프라가 정말 다른데,
내가 기술 접근성 격차를 줄이기 위해 할 수 있는 일은 뭐가 있을까? 다시 한번 생각해보게 되었다.

아직은 나도 주니어고 모르는게 많아 다른 사람들을 끌어주는 일을 많이 하지 못했는데
먼 미래가 아니라 가까운 미래에 내가 할 수 있는 일들(Action item)을 찾아봐야겠다.

마지막으로 지하 1층에서 마이크로소프트에서 제공해준 부타동 솥밥을 먹었다. 
맛있었고, 즐거웠다. 

🔚

![걸스인텍xMS CODE;WITHOUT BARRIERS banner](/images/blog/2209/gitms.JPG)

광화문 마이크로소프트, 빌게이츠씨가 사준 밥, 즐거운 동료 개발자들과 함께

걸스인텍xMS CODE;WITHOUT BARRIERS 밋업에 다녀오다


## 읽은 것

1. [useEffect 잘못 쓰고 계신겁니다.](https://velog.io/@jay/you-might-need-useEffect-diet)

이미 잘 압축된 글이라 짧게 말하자면

`리액트18의 strict mode에서는 렌더링을 두번씩 하는데 그럴 경우 불필요한 상태 변경/리렌더링이 있을 수 있으니 클린업함수를 꼭 넣어줘라,
 연산이 비싸면 useMemo 써라, react-query 등 캐시된 데이터 써라`

라는 내용이었다.

2. 리액트 전역 상태의 기준이 뭘까요? (프론트엔드 단톡방에서 나왔던 얘기를 정리했습니다.)

리액트 쿼리의 철학을 따른다면 **서버 상태는 리액트 쿼리로 관리**하고 클라이언트 상태는 **해당 페이지/컴포넌트의 책임인지, 앱 전체의 책임인지에 따라 구분**한다.  
계정이나 설정 정보같이 **서버와 주고받는** 데이터, **화면과 무관한** 데이터나 **컴포넌트를 가로지르는** 데이터(form 요소들)은 전역에서 관리하는 게 오히려 낫다.

최근 상태 관리의 움직임을 보면 예전보다 더 전역상태를 많이 지원하고 권한다. 컴포넌트 데이터 교환이 props로 인해 복잡해진다면 전역 상태로 관리해도 무방하다.
다만 기존에 전역 상태를 쓰지 말라고 한 것은 전역 상태를 컴포넌트들이 수정하기 시작하면 어디서 수정된 건지 관리가 힘들기 때문이다.
그래서 최근 상태관리들은 대부분 수정 추적을 할 수 있도록 설계되어있다.
마지막으로 페이지나 UI를 가로지르는 state는 큰 전역으로 해야 추적과 디버깅이 편하다.

결론
1. 단순 Ui관련 state는 웬만해선 전역으로 넣지않는다
2. **여러 Ui에서 공유하는 state는 전역으로** 넣는다
3. View단에 절대 state를 선언하지 않는다

리액트 전역 상태로 선언하는 기준

Recent Posts