데브머리큐

Safari - new Date() 이슈

devmomori — Tue, 27 Sep 2022 12:38:21 +0900

크롬에서는 아래와 같은 코드가 잘 작동한다.

new Date('2022-09-27 09:00:00') // Tue Sep 27 2022 09:00:00 GMT+0900 (한국 표준시)
new Date('2022/09/27 09:00:00') // Tue Sep 27 2022 09:00:00 GMT+0900 (한국 표준시)

사파리에서는??

( - ) 붙임표가 문제다

new Date('2022-09-27 09:00:00') // Invalid Date

이렇게 바꿔주자.

new Date('2022/09/27 09:00:00')

객체지향의 사실과 오해 - 객체 지도

devmomori — Wed, 14 Sep 2022 21:29:46 +0900

이번 챕터는 글로 써 내려가는 것보다 그림을 통해 이해하는 게 쉽다.

길을 묻는 방법은 현재의 마을에서 다른 마을로 이동하는 현재의 요구만을 만족시킬 수 있다. 지도는 현재의 목적뿐만 아니라 다양한 목적을 위해 재사용될 수 있다. 즉 지도는 범용적이다.

훌륭한 기능은 훌륭한 소프트웨어를 만들고 훌륭한 구조는 훌륭한 소프트웨어를 만들기 위한 필요조건이다.

게임 플레이어들은 게임 도메인을 캐릭터와 몬스터, 그리고 아이템 간의 관계로 표현한다. 중고 자동차 판매상은 구매되는 자동차와 판매되는 자동차의 교환으로 자동차 도메인을 바라본다.

객사오 - 189쪽 그림

코드의 구조가 도메인의 구조를 반영하기 때문에 도메인을 이해하면 코드를 이해하기가 수월해진다.

객사오 - 198쪽 그림

시스템에 할당된 커다란 책임은 시스템 안의 작은 규모의 객체들이 수행해야 하는 더 작은 규모의 책임으로 세분화된다. 도메인 모델에 명시된 정기예금이나 계좌와 같은 개념을 상태와 행위를 관리하는 자율적인 객체로 간주한다.

이자 계산 기능이 변경되거나 추가되도 클래스와 클래스 간의 관계는 그대로 유지될 수 있다.

객사오 - 204쪽 : 단리, 복리 이자를 계산할 수 있는 클래스 다이어그램

객체지향의 가장 큰 장점은 도메인을 모델링하기 위한 기법과 도메인을 프로그래밍하기 위해 사용하는 기법이 동일하다는 점이다. - 연결 완전성

역방향 역시 성립할 수 있는데, 가역성이라 한다.

객체지향의 사실과 오해 - 책임과 메시지

devmomori — Wed, 7 Sep 2022 15:59:21 +0900

여러 내용들이 가리키는 하나의 목적은 소프트웨어의 유연한 변경, 즉 유지보수를 편하게 하는 것

자율성

객체가 어떤 행동을 하는 유일한 이유는 다른 객체로부터 요청을 수신했기 때문이다. 요청을 처리하기 위해 객체가 수행하는 행동을 책임이라고 한다. 자율적인 객체란 스스로의 의지와 판단에 따라 각자 맡은 책임을 수행하는 객체를 의미한다.

객사오 142쪽 - 그림 5.1

모자 장수는 왕에게 증언할 책임은 있지만, 증언을 위한 구체적인 방법이나 절차에 대해서는 최대한의 자유를 누린다.

객사오 142쪽 - 그림 5.2

여기서 문제는 여러 책임들이 모자 장수가 증언하기 위해 선택할 수 있는 자유의 범위를 지나치게 제한한다는 점이다.

두 번째 모자 장수는 자율적으로 책임을 수행할 수 없다. 객체가 자율적이기 위해서는 객체에게 할당되는 책임의 수준 역시 자율적이어야 한다. 그러나 포괄적이고 추상적인 책임이 무조건 좋은 것은 아니다. 협력의 의도를 명확히 표현하는 것이 중요하다. 어떻게('How') 해야 하는 것보다 무엇('What')을 해야하는가가 중요하다.

메시지

메시지를 가리키는 '증언하라'라는 부분을 메시지 이름이라고 한다. 추가적인 정보가 필요한 경우에는 메시지의 인자(argument)를 통해 추가 정보를 제공할 수 있다. ex) 모자장수.증언(어제, 왕국)

1장부터 4장까지 계속해서 언급해온 메시지 송신자와 수신자에 대해서 설명한다. 요약하면 메시지는 객체들이 서로 협력하기 위해 사용되는 유일한 의사소통 수단이다.

메서드

모자 장수가 메시지를 처리하기 위해서 내부적으로 선택하는 방법을 메서드라고 한다. 해당 메시지를 처리할 수 있는지 확인 후, 주어진 책임을 다하기 위해 메서드를 선택한다. 메서드는 클래스 안에 포함된 함수 또는 프로시저를 통해 구현된다. 어떻게 수행되는지는 명시되지 않으며, '무엇'이 실행되기를 바라는지만 명시한다. 어떤 메서드를 선택할 것인지는 전적으로 수신자의 결정에 좌우된다.

유연하고 확장 가능하고 재사용성이 높은 협력의 의미

송신자가 수신자에 대해 매우 적은 정보만 알고 있더라도 상호 협력이 가능하다는 사실은 설계의 품질에 큰 영향을 미친다.

유연한 협력: 송신자는 수신자에대해 어떤 가정도 하지 않는다. 수신자를 다른 타입의 객체로 대체하더라도 송신자는 알지 못한다. 유연하게 협력이 변경 가능하다.
확장 가능성 : 협력이 동작하는 방식은 변경될지라도 협력의 구조 자체는 변경되지 않는다. ex) 증언을 할 때 재판장에 참석하는 것이 아닌 동영상만 보낼 수 있는 객체
재사용성 : 재판이라는 협력을 누구에게나 적용할 수 있다.

메시지를 기반으로 한 두 객체 사이의 낮은 결합도가 설계를 유연하게 하고 확장 가능하며 재사용 가능하게 만든다.

인터페이스

특징

인터페이스의 사용법을 익히기만 하면 내부 구조나 동작 방식을 몰라도 쉽게 대상을 조작하거나 의사 전달이 가능하다.
인터페이스의 변경 없이 단순히 내부 구성이나 작동 방식을 변경하는 것은 사용자에게 어떤 영향도 미치지 않는다.
대상이 변경되더라도 동일한 인터페이스를 제공하기만 하면 아무런 문제 없이 상호작용 할 수 있다.

메시지가 인터페이스를 결정한다. 객체가 어떤 메시지를 수신할 수 있는지가 객체가 제공하는 인터페이스의 모양을 빚는다.

인터페이스와 구현의 분리

좀 더 추상적인 인터페이스
최소 인터페이스
인터페이스와 구현 간에 차이가 있다는 점을 인식

1. 상세한 수준의 메시지가 아닌 위에서 설명한 '증언하라'처럼 추상적인 수준의 메시지를 통해 수신자의 자율성을 보장한다.
2. 외부에서 사용할 필요가 없는 인터페이스는 최대한 노출하지 않는다. 이를 통해 내부를 수정하더라도 외부에 미치는 영향을 최소화한다.
3. 객체의 외부와 내부를 분리하는 것은 결국 객체의 공용 인터페이스와 구현을 명확하게 분리하라는 말과 동일하다.

인터페이스와 구현의 분리 원칙이 중요한 이유?

소프트웨어는 항상 변경되기 때문이다. 어떤 객체를 수정했을 때 발생하는 사이드 이펙트를 예상하는 것은 어렵다. 객체가 가져야 할 상태와 메서드 구현은 객체 내부에 속한다. 이 부분을 수정하더라도 객체 외부에 영향을 미쳐서는 안 된다. 객체 외부에 영향을 미치는 변경을 객체의 공용 인터페이스를 수정할 때뿐이다.

책임의 자율성이 협력의 품질을 결정한다.

책임의 적절한 추상화를 통한 협력의 단순화. 자율적인 책임은 협력을 단순하게 만든다.

자율적인 책임은 모자 장수의 외부와 내부를 명확하게 분리한다. 왕은 증언하라 명령했지만 모자 장수가 내부적으로 어떻게 책임을 수행하는지는 볼 수 없다. 요청하는 객체가 몰라도 되는 사적인 부분이 객체 내부로 캡슐화된다. 인터페이스와 구현이 분리된다.

수행하는 내부적인 방법을 변경해도 외부에 영향을 미치지 않는다. 증언하는 방법은 변경해도 왕에게는 어떤 영향도 미치지 않는다. 그러나 자율적인 책임을 가질 수 없었던 세세한 증언 방법의 요청(시간 순서로, 목격 장면, 간결한 표현 등)은 하나라도 변경되게 된다면 협력이 무너지게 된다. 책임이 자율적일수록 변경에 의해 수정되어야 하는 범위가 좁아지고 명확해진다. 변경의 파급효과가 객체 내부로 캡슐화되기 때문에 두 객체간의 결합도가 낮아진다.

자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다. 모자 장수 이외에 앨리스나, 요리사가 증언을 하는 예시가 있다. 설계가 유연해지고 재사용성이 높아진다.

객체의 역할을 이해하기 쉬워진다. '증인석 입장', '증언하다'라는 두 가지 책임을 가진 모자장수가 어떤 역할을 해야 하는지 명확히 알려준다. 객체의 응집도를 높은 상태로 유지하기가 쉬워진다.

책임이 자율적일수록
적절하게 '추상화'되고,
'응집도'가 높아지고,
'결합도'가 낮아지며,
'캡슐화'가 증진되고,
'인터페이스와 구현이 명확히 분리'되고,
'설계의 유연성과 재사용성이 향상'된다.

[web.dev 장점 뽑아먹기]: Lighthouse CI로 웹 성능 모니터링 하기

devmomori — Fri, 2 Sep 2022 18:50:31 +0900

운영 중인 서비스의 웹 바이탈(Web Vitals)과 전반적인 개선점을 주기적으로 체크하며 웹 성능을 모니터링을 해보자.

간단한 웹 성능 측정 방법 2가지

먼저 간단한 방법 2가지를 알아보고 Lighthouse CI를 적용해보자.

개발자 도구 - Performance

개발자 도구를 열고 Performance 탭에 들어가 녹화를 시작하고 여러 가지 동작을 수행한 후 녹화 정지 버튼을 누르면 전반적인 지표들을 아래와 같이 볼 수 있다. 이를 통해 웹 페이지 로드(load) 시점에서 일어나는 블로킹(Blocking)을 해결하고 시각적으로 LCP, CLS 지점들을 확인해 볼 수 있다.

Developer Tool Web Performance

개발자 도구 - Lighthouse

Lighthouse는 별도로 어떤 동작을 수행하지 않아도 Analyze Page Load 버튼을 누르면 자동으로 보고서를 생성해준다. 아래와 같은 각 카테고리 별 지표들을 생성해주는데, 각 카테고리별 세부내용이 자세하게 표시되어 있어서 이를 바탕으로 운영 중인 서비스의 개선을 시작해 볼 수 있다.

Lighthouse Google.com Report : Performance, PWA, Best Practices, Accessibility, SEO

위의 여러가지 방법들로 간단하게 웹 성능, 그리고 관련 지표들을 쉽게 확인할 수 있지만 매번 페이지에 접속해 개발자 도구를 열고 녹화 버튼을 누르거나 보고서를 생성하는 것은 꽤나 귀찮은 일이다. 어떻게 주기적으로 관련 리포트를 받아볼 수 있을까?

Lighthouse CI : 웹 성능 리포트 자동화

두 번째 성능 측정 방법인 Lighthouse를 사용, 정확히는 Lighthouse CI를 사용하여 CI(Continuous Integration)에서 보고서 생성을 자동화해보자.

1. 프로젝트 구축
JavaScript, React, Vue, Nextjs 어떤 것이든 상관없다.

// Next.js로 프로젝트 구축
# yarn create next-app --typescript

2. Lighthouse CI 설치 및 파일 추가

/* install @lhci/cli */
# yarn global add @lhci/cli

/* root 경로에 lighthouserc.js 파일 생성 */
# touch lighthouserc.js

3. Configuration 파일 작성

module.exports = {
  ci: {
    collect: {
      staticDistDir: './out',
      url: ['http://localhost:3000'],
      numberOfRuns: 2,
      // 동적 페이지일 경우
      startServerCommand: 'yarn start',
    },
    assert: {},
    upload: {
      // 보고서가 최대 7일까지 저장되는 임시저장소
      // .lighthouseci/ 폴더 저장 및 Github status check
      target: 'temporary-public-storage',
    },
    server: {},
    wizard: {},
  },
};

collect에 대해 간단히 설명하자면, 다음과 같다.

Lighthouse를 n번 실행시키며 만들어진 보고서를 .lighthouseci/ 폴더에 저장한다.

staticDistDir: 사이트가 정적 사이트일 경우 ci.collect가 정적 파일들이 위치한 곳을 가리킨다.
- ex. dist(Vue), build(react), out(Next.js), public(gatsby)
url: lighthouse가 동작하게 될 URL, 여러 페이지를 확인하고 싶은 경우에는 배열 내부에 새로운 url을 계속 추가해주면 된다.
numberOfRuns: lighthouse 실행 횟수
startServerCommand: 서버 실행 명령어

lighthouse가 제공하는 지표 점수에 따라 '주의' 혹은 '에러'를 받고 싶다면 assertion을 적용해주면 된다.

    assert: {
      assertions: {
        'categories:performance': ['warn', {minScore: 1}],
        'categories:accessibility': ['error', {minScore: 1}]
      }
    },

CI 구성을 위해서 간단히 collect와 upload 옵션만 작성해주었다. Configuration 구성 요소들에 대해 더 자세하게 알고 싶다면 lighthouse-ci Github을 참고해보자.

로컬에서 테스트

다음과 같이 명령어를 시작하면 configuration 파일을 기반으로 자동으로 리포트를 생성해준다.

// script comment to build
# yarn build

// lighthouce 실행
# lhci autorun

Next.js로 프로젝트를 구성한 경우

// script comment to build
# yarn build (next build)

// next 정적 파일을 export
# yarn next export

Next.js 내부에서 사용하는 이미지 최적화 Next/Image로 인해 오류가 날 텐데, 다음과 같이 외부 클라우드 이미지 최적화 loader를 사용하도록 설정해준다.

참고: Loader Configuration

/** @type {import('next').NextConfig} */
module.exports = {
  reactStrictMode: true,
  images: {
    loader: 'imgix',
    path: 'https:localhost:3000/',
  },
};

이와 같이 설정 후,

// lighthouce 실행
# lhci autorun

이렇게 나오면 로컬에서 lighthouse-ci는 성공이다.

GitHub Action + Lighthouse-CI

GitHub Action, Travis CI, Jenkins 등 많은 CI와 결합할 수 있는데, 여기선 Github Action을 사용한다.

GithHub App 설치 및 토큰 추가

https://github.com/apps/lighthouse-ci
설치 후 하단에 표시되는 토큰을 기억하자.

해당 토큰을 통해 github이 lhci의 status를 체크할 수 있다.

프로젝트 Settings -> Sectets > Actions -> Repository secrets에 LHCI_GITHUB_APP_TOKEN 추가

workflows/ 파일 추가

// .github/workflows/lighthouse-ci.yml
name: light-house-CI
on: [ push ]
jobs:
  lighthouseci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 17 // 사용할 노드 버전
      - run: yarn && yarn global add @lhci/cli // 프로젝트 패키지 설치와 @lhci/cli 추가
      - run: yarn build && yarn export  // next build & next export

      - name: run lighthouse CI
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
        run: |
          npx lhci autorun || echo "fail"

push 후 GitHub Action 동작 확인

Github Action lighthouse-ci.yml 실행 확인

Github Action CI by lighthouse-ci.yml

log에 보이는 report 링크를 들어가 보면 다음과 같이 나온다. (상단 캡처)

lighthouse-ci report

느낀 점

CI에 lighthouse-ci를 추가해주니 지속적으로 웹 사이트의 성능을 측정할 수 있어서 성능 개선에 대한 경각심을 심어주기도 하고, 무엇보다 간편해서 좋았다. Lighthouse CI Server도 구축해주면 보고서를 장기간 보관할 수 있고 해당 보고서들을 시각화하여 지표로 보여주기도 하는데, 이를 통해 좀 더 효과적인 웹 성능 모니터링 시스템을 구축할 수 있지 않을까 생각한다.

좀 더 찾아보니, 카카오 엔터 FE 기술 블로그에서 설명하는 PR 댓글로 ligthouse 보고서 상세 정보를 보여줄 수 있는 방법이 있는데 이 부분도 나중에 적용해 봐야겠다.

참고자료

객체지향의 사실과 오해 - 타입과 추상화 | 역할, 책임, 협력

devmomori — Wed, 31 Aug 2022 19:54:49 +0900

책을 읽으며 객체지향과 더불어 하나의 컴포넌트가 가지게 되는 역할과 책임에 대해서 계속 생각하게 된다. 재사용성이 가능한 컴포넌트를 만들기 위해서 작은 단위의 컴포넌트로 잘게 쪼개는 상황이 생기는데, 이때 조금 더 각각의 컴포넌트들이 역할과 책임을 작게 작게 가져가게 된다. 많은 설명이 개념 중심이라 배운 것들을 어디서 적용해볼지 고민도 많이 해봐야겠다. 결국에는 직접 설계하고 코드를 짜봐야 내 것이 되니깐...

코드를 빨리 짜는 것이 중요한 게 아니라 유지보수성이 뛰어난 애플리케이션을 구축하기 위해서는 견고한 설계가 우선시 되어야 한다.

타입과 추상화

지하철 승객의 목적 : 하나의 역에서 다른 역으로 이동하는 것

승객이 원하는 것 : 빠르게 목적지에 도착할 수 있는지를 직관적이고 단순하게 보여주는 것

꼭 알아야하는 사실만 표현하고 몰라도 되는 정보는 무시함으로써 목적에 부합하는 지하철 노선도를 창조 -> 지하철 노선을 추상화

모든 경우에 추상화의 목적은 복잡성을 이해하기 쉬운 수준으로 단순화하는 것

이상한 나라의 앨리스의 트럼프

하트 여왕의 행렬에서 나오는 트럼프들을 계급, 나이 , 성격 등의 차이점은 무시하며 '트럼프'라는 유사성을 기반으로 추상화해서 바라봄'

객체지향의 사실과 오해 82쪽 - 앨리스가 추상화한 등장인물들

'기껏해야 트럼프에 불과해'

개념(concept): 공통점을 기반으로 객체들을 묶기 위한 그릇

일반적으로 우리가 인식하고 있는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념을 뜻한다.

객체란 특정한 개념을 적용할 수 있는 구체적인 사물을 의미한다. 개념이 객체에 적용됐을 때 객체를 개념의 인스턴스라고 한다. (객사오 - 84쪽)

개념의 세 가지 관점

심볼(symbol): 트럼프 (개념을 가리키는 이름이나 명칭)
내연(intension): 몸이 납작하고 두 손과 발은 네모 귀퉁이에 달려 있는 등장인물 (개념의 완전한 정의, 의미를 통해 개념에 속하는지 여부를 확인)
외연(extension): 정원사, 병사, 왕자, 공주, 하트 여왕 등 (개념에 속하는 모든 객체의 집합)

개념은 객체들의 복잡성을 극복하기 위한 추성화 도구이다.

객체와 타입

객체는 데이터인가? NO

객체에서 중요한 것은 객체의 행동

행동이 우선

객체가 어떤 행동을 하느냐에 따라 객체의 타입이 결정된다.
객체의 타입은 객체의 내부 표현과는 아무런 상관이 없다.

같은 타입에 속한 객체는 행동만 동일하다면 서로 다른 데이터를 가질 수 있다. 동일한 행동은 동일한 책임을 의미한다.

다형성 : 동일한 요청에 대해 서로 다른 방식으로 응답할 수 있는 능력을 뜻함

앨리스가 바라보는 인물들의 행동 방식이 트럼프 카드와 유사하다는 생각을 갖게 만들었고 '트럼프'라는 타입으로 분류했다.

객사오 95쪽

트럼프는 트럼프 인간을 포괄하는 좀 더 일반적인 개념 -> 두 개념 사이의 관계를 일반화/특수화 관계라고 한다.

좀 더 일반적인 타입 : 슈퍼타입 (Supertype)

좀 더 특수한 타입 : 서브타입 (Subtype)

일반적으로 서브타입은 슈퍼타입의 행위와 호환되기 때문에 서브타입은 슈퍼타입을 대체할 수 있어야한다.

타입의 목적

앨리스의 키가 변화할 때, 모든 경우의 값을 나열하는 것이 아니라 단순히 키가 임의의 값을 가질 수 있다는 사실만을 생각하면 된다. - 변경되는 키라는 상태를 가진다고 단순화

이런 관점에서 타입은 추상화다

객체를 분류하는 기준은 타입 -> 타입을 나누는 기준은 행동 -> 객체 분류를 위해서 타입을 결정한 후 프로그래밍 언어를 이용해 타입을 구현할 수 있는 한 가지 방법이 클래스라는 사실을 기억하자.

역할, 책임, 협력

흔히 하는 실수 : 협력이라는 문맥을 고려하지 않은 채 객체가 가져야 할 상태와 행동부터 고민하기 시작한다.

객사오 113쪽 - 왕과 하얀 토끼, 모자 장수 사이의 협력 관계 그림

등장인물들이 특정한 요청을 받아들일 수 있는 이유는 그 요청에 대해 적절한 방식으로 응답하는 데 필요한 지식과 행동 방식을 가지고 있기 때문이다.

책임과 메시지

각각의 등장인물들은 요청을 처리하기 위한 책임을 가지고 있음

객체의 책임을 이야기할 때는 일반적으로 외부에서 접근 가능한 공용 서비스의 관점에서 이야기한다. 책임은 객체의 공용 인터페이스를 구성한다.

주의할 점 : 책임과 메시지의 수준이 같지 않다. 책임은 객체가 협력에 참여하기 위해 수행해야 하는 행위를 상위 수준에서 개략적으로 서술한 것. 책임을 결정한 후 실제로 협력을 정제하면서 이를 메시지로 변환할 때는 하나의 책임이 여러 메시지로 분할되는 것이 일반적이다.

설계 초반에는 어떤 객체가 어떤 책임을 가지고 어떤 방식으로 서로 협력해야 하는지에 대한 개요를 아는 것만으로도 충분하다. 책임을 구현하는 방법에 대한 고민은 잠시 뒤로 미뤄도 좋다.

왕은 판사 / 모자 장수는 증인 - 왜 이렇게 불러서 상황을 복잡하게 만들어야 하나?

역할이 재사용 가능하고 유연한 객체지향 설계를 낳는 매우 중요한 구성요소이기 때문이다.

그림으로 보면 좀 더 이해가 쉽다.

객사오 123쪽 - 유사한 세 개의 협력과 역할을 통한 단순화한 협력

이러한 역할의 개념을 사용하면 유사한 협력을 추상화해서 인지 과부하를 줄일 수 있다.

참고: 인지부하이론의 핵심은 인간의 작동기억에는 한계가 있기 때문에 학습자에게 너무 많은 양의 정보를 한꺼번에 제공하면 인지적 과부하를 일으켜 효과적인 학습을 방해하게 된다는 것이다.

다양한 객체들이 협력에 참여할 수 있기 때문에 협력이 좀 더 유연해지며 다양한 객체들이 동일한 협력에 참여할 수 있기 때문에 재사용성이 높아진다. 역할은 객체지향 설계의 단순성, 유연성, 재사용성을 뒷받침하는 핵심 개념이다.

추가적으로, 객체는 역할이 암시하는 책임보다 더 많은 책임을 질 수 있다.

왕은 재판도하고 국정도 돌본다.
모자 장수는 증인이지만 모자를 판매하는 본질적인 책임이 있다.

객체의 모양을 결정하는 협력

시스템에 필요한 데이터를 저장하기 위해 객체가 존재한다? -> NO

객체가 상태의 일부로 데이터를 포함하지만, 데이터는 단지 객체가 행위를 수행하는 데 필요한 재료일 뿐이다.

클래스와 클래스 간의 관계를 표현하는 시스템의 정적인 측면에 중점 -> NO

중요한 것은 협력에 참여하는 동적인 객체이며, 클래스는 단지 시스템에 필요한 객체를 표현하고 생성하기 위해 프로그래밍 언어가 제공하는 구현 메커니즘이라는 사실을 기억하자.

올바른 객체를 설계하기 위해서는 먼저 견고하고 깔끔한 협력을 설계해야 한다.

객체지향 설계 기법

책임-주도 설계 : 협력에 필요한 책임들을 식별하고 적합한 객체에게 책임을 할당

디자인 패턴 : 반복적으로 사용하는 해결 방법을 정의해 놓은 설계 템플릿의 모음

테스트-주도 개발 : 테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 추가하면서 애플리케이션을 완성해가는 방식

테스트가 아니라, 설계를 위한 기법이다. 실제 목적은 구체적인 코드를 작성해나가면서 역할, 책임, 협력을 식별하고 적합한지 피드백 받기 위함이다.

MSW(Mock Service Worker)를 사용한 네트워크 단 API Mocking 테스트

devmomori — Tue, 23 Aug 2022 03:46:00 +0900

MSW(Mock Service Worker)

MSW는 서비스 워커(Service Worker)를 사용하여 실제 요청(Requests)을 중간에서 가로채 API를 Mocking 해주는 라이브러리이다. 기존의 라이브러리들과는 다르게 네트워크 단에서 실제로 요청을 주고받으며 테스트를 진행할 수 있는 장점이 있으며, REST API 및 GraphQL 모두 지원하고 있다.

프런트엔드 개발에서 Mock API는 떼려야 뗄 수 없는 부분인 것 같다. 개발을 위한 목업 데이터 만들고 관련 로직과 컴포넌트를 만든다. API 개발을 기다리며 타입을 작성하고, 여러 가지 테스트를 진행한다. 여러 이슈들은 대부분이 잘못된 API를 호출하거나 에러 처리를 잘못하였을 때 발생하기 때문에 Mock API를 사용하여 디버깅을 해보는 것이 도움이 된다.

또한, 운영에서 사용될 API 개발이 늦어지는 경우에도 이러한 목업 데이터를 활용하여 개발 일정이 최대한 병렬적으로 수행될 수 있도록 하는 것이 생산성을 높이는 데 도움을 주는 것 같다. MSW는 별도의 목업 서버(JSON Server, etc.)를 구축하지 않아도 되고 실제 네트워크를 사용해 볼 수 있으며, API Mocking 로직들을 관리하는 데 좀 더 편한 것 이 큰 장점으로 다가오는 것 같다.

작성된 코드는 해당 레포를 참고하시면 됩니다.

GitHub - somedaycode/msw-react-tutorial: MSW(Mock Service Worker)를 사용한 API Mocking Tutorial

MSW(Mock Service Worker)를 사용한 API Mocking Tutorial - GitHub - somedaycode/msw-react-tutorial: MSW(Mock Service Worker)를 사용한 API Mocking Tutorial

github.com

기존의 API Mocking

기존의 API Mocking은 fetch 혹은 axios를 Jest.mock을 사용하여 진행하고는 했다. 실제로는 네트워크 요청이 일어나지 않으며 mockImplementation과 같은 Jest 내부 메서드를 사용하여 요청과 응답이 일어난 것처럼 테스트를 작성했다.

  import mockAxios from "jest-mock-axios";
  // mockAdapter from "axios-mock-adapter";
  // const mockAxios = new MockAdapter(axios);
  import fetchUsers from './api';

  it("유저목록을 반환한다.", async () => {
      const users = [
        { id: 1, name: "somedaycode" },
        { id: 2, name: "devmomori" },
      ];
      mockAxios.get.mockResolvedValueOnce(users);

      const result = await fetchUsers();

      expect(mockAxios.get).toHaveBeenCalledWith(`/users`);
      expect(result).toEqual(users);
    });

테스트코드가 늘어나면서 API Mocking을 위해서 mockAxios, MockingPromise와 같은 유틸 함수를 작성해서 관리하는 부분이 꽤 번거롭고 불편하게 느껴진다. 또한, 실제로 네트워크의 요청을 주고받는 것이 아니다 보니, HTTP 상태나 Error 처리에 대한 부분을 확인하기 위해서 추가적으로 작성되는 코드들이 많아지기도 하였다.

MSW의 요청과 응답은 다음과 같이 이루어진다.

브라우저의 MSW

실제로도 mockServiceWorker.js 파일을 까 보면 다음과 같이 동작하는 것을 확인할 수 있다.

// public/mockServiceWorker.js

self.addEventListener('fetch', async function (event) {
  const { clientId, request } = event
  const requestClone = request.clone() // 2. 요청 복제
  const getOriginalResponse = () => fetch(requestClone)
  
  ...more
}

// MOCK_SUCCESS 확인
switch (clientMessage.type) {
  case 'MOCK_SUCCESS': {
    setTimeout(
      esolve.bind(this, createResponse(clientMessage)),
      clientMessage.payload.delay,
    )
   break
   
   ...more
}

설치

// MSW 패키지 설치
yarn add msw --dev

// 기존 프로젝트 Public 폴더에 서비스워커 생성
npx msw init <PUBLIC_DIR> --save
// npx msw init public/ --save

다음과 같이 설치를 완료하면 mockServiceWorker.js 파일이 public 폴더에 만들어진다.

API Mocking 준비

1. '/users' HTTP GET 요청을 위한 핸들러 함수 작성

HTTP GET /users 데이터를 받기 위한 코드 작성

2. 브라우저에서 API Mocking을 위한 Worker 셋업

브라우저에서 msw 사용을 위한 코드

3. API Mocking 응답을 활용하기 위한 Users 컴포넌트 작성

유저 목록을 불러오기 위한 User.tsx

4. 렌더링

index.tsx 파일에 다음과 같이 코드를 작성해줍니다.

Index.tsx

실행 결과

해당 리액트 앱을 실행시키면 개발자도구에서 다음과 같은 화면을 볼 수 있습니다.

개발자 도구 확인

Application -> Service Worker로 들어가 서비스 워커가 잘 설치되었는지도 확인해봅니다.

install Service Worker

테스트 화면

이제 한번 버튼을 눌러 API Mocking 된 응답이 잘 들어오는지 확인해봅니다.

유저 목록을 불러올 때 서비스워커를 통해 네트워크 요청을 보내고 위에서 설정한 응답 값을 화면에 뿌리는 것을 확인할 수 있습니다.

유저 목록을 불러오는 GIF

네트워크 탭 응답 화면

네트워크 탭도 확인화면 Status Code 옆에 (from service worker)라고 표시되어 있는 것을 확인할 수 있습니다.

느낀 점

실제로도 MSW를 이용한 API Mocking은 러닝 커브가 낮았고, 간편하고 쉽게 API Mocking을 진행해 볼 수 있었습니다. 보다 쉽게 네트워크 단에서 API의 호출과 응답을 테스트 할 수 있다는 점이 애플리케이션 내부에 목업을 만들고 테스트를 진행하는 것에 비해 굉장히 매력적으로 느껴집니다. 더불어 이전에 테스트 코드를 진행하며 리소스를 찾는 데 어려움이 있었던 것에 비해서 MSW는 Github에 여러가지 example 보일러 플레이트가 많기 때문에 다양한 프레임워크에서의 동작도 쉽게 확인할 수 있었습니다. vercel/Next.js의 MSW Example도 있으니 확인해보면 좋겠습니다.

참고문서

코드 확인

객체지향의 사실과 오해 - 이상한 나라의 객체

devmomori — Wed, 17 Aug 2022 21:05:13 +0900

여러 개념들을 머릿속에서 잘 정립하지 않은 상태에서, 혹은 '개념을 정확히 이해하지 못한 채로 애플리케이션 설계를 하고 있지 않았나?' 반성해본다. 이전에는 뭉뚱그려서 자의적으로 해석했던 여러 개념들을 다시 한번 차곡차곡 정리할 수 있었다. 특히, 상태에 대한 개념과 애플리케이션 설계에서 행동을 중심으로 고민하고 프로그램을 설계해 나아가야 한다는 것이 굉장히 와닿았다. 같이 스터디를 한 친구들도 마찬가지인 것 같다. :) 잘못된 설계는 결국 많은 시간을 더 소요하도록 만드는데, 이런 가장 기본적인 개념이 설계를 함에 있어서 더 좋은 방향으로 가이드해주는 것이 아닐까?

들어가며,

물체가 여러 부분으로 구성되어 있더라도 함께 움직일 경우 그 물체를 하나의 유기적인 단위로 인식한다. 세상을 더 작은 객체로 분해하는 것은 본질적인고 세상이 포함하고 있는 복잡성을 극복하기 위한 인간의 작은 몸부림이다.

그러나 현실 세계와 소프트웨어 세계 사이의 유사성은 한계가 있다.

실행 중인 객체지향 애플리케이션의 내부를 들여다볼 수 있다면 겉으로는 우리가 알고 있는 세계와 유사해 보이지만 본질적으로는 이질적인 모습이 될 것이다.

앨리스 객체

책에서 이상한 나라의 앨리스 줄거리를 예시로 객체에 대해 설명

문을 통과하기 위하여 자신의 키를 계속해서 변화 시킴
결국 특정 시점의 앨리스의 상태란 특정 시점에서의 앨리스의 키를 의미
키를 변화시킨 것은 앨리스의 행동
앨리스의 행동에 따라 앨리스의 상태가 변화

즉, 어떤 행동의 성공 여부는 이전에 어떤 행동들이 발생했는지에 영향을 받는다.

문을 통과하려면 음료나 케이크를 먹는 행동이 선행되어야 함

상태, 행동, 식별자

객체의 다양한 특성을 효과적으로 설명을 하기 위해서는 객체를 상태(state), 행동(behavior), 식별자(identity)를 지닌 실체로 보는것이 가장 효과적이다 - Booch 2007

모든 객체의 상태는 단순한 값과 객체의 조합으로 표현된다. 상태를 구성하는 모든 특징을 객체의 프로퍼티(property)라고 지칭한다. 객체와 객체 사이의 의미 있는 연결을 링크(link)라고 한다.

서로 연관이 있는 객체를 선으로 표시

변경된 상태로, 객체 간의 링크가 없을 때를 표현

이러한 링크는 객체가 다른 객체를 참조할 수 있다는 것을 의미하고, 한 객체가 다른 객체의 식별자를 알고 있는 것으로 표현된다.

더불어, 객체의 상태는 저절로 변경되지 않는다. 객체가 취하는 행동이 객체 자신의 상태를 변경시키며 이런 행동은 부수 효과(side effect)를 초래하는 것이다.

예시) 앨리스가 케이크를 먹음 -> 키를 작게 변화 -> 케이크의 양을 줄임

객체의 행동은 상태를 변경시키지만 행동의 결과는 객체의 상태에 의존적이다. 음료를 마신 후의 앨리스의 키는 마시기 전보다 작아야 한다.

상태를 이용하여 객체의 행동을 쉽고 우아하게 표현하기

[앨리스가 통과해야 하는 문의 크기는 40센티]

앨리스의 키가 40센티미터 이하라면 문을 통과할 수 있음
문을 통과한 이후에는 앨리스의 위치가 정원으로 바뀌어야 함

객체가 다른 객체는 메시지를 통해서만 의사소통할 수 있는 것을 기억하자. 객체가 어떤 행동을 하도록 만드는 것은 객체가 외부로부터 수신한 메시지다. 이를 통해 협력에 참여하고 상태를 변경한다. 객체의 행동을 통해 발생하는 결과는 두 가지 관점에서 설명이 가능하다

객체 자신의 상태 변경
행동 내에서 협력하는 다른 객체에 대한 메시지 전송

메시지를 통한 앨리스와 음료 사이의 협력 관계

메시지 송신자는 메시지 수신자의 상태 변경에 대해서는 전혀 알지 못한다. 이것이 캡슐화가 의미하는 것. 상태를 외부에 노출시키지 않고 행동을 경계로 캡슐화하는 것은 객체의 자율성을 높이고 각 객체 간의 협력이 유연해지고 간결해질 수 있다.

객체는 시간에 따라 변경되는 상태를 포함한다. 타입이 같은 두 객체의 상태가 완전히 똑같더라도 두 객체는 독립적인 별개의 객체이며, 이름이 같고 키가 동일한 두 사람이 함께 있다 하더라도 어떤 누구도 같은 사람이라고 생각하지 않는다.

행동이 상태를 결정한다.

상태를 먼저 결정하고 행동을 나중에 결정하는 방법은 설계에 나쁜 영향을 끼친다.

앨리스 객체 설계 시

상태 (키, 장소)를 추가 후 -> 행동에 대해 고민 ( X )
행동 -> 상태 ( O )

WHY?

캡슐화를 저해한다.
협력에 적합하지 못한 객체를 창조하게 된다. (상태를 먼저 고려한다는 것은 협력이라는 문맥에서 멀리 벗어난 채 객체를 설계하기 때문이다.)
재사용성이 저하된다.

은유와 객체

현실 속의 객체와 소프트웨어 객체 사이의 가장 큰 차이점은? 현실 속에서의 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다는 것이다. (의인화)

현실 속의 전화기는 스스로 전화를 걸 수 없지만, 우리가 알고 있는 전화기라는 개념을 이용해 소프트웨어 객체를 묘사하면 그 객체가 전화를 걸 수 있다는 사실을 쉽게 이해하고 기억할 수 있게 된다. (은유)

객체지향의 사실과 오해 - 협력하는 객체들의 공동체

devmomori — Wed, 10 Aug 2022 20:39:59 +0900

객체란 현실 세계에 존재하는 사물에 대한 추상화라는 것 이다.

어플리케이션을 개발하면서 객체에 직접적으로 대응되는 실세계의 사물을 발견할 확률은 그다지 높지 않다.

객체지향 설계의 핵심 사상인 '연결완전성'을 설명하는 데 적합한 틀을 제공한다.

객체지향에서 가장 중요한 개념 세가지

역할
책임
협력

1장에서 나오는 카페에서 커피를 주문 후 커피를 받기까지의 과정

객체지향 사실과 오해 그림 1.2

일반적으로 하나의 문제를 해결하기 위해 다수의 사람 혹은 역할이 필요하다.
한 사람에 대한 요청이 또 다른 사람에 대한 요청을 유발하는 것이 일반적이다.
요청은 연쇄적이다.
요청 받은 사람 또한 주어진 책임을 다하면서 지식이나 서비스를 제공한다. 요청의 방향과 반대 방향으로 연쇄적으로 전달된다.

역할과 책임

역할이라는 단어는 일반적으로 책임이라는 개념을 내포하고 있다.

- 선생님이라는 역할은 학생을 가르칠 책임이 있다.

협력을 위해 특정한 역할을 맡고 적합한 책임을 수행한다는 것은 몇가지 개념을 제시한다.

1. 동일한 역할 수행

- 손님은 캐시어가 누구든 상관없이 커피를 주문하고 받을 수만 있으면 된다.

2. 대체 가능성

- 캐시어가 두명일 때 누가해도 상관없다.

3. 책임을 수행하는 방법은 자율적으로 선택

- 바리스타가 동일한 요청에 대하 서로 다른 방식으로 응답할 수 있는 능력 (다형성)

4. 한 사람이 동시에 여러 역할을 수행

- 한 사람이 캐시어와 바리스타의 역할을 동시에 수행

실세계의 커피 주문과정을 통해 객체지향을 좀 더 쉽게 설명이 가능하다. 이렇기 때문에 실세계의 모방이라는 은유를 사용한다.

역할과 책임을 수행하며 협력하는 객체들

특정한 목표를 이루기 위해 협력하고, 책임을 수행하는 역할들 간의 연쇄적인 요청과 응답을 통해 목표를 달성한다.
목표는 더 작은 책임으로 분할되고 책임을 수행할 수 있는 적절한 역할을 가진 사람에 의해 수행된다.

객체는 두 가지를 갖춰야한다.

1. '협력적' 이어야 함

외부의 도움을 무시한 채 모든 것을 스스로 처리하려고 하는 객체는 내부적인 복잡도에 의해 자멸하고 만다.

2. '자율적' 이어야 함

손님에게 음료를 주문하는 절차나, 바리스타에게 관련 내역을 전달하는 방법은 스스로 결정한다.
손님은 캐시어에게 어떤 방식으로 어떻게 주문을 바리스타에게 전달해야하는지 지시하지 않는다.

상태와 행동을 함께 지닌 자율적인 객체

행동을 하기 위해서는 필요한 상태를 함께 지니고 있어야한다.

객체 내부와 외부를 명확하게 구분함으로써 스스로 결정하는 자율성을 가지게 된다.

이렇게 구성된 어플리케이션은 유지보수가 쉽고 재사용성이 용이한 시스템을 구축할 수 있는 가능성을 제시해준다.

'Layer Architecture'가 문득 떠올랐다.

객체지향에서는 오직 한 가지 의사소통 수단만이 존재하는 데 그것을 메시지라 부른다.

전송하는 객체는 Sender - 수신하는 객체는 Receiver

객체가 수신된 메시지를 처리하는 방법을 메서드(Method)라고 부른다.

객체지향 프로그래밍 언어와 다른 프로그래밍 언어를 구분짓는 핵심적인 특징은 메시지를 수신한 객체가 실행 시간(run-time)에 메서드를 선택할 수 있다는 점이다.

외부의 요청이 무엇인지 표현하는 메시지와 요청을 처리하기 위한 메서드를 분리하는 것은 객체의 자율성을 높이는 핵심 메커니즘이다.

이것은 캡슐화와도 관련이 있다.

클래스와 객체 지향

클래스가 객체지향 프로그래밍 언어의 관점에서 매우 중요한 구성요소 이지만 핵심을 이루는 중심 개념이라고 말하기에는 무리가 있다.

자바스크립트는 프로토타입 기반의 객체지향 언어이며 클래스가 존재하지 않고(sugar syntax) 객체만이 존재한다.

훌륭한 객체지향 설계자가 되기 위해서는 클래스의 관점에서 메시지를 주고받는 객체의 관점으로 사고의 중심을 전환해야한다.

클래스는 그저 협력 관계를 코드로 옮기는 도구일 뿐이다.

클래스의 구조와 메서드가 아니라 객체의 역할, 책임, 협력에 집중하자.

Nuxt3 Page 내부에 하나의 root element가 없을때 경고문 이슈 : Component inside <Transition> renders non-element root node that cannot be animated.

devmomori — Wed, 10 Aug 2022 18:24:11 +0900

Nuxt를 사용하면서 발생한 에러.

에러가 불친절해서 Nuxt github에 feature issue를 올렸다.

답변이 굉장히 빨랐는데, 관련 이슈를 훑어보니 비슷하게 생각하는 사람들이 몇몇 있었던 모양이다.

Warn needs to be much more specific when there's no root element in <template> · Issue #6476 · nuxt/framework

Describe the feature these are vue components in my pages directory // pages/index.vue <template> <h1>Home</h1> <NuxtLink to="some-route/1">page 1</NuxtLink>...

github.com

Nuxt에서도 이를 인지하고 있는 것인지 관련 PR이 올라와있다.

feat(nuxt): add warning in dev mode if layouts/pages do not have a single root node by danielroe · Pull Request #5469 · nuxt/f

Linked issue resolves #4598, resolves #6476 ❓ Type of change Documentation (updates to the documentation or readme) Bug fix (a non-breaking change that fixes an issue) Enhancement (imp...

github.com

문제

<route-link>와 같은 동작을 하는 <NuxtLink>를 사용하여 페이지 전환 후 param.id를 가져오는 단순한 코드다.

root element error code

이렇게 실행하면 다음과 같은 에러를 마주한다.

runtime-core.esm-bundler.js:38 [Vue warn]:
Component inside <Transition> renders non-element root node that cannot be animated. at
<Index onVnodeUnmounted=fn<onVnodeUnmounted> ref=Ref< undefined > key="/" > at <BaseTransition mode="out-in" appear=false persisted=false ... > at <Transition name="page" mode="out-in" > at <RouterView name=undefined route=undefined > at <NuxtPage> at <App key=1 > at <NuxtRoot>

여기서 내가 헷갈렸던 부분은 '<Transition>' 과 'animated' 라는 단어였는데, 애니메이션을 사용하지도 않았고 해당 에러를 찾아보니 애니메이션과 관련된 문서만 나와서 뭔가 싶었다.

알고보니 단순히 index.vue에 엘리먼트를 감싸는 Root Element가 없어서 그랬던 것.. 아래와 같이 div로 감싸주면 해결된다.

root element should wrap others

React를 사용하면 JSX expresstions must have one parent element. 라는 간단명료한 문구를 IDE에서 바로 확인이 가능한데 Vue의 경고는 조금 불친절한 부분이 있는 것 같다.

'/deep/' selector is not working

devmomori — Thu, 14 Jul 2022 19:57:56 +0900

차트 라이브러리 개발 도중 마주친 에러

- vue2.x 사용

vue-cli-service build --target lib --name index [entry]

뷰 컴포넌트를 라이브러리로 만든 후, 해당 라이브러리를 다른 서비스에서 사용하려했지만 다음과 같은 에러가 발생했다.

Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
SassError: expected selector.

& /deep/ .class-name {}

비슷한 문제를 스택오버플로우에서 발견

The `/deep/` selector is not working using sass-loader in my VueJS application

In my Vue 2.6.10 webpack application I am trying to add SASS as our team wants to migrate our legacy application from LESS to SCSS. In my package.json I have installed these to my devDependencies per

stackoverflow.com

sass-loader에서 node-sass를 사용하도록 변경하면 해결할 수 있다.

Vue Config 설정 변경

css: {
  loaderOptions: {
    sass: {
      implementation: require("node-sass"),
    },
  },
},

Dart Sass

- https://github.com/sass/dart-sass#why-dart

node-sass
- https://github.com/sass/node-sass

Deprecated 된 걸 쓸 이유가 있을까?

dart-sass does not support /deep/ selector · Issue #3399 · vuejs/vue-cli

Version 3.4.0 Reproduction link https://github.com/lianzhao/vuecli-3.4 Environment info Environment Info: System: OS: macOS Sierra 10.12.4 CPU: (4) x64 Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz Bina...

github.com

::v-deep으로 모두 교체하여 해결

Vue3 에서는?

How do I use /deep/ or >>> or ::v-deep in Vue.js?

So, I've read here that in Vue.js, you can use /deep/ or >>> in a selector in order to create style rules that apply to elements inside of child components. However, attempting to use this...

stackoverflow.com

:deep(.child-class) 로 사용!

결론

Vue2 : /deep/ 대신 ::v-deep을 사용하자
Vue3 : :deep(.child-class) 를 사용하자

기존 프로젝트가 모두 /deep/으로 되어있어서 교체 후 테스트 하는 별도의 과정이 필요하지만, 이후를 생각하면 이게 더 낫다!

-컴포넌트 내부에서 스타일을 scoped로 제한하고 있다면 deep selector를 최대한 쓰지 않는게 유지보수가 편하다.
-정말 어쩔 수 없는 경우라면.. deep으로 하겠지만, 쉬운방법을 찾다보면 그게 쌓이고 쌓인다 .

Vue2, Vue3 같은 Vue인데 조금씩 너무 다르다..