SSOT (Single Source Of True)

같은 데이터는 코드베이스 한 곳에서만 존재하는 구조.
하나의 진실은 한 곳에서만 저장되고, 나머지는 전부 그 원본에서 파생되어야 한다는 규칙.

왜 지켜야 하냐

같은 데이터의 복사본이 생겨서 두 군데 이상 존재하게 되면 동기화 문제가 생긴다.
원본이 바뀔때마다 복사본도 수동으로 갱신 되어야 하는데, 갱신경로를 하나라도 빠뜨리면 두 값이 어긋난 채로 돌아가는 버그가 된다.

어떻게 지킬 수 있냐

1. 파생 가능한 값은 별도 필드로 저장

ex)

// NOT PASS — isDday는 currentDate에서 계산 가능한데 별도 필드로 존재
bool isDday;              // currentDate가 바뀔 때마다 누군가 수동으로 갱신해야 함
Rx<Date> currentDate;

// PASS — 원본은 currentDate 하나, isDday는 항상 원본에서 계산
bool isDday => currentDate.Value == targetDate;
Rx<Date> currentDate;

current date를 바꾸는 코드마다 isDday를 업데이트 해주기 보다, isDday에서 계산하는 방식으로 구현할 수 있다.
저장히지 말고, 계산 하는 것이 포인트

2. 동일 패턴, 필드 쌍의 반복 시 헬퍼 메서드나 구조체로 추출

코드 리뷰 단에서 동일 코드 패턴이 3회 이상 반복 될 경우 헬퍼 메서드나 구조체로 추출하면 나중에 로직이 바뀔때 한 곳에서만 바꾸면 된다.

또한 필드가 항상 한 쌍으로 다니면 (ex. itemID & itemLevel) 구조체 하나로 묶어서 한쪽만 확장되는 사고를 방지할 수 있다.

3. 같은 모듈/데이터의 재구현

같은 데이터의 이중 저장(ex. 골드 관리가 currencyController에서도 되고 PlayerManager 에서도 된다면?)시 어느 쪽이 원본인지 불명확해진다.(ex. 한쪽만 차감되는 재화 버그 발생 가능성 높음)

같은 역할의 메서드/클래스가 여러 구현체로 존재하면 수정이 한쪽에만 들어가서 앞서 말한 문제가 발생할 수 있다. 이것도 합칠 수 있으면 합친다.

---

방금 말한 3가지의 기준을 CI때 클로드한테 PR 리뷰시키라고 넣어두면 손쉽게 SSOT 위반인지 아닌지 체크할 수 있다. 👍