[트러블 슈팅]알림 모델 개선

문제 정의

1. 알림 유형 구분의 어려움:

   • 알림 유형을 숫자(int)로 관리하다 보니, 코드에서 의미를 직관적으로 파악하기 어려움
   • 예: type=1이 무엇을 의미하는지 명확하지 않음

2. 알림 상태 관리의 불편함:

   • 알림의 읽음 여부(is_read)를 별도로 관리하지 않아, 사용자가 읽은 알림을 처리하는 로직이 복잡해질 가능성이 있음

3. 확장성 부족:

   • 새로운 알림 유형을 추가하려면, 기존 코드의 모든 type 관련 부분을 수정해야 하는 구조적 문제가 있음

---

해결 방안

1. choices 필드를 활용한 유형 정의:

   • TYPE_CHOICES를 도입해 알림 유형의 의미를 명확히 하고, 새 유형 추가 시 수정 범위를 최소화
   • 각 알림 유형에 대해 상수(TYPE_GENERAL, TYPE_FRIEND_REQUEST 등)를 정의해 코드 가독성을 높임

2. 읽음 여부 관리:

   • is_read 필드를 추가해 알림의 상태를 관리
   • 사용자가 알림을 읽었는지 여부를 직관적으로 확인하고 처리할 수 있도록 개선

3. 모델 기본값 및 정렬:

   • type의 기본값을 지정하고, 생성일 기준 정렬을 기본으로 설정해 데이터 조회 성능 향상

---

최종 수정 모델

class Notice(models.Model):
    user_id = models.ForeignKey(
        settings.AUTH_USER_MODEL, on_delete=models.CASCADE, related_name="accounts"
    )
    TYPE_GENERAL = 1
    TYPE_FRIEND_REQUEST = 2
    TYPE_COMMENT = 3

    TYPE_CHOICES = [
        (TYPE_GENERAL, "일반 알림"),
        (TYPE_FRIEND_REQUEST, "친구 요청 알림"),
        (TYPE_COMMENT, "댓글 알림"),
    ]

    type = models.IntegerField(choices=TYPE_CHOICES, default=0)
    content = models.CharField(max_length=50)
    is_read = models.BooleanField(default=False) # 읽음 여부
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

---

변경

1. TYPE_CHOICES로 알림 유형 관리:

   • 숫자 값 대신 상수(TYPE_FRIEND_REQUEST 등)를 사용해 가독성을 높이고, choices를 통해 유효성을 보장.

2. is_read 필드 추가:

   • 알림의 읽음 여부를 쉽게 확인하고, 클라이언트와 서버 간 상태 동기화를 용이하게 만듦.

---

모델 변경에 따른 영향

1. 직렬화 코드 변경:

   • NoticeSerializer에서 추가적인 변경 없이 동작 가능:

     class NoticeSerializer(serializers.ModelSerializer):
         class Meta:
             model = Notice
             fields = ['id', 'type', 'content', 'is_read', 'created_at', 'updated_at']

   • get_type_display()를 활용하려면 추가 필드를 정의 가능:

     class NoticeSerializer(serializers.ModelSerializer):
         type_display = serializers.CharField(source="get_type_display", read_only=True)
     
         class Meta:
             model = Notice
             fields = ['id', 'type', 'type_display', 'content', 'is_read', 'created_at', 'updated_at']

2. 조회 및 업데이트 로직 변경:

   • 알림을 읽음 처리하거나 삭제하는 API를 간단하게 구현 가능:

     # 읽음 처리
     notice = get_object_or_404(Notice, id=notice_id, user_id=request.user)
     notice.is_read = True
     notice.save()

   • 읽은 알림 삭제:

     Notice.objects.filter(user_id=request.user, is_read=True).delete()

3. 확장성 향상:

   • 새로운 알림 유형 추가 시, TYPE_CHOICES에 값을 추가하기만 하면 쉽게 확장 가능:

     TYPE_LIKE = 4
     TYPE_CHOICES.append((TYPE_LIKE, "좋아요 알림"))

---

피드백

1. 가독성과 유지보수성:

   • choices와 상수를 활용하면 코드를 더 직관적이고 관리하기 쉽게 만들 수 있다

2. 데이터 상태 관리:

   • 상태 필드(is_read)를 추가해 클라이언트와 서버 간의 데이터 동기화가 원활해짐

3. 확장 가능성:

   • 구조적으로 개선된 모델은 새로운 요구사항이 추가되더라도 최소한의 수정만으로 대응할 수 있다

---

앞으로의 계획

실시간 알림 지원:

• WebSocket이나 Django Channels를 통해 알림을 실시간으로 전달하는 구조를 검토할 예정