점핑배틀외주 프로젝트4-지난 기능 함수 리팩토링
문제점
점핑배틀의 일부 기능을 론칭하고 거의 1달 이상이 지난 지금, 아직까지 서버의 문제로 인한 전화는 받은 적 없기 때문에 일차적인 목표인 돌아가는 코드 짜기
는 훌륭하게 성공한 것으로 보인다.
그러나 급하게 jpg다운로드 기능을 추가하면서 구현해낸 함수에서 제일 아쉬운 부분은 함수의 역할에 대한 인식이 없음
이어서 이 글을 작성하게 되었다.
클래스와 함수
보통 클래스는 큰 의미에서의 기능 설계(예를 들어서 랭킹/서버/랭킹 이외의 db조회)등을 말하며, 함수는 그에 따라서 가져야할 기능에 대한 조감도 같은 것이다.
즉 둘다 큰 범주에서는 역할을 가지지만 그 역할의 크기에 따라 개념이 나뉜다고 생각하면 된다.
함수의 특징
함수는 클래스보다 작은 범위에서 이루어져야하므로, 보다 경제적(재사용성)이어야하며 일차적인 모듈성인 클래스보다 좀 더 작은 단위의 모듈화가 이루어져야한다.
여기에서 중요한 것인 쪼갤 수 있는 기능은 쪼개되 너무 작은 단위로 함수를 쪼개게 되면 쓰이지 않는 함수가 생긴다거나, 함수 내에서 함수를 호출하는 역할을 하는 함수가 생기는 등 함수의 본질인 가독성과 경제성을 모두 해치게 될 우려가 있다.
이번 프로젝트 내 함수의 문제
일차적으로, 너무 작은 단위의 함수를 구성하여 경제적인 재사용이 불가능해졌다.
프로젝트 계약건으로 인해 코드의 내용을 정확하게 공개할 수는 없지만 수도 코드로 표현을 해보겠다.
수도 코드
1. def get_video_metadata(uuid): 비디오의 존재 여부확인
2. def get_jpg_metadata(uuid): jpg에 대해 마찬가지인 작업 수행
3. def check_download_limit(file_path, uuid):
4. def check_jpg_download_limit(file_path,uuid): 3,4번 모두 다운로드 카운트에 대한 확인을 하는 함수
5. def increment_jpg_download_count(file_path):6번 코드는 생략. 모두 jpg와 mp4에 대한 다운로드횟수를 증가시키는 함수
6.(생략)
7.def check_download(uuid), def jpg_check_download(uuid): 위에 함수들을 호출해서 본격적인 다운로드를 하는 서버측의 함수
jpg다운로드의 경우 다운로드의 만료일은 mp4와 동일하지만, 다운로드의 횟수 제한이 다르며 한 개만 다운로드 받는 경우도 고려해야하므로 db상에선는 이 둘을 분리하여 저장해야한다.
그래서 나의 경우 초반에 jpg다운로드 횟수 가져오기 및 증가함수,mp4에 대한 횟수 및 증가함수, 둘 다 동일하게 사용가능한 만료일 조회 및 그 여부에 따른 랜더링 함수로 만들어주었다.
개선 가능한 지점
지금 보여준 수도코드의 가장 큰 문제는 기능이 추가될 때마다, 또다른 함수를 만들어야한다는 데에 있다.
만약 이 함수를 다시 짠다면 확장자가 두개 정도로 많지 않은 것 까지 고려하여 확장자와 uuid를 매개변수로 받은 뒤 if문으로 확장자를 전개하는 방식으로 코드를 짤 것 같다.
만일 다시 짠다면
저 코드 중 존재 여부에 대한 부분과 카운트에 대한 부분을 통합할 것 같다.
어차피 존재할 수 없는 형태의 파일명이든 카운트에 대한 초과이든 유저에게는 동일한 결과를 생산하기 때문이다.
또한 대부분의 함수가 역할은 똑같은데 확장자에 의해 다른 함수로 나누어지는 구조이기에 다시 짠다면 매개변수로 확장자를 받아 함수 내부에서 if문을 통한 전개를 할 것이다.
구체적인 예시
def get_metadata(file_name):
.을 기준으로 앞부분은 uuid, 뒷부분은 확장자로split하여 return한다.
return uuid,ext
def get_metadata(file_name)를 import하여 uuid와 ext를 받는다.<br>
def increment_count(): if ext가 jpg냐 mp4냐에 따라 config에 정의한 다운로드 횟수대로 올려줄지 말지를 결정. 이때에 횟수가 넘으면 에러코드를 return하고 프론트에서 alter띄우기
def check_download(): #우선 today변수를 두어 오늘 날짜로부터 uuid의 날짜가 7일 이내인지 확인 후 작업 진행. 7일이 넘은 경우에는 바로 파일의 return을 중지하고 오류페이지를 랜더링. 7일 이내의 경우 count를 확인하는 함수로 넘어감
@app.route('/download/<uuid>')
def download(uuid,ext):# 각각의 파일의 ext에 따라 파일을 준비해준다. uuid가 필요한 이유는 firebase에 요청할 데이터를 찾기 위해
이런 식으로 리팩토링을 할 것 같다.
댓글남기기