이커머스 프로젝트 회고를 쓴 지 또 사흘밖에 안 된 것 같은데 벌써 2주가 지났다. 이번에도 같은 식으로 회고해보려 한다.
프론트엔드 2명과 백엔드 2명이 모여 진행된 프로젝트다. 기간은 2주였고 타깃 사이트는 채용 공고 사이트로, 기업은 채용 공고를 올리고, 지원자들은 이력서를 관리하고 해당 이력서를 가지고 지원할 수 있는 서비스를 제공하는 플랫폼이다. 시간상의 문제로 기업 쪽의 기능은 구현할 수 없었지만 지원자의 가입 및 이력서 관리, 지원까지의 기능들은 목표한 만큼 구현할 수 있었다.
-완성본-
채용 사이트 말고 다른 아이템을 찾아 기획을 수정하려고 했는데, 이커머스와는 달리 아이템이 바뀌면 기획 자체가 바뀌어서 포기하고 리쿠르팅 서비스를 그대로 진행했다.
Python을 기반으로 Django web fremework가 사용되었고 DB는 MySQL을 사용하였다. django ORM을 점점 더 많이 알게 되었는데, ORM이 어디까지 할 수 있는지 알게 되는 게 정말 재미있었다. 하드코딩할 때마다 검색해본 바로 SQL문 자체는 MySQL이 Oracle과 얼마나 어떻게 다른지 알아볼 수는 없었지만, 오히려 그래서 DB를 수정할 일이 생길 때 마음 편하게 update문을 작성하는 재미도 있었다.
팀이 이전보다 작으니 회의 자체는 먼저 말을 꺼내는 등 진행을 조금 했지만 PM을 맡는 등 어떤 책임을 가지고 한다기보다 각자 맡은 일을 진행하면서 상의하는 것이 훨씬 수월했다. 팀원이 6명인 것과 4명인 것을 둘 다 경험해볼 수 있었던 것은 참 좋았던 것 같다.
이 이미지를 다시 보지 않을 수 없다. Agile! MVP! Scrum! Daily Meeting!
지난 프로젝트 회고록을 작성한 것을 한번씩 다시 읽어보면서, 이번에도 일단 굴러가게 만드는 것에 집중했다. 필요한 기능들은 전부 잊고, 일단 냅다 뿌리는 거다.
내가 구현한 부분안 카카오 소셜 로그인과 채용 공고 상세, 채용 공고 리스트다.
공고 리스트와 공고 상세는 동시에 진행하게 되었는데, 프론트 팀원들이 어떤 페이지에 어떤 데이터가 필요한지 미리 많은 논의를 거쳐 깔끔하게 정리해 주었기에 굉장히 편안하게 진행할 수 있었다. 리스트에는 이미지 중 .first()를 사용해 가장 먼저 나오는 이미지들을 썸네일에 사용할 수 있도록 했고, 상세에서는 이미지 여러 장을 함께 리턴했다.
카카오톡 소셜 로그인은 프론트에서 레이아웃을 만드는 동안에 진행할 수 없어서 그냥 처음부터 끝까지 백엔드에서 요청하고 받는 것으로 작성한 후 수정했다. 주고받는 데이터가 조금 달라진 것 외에는 특별히 달라진 부분 없이 완성했다. 다음에는 조금 더 섬세하고 상세한 api를 다양한 기능을 사용해 구현해보고 싶다.
리스트에 필요한 데이터들 중에는 공고를 올린 회사의 이름과 위치에 대한 것이 필요했는데, 여기서 조금 고민이 있었다.
q = Q()
if location:
q &= Q(company__location__startswith=location)
q = Q()
if tag_id:
q &= Q(tagnotification__tag_id=tag_id)
마무리된 후에 select_related와 prefetch_related를 사용했는데, 사용해보니 오히려 prefetch_related가 있을 때 더 느린 것을 알게 되었다.
몇번 수정하며 실험해본 후에 select_related만 남는 것으로 확정되었다.
queryset = JobPosition.objects.select_related("company").filter(q).order_by(sort)
이전 프로젝트에서는 페이징에 관한 모든 데이터를 전달받아서 사용했는데, 이번에는 프론트에서 진행하도록 하고 offset과 limit만 받고 또 해당하는필터링을 적용한 후의 채용 공고 갯수를 함께 리턴했다. 데이터를 따로 요청해 전체 count와 [offset:limit]
슬라이싱을 받을까 했는데, 대신 전체 쿼리셋을 요청해 담은 후 count를 계산하고 그 후에 슬라이싱해 리턴하는 것으로 결정했다. 조금 여유가 있었다면 django paginator를 사용했을 텐데 아쉽다. 리팩토링할 때 꼭 수정할 것이다.
상품은 한 사용자가 여러번 구매할 수 있지만, 채용 공고는 다르다. 채용 공고에서 이력서를 선택해 지원할 수도 있고, 지원한 공고에 다시 지원할 수는 없기에 로그인한 사용자가 공고의 상세 정보를 확인한다면 지원 여부에 대해서도 데이터가 있어야 한다.
처음에는 공고의 상세 정보와 사용자의 정보를 동시에 돌려주는 api를 작성했는데, 페이지 단위로 생각하는 것 같아서 사용자 정보를 따로 돌려주도록 수정했다.
이 부분을 작성하면서 삼항연산자도 사용했는데, 파이썬의 삼항연산자는 내가 알던 형태가 아니라 꽤 놀랐었다.
이번 프로젝트 역시 KPT 회고 방식을 사용할 것이다. 전반적으로 이전 프로젝트와 비교를 많이 하게 되었다.