Django 유틸리티

해당 내용은 Two Scoops of Django의 29장 유틸리티들에 대해 의 내용을 작성자의 의견을 추가하여 재 구성하였습니다. 피드백을 환영합니다.

Django 유틸리티를 찾아보게 된 계기

화해의 기술 블로그 를 알게 되고 작성한 글들을 읽어보며 Django manager에 대해 알게 되었습니다. 프로젝트에 적용해보며 해당 기능의 편의성을 알게 되었고 복잡한 모델에 체이닝을 걸기 위해 커스텀 쿼리셋을 작성하였습니다.

결과적으로 하나의 모델에 필드, 메서드, 프로퍼티, 커스텀 매니저, 커스텀 쿼리셋 등 코드의 양이 방대해져 이것을 분리하기 시작하였고 (하나의 모델 파일에서 모델 파일과 매니저 파일로 구분하였습니다.) 코드를 조각내어 분리하던 중 중복되는 코드를 저장하는 모듈이 필요함을 느꼈습니다.

패스트캠퍼스의 조교를 했던 기수에서 core 모듈을 통해 중복 사용되는 코드들을 저장하는 법을 알고 있었으나 그렇게 사용하는 이유를 이전보다 정확히 파악해보고자 이 글을 작성하게 되었습니다.

Django 유틸리티

프로젝트를 진행하면 공통적으로 이용되는 클래스나, 다양한 목적으로 시스템 전반에 이용되는 작은 유틸리티들을 제작하게 됩니다.

이러한 부분들은 특정 앱 하나에만 종속적으로 속해 있는 것이 아니며 다양한 코드 작성 시 이용되는데 이런 유틸리티들을 저장하는 모듈에 대해 고민하는 순간이 있으실 것 입니다.

우리는 프로젝트 전반에 걸쳐 쓰이는 함수들과 객체들을 넣어두는 코어(core)라는 명칭의 앱으로 유틸리티들을 보관하는것을 권장합니다.

./manage.py startapp core

비슷한 패턴으로 common, generic, util, utils 란 이름의 앱을 사용하기도 합니다.

저는 회사에서는 common 이란 명칭으로, 학원에서는 core 라는 명칭으로 유틸리티들을 관리하였습니다.

여러 앱에서 공통으로 이용하는 커스텀 모델 매니저와 커스텀 뷰 믹스인이 있다면 다음과 같은 코어 앱을 구성하게 됩니다.

core/
    __init__.py
    managers.py # 커스텀 모델 매니저 포함
    models.py
    views.py # 커스텀 뷰 믹스인 포함

주의사항으로는

core 디렉토리 장고 앱을 만들며 다음 중 하나의 구성을 선택하여 이용해야 합니다.

• 코어는 비추상화 모델(non-abstract)을 가지게 됩니다.
• 코어에 어드민 자동 발견을 적용한다. ( 해당 부분은 작성자가 이해하지 못해 추 후 내용을 보강하도록 하겠습니다.)
• 코어에 템플릿 태그와 필터를 위치시킨다.

여러 곳에서 공통적으로 쓰이는 코드를 저장해 두기

여러 곳에서 공통으로 쓰이는 함수와 클래스지만 models.py , forms.py 또는 다른 특별한 이름의 모듈에 이를 넣을 수 없을 때 가 있을 수 있습니다. 이러한 로직들은 utils.py에 위치하는것을 권장합니다.

모델을 좀 더 간결하게 만들기

Order 모델을 빈번히 이용한다고 가정하겠습니다.
다양한 필드들과 메서드 및 클래스 메서드들을 연이어 붙여가며 코드를 작성하게 됩니다.
그러다 어느 날 우리의 모델이 너무나 비대해지고 수천 줄이 넘는 상태가 되었을 때
우리는 이러한 코드를 디버그 하기도, 지속적으로 관리하기도 쉽지 않은 순간을 마주하게 될 것입니다.

프로퍼티나 클래스 메서드를 포함한 여러 메서드에서 Order/utils.py안으로 쉽게 캡슐화 하여 넣을 수 있는 부분을 생각하면 됩니다. 기존의 (프로퍼티나 클래스 메서드를 포함한) 메서드들을 Order/utils.py 에서부터 호출되는 간단한 메서드들로 만들 수 있습니다.
이렇게 함으로서 코드를 좀 더 쉽게 분산시킬 수 있고 재사용과 테스팅이 한결 수월해지는 효과를 볼 수 있습니다.

좀 더 손쉬운 테스팅

복잡하게 얽힌 로직들로부터 함수들을 떼어내서 독립적인 모듈로 이전함으로서 얻는 부수적 효과로 좀 더 손쉬운 테스트가 가능해짐들을 알 수 있습니다.
우리가 이야기한 독립적이란 의미는 하나의 앱 안에서 독자적으로 임포트되는 것 만으로도 기능을 충분히 발휘할 수 있어야 한다는 것 입니다.
프로젝트 전반에 걸쳐 여러 부분에 임포트되어야 하는 경우가 아닙니다.
이렇게 함으로서 비즈니스 로직은 덜 복잡해지고 해당 모듈의 테스트가 한결 수월해지는 효과를 가져오게 됩니다.

• 유틸리티 코드들은 가능한 자신의 주어진 역할에만 집중하도록 한다.
  • 될 수 있는 한 함수나 클래스들에 여러 기능이나 동작을 넣지 말자. 각 유틸리티 함수는 각각 자기가 맡은 한 가지 기능만 수행하게 하며 반복적인 작업이나 중복되는 기능을 피하도록 하자. 모델의 기능과 중복되는 유틸리티 함수를 만드는 것을 피하자.