jumpit의 그룹 프로젝트 지원서 관리 및 마이 페이지 백엔드 제작 회고록

jumpit 클론 코딩 프로젝트

할당된 업무

+직무별 스킬 데이터들 정리 및 관리
+마이 페이지 제작
+지원서 수정, 업데이트, 삭제, 및 지원 상태 관리 제작
+관심있는 공고 스크랩

전체 과정 예시 이미지:

관심 공고 스크랩 :

지원현황 :

지원 상태 :

디자인 패턴 활용

• 지원서의 상태가 변할때마다 이력서 및 개인 정보등 필요로하는 데이터 추출이 다르며, 지원서의 상태에따라 여러 데이터를 활용하여 서비스에 적용하는 방식
• 지원서 작성 함수 하나를 다른기능에서도 재사용하는 패턴 구축

DB ERD 제작 및 활용

applications와 job_postings를 적극 활용

good

• Management of abstracted data (추상적인 데이터의 관리) 프로젝트의 전체적인 워크 플로우를 파악한 이후 필수적인 데이터가 무엇이고 인지가 어려운 추상적인 데이터가 어떤 부분에서 통합과 전처리를 진행하며 어떤 함수에서 데이터를 변환시켜 송.수신을 하는지 디테일한 플로우를 파악하고 정리 하였습니다. 팀원들이 정리된 데이터의 문서를 통하여 보다 더 계획적으로 데이터들을 더 전략적으로 활용하는 함수들을 개발 하였습니다.
  되돌아보는 보완점 : 데이터 명과 기능의 예시까지 덧붙여서 문서를 만들었다면 팀원들간의 소통의 시간을 더 절약하여 더 빠른 시간에 함수들을 만들수 있지 않았을까 생각이 됩니다.
  
• Application of structural functions (구조화된 함수들의 응용) 레이어드 패턴 안에서 사용하는 함수의 종류를 최소화하여 하나의 함수를 불러 여러 상황에서 재사용하는 방향성으로 전체적인 구조를 만들었습니다. 지원서 관련 부분에서 지원서의 수정중, 제출완료, 합격, 불합격 등 의 지원서 상태를 보여주는 기능 부분에서 상태를 나타내는 다수의 서비스들이 한 가지의 함수만을 재사용하여 코드의 복잡성을 최소화 하였습니다. 더하여 사용하는 변수의 종류들 역시 최소화하여 코드의 리팩토링을 잘 완수 할 수 있었습니다. 처음에 코드의 기능성들 쪼개어 생각하고 구도를 잡은 것이 결정적인 역할을 할 수 있었습니다.
  되돌아보는 보완점 : 변수나 다른 함수들을 다양한 방법으로 재사용 및 관리하는 기술들을 정착 시켰다면 훨씬 더 클린한 코드와 구조를 만들 수도 있었을 거라 생각됩니다.
  
• Agile process and communication (애자일 프로세스와 커뮤니케이션) 애자일 프로세스의 중요 요소인 빠른 개발 투입, 유연성있는 작업, 코드 리뷰, 개선 사항 등의 중요 사항들을 지키기 위해 주기적으로 팀이 지향하는 목표와 요구 사항을 지켜왔으며, 트렐로등의 툴을 통하여 분산 작업의 체계성을 따랐습니다. 더하여 빠르게 맞물려서 이루어지는 MVC(Model-View-Controller) 형태의 개발 상황에 맞게 대응하기 위하여 팀원들의 의견 및 요구 사항들을 확실히 파악하여 서로의 작업 상황을 이해할 수 있는 방향성으로 심플하면서도 협동하기 쉬운 의사 소통으로 협업을 이루어 나가도록 하였습니다.
  되돌아보는 보완점 : 이번엔 시간이 없어서 작업 보고 상황에 체계가 짜여있는 포맷이 없었지만, 다음 기회엔 개발 계획, 개발 상황, 활용할 함수 또는 데이터 등으로 포맷이 있었으면 효과적으로 관리가 되었을 거라 봅니다. 더하여 체계성있는 실시간 작업 보고서는 서로의 작업에 대한 이해도를 높이고 더 유연하게 서로의 개발 테크닉을 공유할 수 있는 방향성을 가졌을 것이라 생각합니다.
  

problem

• github 활용 미숙 main과 branch등을 분할하여 생성하고 이를 push 하고 main merge등으로 업데이트들을 주기적으로 하지 못하였다. 따라서 변형되는 코드에 맞게 실시간으로 페이스를 잘 맞추어 가주지 못하였다. 더하여 github에 부족한 경험으로 인해 짧은 주기로 개발 코드를 push하지 못하였다. 만약에 github가 익숙했다면 짧은 주기로 개발 코드를 push하며 내 개발 코드에 다양한 리뷰를 받아서 다양한 개선점 및 기능을 개발 할 수 있었을 거라고 생각한다.
  
• DB design participation (DB 설계 참여) 초반에 데이터의 수집 및 관리 작업으로 할당으로 인해 DB 설계에는 적극적으로 참여하지 못하였다. API 설계를 하는 개발자 입장에서는 DB안에 데이터 테이블을 재사용 할 수 있는 ERD 디자인은 매우 가치 있는 경험이라 생각한다. 특히, 데이터의 추출과 CICD를 관리하는 백앤드 엔지니어라면 ERD디자인에서 주는 인사이트는 자신의 개발에 다양한 영감을 줄 수 있으며 생각 확장의 기회라고 생각한다. 하지만, ERD 디자인에 주축으로 공헌하지 못한 것이 매우 아쉽다.
  
• Incomplete Understand of function (불완전한 기능의 이해) 마이점핏의 서비스 기능을 사용하고 분석하면서 기능들을 따라하면 구현 하였다. 하지만 그기능들을 완전히 이해한건 같지 않았다. 지원서 관련 기능들을 지원자 입장에서만 구현 하였지, 회사 입장에서 지원자들의 데이터를 관리하는 기능들은 만들지 못한게 아쉬웠다.