ADR 문서로 의사결정 기록하기

• 키워드: ADR, Architectural Decision Records
• 상황
  1. 과거 코드를 보다보면 왜 이 기술스택을 채택했는지 이해가 되지 않는 경우가 있다.(상태관리 방법, API 통신 방법 등)
  2. 새로 들어온 팀원들도 나에게 왜 이 기술스택을 채택했었는지 직접 묻는 경우가 종종 있다.
  3. 보통 git log를 뒤져보거나 코드의 로직을 살펴보는 과정에서 의문이 풀리지만, 잘못된 의사결정이었거나 당시에만 옳았던 방법이었을 경우 의문이 계속 풀리지 않는 경우가 생긴다.
• 해결 방법
  1. '프레임워크 없는 프론트엔드 개발' 책의 내용에서 'ADR'에 관한 개념을 알게 되었다.
     https://github.com/Apress/frameworkless-front-end-development/blob/master/Chapter08/ADR-001.MD
     
     구글의 문서에서도 ADR에 대한 설명을 확인할 수 있다.
     https://cloud.google.com/architecture/architecture-decision-records?hl=ko
     
     위와 같이 ADR 문서를 사용하면 왜 그런 설계를 선택했는지에 대한 히스토리를 관리할 수 있다.
     
     
  2. ADR 문서는 크게 4단계로 작성한다.
     1. Context: 이 문제를 해결해야하는 상황을 정의.
     2. Decision: 각 설계의 장단점에 대해 토론하고 토론 내용(각 설계의 장단점 등)을 정리. 논의한 내용을 토대로 어떤 설계를 선택했는지 기록.
     3. Status: 현재 해당 논의의 상태.
        토론 중/수락/중단/대체/제대로 이행되지 않음, proposed/accepted/rejected/superseded/deprecated 등 팀에서 정한 표현으로 기록.
     4. Consequences: 이 결정으로 인해 생기는 실질적인 결과. 성능이 개선되었는지, 코드가 깔끔해졌는지 등 어떤 효과가 발생했는지 기록.
  3. 예를 들어 아래는 리액트 프로젝트에서 상태 관리 라이브러리를 정하는 ADR 문서이다.

# Data-fetching-001

Context
- 새로운 프로젝트에서 사용할 상태 관리 라이브러리를 선택해야한다.
- 용량, 성능, 난이도 측면에서 trade-off가 있기 때문에 '좋은 라이브러리가 무엇인가'보다는 'OOO 서비스에 적합한 기술이 무엇인가'를 고민해야한다.

후보
- swr
  - Next.js를 만든 Vercel 팀이 개발한다.
  - react-query에 비해 가볍고 속도가 빠르다.
  - 공식 문서가 쉽고 한글을 지원한다.
  - 코드량이 적다.
  - react-query에 비해 없는 기능이 있어 middleware를 추가해줘야한다.
 react-query
  - 고급 기능을 swr에 비해 간단하게 처리할 수 있다.(ex> laggy, devtool, selector)
  - 공식 문서가 길지만, 그만큼 많은 기능이 있다.
  - mutation 로직이 장황하다.
redux
  - 복잡하게 얽힌 비동기 로직에 사용하면 좋다.
  - 보일러 플레이트가 많고 '잘' 사용하기 쉽지 않다.
  - data-fetching 기본 기능을 제공하지 않는다.(ex> Suspense, revalidate)

Decision
- 라이브러리를 확정하기 전에는 OO를 이용해 token을 관리한다.

Status (토론/수락/중단/대체)
- 토론

Consequences
- OO를 이용해 개발 중이다. OO 환경에서 사용하기엔 문제가 있어 빠른 시일 내에 라이브러리를 결정해야한다.