jtwjs Dev Wiki
  • DEV_ROAD
    • 💪🏻 생존하기
    • Week 1
      • 개발 환경 세팅
      • 타입스크립트
      • 리엑트
      • Testing Library
      • Parcel & ESLint
    • Week 2
      • JSX
      • Virtual DOM
    • Week 3
      • React Component
      • React State
    • Week 4
      • Express
      • Fetch API & CORS
      • React Hook
      • useRef & Custom Hook
    • Week 5
      • TDD
      • React Testing Library
      • MSW
      • Playwrite
      • Snapshot
    • Week 6
      • Separtion of Concerns
      • Principle
      • DI, (Dependency Injection)
      • Reflect-metadata
      • TSyringe
      • External Store
      • Follow Redux
      • usestore-ts
      • useSyncExternalStore
    • Week 7
      • Routing
      • Routes
      • Router
      • Navigation
    • Week 8
      • Design System
      • Style Basics
      • CSS-in-JS
      • Styled-Components
      • Global Style & Theme
    • Week 9
      • 개발하기 전 준비
      • 상품 목록 페이지
      • 상품 상세 페이지
      • 장바구니 페이지
    • Week 10
      • 로그인
      • 로그아웃
      • 회원가입
      • 주문 목록 & 주문 상세
    • Week 11
      • 배송 정보 입력
      • 포트원 결제 요청
      • 배송 및 결제 정보 전달
    • Week 12
      • 관리자 웹사이트개발시작
  • DEV_NOTE
    • TypeScript
      • 기본적 문법
        • Enum
        • 다형성
          • Untitled
        • 구조적 타이핑
        • 제너릭 타입
        • 컨디셔널 타입
        • 함수 메서드 타이핑
        • infer로 타입스크립트의 추론 직접 활용
        • 재귀 타입
        • 템플릿 리터럴 타입
        • 추가적인 타입 검사 satisfies 연산자
        • 타입스크립트 건망증
        • 원시 자료형에도 브랜딩 기법 사용 가능
        • 타입 좁히기
        • 유용한 타입 만들기
        • 데코레이터 함수
        • 앰비언트 선언도 선언 병합이 된다.
        • 앰비언트 선언도 선언병합이 된다.
    • Testing
      • Unit Testing
      • 단위 테스트의 두 분파
      • 좋은 단위 테스트를 구성하는 4대 요소
      • 테스트 대역과 식별할 수 있는 동작
      • 단위 테스트 스타일
      • 가치 있는 단위 테스트를 위한 리팩토링
      • 통합 테스트
      • Cross Browsing Testing
      • 기능 테스트 종류
      • React Testing Pattern
      • 프론트엔드 테스트 입문
        • 테스트 범위
        • 단위 테스트 검증
        • Mock
        • UI 컴포넌트 테스트
        • 테스트 커버리지
        • 웹 통합 테스트
        • MSW
        • 스토리북
        • 시각적 회귀 테스트
        • E2E 테스트
        • Github Actions 설정
        • 깃허브 액션에서 E2E
      • 시프트 레프트
        • 테스트 기본중의 기본
        • 단위 테스트
        • 코드 복잡도
        • 리팩터링
        • 코드 리뷰
        • 통합 테스트 패턴
        • 시스템 테스트의 자동화
        • 탐색적 테스트
      • Test Tip
      • vitest
      • playwright
      • Test Data Generator
      • MSW
    • Algorithm
      • coding test
      • Data Structure
    • Next.js
      • Data Fetching
      • Hydration
      • Next 13
      • Optimization
      • Next 15
    • Tailwind
      • Tailwind CSS
      • Theme
      • Directives
      • Tool
      • Design System
    • Storybook
      • Storybook
      • CSF3
      • CDD
      • Headless Component
    • Funtional Programming
      • 함수형 프로그래밍
      • 참조 투명성
      • 부수효과
      • 함수 합성
      • 제너릭 타입 활용하기
      • 암묵적 입출력
      • 액션과 계산, 데이터
      • 계층형 설계
      • 호출 그래프
      • 함수형 설계
      • 불변성
      • 일급 함수
      • 함수형 도구
    • Git
      • Github Actions
      • Conflict
      • Branch 전략
    • Contents Format
      • Audio
    • 3D Graphic
      • 3D keyword
      • Three.js
      • Geometry
      • Material
      • Light
      • Camera
      • Decal
      • Rotation
      • Text
      • Shadow
      • Fog
      • Post Processing
      • Animation
      • Math
        • Vector Space
        • 벡터의 연산
        • 회전 계산
      • 3D 컨텐츠가 만들어지는 과정
      • R3F
      • Env
      • Scene
      • Transform
      • R3F
      • Interaction & Raycast
      • Rendering Algorithnm
      • Blender
      • Blender
    • Accessibility
      • 접근성이란
    • Interactive Web
      • Parallax
      • Canvas
      • requestAnimationFrame
      • Effect
      • HSL
      • React.js + Canvas
      • Matter.js
    • AWS
      • DevOps
      • Amplify
      • S3
      • 클라우드 컴퓨팅
        • 온프레미스와 클라우드
        • 클라우드 도입효과
        • 클라우드 컴퓨팅의 범위
        • 컴퓨팅 옵션
          • EC2 - Virtual Machin
          • ECS, EKS - Container
          • Lambda - Serverless
        • 네트워크 가상화
        • 스토리지
        • 데이터베이스
        • 데이터 수집
        • 머신 러닝 영역
        • IoT 영역
        • 블록체인 영역
      • 클라우드 아키텍처 설계
    • Network
      • Web Server & WAS
    • System Design
      • System Design
      • Component
      • 의존성을 배제한 개발
      • Error Handling
      • Architecture
        • 모노로틱 아키텍처
        • Clean Architecture
        • Layered Architecture
        • 이벤트 기반 아키텍처
      • 상황을 파악하는 메타인지
      • 중복 문제 해결하기
      • Monorepo Arhitecture
        • 모노레포 운영과 트러블슈팅
        • Module Federation
      • 코드 병목지점
      • API 대응
      • 공통 코드
      • Infra 구축
      • 모듈 기반의 개발 방식
      • Design System
        • 최소 수준의 아키텍처 설정
        • 더 효율적인 디자인시스템 만들기
        • 디자인 시스템과 UI 라이브러리 목적
        • 디자인 토큰
      • 효율적인 업무
        • 업무 프로세스 병목 파악
      • Clean Code
      • Design Pattern
        • CQRS Pattern
        • Strangler Fig Pattern
        • 데코레이터 패턴
        • 커맨드 패턴
        • 전략 패턴
        • 옵저버 패턴
      • A/B 테스팅
      • 대규모 리엑트 웹앱 개발
        • 복잡성 관리
        • 모듈성
        • 성능
        • 디자인 시스템
        • 데이터 패칭
        • 상태 관리
        • 국제화
        • 코드 조직화하기
        • 개인화 A/B 테스팅
        • 확장 가능한 웹 아키텍처
        • 테스팅
        • 툴링
        • 기술적 마이그레이션
        • 타입스크립트
        • 라우팅
        • 사용자 중심 API 디자인
        • 리액트 미래
    • Performance
      • React DevTools
      • Component 최적화
      • Page Load
      • API
    • MFA
      • MSA
      • MFA 도입하기
      • Monorepo
        • Monorepo Tool
        • Yarn Berry Workspace
        • Turborepo
      • MFA Composition
      • SPA 통합
      • Design System
      • Package Manager
        • Yarn
        • pnpm
      • Transpiler & Bundler
        • Babel
        • Rollup
        • esbuild
        • swc
        • Webpack
        • Vite
      • 분해와 통합을 위한 여러 기술 비교
    • State Management
      • Zustand
    • React v18
      • Automatic batching
      • Suspense
      • Transition
    • SEO
      • Search Engine Optimization
      • Open Graph Element
      • Metadata
    • FE Develop
      • Scrubbing
      • Clipboard
    • Refactoring
      • 리팩토링 깊게 들여다보기
      • 긴 코드 조각내기
      • 타입 코드 처리하기
      • 유사한 코드 융합하기
      • 데이터 보호
      • 코드 추가 및 제거
    • OAuth 2.0
    • Analytics
      • Mixpanel
    • ETC
      • VSCode
    • React Hook In Action
      • useContext & Provider
      • 커스텀 훅
      • 코드 분할하기 with Suspense, lazy
      • Suspense와 이미지 적재하기
      • useTransition, uesDeferredValue
      • SuspenseList
Powered by GitBook
On this page
  • 계층형 설계
  • 계층형 설계 패턴
  • 직접 구현
  • 추상화 벽
  • 작은 인터페이스
  • 편리한 계층
  1. DEV_NOTE
  2. Funtional Programming

계층형 설계

"어떤 코드도 이상적인 모습에 도달할 수 없다."

설계는 개발자들 간에 생각하는 부분이 서로 다르고, 상황에 따라 좋은 설계 기준이 달라지기도 한다.

설계에 대해 이야기할 때는 서로 같은 용어를 사용하고, 상황을 고려해서 평가해야 한다.

계층형 설계

소프트웨어를 계층으로 구분하여 설계하는 방식

  • 각 계층의 함수는 바로 아래 계층의 함수를 이용해 정의한다.

  • 즉, 계층형 설계에서 모든 계층은 바로 아래 계층에 의존해야 한다.

  • 계층형 설계는 코드를 추상화 계층으로 구성한다. 즉, 구체화 단계에 따라 계층이 나뉨

    • 흔히 소프트웨어 레이어드 아키텍처를 보면 도메인 계층과 외부 프로세스와 도메인을 연결시키는 애플리케이션 계층이 있다. 가장 하위에 있는 계층은 구체화 수준이 높고 상위로 갈수록 구체화 수준이 낮다.

  • 각 계층을 볼 때 다른 계층의 구체적인 내용을 몰라도 된다.

소프트웨어 설계란, 코드의 확장성, 유지보수성, 테스트 용이성 등을 높히기 위해 미적 감각을 사용하는 것

계층형 설계 패턴

직접 구현

직접 구현된 함수를 읽을 때 함수 시그니처가 나타내고 있는 문제를 함수 본문에서 적절한 구체화 수준으로 해결해야 한다.

함수 시그니처란?

함수의 이름과 입력값, 반환값의 타입으로 함수를 고유하게 식별할 수 있는 정보를 말한다.

  • 본문이 너무 구체적이라면 코드에서 나는 악취일 가능성이 높다. (명령형)

  • 직접 만든 함수와 언어에서 제공하는 기능은 추상화 수준이 다르다.

  • 추상화 수준이 서로 다르다면, 흐름이 불규칙적이고 명확하지 않아 가독성을 해친다.

  • 함수가 모두 비슷한 계층에 있다면 직접 구현했다고 볼 수 있다.

  • 같은 계층에 있는 함수는 같은 목적을 다뤄야 한다.

사용하는 곳에서 함수가 어떤 데이터 구조인지 알아야 한다면 낮은 수준의 계층이다. ex:) 가장 낮은 계층 - 자바스크립트에서 제공하는 메서드(반복문, 배열 인덱스 접근 등)

한 줄 짜리 코드가 좋은 코드인가?

코드의 라인 수는 중요하지 않고, 코드가 적절한 구체화 수준과 일반화가 되었는지가 중요하다.

일반적으로 한줄 짜리 코드는 여러 구체화 수준이 섞일 일이 없기 때문에 좋은 코드이다.

직접 구현 패턴

직접 구현 패턴은 함수를 명확하고 아름답게 구현해 계층을 구성할 수 있도록 알려준다.

  • 함수가 더 구체적인 내용을 다루지 않도록 일반적인 함수로 추출하는 작업은 직접 구현 패턴을적용한 방법 중 하나

  • 문제 해결을 위한 함수를 구현할 때 어떤 구체화 수준을 따를지에 따라 어떤 계층에 속할지 정해진다.

  • 함수의 이름은 의도를 나타내며, 본문은 중요한 세부 사항을 나타내어 함수가 어떤 계층에 속해야 하는지 알려준다.

추상화 벽

추상화 벽(abstraction barrier)은 세부 구현을 감춘 함수로 이루어진 계층

"어떤 것을 신경 쓰지 않아도 되지?"라는 말을 거창하게 표현한 개념

  • 중요한 세부 구현을 감추고 인터페이스를 제공하는 식으로 코드를 만들면 높은 차원으로 생각할 수 있다.

  • 고수준의 추상화 단계만 생각하면 되기 때문에 두뇌 용량의 한계를 극복할 수 있다.

  • 구현 세부사항을 전혀 몰라도 함수를 사용할 수 있다.

  • 계층 구조에서 어떤 계층에 있는 함수들이 공통된 개념을 신경 쓰지 않아도 된다면 그 계층을 추상화 벽이라 할 수 있다.

  • 추상화 벽으로 추상화 벽 아래에 있는 코드와 위에 있는 코드의 의존성을 없앨 수 있다.

  • 신경 쓰지 않아도 되는 것을 다루는 것이 추상화 벽의 핵심!

추상화 벽을 사용하면 좋은 상황

  1. 쉽게 구현을 바꾸기 위해 → 뭔가 바뀔것을 알고 있지만 아직 준비되지 않은 경우 (ex: api 더미 데이터)

  2. 코드를 읽고 쓰기 쉽게 하기 위해 → 알아야할 필요가 없는 세부 구현사항을 숨겨서 단순화함으로써 뇌 과부화 방지

  3. 주어진 문제에 집중하기 위해 → 복잡한 세부 구현사항을 감추고 필요한 주요 기능에만 집중할 수 있게 된다.

작은 인터페이스

작은 인터페이스 패턴은 새로운 코드를 추가할 위치에 관한 것

  • 시스템이 커질수록 비즈니스 개념을 나타내는 중요한 인터페이스는 작고 강력한 동작으로 구성하는 것이 좋다.

  • 추상화 벽에 만든 함수는 인터페이스라고 볼 수 있다.

  • 추상화 벽에 있는 인터페이스로 어떤 값의 집합에 접근하거나 값을 조작할 수 있다.

  • 작은 인터페이스 패턴은 추상화 벽 뿐만 아니라 모든 계층에 적용할 수 있는 패턴

  • 새로운 기능을 만들 때 하위 계층에 기능을 추가하거나 수정하는 것보다 상위 계층에 만드는 것이 작은 인터페이스 패턴이다.

추상화 벽을 작게 만들어야 하는 이유

  • 추상화 벽에 코드가 많을 수록 기능이 수정됬을 때 변경해야 하는 코드가 많아진다.

  • 하위 계층에서 불필요한 기능이 쓸데없이 커지는것을 방지할 수 있다.

  • 추상화 벽에 있는 코드(인터페이스)는 보통 낮은 수준의 코드이기 때문에 더 이해하기 어렵고 많은 버그가 존재할 수 있다.

계층이 가진 함수는 완전하고, 적고, 시간이 지나도 바뀌지 않아야 한다. 이것이 작은 인터페이스가 전체 계층에 사용되는 이상적인 모습이다.

편리한 계층

코드와 그 코드가 속한 추상화 계층은 작업할 때 편리해야 한다.

  • 단순한 이유(그냥 좋아서)로 계층을 추가하면 안된다.

  • 소프트웨어를 개발할 때 더 빠르고 고품질로 제공하는 계층에 시간을 투자해야 한다.

Previous액션과 계산, 데이터Next호출 그래프

Last updated 1 year ago