코드 병목지점

코드 병목지점

코드를 작성하는데 시간이 오래걸리며, 잦은 충돌이 일어나는 지점

Check Point

• 공통 코드를 몇명이서 개발하는가

  • R&R을 나누거나 계층을 쪼개서 개발

  • 기술적으로 오버헤드를 일으키지 않는지 판단

• 리베이스 충돌이 일어나는 근본적인 원인이 무엇인가

  • 브랜치 전략 문제인지, 컨벤션 문제인지

  • 코드의 응집도가 심한가?

• 자동화된 툴(코파일럿, 린트)을 적용해서 생산성 향상을 할 수 없는가

#1 비즈니스 로직 분리하기

코드 병목을 개선하기 위해 가장 첫번째로 해야할 일은 컴포넌트 내부에 비즈니스 로직과 레이아웃 로직을 분리시키는것 -> 비즈니스 로직을 분리하지 않게되면 코드 병목을 개선하면서 레이아웃 코드에 영향을 줄 수 있기 때문

• 생산성없이 비즈니스를 쳐내기 위해 달린 프론트 코드는 컴포넌트에 레이아웃 로직과 비즈니스 로직이 함께 존재

  • 이 때 타입스크립트 타입 등을 함께 개선시키지 않는다. Only 비즈니스 로직 분리

• 비즈니스로 모든 코드를 분리했다면 인터페이스 기반으로 동작하기 때문에, 인터페이스에 맞춰서 기능만 수정하면 됨

  • 코드 안정성 증가 -> 타입은 런타임 체크가 안되기 때문에 테스트 코드는 별도로 필요

interface UseCustomHookProps {
 ...
}

interface UseCustomHookReturn {
 ...
}

type UseCustomHook = (props: UseCustomHookProps) => UseCustomHookReturn

export const useCustomHook: UseCustomHook = (props) => {}

#2 공통 로직 응집하기

하나로 모아둔 비즈니스 코드에는 공통된 패턴이 보이게 되는데, 해당 패턴을 공통 단위로 묶어서 작업

• 라우팅 포인트를 기반으로 hook에 여러 비즈니스 로직이 적용될 수 있도록 그림 그리기

• 공통 로직에서도 API, Common를 분리

• 간단한 레이어 구축으로 영역별 1명씩 R&R 분리 가능,

#3 각 영역의 패키지화 & 문서화

로직이 물리적으로 떨어지게되면 공통 로직은 수정에 따른 영향도가 커질수밖에 없다. -> (인터페이스 추가 및 제거는 꼭 생김)

• 각 영역을 안전하게 운영할 수 있도록 패키지화와 문서화를 고려

  • CHANGELOG

  • Node version, OS version, Browserlist,...

  • npm publish 등 안적으로 서빙할 수 있는 구조 마련

• 공통 로직 테스트 코드 작성

  • 긴급히 동작하는 비즈니스에서는 테스트 코드가 필수지만 일정상 빠지는 경우가 흔함

  • 틈틈이 여유있을 때 테스트 코드 작성하는 습관 기르자.

상태의 종류

• 전역 상태 -> 웹 애플리케이션 전역에서 공통으로 사용되는 상태

  • 인증정보, 사용자 데이터, 레이아웃과 관련된 상태 등...

• API 상태 -> 서버의 데이터 상태

  • API를 통해서 서버(DB)와 지속적인 상태를 공유하므로써 레이아웃을 변경함

  • 최근은 페이지 단위의 상태를 BFF에서 취합해서 전달해주므로써, 페이지 단위로 API를 하나만 쓰는 등의 일들이 일어남(어드민 등)

• 컴포넌트 상태 -> 컴포넌트 내부에서 쓰이는 상태

전역 상태와 API 상태는 구분해서 생각하자.