본문 바로가기
Coding

Django 프로젝트를 위해 알아야 할 리팩터 정리

by Jake Gyllenhaal 2022. 4. 16.
반응형

Django 프로젝트를 위해 알아야 할 리팩터 정리

 

Django를 사용 중이신가요? 이러한 것들을 리팩토링해야 합니다!

Unsplash에서 Chris Ried의 사진

** 참고: 이 기사는 CSUI의 소프트웨어 엔지니어링 프로젝트 과정 2022에 대한 개별 검토를 위해 작성되었습니다. **

리팩토링은 모든 프로젝트에 대해 수행해야 하는 가장 중요한 방법 중 하나입니다. 프로젝트가 비교적 작고 단순하더라도 리팩토링 코드는 항상 권장되며 더 읽기 쉽고 간단하며 깨끗한 코드를 위한 모범 사례입니다. 이 기사에서는 Django(특히 Django REST Framework)를 선택한 프레임워크로 사용할 때 리팩토링할 수 있는 몇 가지 사항을 보여 드리겠습니다! 갑시다!

You Need to Know These Refactors!
(Django Models) Custom Model Manager
(Django Models) Select Related and Prefetch Related
(Django REST Views) Class Based Views with Mixins and Generics
Conclusion

이 예에서는 소프트웨어 엔지니어링 프로젝트 과정 2022를 위해 만든 모델을 사용할 것입니다.

(Django Models) 커스텀 모델 매니저

Django Documentations에 따르면 "Django의 모델 관리자는 데이터베이스 쿼리 작업이 Django 모델에 제공되는 인터페이스입니다."

이것을 깨닫지 못할 수도 있지만 Django Models를 사용할 때 Django의 모델 관리자를 사용했을 것입니다. 당신이 쓸 때 Term.objects.all()기본 관리자 중간에 있는 '객체'는 Django에서 모든 모델에 제공합니다.

흥미로운 점은 다음과 같습니다. 사용자와 사용자의 모델에 편리한 다른 작업을 수행할 수 있는 사용자 정의 모델 관리자를 만들 수 있습니다.

예를 들어, 특정 용어(예: "2021/2022–1" 용어)의 모든 코스를 가져오고 코스 이름으로 정렬되도록 하려면 일반적으로 다음과 같이 작성합니다.

Course.objects.filter(term__name="2021/2022-1").order_by("name")

솔직히 말해서 큰 문제는 없지만 이 정확한 필터링을 사용하고 코드에서 여러 번 순서를 지정하면 코드를 계속해서 반복하게 될 것입니다. 이 긴 필터와 순서는 코드의 가독성을 떨어뜨릴 수 있습니다. 예를 들어 다음과 같이 사용자 지정 모델 관리자와 QuerySet을 사용하면 상황이 개선될 수 있습니다.

새 사용자 정의 관리자를 모델에 할당하는 것을 잊지 마십시오. 기본 '개체' 관리자를 덮어쓰거나 다른 이름으로 새 사용자 정의 관리자를 생성할 수 있습니다. 이를 위해 기본 '개체' 관리자를 덮어씁니다.

이를 통해 다음과 같이 작성하여 이전과 동일한 작업을 수행할 수 있습니다.

Course.objects.get_by_term_name_with_ordered_name("2021/2022-1")

이전 코드보다 더 읽기 쉽고 반복하지 않고 더 간단하다는 것을 알 수 있습니다. .filter 그리고 .order_by. 물론, 이 예제는 코드를 많이 개선하지 않는 것처럼 보일 수 있지만 원하는 것과 필요한 것은 무엇이든 사용자 정의 관리자를 사용할 수 있습니다. 이렇게 하면 코드 가독성이 크게 향상되고 코드 반복을 방지할 수 있습니다.

(Django 모델) 관련 항목 및 프리페치 관련 항목 선택

에 대해 아직 모를 수도 있습니다. select_related그리고 prefetch_related, 하지만 Django에서 제공하는 이러한 기능은 정말 유용합니다. 제 생각에는 데이터베이스 쿼리 성능을 향상시키기 위한 필수품입니다. 이는 이미 QuerySet에 대한 많은 객체를 쿼리한 다음 외래 키 객체의 속성에 액세스하려는 경우 Django가 호출하는 모든 객체의 모든 외래 키 속성에 대해 데이터베이스를 다시 쿼리하기 때문입니다.

추측해 보세요. 아래 코드가 실행되면 Django는 데이터베이스에 몇 개의 쿼리를 생성할까요?

courses = Course.objects.filter(credit=4) #for example returns 2 objfor course in courses:
print(course.term.name)

하나가 되어야 한다고 생각할 수 있습니다. 그렇죠? 다음과 같은 경우 데이터베이스를 쿼리해야 합니다. Course.objects.filter 실행된다? 죄송합니다만, 그 대답은 정확하지 않습니다. 정답은 세 번의 데이터베이스 쿼리 호출이 있다는 것입니다.

어떻게? 분명히 첫 번째 쿼리는 필터에 있습니다. 그 다음은 2개이기 때문에 Course 쿼리 세트의 개체, courses그리고 코드는 외래 키의 속성(course.term.name), 모든 반복에 대해 for 루프에서 Django는 데이터베이스에 대한 추가 쿼리 호출을 수행합니다.

이는 초기 Course.objects.filter 용어의 이름에 대한 정보가 없습니다. 1,000번 이상 반복한다고 상상해 보세요. 이것만으로도 데이터베이스를 1,000번 쿼리하게 됩니다.

이를 방지하기 위해 다음을 사용할 수 있습니다. select_related그리고 prefetch_related초기 필터 쿼리에서 이러한 외래 키 속성을 가져옵니다. 둘 사이의 차이점을 검색할 수 있지만 간단히 말해서 다음을 사용합니다. select_related객체 속성이 단일 객체인 경우(예: OneToOneField 또는 ForeignKey), 당신이 사용하는 동안 prefetch_related단일 개체 또는 일련의 사물(ManyToManyFields또는 반전 ForeignKey'에스).

courses = Course.objects.filter(credit=4).select_related("term")for course in courses:
print(course.term.name)

추가하여 select_related("term")외래 키 "용어"의 모든 정보를 쿼리합니다. courses 첫 번째 쿼리의 개체. 그 때문에 Django는 모든 반복에 대해 데이터베이스를 쿼리할 필요가 없습니다. for 루프.

이렇게 하면 데이터베이스 쿼리 성능이 크게 향상되며(대량의 데이터베이스 쿼리를 방지하는 것과 유사) 나중에 특정 외래 키의 이러한 속성이 필요하다고 독자에게 명시적으로 알려줌으로써 코드를 더 읽기 쉽게 만들 수 있다고 개인적으로 생각합니다.

(Django REST Views) 믹스인 및 제네릭이 포함된 클래스 기반 보기

** 참고: Django REST Framework에 대한 클래스 기반 보기에 대해 논의할 것입니다. Django의 클래스 기반 보기는 약간 다르며 자세한 내용은 Django 설명서를 참조하세요. **

클래스 기반 뷰는 이미 많은 Django 사용자에게 잘 알려져 있습니다. 그러나 제 생각에는 클래스 기반 보기를 적당히 사용해야 합니다. 복잡한 보기의 경우 클래스 기반 보기가 가독성을 낮추고(클래스 기반 보기에 능숙하지 않은 사람들의 경우) 유연성이 부족할 수 있다고 생각합니다.

그러나 간단한 보기, 특히 Django REST Framework(DRF)의 REST 보기의 경우 훨씬 더 간단하고 코드가 덜 필요하며 가독성이 향상되므로 제공된 믹스인 및 제네릭과 함께 클래스 기반 보기를 사용해야 합니다(이미 클래스를 알고 있는 다른 사용자의 경우). - 기반 보기).

예를 들어, 함수 기반 보기를 사용하여 다음과 같이 작성합니다. GetAndDeleteTermViews 이와 같이 데이터 직렬화를 위해 먼저 모델에 대한 직렬 변환기를 만들어야 한다는 점을 염두에 두십시오. 이 경우 내 이름을 지정했습니다. TermSerializer:

위의 코드는 기능적으로 큰 문제가 없습니다. 정상적으로 작동해야 합니다. 그러나 더 복잡한 논리로 보면 훨씬 더 복잡해집니다. 훨씬 더 많은 코드 라인 및/또는 더 많은 ifs 및 elifs가 있을 것입니다. 이렇게 하면 코드의 가독성이 낮아집니다. 다음은 클래스 기반 뷰, 믹스인 및 제네릭과 동일한 기능입니다.

보시다시피 훨씬 더 간단하고 읽기 쉽습니다. 또 다른 장점은 발생할 수 있는 모든 오류(예: 객체가 존재하지 않을 때 404)가 Django에서 이미 처리된다는 것입니다. 이렇게 하면 개발 시간이 단축되고 클래스 기반 보기에 대한 기본적인 이해가 있는 독자의 가독성이 향상됩니다.

Django 프로젝트에서 반드시 고려해야 하는 필수 리팩터라고 생각합니다. 이것들이 확실히 리팩토링해야 하는 모든 것은 아닙니다. 리팩토링이 필요한 항목을 더 검색해야 하지만 Django를 처음 접하는 많은 사람들이 모델 관리자 및 select_related/prefetch_related 장고에서.

코드를 리팩토링하는 데 드는 모든 노력은 더 깨끗하고 단순하며 읽기 쉽고 개선된 코드로 확실히 보답할 것입니다.

반응형

댓글