[커뮤니티 #17] 기본 키 타입, 네이밍 리팩토링 작업

 

안녕하세요.

 

신년의 첫 포스팅이네요! 다들 새해 복 많이 받으세요.

 

오늘도 커뮤니티 프로젝트 리팩토링에 대한 내용을 다룹니다.

레거시 프로젝트를 리팩토링 하는 것이 이렇게 힘든 일인줄 몰랐습니다 ㅠㅠ

 

이번 경험을 바탕으로 앞으로는 "처음부터 꼼꼼한 설계와 클린코드를 이용해서 프로젝트를 제작해야겠다."라고 생각했습니다.

 

오늘은 세 가지 작업을 했습니다.

1. 도메인 기본 키 타입 리팩토링 작업
2. User 도메인 리네이밍
3. README.md 가독성 좋게 수정하기

 

---

1. 도메인 기본 키 타입 리팩토링 작업

현재 레거시 프로젝트의 도메인 기본 키 타입은 전부 int형으로 만들었습니다.

 

사실 int형으로 모두 기본 키 처리를 해도 상관은 없겠지만, 만약 프로젝트의 규모가 커지고 트래픽과 데이터가 많아진다면 데이터베이스에 수 많은 데이터가 쌓이게 될 것입니다.

 

int 타입은 약 21억개의 데이터밖에 다룰 수 없습니다.

 

이해하기 쉽게 배달의민족 어플을 만들었다고 가정을 해보겠습니다.

만약 주문 관련 도메인의 기본키를 int형으로 설정했을 때, 총 주문의 수가 21억 개가 넘었다면 어떻게 될까요?

int형으로는 감당하지 못하게됩니다. 따라서 Long타입으로 범위를 더 늘려주면서 관리할 수 있어야하겠죠.

 

이러한 이유로 시스템이 커지는 경우를 대비하기 위해서 Long타입으로 리팩토링 작업을 해주었습니다.

사실 권장하는 전략은 [Long 타입 + 대체 키 + 키 생성전략]입니다.

 

기존 프로젝트에서 int 타입으로 모든 것을 해결했기 때문에 Domain, Dto, Test 등 모든 코드에서 기본 키를 다루는 것은 모두 아래 사진처럼 Long으로 리팩토링 해주었습니다.

---

2. User 도메인 리네이밍

User 도메인의 이름을 Member로 변경했습니다.

 

이유는 Member로 변경하는게 추후에 User 시스템을 만들었을 때, 더욱 가독성이 좋다고 판단했기 때문입니다.

 

이거는 큰 내용은 없으니 패스하겠습니다!

 

 

---

3. README.md 가독성 좋게 수정

깃허브에서 프로젝트를 처음 들어가면 가장 먼저 보이는 것은 README.md 즉 프로젝트 소개입니다.

 

대문이 예뻐야 집안도 예쁘다고 생각하겠죠?

이런 이유로 조금 더 가독성 좋게 수정해주었습니다.

 

 

어떤가요? 변경한 오른쪽 부분이 진행 사항을 볼 때 더욱 가독성이 좋아졌습니다.

 

[ ] 체크 없는 것
[X] 체크 있는 것

 

이런 방법으로 md 파일을 작성해주면 됩니다.