dev-camp Day6 코드 뜯어보고 개선점 찾고 계획 세우기

1. 코드 개선점 찾기

[SQL point 매핑 테이블 대신 Redis 사용]

point라는 SQL 매핑 테이블 내의 컬럼이 아닌 
Redis를 이용해 총 포인트 수를 저장하여 공간복잡도와 시간복잡도를 줄일 수 있을 것 같습니다. 

Point Log 테이블에는 User 테이블을 userId를 이용해 1:N 관계를 맺습니다. 
포인트에 변동이 있을 때 마다 총 포인트 수를 포인트 로그 테이블에서 계산하여 저장합니다. 

Redis는 메모리 내에서 작동하기 때문에 읽기/쓰기 속도가 빠릅니다. 
데이터 베이스 테이블을 1개 절약 할 수 있습니다. 

 

[regNo]

User 엔티티에서 createdAt 을 Base Entity로 상속 받는다면
createdAt 기준으로 sort 하면 되기 때문에 User 테이블에서 regNo 컬럼이 불필요합니다. 

전체 회원의 수가 필요한 경우 count 메서드를 통해 계산할 수 있습니다. 

불필요한 컬럼이므로 삭제하는 것이 공간복잡도를 절약할 수 있다고 생각합니다. 

 

[jti]

json web token의 jti는 토큰의 고유한 식별자입니다.

하지만 Access Token 엔티티와  Refresh Token 엔티티가 둘다 Base Entity를 상속 받으므로

Base Entity에 포함된 id(UUID로 생성)를 통해 식별하고 해당 토큰을 파기할 수 있습니다. 

중복되는 역할이므로 해당 컬럼을 삭제하는 것이 공간 복잡도를 절약할 수 있다고 생각합니다. 

 

[deletedAt을 이용한 soft-delete]

Base Entity에 deleted At이 없고 hard delete 되고 있습니다.

결제가 존재하는 서비스 이므로 정보를 삭제하기 보다는 추후의 증빙자료를 위해
삭제일인 deletedAt을 Base Entity에 추가하여 soft delete하는 것이 좋아 보입니다. 

 

[class-validator를 활용한 유효성 검사]

class validator를 활용하여 DTO의 타입들을 검사하고
타입이 맞지 않는 input이 있는 경우 간편하게 응답을 전송할 수 있도록 하는 것이 좋을 것 같습니다. 

 

[calculateExpiry 메서드 삭제]

env에 expiry를 밀리초 단위로 적는다면

calculateExpiry 메서드를 사용하지 않아도 될 것 같습니다. 

 

[oauth 회원 생성 시 createUser 메서드에 argon2 hash 하지 않는 것으로 if문 분기]

oauth 회원의 경우

1. oauth 서비스 제공자로부터 받은 고유 id를 저장하는 컬럼을 만들거나

2. password 컬럼에 삽입 할 수 있는데

password 컬럼에 삽입하는 경우 공간 복잡도를 절약할 수 있습니다. 

이 경우 createUser 메서드를 여러 곳에서 활용할 수 있으므로 로그인 유형에 따라

oauth인 경우 argon2 hash를 하지 않는 것으로 설정하는 것이 좋습니다.

oauth의 경우 email 정보가 없다면 고유 id로 식별해야 하는데

암호화를 하면 고유 id만으로 조회하는 과정의 시간복잡도가 늘어나기 때문입니다.  

 

[point-log에서 reason을 삭제하고 Order 테이블과 관계 설정]

reason을 문자열로 받으면 필요한 경우 조회해야 할 때 시간 복잡도가 늘어난다.

reason 대신 Order 테이블과 관계를 설정한다. 

 

[Token Black List 에서 expiresAt, jti  삭제]

createdAt과 token이 동일한 역할을 할 수 있으므로 불필요한 컬럼을 제거하여 공간복잡도를 줄인다. 

 

[Access Log 에서 AccessedAt 삭제]

createdAt이 동일한 역할을 할 수 있으므로 불필요한 컬럼을 제거하여 공간복잡도를 줄인다. 

2. ERD 설계

3. 주요 비즈니스 로직 계획 수립

Point 매핑 테이블 대신 총 포인트수는 Redis에  count 하여 업데이트

percent : 할인율

toss payment