WIL 9 - 2주차 : 첫 API 작성 완료

이번주는 추석 연휴가 껴있어서 미리 회고를 작성한다.(이번주는 책보고 정리 못한 내용 실컷 정리해야지~~) 

이번주는 3일(월, 화, 수)뿐이 일을하지 못했다. 회고를 작성하는 오늘(목요일)은 회사 창립기념일 대체 휴일로 쉰다. 짧은 3일동안 열심히 API 작성을 끝냈다. 

 

---

 

요구사항

1.  원하는 조건을 충족하는 쿼리문을 만들어 줄 것 

2.  Pagination을 추가 할 것 

 

이번에 작성한 API의 요구사항은 매우 간단했다. 검색기능에 Pagination만 추가하면 되기에(과거 프로젝트를 만들어 볼 때도 많이했다!) 그런데 왜 몇일동안이나 고민을 했냐? 과거의 내가 작성한 코드는 재사용성이 ZERO 였기 때문이다.. 작성할 API의 요구사항을 들었을 땐, "어? 나 이거 해본거라서 바로 할 수 있겠다!"라는 생각이 들었고, 내 자리에서 과거 내 자신의 코드를 들여다 보았다. 순간 부끄러움과 만족감이 공존했다.

 

"이걸 이렇게 왜 했을까..?"

 

페이지네이션을 사용한 그곳.

 

과거에 작성한 코드에 대한 나의 생각은 다음과 같다.

1. 페이지네이션이 필요한 부분에는 전부 다 작성해야한다.(코드 중복)
2. 코드 작성이 맘에 들지 않는다..(에러는 어디서 잡지?, 어딘가 막,,, 막메 안든다...)

 

 

당시엔 나름 재사용성을 생각해서 service 함수를 따로 만들었다. 당시에는 이렇게 만들어 두면 필요한곳에서 끌어다 쓰면 되고, 코드 가독성도 좋아질 것이라고 생각했다.

 

내가 따로 만들었던 service 함수

 

하지만 저렇게 따로 만들어 놓고, 모든 render 되는 곳에 다 작성을 해뒀으니, 내 서비스 함수 작성 목표를 잃어버렸다. 그래서 지금 들은 생각은  두가지가 있다.

1. private 메서드를 만들어 request와 category 를 입력받아 결과값을 반환한다. 

이렇게 하면 해당 메서드를 불러와 view의 가독성이 좀 더 좋아지지 않을까? 하는 생각을 하게 되어 이런 방법을 생각해보았다.

 

_get_articles_by_category(request(category: string, page: int) -> list[Article]:
    target_articles = read_category_articles(category)
    taget_articles = get_page_context(target_articles, page)
    return target_articles

하지만 이 방법은 문제가 있다. 페이지 네이션은 지금 페이지에서만 사용하는 것이 아니라, 다른 view 에서도 많이 쓰일 수 있는데 그럼 또 똑같은 코드를 사용해야한다.. 

 

2. Paginginteractor 클래스 모듈을 만든다.

내가 생각한 방법은 모듈을 만들어서 해당 모듈을 필요한 곳에서 Import 하여 사용하는 것이었다. 이렇게하면 의존 주입을 통해 view가 훨씬 유지보수하기 쉬워질것이라고 생각했다.

 

그리고 여기에는 입력 값에 대한 검증, 중간에 발생하는 에러에 대한 핸들링을 추가했다.

 

그래서 나는 이번 API를 작성할 때에는 Paginginteractor 를 구현하여 페이지 네이션을 구현하였다.

 

 

 

나머지 조건인 원하는 조건을 충족하는 쿼리 작성은 어렵지 않게(?) 작성했다.

 

filter를 해주는 쿼리라고 생각하였고, 조건을 쿼리해주는 것은 다른 곳에서도 사용 될 수 있다 생각하여, interface를 만들어하여 해당 FilterInterface를 구현하였다.

 

이번 FilterInterface를 만들어보면서 내가 생각보다 django ORM을 사용하면서 (역시나) 제대로 알지 못하고 사용했단 사실을 깨달았다. 많이 들어보았던 lazy loading 과 n+1 쿼리에 대한 고민을 이번에 해보게 된 것 같다.

 

덕분에 django ORM 관련 글과 내용을 공부 할 수 있었다! 근데 django ORM을 공부하다보니 Raw Query(SQL)이 더 우선적으로 필요하다는 생각이 들었다. ORM을 작성하기 전에, 어떤 쿼리를 작성할 것인지 먼저 그려보는게 필요하다 생각이 들었기 때문이다. (근데 무엇보다  레거시 코드 할말 하않...다 내가 부족해서 못하는거다... 그렇다...)

 

---

느낀점

이번 API 작성을 하면서 무엇보다 가장 큰 목표는 현재 작성된 API 틀을 최대한 따라가는 것이였다. 이것이 맞다 틀리다를 따져보는게 아니라, 현재 작성된 API 틀을 그대로 유지하면서 새로운 기능 개발을 해보는게 가장 큰 목표였다.  이렇다 보니 레거시 코드를 보며 몇몇 궁금증이 생겼다..

 

1.  Interactor 은 어느 경우에 사용해야하는가?
2. Interface와 Abstract Class 의 차이는 뭘까?
3. 현재 적용된 디자인 패턴이 존재하는걸까? 존재한다면 어떤 패턴인걸까? 그리고 더 나은 방법은 없었을까?

   등등..

 

여러 생각들이 많이 들었다.. 근데 이걸 당장 답을 얻기에는 시간도 내 능력도 아직 많이 부족하다는 생각이 들었다..! (갈길이 멀다 멀어 ~~)

근데 너무 재밌다.. 이런 고민을 하는 것이 왜이리 재밌는지 모르겠다!! 어서빨리 책도보고 코드도 파악해서 경험치를 쌓아야겠다!