키, 엔티티 네이밍 정리하기 ‐ 최진원 - Team-HGD/SniffMEET GitHub Wiki

작업 내역

백로그

현재 네이밍의 문제점

1. 프로필 사진 이름 프로퍼티 네이밍 일관성 없음

// ProfileInfo
struct ProfileInfo: Codable {
		...
    var profileImageName: String?
}

// UserInfoDTO
struct UserInfoDTO: Codable {
		...
    let profileImageURL: String?
}

// Mate
struct Mate {
		...
    var profileImageURLString: String?
}

// DogDTO
struct DogDTO: Codable {
		...
    var profileImage: String?
}

위 코드에서 볼 수 있듯이 엔티티마다 프로필 사진의 ‘이름’을 저장하고 있는 프로퍼티명의 일관성이 매우 떨어집니다. 현재 사용되고 있는 이름은 다음과 같습니다:

• profileImageName
• profileImageURL
• profileImageURLString
• profileImage

위의 프로퍼티들은 프로필 사진의 ‘이름’만을 가지고 있고, 저희 프로젝트에선 이를 이용해서 서버에서 이미지를 호출하는 방식을 사용하고 있습니다.

이에 가장 적합한 네이밍은 profileImageName이라고 생각합니다, 해당 프로퍼티에 URL이 저장되는 것이 아니며, 이미지 그 자체가 저장되는 것도 아니기 때문입니다.

enum CodingKeys: String, CodingKey {
    case id, age, sex, size, keywords, nickname
    case dogName = "dog_name"
    case sexUponIntake = "sex_upon_intake"
    case profileImageName = "profile_image_url"
}

하지만 CodingKey를 사용해서 JSON과 엔티티를 매핑할 때 비직관적으로 매핑되는 문제가 발생할 수 있습니다. 이 문제를 해결하려면 Supabase 테이블의 어트리뷰트 네임을 변경해야 합니다. 따라서 PR이 dev 브랜치에 머지되기 전에, Test 서버로 먼저 실행을 검증한 후에, 변경하면 좋을 것 같습니다.

추가적으로, 이 프로퍼티의 값을 파라미터로 받는 인터랙터나 유즈케이스 내부 메소드들의 파라미터 네임과 아규먼트 레이블도 정리하여 일관성을 만들 필요가 있었습니다. 예시로는 다음과 같은 경우가 있습니다:

// 이전
func fetchProfileImage(urlString: String)

// 이후
func fetchProfileImage(named imageName: String)

// 사용
guard let profileImageName = senderInfo.profileImageName else { return }
fetchProfileImage(named: profileImageName)

2. 프로필 이미지 데이터에 대한 일관성 없음

// DogProfileDTO
struct DogProfileDTO: Codable {
		...
    var profileImage: Data?
}

// ProfileEditPresenter.didTapCompleteButton
func didTapCompleteButton(
    nameText: String?,
    ageText: String?,
    sizeText: String?,
    keywords: [Keyword]?,
    profileImage: UIImage?
)

하나는 엔티티이고, 하나는 함수이지만 프로퍼티 profileImage와 메소드 파라미터 profileImage는 타입이 다릅니다. 하나는 Data?타입이고, 다른 하나는 UIImage?타입입니다.

Data타입에 profileImage라는 네이밍은 적절하지 않다고 생각합니다. 모든 값이 ‘데이터’이긴 하지만, 프로퍼티 이름을 지을 때는 협의의 Data타입을 뜻하는 의미로 Data를 붙일 필요성이 있습니다. 왜냐하면 이미지를 식별할 수 있는 String, Data, UIImage 모두 이미지를 ‘유니크’하게 표현하는 방법이지만 이 모든 표현 방식들을 단순히 profileImage라는 용어 하나로 표현하기엔 너무 많은 혼동을 일으킬 위험이 있으며, 실제로 혼동을 일으키고 있습니다!

따라서 프로필 이미지를 표현하는 값은 UIImage타입을 제외하고는 뒤에 어떤 방식으로 표현했는지를 적는 것을 제안합니다:

• ProfileImageName: String → 프로필 이미지를 이름으로 표현 (나중에 서버에서 가져와서 사용…)
• ProfileImageData: Data → 프로필 이미지를 데이터로 표현 (ProfileImageBin이 더 좋을것 같지만, 이미 ImageData로 된 부분이 많아서 유지합니다.)
• ProfileImage: UIImage → 프로필 이미지를 실제 시각적 이미지(UIImage)로 표현
• ProfileImageCG: CGImage → 현재 이런 코드는 존재하진 않지만, 나중에 사용하게 될 가능성이 있으므로 미리 적어놓습니다.

2-1. WalkLog도 조금 수정했습니다.

// 이전
struct WalkLog: Codable, Equatable {
    let image: Data?
}

// 이후
struct WalkLog: Codable, Equatable {
    let imageData: Data?
}

• image → imageData 프로퍼티로 변경했습니다.

SupabaseStorageRequest에도 비슷한 부분이 있지만, 이 부분은 추후 Storage가 DB처럼 쿼리 구성 방식이 개선될 때, 고치는 것이 알맞다 판단됩니다.

3. 키 네이밍 문제

enum UserDefaultsKey {
		static let profileImage: String = "profileImage"
    static let dogInfo: String = "dogInfo"
    static let sessionUserInfo: String = "sessionUserInfo"
    static let expiresAt: String = "expiresAt"
    static let mateList: String = "mateList"
    static let isFirstLaunch: String = "isFirstLaunch"
}

키 값만으로, dogInfo가 무엇을 저장하는지, profileImage가 뭘 저장하는지 잘 알 수 없습니다.

하지만 미리 정의한 키의 프로퍼티 명을 바꾸는 것은 상관 없지만, 리터럴 dogInfo를 profileInfo로 바꾸면, 기존에 dogInfo키에 저장되어있는 정보를 불러올 수 없는 문제가 생깁니다.

이 부분도 마찬가지로 고민해봐야 할 필요가 있습니다.

4. ProfileInfo, UserInfo, DogInfo 문제 + DTO

현재 엔티티에서 가장 큰 문제점이 엔티티들의 이름이 매우 비직관적인 것입니다. 사실 근본적인 원인을 분석해보면 현재 Supabase에서 사용하고 있는 테이블의 이름까지 연관되지만, 현 시점에서 바꾸기는 어렵다고 생각합니다.

이전에 UserInfo를 ProfileInfo로 바꾼 이유는 해당 프로퍼티가 유저의 정보라고 하기엔 정보를 충분히 가지고 있지 않으며, 유저의 프로필의 관한 정보만 가지고 있다고 판단했기 때문입니다.

enum UserDefaultsKey {
    static let profileInfo: String = "dogInfo"
}

하지만 미리 정의한 키 중 하나인 dogInfo를 profileInfo로 바꾸면, 기존에 dogInfo키에 저장되어있는 정보를 불러올 수 없는 문제가 생깁니다.

이 부분도 마찬가지로 고민해봐야 할 필요가 있습니다.

마지막으로 생각했으면 좋을 부분…

헝가리안 표기법과 유사해지는 것 같아 거부감이 있을 수 있지만, ‘같은 정보’를 다양한 타입으로 표기하는 경우가 많아서 어느 정도는 프로퍼티명에 타입을 유추할 수 있는 정보가 있었으면 좋겠습니다.

예를 들어:

• 이름에 ‘URL’이 붙은 프로퍼티가 String타입, URL타입인 경우가 혼재됩니다.
  • 개인적으로 URL을 스트링으로 표현할 경우에는 프로퍼티 명을 ‘URLString’을 사용했으면 좋겠습니다.
• 위에서 말한 것 처럼, ‘Image’ 이름이 붙은 프로퍼티가, String, Data, UIImage등 다양한 타입으로 혼재되어 있었습니다.