DEV Community: Nily

React vs Angular

Nily — Wed, 14 Feb 2024 08:36:02 +0000

React와 Angular를 비교해 놓은 글들은 이미 상당히 많다.

그래서 나는, Angular를 현업에서 쓰면서 내가 겪은 React와의 차이점에 대해 글을 써보려고 한다🤓

가장 크게 느끼는 차이는 data binding 방식이다.

Angular는 React와 다르게, two-way binding이 가능하다.

즉, 부모 ↔️ 자식 컴포넌트 사이에 데이터를 공유할 수 있다는 것이다.

React는 부모에서 자식으로 데이터를 전달하는 방식이었다면, Angular에선 자식에서 부모로 데이터를 전달 하는 것이 가능하다.

하지만, two-way binding에도 단점은 존재한다.

데이터가 변화함에 따라 view와 model도 그 상태를 감지해야 하기 때문에 memory 사용량이 단방향보다 크다.
간결한 코드로 가독성이 높아서 복잡해보이지 않을 수 있지만, 코드의 결합도가 높아져 디버깅이 어려울 수 있다.

실제로, 특정 컴포넌트에 간단한 기능을 추가하기 위해 코드를 분석하는 과정에서 컴포넌트 전체 데이터 흐름을 파악하는데 꽤 오래 걸린 적이 종종 있었다.

두번째로 느낀 차이는, Angular는 배워야 할 개념이 꽤 많다는 것이다.
(= learing curve가 높다😅)

modules
dependency injection
services
templates
RxJS
...

따지고 보면, Angular는 framework이고 React는 View만 담당하는 library이기 때문에 당연한 걸지도 모른다.

service를 사용하면서 typescript에서 class의 구조를 더 잘 이해하게 되고, RxJS를 통해서도 처음에 헷갈렸던 비동기를 자유자재로 사용할 수 있게 되었다.

배워야 할 것들이 많은 만큼, 한 번 그 개념을 이해하고 자주 사용하면서 오픈 소스 라이브러리 등 새로운 코드를 분석하는데 있어서 전체 흐름을 파악하는데 아주 많은 도움이 되었다.

현재는 Angular보다 React가 점유율이 더 높고, 그만큼 커뮤니티나 생태계가 활성되어 있어서 많은 기업에서 사용중이다.

어떤 개발팀에서는 Angular에서 React로 전환하고 있다는 글도 보았다. (link)

나도 지금은 떠났지만, 이전 회사의 개발팀에 React로 전환하자는 의견을 내기도 했었다.(팀 내부에서 여러가지 이유로 진행하진 못했지만😭)

React냐 Angular냐 여전히 프론트엔드 개발 생태계에서 자주 회자되는 이슈인 만큼, 자주 관심을 가지고 찾아봐야 겠다.

출처
https://www.clickittech.com/developer/react-vs-angular/
- https://www.simform.com/blog/angular-vs-react/
- https://borstch.com/blog/understanding-angulars-two-way-data-binding
- https://www.simplilearn.com/tutorials/angular-tutorial/angular-service

Deploying a Static Site (feat.Vite, gh-pages)

Nily — Mon, 15 Jan 2024 03:47:26 +0000

다시 React 공부를 시작했다.

간단한 토이 프로젝트를 만들어 gh-pages로 간단히 배포하려고 했는데, 여기서 이슈가 발생했다.

배포후 확인해보니 404 not found error가 뜨는 것!

구글링 하다가 vite 관련 해결방법을 찾았는데 vite에 익숙해질겸 해서, 우선 creae-react-app으로 만들어진 프로젝트를 vite로 migration하는 것 부터 시작했다.

(요즘은 cra보다 가볍고 빠른 vite를 사용하는 추세인 것 같다. 관련 링크)

migration하는 과정은 크게 어렵지 않았다.

하지만 vite로 migration 후, 위 해결 방법을 적용해도 빈 페이지가 나오는 이슈는 여전히 있었다😅

다른 방법들을 다 적용해봐도 해결을 못하고 있던 중에, React Router path와 관련되어 있다는 것을 찾았다. (관련 링크)

vite.config.ts 파일에 basename은 /repoName/으로 설정되어있는데, router의 basename은 추가로 설정하지 않았기 때문에 /로 되어 있다는 게 원인이었다.

// vite.config.ts

export default defineConfig({
    base: '/<repoName>/',
    plugins: [react(), viteTsconfigPaths()],
    server: {    
      open: true,
      port: 3000, 
    },
})

따라서, router의 basename을 아래와 같이 조건에 맞는 path로 변경해주면 된다.

import { createBrowserRouter, RouterProvider } from 'react-router-dom'

function App() {
 const routes = [...];

  const router = createBrowserRouter(routes, { basename: import.meta.env.DEV ? '/' : '/repoName/' })

  return <RouterProvider router={router} />
}

import.meta.env.DEV는 Vite에 내장된 환경변수로, dev 모드일 때 값을 return 한다.

이 이슈를 해결하기 위해, 때문에 꼬박 하루를 사용했다.

초반엔 당연히 배포 설정 문제일 거라 생각하고 gh-pages 관련 이슈 위주로 찾아봤었다. router path 문제였을 줄이야...

위 블로그에도 나와있지만, 404 not found error 메시지가 화면에 뜨는데 console에선 어떤 에러도 보이지 않아서 더욱 의심하지 않았던 것 같다.

나와 같은 이슈를 겪는 사람들에게 도움이 되길 바라며..!!🤓

Popper.js with Framework

Nily — Sun, 30 Jul 2023 10:31:11 +0000

새로운 feature 기능이 들어가면서, 기존에 사용하던 popover에 UI에 이슈가 생겼다.

우리 팀은 ngx-bootstrap을 사용중인데, popover에 component를 넣는 방식을 사용하자 간헐적으로 그 위치가 맞지 않고 덜덜거렸다.
(+ 기존의 popover도 hover시, 다른 popover의 position에 영향을 미치는 버그는 있었다😂)

열심히 구글링한 결과, ngx-bootstrap의 고질적인 이슈로, 버그가 수정되지 않고 계속 있는 것 같았다.

시니어분께 상황을 공유하니 이참에 새로운 popover 라이브러리로 갈아타는게 어떻겠냐고 의견을 주셨다. 기존에 있던 버그 + 현재 발생한 이슈를 동시에 다 해결할 수 있는 방법이었다.

여러 패키지들을 조사한 결과, poppper.js가 가장 대중적이고 널리 쓰이는 듯 했다.

해당 패키지를 바로 Angular에 적용하면 되는 줄 알았는데,
알고보니 popper.js는 순수 Javascript 모듈이기 때문에 Angular에서 사용 가능하게 wrapping 된 버전(= Angular 구조에 맞게 popper.js를 사용할 수 있도록 해놓은 것)을 또 찾아야 했다.

👉 Tip: Angular 관련 모듈을 검색할 땐, ng or ngx를 앞에 붙여 찾으면 더 쉽게 찾을 수 있다.

ex) ng popper, ngx popper

검색 결과, ngx-popper를 쓰기로 결정했다.

ngx-popper의 package-lock.json을 보면 아래와 같이 popper.js에 dependency가 걸려있다. 최소 1.14.3 버전을 사용해야 하는것.

"popper.js": {
  "version": "1.14.3",
  "resolved": "https://registry.npmjs.org/popper.js/-/popper.js-1.14.3.tgz",
  "integrity": "sha1-FDj5jQRqz3tNeM1QK/QYrGTU8JU=",
  "dev": true
}

우리 서비스는 popper.js 1.12.9 버전을 사용중이었기 때문에 버전을 올려야했다. dependency가 걸리는 패키지들까지 업데이트 후 적용하니 잘 동작하는 걸 확인할 수 있었다.

이번 일을 통해, 아래와 같이 2가지 사항을 배울 수 있었다.

1. 사용하는 Framework에 맞게 라이브러리를 wrapping 하여 사용하기
2. 새로운 라이브러리를 추가할 땐, dependency 반드시 확인하기

시니어 분께서 "사용하는 Framework에 맞게 라이브러리를 wrapping 하여 사용하기"는 나중에 시간 될 때 한 번 꼭 해보라고 추천도 해주셨다.

Angular 구조를 이해하고 라이브러리가 프레임 워크 안에서 어떻게 동작하는지 알 수 있을것 같았다. (관련 링크)

시간 될때 꼭 해보고 포스팅까지 해보는 걸로💪🏻

Angular version upgrade v4 to v12 - part 2: performance

Nily — Sat, 06 May 2023 12:17:45 +0000

Angular 업그레이드로 인해 서비스의 성능이 얼만큼 개선되었는지 궁금했다.

크롬에서 제공하는 lighthouse라는 툴을 이용해 성능을 비교해봤다.

[v4]

[v12]

performance의 측정 항목은 아래의 5가지 metric으로 정의된다.

First Contentful Paint
Largest Contentful Paint
Total Blocking Time
Cumulative Layout Shift
Speed Index

performance 점수는 33에서 60으로 약 1.8배 상승했다.
각 항목에 어떤 변화가 있었는지는 아래 표로 정리해 보았다.

항목	v4	v12	차이
First Contentful Paint	1.3s	1.8s	+ 38%
Largest Contentful Paint	16.4s	4.2s	- 74%
Total Blocking Time	1,290ms	90ms	- 93%
Cumulative Layout Shift	0.008	0.007	- 12%
Speed Index	7.7s	2.4s	- 68%

가장 많은 변화가 있었던 항목은 Total Blocking Time과 Largest Contentful Paint였다.

TBT:

Sum of all time periods between FCP and Time to Interactive, when task length exceeded 50ms, expressed in milliseconds.
마우스 클릭, 화면 탭 또는 키보드 누름과 같은 사용자 입력으로부터 페이지가 응답하지 못하도록 차단된 총 시간
LCP:

LCP measures when the largest content element in the viewport is rendered to the screen. This approximates when the main content of the page is visible to users.
가장 큰 컨텐츠를 렌더링 하는데 걸리는 시간

Lighthouse는 검사 조건에 따라 점수의 변동성이 있긴 하지만, 여러번 검사를 실시한 결과 전반적으로 performance가 향상된 것을 확인할 수 있었다.
(4에서 12까지 버전이 확 높아진 만큼, 성능 개선은 당연한 것 일수도..)

검사 보고서를 보면, 어떤 부분에서 더 성능을 향상할 수 있는지 제안까지 해준다.

성능 최적화를 위해 단순히 프레임 워크 업그레이드에 의존하는 것이 아니라, Lighthouse등 여러 tool등의 도움을 받아 꾸준히 점검하고 시간을 투자해야 한다는 것을 또 깨닫는 경험이었다.

Angular12의 feature들 참고:
관련 링크

Angular version upgrade v4 to v12 - part1

Nily — Sat, 08 Apr 2023 08:53:10 +0000

때는 작년 3월, 우리 팀에서 계속 미뤄왔던 Angular 버전 업그레이드를 진행하기로 했다. v4를 사용하고 있었으니 현재 버전(v16)과 꽤 차이가 나는 것...

시니어 개발자 분께서 말씀하시길 꾸준히 업그레이드를 해왔어야 하는데, 계속 미루느라 기술 부채가 되어버렸다고 했다.😅

목표는 v12까지 업그레이드 하는것이었다.
한 번에 12까지 갈 수 없으니 각 버전별로 branch를 만들고 차근차근 올려보기로 했다. 한 스프린트 내에 하긴 무리라고 판단되어 기간도 넉넉히 2-3 스프린트 정도로 잡았다.

가장 큰 이슈는 dependency가 걸리는 package들이 꽤 많아, 버전 업그레이드 시 사용할 수 없는 패키지들이 생긴다는 것이었다.

Angular 공식 페이지에 업데이트 가이드는 잘 되어있다.

ex)

내 주요 업무는 dependency가 걸리는 package들을 변경하는 것이었다.

1. CSV 다운로드 모듈 변경
패키지 이름에서 알 수 있듯이, 현재 사용중인 angular2-csv는 Angular6까지 밖에 지원하지 않았다.

Angular 최신버전까지 지원 + 비교적 최근까지 업데이트 되어있음 + 깃헙 스타 갯수 까지 적절한 조건이면서, 안정적인 패키지를 찾는 일이 쉽진 않았다.

여기서 한가지 팁은, npmjs에서 Angular 관련패키지를 검색하고 싶다면 앞에 ng or ngx를 붙이면 더 정확한 검색 결과를 얻을 수 있다.

ex) ng csv download

한참 검색하다가, 이전에 사용하던 패키지를 fork 해서 Angular 최신 버전까지 지원 하는 걸 발견했다.🙌

패키지를 교체하고 이제 이전과 동일하게 잘 동작하는지 확인하는 과정을 거쳤다.
우리 서비스에 CSV 다운로드 하는 기능을 지원하는 곳이 꽤 많이 있었기에, 전반적으로 다 꼼꼼하게 확인이 필요했다.

다운로드시 column header 순서가 이전과 달라져서, 그 부분만 로직을 추가하니 잘 동작했다.

2. Renderer => Renderer2
Angular4 이후로 Renderer에서 Renderer2로 변경되면서 이전 모듈에 depdency가 걸리는 패키지들이 있었다.

이 중에 하나 이슈가 있었던 건, 고객 정보 영역에 사용하던 필드 수정 / 편집이 가능한 패키지였다. Renderer2로 모듈이 변경되면서, 현재 사용중인 라이브러리를 대체할 수 있는 것을 찾지 못했다. 기존 기능과 동일하게 동작하지 않거나, UI가 너무 달라지는 등 적합한 패키지가 없었다.

그리고 사실, 해당 부분은 UI 개선이 곧 이루어질 계획이 있었기에 이번 기회에 라이브러리에 의존하지 않고 component를 직접 구현하는 것이 낫겠다는 의견이 나왔다.

사실 좋은 라이브러리가 있다면, 가져다쓰는 것도 좋지만 이벤트나 method, property등 내부 요소가 한정적이기 때문에 그 확장성이 제한적이라는 단점도 있다.

자체 component로 만들어 쓴다면, 확장성 뿐만 아니라 패키지 의존성을 낮출 수 있기 때문에 해당 부분은 기존 기능과 동일하게 공통 component로 분리하는 작업도 같이 진행했다.

3. style-loader 제거
추후 v14까지 업그레이드를 위해 CSS파일 load방식도 변경하기로 했다.

글로벌 css파일은 angular.json의 styles에 추가
각 component.ts의 css파일 styleUrls에 추가

[변경 전]
component.ts

import 'style-loader!quill/dist/quill.core.css';
import 'style-loader!quill/dist/quill.snow.css';

[변경 후]
angular.json

"styles": [
  "node_modules/quill/dist/quill.core.css",
  "node_modules/quill/dist/quill.snow.css"
],

[변경 전]

import 'style-loader!./exampleComponent.scss';

[변경 후]

@Component({
  selector: 'example-component',
  templateUrl: './exampleComponent.html',
  styleUrls: ['./exampleComponent.scss']
})

이 때, 한가지 이슈가 있었다.

styleUrls로 css파일 load시 parent component의 css child component에 적용되지 않는 것!!

css 선택자에 ::ng-deep을 사용하여 해결할 수 있지만, 권장하지 않는 방법이었다. (참고 링크)

구글링하다 찾은 방법은, encapsulation 속성을 사용하는 것이었다.

import { ViewEncapsulation } from '@angular/core';

@Component({
    ....
    encapsulation: ViewEncapsulation.None
})

위에 언급한 이슈들 외에도, 자잘한 이슈들이 많이 있었다. 아마 버전 업그레이드 후기2탄을 작성해야 할 수도...

v4에서 v12로 가는 건 쉬운일은 아니었다.

패키지 뿐만 아니라, 사용 모듈이 변경되면 이전과 방식이 달라져 또 일일이 확인해야하고, ivy엔진으로 인한 build 에러, UI 깨지는 이슈 등 전체 서비스 기능에 영향을 미치는 부분이라 시간도 꽤 오래 걸렸다.

또 업그레이드를 진행하는 동안 약 한달 넘게 정식 배포를 하지도 않아서, 업그레이드 후 최종 배포하는 날 심장이 두근두근 했던 게 생각난다.

사용자가 직접적으로 큰 변화를 느낄 순 없었겠지만, 개인적으로 매우 뿌듯했다. 버전 업하면서 Renderer나 encapsultaion등 Angular에 대한 더 깊은 지식도 생기고 여러 패키지들을 살펴보며 보는 눈(?)이 생겼다고 해야하나 여러모로 많이 배울 수 있는 기회였다.

프레임 워크를 최신 버전으로 꾸준히 유지한다면, 그 다음 버전으로 가는 것은 크게 어렵지 않다고 한다. (그 사이 구조적으로 큰 변화가 생기거나 사이즈가 큰 feature가 추가되는 것이 아니라면)

개인 프로젝트를 진행할 땐, 버전의 중요성을 크게 깨닫지 못했었던 같다. 항상 최신버전의 최신 기능들을 모두 사용할 수 있다보니 불편함도 없었다.

v16까지 업그레이드 하는 날을 기대하며..🤩🤩

E2E Testing with Jest & Puppeteer

Nily — Sat, 01 Apr 2023 11:59:50 +0000

입사후, 온보딩 프로젝트가 끝나고 정식으로 처음맡았던 일이 바로 E2E 테스트 관련 일이었다.

기존에 nightwatch로 동작하던 것을 jest + puppeteer 환경으로 변경하고 Test case를 추가하는 것!!

jest: 테스트 가능한 자바스크립트 라이브러리
puppeteer: headless Chrome 이나 Chromium을 컨트롤하기 위한 Node.js 라이브러리

headless browser란?

A headless browser is a web browser without a graphical user interface.

출처: Wiki

GUI가 없이 작동되는(= 렌더링) 브라우저 라고 이해하면 된다.

jest에 대한 일반적인 내용 보단, Test case를 작성하면서 겪었던 문제와 경험 위주로 작성해보려고 한다.

이슈1: test 시작 전, beforeAll안의 함수들이 모두 실행되지 않고 테스트가 시작되므로 error발생.

beforeAll 안에 workspace에서 로그인후 해당 상담사의 상태를 체크하고, online이 아니라면 online으로 변경해주는 함수가 있었다.

상담사 상태가 온라인이어야만, 그 다음 test case들이 정상적으로 실행되기 때문에 반드시 beforeAll 함수 안에서 실행되어야만 했는데,

기다려주지 않고 다음 case들이 실행되어 그 이후 case들은 당연히 error가 발생하는 문제였다.

 beforeAll(async() => {
    .....
    await lib.login(AGENT.id, AGENT.password);
    await lib.checkUserState();
 });

jest문서에서 해결책을 찾을 수 있었다.

Optionally, you can provide a timeout (in milliseconds) for specifying how long to wait before aborting. The default timeout is 5 seconds.

default timeout이 5초이기 때문에, 아래와 같이 setTimeout 시간을 명시적으로 설정해주면 해결할 수 있었다.

jest.setTimeout(50 * DEFAULT_TIMEOUT);

이슈 2: 각각 다른 브라우저 2개에서 연관된 테스트 실행시, error 발생.

유저와 상담사간 상담이 진행되는 test case이기 때문에 브라우저 2개가 필요했다.

workspace와 채팅앱 화면을 왔다갔다 하며 테스트가 진행되어야 하는데, 채팅앱에서 workspace으로 화면에 접근이 되지 않았다.

알고보니, tc를 진행할 browser에 focus를 줘야 하는 것이었다.

browser를 컨트롤 하는 부분이므로, puppeteer의 bringToFront method를 이용하면 된다.
(각각 다른 브라우저 뿐만 아니라, 한 브라우저 내의 tab 전환도 가능하다.)

입사전 혼자 프로젝트를 진행할 땐, 테스트의 중요성을 잘 깨닫지 못해서 테스트 코드는 우선 순위에서 밀려나 작성하지 않았던 경우가 대부분이었다.

서비스 제품을 개발하는 팀에선, 테스트 코드가 필수인 걸 알게 됐다.
특히, 큰 feature들이 추가되는 경우라면 기존 로직이 동일하게 동작하는지 side effect이 없는지 등 에러를 방지할 수 있기 때문이다.

E2E 테스트와 더불어, unit 테스트 기반의 TDD를 실천하는 우리 개발팀이 될 수 있길 바라며...💪🏻

Why Lodash?

Nily — Sat, 18 Mar 2023 08:43:02 +0000

lodash는 현재 회사의 온보딩 교육 과정에서 처음 접했던 라이브리러리 였다.

회사의 기술 스택을 전반적으로 경험해 볼 수 있는 프로젝트 였는데, 시니어 개발자 분께서 프론트엔드에서 가장 널리 쓰이고 있는 것이니, 꼭 익숙해지라고 하셨던 생각이 난다.

아래 설문조사에 따르면, lodash가 1위를 차지한 것을 볼 수 있다.

출처: https://2022.stateofjs.com/en-US/other-tools/

이젠 필수가 되어버린 lodash를 쓰며 느낀 장점들을 써보려고 한다.

1. 코드의 가독성이 좋아진다

함수 이름이 직관적이고, 코드를 간결하게 쓸 수 있기 때문에 그 흐름이 비교적 쉽게 이해된다.

_.uniq([1, 1, 2]); // [1, 2]
_.intersection([2, 1], [2, 3]); // [2]

2. native 함수에서 가능하지 않았던 것들이 가능해진다.

예를 들어, native javascript의 .forEach(), .map()같이 Array에서만 가능했던 method들에 Object type도 적용할 수 있다.
함수의 확장성이 높아져서 그 활용도가 높다는 것이다.

const person = {
 name: 'Jenny',
 age: 20,
 hasDog: true
}

_.forEach(person, (value, key) => console.log(value));
// 'Jenny'
// 20
// true

_.forEach(person, (value, key) => console.log(key));
// name
// age
// hasDog

개인적으로 가장 큰 장점이라고 느꼈던 부분이다.🤩

일하면서 가장 자주 썼던 함수들은 native함수에서 복잡하게 구현하지 않아도 되는 것들이다.

_.filter()
_.clone() / _.cloneDeep()
_.isEqual()
_.remove()
_.orderBy()
...

아래 항목들은 구글링으로 찾아본 장점들이다.

3. Cross-browser compatibility

브라우저에 상관없이 동일하게 동작하기 때문에 호환성 이슈를 신경쓰지 않아도 된다.

4. 에러 처리에 있어 안전하다.

[native JS]

const products = [
{code: ‘00123’,name: ‘Milk’ },
{code: ‘01020’,name: ‘Bread’ },
{code: ‘12232’,name: ‘Eggs’ },
]

const productCodes = products.map(product => product.code)

// productCodes -> [‘00123’, ‘01020’, ‘11232’]

이 때, products가 항상 Array 타입을 유지한다는 보장이 없다면? 👉 productCodes는 Error를 발생시키게 된다.

const products = await SomeAPI.fetchProducts() //-> null

const productCodes = products.map(product => product.code)
//-> Uncaught TypeError: Cannot read property 'map' of null

lodash의 _.map을 사용한다면?

const productCodes = _.map(products, product => product.code)

products가 null or undefined 이어도 _.map을 사용했기 때문에 empty Array를 return하게 된다.

API로 부터 정상적인 값을 받지 못해도, productCodes가 Array type으로 유지 되기 때문에 에러가 발생하진 않는다.

구글링 하면서 보다 보니, 굳이 lodash를 사용하지 않아도 된다는 의견의 글들도 여럿 보았다. (관련 링크)

이미 너무 익숙해져 버린 lodash... 자주 사용하는 method만 계속 쓰는 습관이 있는데 이외에도, 더 유용한 method들이 있다면 적극 사용하도록 노력해야겠다.

[Typescript] Study TS with me (2) - Generics

Nily — Sun, 12 Mar 2023 13:57:48 +0000

Generics allow creating 'type variables' which can be used to create classes, functions & type aliases that don't need to explicitly define the types that they use.

Generics makes it easier to write reusable code.

제네릭은 Java나 C++ 같은 정적 타입 언어에선 이미 널리 쓰이고 있는 기능이라고 한다. 다양한 타입에서 작동한다는 장점이 있기 때문에 component를 만들때 유용하게 쓰일 수 있다.

1. Function

function identity<T>(arg: T): T {
  return arg;
}

// 함수를 호출하는 순간 Type이 결정됨.
const output1 = identity(3); // number
const output2 = identity('myName'); // string

2. Class

class SimpleImage<T, S> implements Image<T, S>{
  constructor(
    private _title: T,
    private _size: S,
  ){}

  title(): T {
    return this._title;
  }
  size(): S {
    return this._size;
  }
}

const simpleImage = new SimpleImage({ main: 'sample image'}, 300);

3.1 Generic Constraints

interface Lengthwise {
  length: number;
}

function logginIdentity<T extends Lengthwise>(arg: T): T {
  console.log(arg.length);

  return arg;
}

// 제네릭 함수의 타입이 제한되어 있기 때문에, 모든 타입에 대해선 동작하지 않음.
logginIdentity(3); // Error

// length property가 있는 type을 전달해야 함.
logginIdentity({ length: 10, value: 3 });

3.2 Using Type Parameters in Generic Constraints

// obj에 존재하는 property만 가져오도록
function getProperty<T, K extends keyof T>(obj: T, key: K) {
  return obj[key];
}

const x = {
  a: 1, 
  b: 2, 
  c: 3,
  d: 4
}

getProperty(x, 'a');
getProperty(x, 'f'); // Error: f는 x에 존재하지 않는 property

scss에서 많이 쓰이는 디자인 패턴인 mixins을 만드는데도 Generic이 쓰였다고 하니, 나중에 기회가 되면 또 포스팅 해봐야 겠다. (참고 링크)

[출처]

https://www.typescriptlang.org/ko/docs/handbook/2/generics.html -https://www.w3schools.com/typescript/typescript_basic_generics.php

Agile Team - How do we work?

Nily — Sat, 15 Oct 2022 07:13:19 +0000

현재 직장인 Agile 팀 일한지 1년 5개월째, 이번 글은 약 1년 동안 느낀 애자일 조직 문화를 주제로 써보려고 한다.

입사 전, "애자일" 이라는 단어만 들었을 땐 무슨 개발 용어인줄 알았다. 현재 팀에 합류한 뒤 온보딩 과정에서 애자일 방법론에 대한 교육을 받았을 때, 적지 않은 충격을 받았던 기억이 난다.

이전 회사에선 워터폴 방식으로 업무를 했었기도 했고, 모든 개발팀은 다 그런식으로 일하는 줄 알았기 때문이다.

애자일과 워터폴은 프로젝트 방법론으로, 조직의 특성에 맞게 알맞은 방식을 채택하여 사용한다. SaaS(Software as a service) 제품을 개발하는 우리는 팀의 특성에 맞게 애자일 방식을 채택하여 운영중이다.

출처: https://hackr.io/blog/agile-vs-waterfall

간단히 설명하자면,

Waterfall: 전체 개발 주기가 정해져 있고 작업이 순차적으로 진행됨.
Agile: 짧은 개발 주기가 반복되고, 완성도의 차이는 있지만 결과물을 빠르게 볼 수 있음.

우리 팀은 애자일 방법론 중에서도, Scrum이라는 방식을 사용하고 있다.

우리 팀이 일하는 방식을 하루 일과를 통해 알아보자🙌

10:30am - 데일리 미팅

어제 한 일을 서로 짧게 공유하고, 오늘 todo를 정한다. (+ 이슈가 있었다면 이슈 공유도 한다)
이번 스프린트의 todo는 화이트 보드에 각 이슈별로 포스트 잇으로 정리되어 있다
작업이 완료된 이슈는 todo 에서 done으로 옮긴다

다들 각자 할일이 명확하게 정해져 있기 때문에 하루 일정을 자유롭게 사용하면 된다.

나는 보통 코드 리뷰할 일이 있다면, 오전에 리뷰를 요청드려서 오전 시간을 보내는 편이다.
(우리 팀은 PR이 아닌 1:1 또는 1:2 코드 리뷰를 하기 때문에 시간이 꽤 소요된다)

점심 시간은 자유롭게 편한 시간에 사용하고, 오후 업무를 시작한다.

오후 일정도 특별한 일은 없고, 데일리 미팅 때 정한 todo를 이어서 하면 된다.

sprint planning
2주 주기로 있는 스프린트 회의는 PO(Product Owner)의 주도 하에 앞으로 2주동안의 계획을 짠다.

기획, 개발 팀은 필수로 참여하고, 영업/마케팅 팀은 영업적 측면에서 고객의 요구사항 등 필요한 기능들을 전달한다.

돌아가면서 짧게 회고를 하고, 각 이슈에 대한 내용을 공유하며 해당 이슈에 대한 estimation을 한다.

작업이 어느 정도 소요될지를 정하는 단계이며 스프린트 회의의 핵심이라고 할 수 있다.

1d, 3d 등 day 기준으로 estimation이 이루어지고, 디테일한 일정은 개발팀끼리 따로 2차 플래닝 때 정한다.

2차 플래닝 때는, estimation이 된 이슈를 가지고 세부 계획을 짠다.
만약 2d(1d = 6h) 기준 짜리 작업이 있다면, 시간 단위(h)로 또 일정을 세운다.

ex)

3h - 기능 분석
3h- API 작업 (query 추가, schema 변경)
3h - UI (style, 레이아웃)
3h - 테스트 및 이슈 처리

장점

2주라는 짧은 기간동안 작업한 것들을 상용에 배포시키기 때문에 성취감이 잘 느껴진다.
미리 2주동안의 계획이 있기 때문에, 급하게 요청받을 일이나 계획에 없던 작업이 생길일이 거의 없다.
(크리티컬한 버그를 급하게 수정해야 할 일이 아니라면)
각자 주도하에 todo만 잘 해낸다면, 일정이 자유롭다.
(회사의 분위기에 따라 다르겠지만, 만약 오늘 6h가 걸리는 일을 3h 만에 끝냈다면? 그냥 퇴근해도 아무런 문제가 없다!!)
기획, 디자인 일정에 영향을 받지 않는다.
- 만약, 워터폴 방식이라면 기획이 늦어지면 디자인, 개발을 진행하기 어렵다.
- 애자일 방식은, 기능 단위로 기획-디자인-개발-테스트-배포가 진행되기 때문에 기획 + 디자인이 완료된 다른 기능 개발을 시작하면 된다.

단점

2주 스프린트가 계속 반복되기 때문에 일의 강도가 높은 편이다.
- 이 부분도 팀마다 다를 순 있겠지만 보통 일정이 여유로울 때도 있고 빡빡(?)할 때도 있는데, 일정한 강도의 업무가 계속 이어져서 지치기 쉽다.

(최근 팀에 합류한 동료의 말에 따르면, 처음에 적응하기 어려웠다고 한다)

보통 스프린트 플래닝 하는 날엔, 하루 종일 플래닝을 하기 때문에 끝나고 나면 기가 엄청 빨릴 때도 있다😅😅

그래도 지금까지 경험하기에 단점보다 장점이 훨씬 많고, 개인적으로도 잘 맞는 업무 방식이기 때문에 충분히 만족하고 추천할 만한 개발 방법론이라고 생각한다.

이번에 이렇게 글을 작성하면서, 다시 한번 이상적인 애자일 팀에서 일하고 있다는 생각이 들었다. 시니어 분들이 이미 애자일에 경험이 많으신 분들이라 시스템화가 잘 되어있고, 항상 더 효율적인 업무 방식을 고민하시기 때문이다.

애자일 방식을 채택하지 않은 팀에 간다면 적응하기 힘들 정도로, 잘 적응이 되었고 애자일의 스크럼 이외에도 더 좋거나 공유하고 싶은 개발 방법론이 있는지 알아봐야겠다.

[Javascript] Performance of Set and Array

Nily — Sat, 08 Oct 2022 06:57:32 +0000

이번주 회사에서 코드 리뷰를 하면서 기술 블로그로 쓰기 딱 좋은 주제가 생겼다.

object의 property 값이 중복되는지 체크하는 부분이었는데, 내가 작성한 로직은 아래와 같다.

Array에 해당 property 값들을 담아 놓음
lodash의 _.uniq()로 Array에서 중복 값 제외
object와 Array의 length 비교 (length가 다르다면 중복 값이 존재함)

리뷰해주는 동료분께서, 중복값을 체크하려면 Set을 써도 되지 않겠냐고 의견을 주셨다. 한동안 Set을 안쓰고 있어서 기억 저편에 있었다😅

Set을 사용하는 경우 로직:

Set에 해당 property 값들을 담아 놓음 (Set은 uniq한 값들만 저장됨)
object와 Array의 length 비교

Array와 가장 큰 차이는 중복값을 체크하는 코드가 필요없다는 것!!!
그러다 문득 Array와 Set의 퍼포먼스가 어느정도 차이가 나는지 궁금해졌다.

Array를 사용한 경우:

let isDuplicate: boolean = false;
const names: string[] = [];

console.time('use Array');

_.forEach(result, (item) => {
  names.push(item.name);
});

if (result.length !== _.uniq(names).length) {
  isDuplicate = true;
}

console.timeEnd('use Array');

Set을 사용한 경우:

let isDuplicate: boolean = false;
const names: Set<string[]> = new Set();

console.time('use Set');

_.forEach(result, (item) => {
  names.add(item.name);
});

if (result.length !== names.size) {
  isDuplicate = true;
}

console.timeEnd('use Set');

데이터의 수가 100개 미만인 지금 상황과 같은 경우, Set이 Array보다 약 0.01 ms 정도 빨랐다.
현재 코드에선 거의 차이가 안나는 수준이긴 하다.

그런데 만약 데이터가 1k, 10k 정도로 많아진다면?

	Array	Set
1k
10k
100k

1,000개 까지는 눈에 띄게 차이가 나지 않지만, 10만개 이상의 많은 데이터의 경우 38ms 정도 차이가 난다. 이 땐, Set을 사용하는 것이 퍼포먼스 측면으로는 더 낫다고 볼 수 있겠다.

❗️이건 Array의 push + lodash _.uniq() + Array.length
Set의 add + Set.size 조합을 비교한 경우이기 때문에,
데이터 삭제, index 추출 등 Array와 Set의 퍼포먼스는 각각 다 다를 수 있다.

현재 해당 기능의 로직상 10만개 이상의 데이터가 들어오는 경우는 거의 없지만, 코드의 가독성 측면에서 Set을 사용하는 게 더 낫다고 결론이 나왔다.😌😌

잊고 있었던 Set을 다시 상기 시키고, Array와 Set을 비교해 글까지 작성하게 해준 이번 코드 리뷰였다. 매일 배우는 즐거움과 성장할 기회가 주어지는 개발자라는 내 직업이 너무 행복함을 다시 한 번 느꼈다🥰

Today I learned - Problem Solving Skills

Nily — Sat, 01 Oct 2022 07:37:08 +0000

효율적인 문제해결 과정이란 무엇일까?

흔히 말하는 "삽질"을 줄이고 눈 앞에 닥친 문제를 어떻게 하면 빨리 해결할 수 있는지 현업에서 겪은 일을 통해 깨달은 3가지 방법을 소개하려고 한다.

최근 dropdown typeahead 기능을 구현하는 작업을 했다. 부모 component로 부터 option값들을 전달받아야 했는데, object로 부터 빈 array만 받아오는 것이었다.

빈 값만 전달받기 때문에 dropdown에 뿌려줄 목록은 안나오는 상황이었고, 그 부분에서 막혀 계속 헤매고 있었다. 답답해서 시니어 개발자 분께 여쭤보니 일단 모든 곳에 로그를 찍어보라고 하셨다.

문제 원인은 생각보다 너무 단순했다. value change 이벤트를 받을 때 값이 변경되기 때문에 그 때 option 값들을 할당해주면 되는데, component가 init 될 때만 값을 받아와서 당연히 빈 값만 셋팅 되었던 거였다.

첫번째 depth에서 선택한 값에 따라 2depth, 3depth의 dropdown 옵션들이 달라지는 로직이기 때문에 이벤트가 어디서 오는지 파악하고, 로그만 찍어봤어도 바로 해결되었을 문제...!!

이 사건으로 깨달은 나의 개선해야할 점을 정리해 봤다.

막연한 가정하지 않기

일단 모르겠으면, console log 찍어보기

다른 사람이 작성한 코드를 참고할 땐, 제대로 분석하고 그 흐름을 이해해서 필요에 맞게 쓰기

1. 막연한 가정하지 않기

이 상황에선 이렇게 데이터가 출력되겠지, 여기선 아직 데이터 set 안됐겠지 등 암묵적으로 가정하고 문제를 해결하려고 했기 때문에 삽질한 시간이 더 길어졌다.

2. 일단 모르겠으면, console log 찍어보기

옆자리 시니어 개발자 분께서 제일 강조하신 말씀이다..ㅎㅎㅎ "막연한 가정하지 않기" 와 이어지는 부분으로, 일단 log를 찍어보고 데이터의 흐름을 파악하는게 중요하다고 말씀하셨다.

3. 다른 사람이 작성한 코드를 참고할 땐, 제대로 분석하고 그 흐름을 이해해서 필요에 맞게 쓰기

이번에 작업한 부분은 formly라는 라이브러리로, JSON 데이터를 인식해 form UI 형태로 만들어주는 걸 사용중이었다. formly에서 typeahead가 가능한 dropdown을 구현하기 위해 해당 코드를 참고해서 적용했다.

RxJs의 Subject와 Observable을 변수로 이용해서 사용하는데, 사실 동작하는데만 초점을 맞추고 그냥 아무 생각없이 가져와서 어떻게든 우리 코드에 우겨넣으려고(?)했던 것 같다.
참고한 코드를 분석해서 왜 이건 이런식으로 썼을지 고민은 하지 않고 기능을 구현하는데 급급했다.

이런 부분에서 약간 꾸지람을 들었다.😅😅 (동작 원리를 제대로 파악하고 있지 않는데 어떻게 활용해서 그 코드를 쓸 수 있겠냐고...)

주니어 개발자로서, 매 순간 과정에서 배워야 할 점이 생긴다. 이번에 깨달은 문제 해결 방법 3가지를 새기면서, 앞으로는 같은 문제가 생겨도 더 쉽게 접근하고 해결할 수 있기를 바래본다.

[Typescript] Study TS with me (1) - basic type

Nily — Sat, 24 Sep 2022 07:24:11 +0000

평소 일하면서 Typescript를 쓰면서도, type/enum/interface 등 왜 저런 코드로 쓰는지를 생각하지 않고 그냥 사용한 적이 많았다. 이렇게 코드를 작성한 이유가 있겠지 하면서 이전 코드를 복붙하거나 의문을 가졌던 적이 별로 없다.

최근에 팀에 새로 합류한 분의 온보딩 스터디 프로젝트를 같이 리뷰하는 시간을 가졌는데, class 구현부터 Typescript를 적극적으로 사용한 걸 보면서 그 동안의 나를 반성하게 되었다.😂

다시 기초부터 차근차근 공부하면서, type 선언 정도로만 ts를 쓰는 수준이 아닌 ts의 장점을 제대로 활용하는 코드를 쓰고 싶어 이렇게 ts스터디를 시작하게 되었다.

String Literal Types

문자열 자체를 type으로 선언해서 사용

type All = 'all';

let selectAll: All = 'all';
selectAll = 'other'; //error

Union Types

2개 이상의 선언된 type을 사용할 수 있음

Union Type은 평소에 익숙하게 사용중이다. 보통 여러개 string type을 가질 때 사용했다. 아래 예제처럼 서로 다른 type들도 Union Type으로 선언해 사용할 수 있다는 걸 알았다.

type Id = number | string;

function printId(id: Id) {
 if (typeof id === "string") {
    console.log(id.toUpperCase());
 } else {
    console.log(id);
 }
}

Discriminated Union Types

각각 다른 Type별로 동일한 property 이름을 가지고 있음
해당 property로 Type별로 구분이 가능함

 type Circle = {
  kind: 'circle',
  radius: number
 }

 type Square = {
  kind: 'square',
  x: number
 }

 type Triangle = {
  kind: 'triangle',
  x: number,
  y: number
 }

 type Shape = Circle | Square | Triangle;

 function area(s: Shape) {
  if (s.kind === "circle") { // discriminate type
    return Math.PI * s.radius * s.radius;
  } else if (s.kind === "square") { // discriminate type
    return s.x * s.x;
  } else {
    return (s.x * s.y) / 2;
  }
 }

Enum Types

여러개의 상수를 하나의 type으로 묶어 관리할 수 있음.

enum Direction {
  Up = 1, // 시작하는 숫자를 할당해 줄 수 있음(default는 0) 
  Down,
  Left,
  Right,
}

구글링 하다보니, Enum typ은 안정성이 떨어진다는 얘기가 꽤 많았다.

[이유]

transfile 되면서, bundler(rollup)에서 TreeShaking을 할 수 없음.
관련 링크
Tree-Shaking, const enum 등 설명할 개념이 많아서 이건 다음편으로..
number일 경우, type이 보장되지 않음

 type enum DAYS = {
  Mon,
  Tue,
  Wed,
  Thur,
  Fri,
  Sat,
  Sun
 }

 let day = DAYS.Mon;
 day = DAYS.Wed;
 day = 10; // error지만 compile시 error가 발생하지 않음!(= type이 보장되지 않는다)

Enum type은 Union Type으로 대체 가능하기 때문에 Union Type을 사용하는 것이 권장되는 분위기 였다.

하지만 팀의 개발 환경이나 가독성 측면에서 Enum을 사용하는 것이 더 나을 때도 있으니 충분히 설명 가능한 이유가 있다면 채택해서 사용해도 큰 문제는 없다는 글도 봤다.

TMI:
사실 우리 팀에서도 Enum Type을 꽤 사용중이다.😅😅 팀에서 굉장히 논리적인 이유로 뭐든 것을 설명하시는 시니어 개발자 분이 계신데, 다음에 출근해서 물어봐야겠다. (엄청난 합리적인 이유가 있을 것으로 예상되는...)