[KPT 회고][Team Unity] News Feed 서버 기능 프로젝트 KPT 회고

프로젝트 소개

• 프로젝트 명 : 뉴스피드
• 소개
  • 한 줄 정리 : 뉴스피드 서버 기능 구현하기
  • 내용
    1. 프로필 관리
       • 프로필 조회
       • 프로필 수정
         • 비밀번호 수정 => 본인 확인용 현재 비밀번호 확인/ 현재 비밀번호와 동일한 비밀번호로 변경 불가
         • 비밀번호 형식에 맞는 비밀번호로 변경가능
    2. 게시물 관리
       • 게시물 작성
       • 게시물 전체 조회
         • 기본정렬은 생성일자 기준으로 내림차순
         • 10개씩 페이지네이션
       • 게시물 수정
         • 본인 확인 필요
       • 게시물 삭제
         • 본인 확인 필요
    3. 사용자 관리
       • 회원가입 기능
         • 아이디 : 이메일 형식
           • 중복된 사용자 아이디 가입 불가
         • 비밀번호 : 대소문자 포함 영문 + 숫자 + 특수문자로 최소 1 글자씩 포함, 최소 8글자 이상, Bcrypt 인코딩
       • 회원탈퇴 기능
         • 탈퇴 시 비밀번호 확인 → 일치하면 탈퇴 처리
         • 탈퇴한 사용자의 아이디로 재가입 불가, 탈퇴 계정 복구 불가
    4. 친구 관리
       • 친구 추가
         • 상대방 수락 기능
           • 친구 추가 신청 목록 확인
           • 친구 추가 수락 기능(API)
         • 뉴스피드에서 친구의 최신 게시물을 최신순으로 볼 수 있음
       • 친구 삭제
         • 서로의 게시물 확인 불가

 

프로젝트 깃허브

https://github.com/Sparta-Team-Unity/News-Feed

GitHub - Sparta-Team-Unity/News-Feed: 뉴스피드 서버 개발

 

 

KPT 회고

Keep - 현재 만족하고 있는 부분

• 개발 - 서로 진행되면서 발생하는 문제점을 해결하기 위해 코드리뷰를 진행하며 로직 설명을 통해 해결한 부분이 좋았습니다. 코드리뷰를 진행하면서 문제점을 파악하고 해결하는 코드적 이해도를 높일 수 있었습니다.
• 프로젝트 설계 - 설계를 바탕으로 개발을 진행 할 수 있어서 소통할 때 유연한 소통이 가능한 부분이 좋았습니다.
• 코드 관리 - 깃허브를 사용하여 코드 버전 관리와 기능별 코드 관리를 팀원별로 체계적이게 관리할 수 있었던 부분이 좋았습니다.
• 개발 - 제일 좋았던 점은 역할을 큰 기능별로 체계적으로 나눠 개발을 진행했다는 점입니다. 기능별로 나눠 개발을 했다는 것이 꼭 좋은 것은 아닙니다.
  하지만, 시간이 부족했던 이번 뉴스피드 프로젝트 였던 만큼, 개발 진행 중 커밋 충돌에 투자할 시간을 최소화할 수 있다는 것이 큰 장점이었습니다.
• ERD - ERD 설계를 하는 과정에서 저희가 구현할 내용, 해당 내용에 필요한 자료에 대해 토론을 통해 작성하고 해당 내용을 토대로 Table을 작성할 수 있었습니다.
  이 과정에서 추후에 변경이 될 가능성이 적을 것이라는 예상 덕분에 Entity Class, Dto와 같은 데이터 설계에 대한 부담이 확연히 내려갔습니다.
• 커뮤니케이션 - 저희 조는 첫 날부터 꼬박 하루를 회의로 사용했습니다.
  그런 상황에서도 저희 조원 분들은 불편한 기색 없이 서로 갖고 있는 지식과 정보를 공유했고, 아쉬운 점이나 다른 아이디어가 생길 경우, 세심한 피드백을 진행했습니다.
  또한, 프로젝트가 진행되는 과정 중에서도 모르는 것이 있거나, 의논이 필요한 상황이 올 때마다 질문하거나 회의를 통해 서로가 갖고 있는 지식을 공유했고, 해답을 찾기 위해 함께 노력했습니다.
• 개발 - 과제를 수행하기에 모자란 실력이었으나, 최대한 해볼 수 있는 만큼 노력해서 과제를 수행했습니다.

 

Problem - 불편하게 느끼는 부분

• 개인 회고 - JWT의 인증/인가 기술적 이해도가 높지 못해 팀 프로젝트를 진행하면서 스스로의 기술지식 및 이해도의 부족함을 느끼게 되었습니다. 이로 인해 팀 프로젝트 개발진행에 지연이 생겼고, 미숙한 기술적 이해도를 개선해야겠다고 느꼈습니다.
  프로젝트를 설계함에 있어서 전체적인 프로젝트 흐름을 이해하지 못하여 개발 과정에서 프로젝트 설계된 부분을 수정하는 일이 발생하게 되었습니다.
  프로젝트를 코드를 구현함에 있어서 기술적으로 왜 기능 코드를 작성하게 되었는지 충분히 설명할 수 있지 못하고, 동작하는 코드를 레퍼런스하여 따라서 작성하는 식의 개발 진행을 하게 되어 아쉽습니다.
• API 명세 - 설계과정에서 API 기능 추가와 변경이 발생하였을때 실시간 공유와 반영이 제대로 이루어지지 않아서 아쉬웠습니다. 코드적 구현을 마친 후 API를 구현된 기능에 맞춰 수정을 반복하면서 처음 API를 설계한 이점이 줄어들어 설계 때 충분한 의논과 모든 케이스를 고려하여 설계해야겠다고 생각했습니다.
• 개발 - 프로젝트의 기능을 확장하여 추가적인 기능을 구현해 내지 못한 부분이 아쉽습니다. 기술적 이해도를 높여 확장된 기능 추가 방향으로 기능 확장을 해보면 좋을 것 같습니다.
• 기간 - 프로젝트 마감기간이 촉박하여 이해도 높은 코드구현을 하지 못한 부분이 아쉽습니다. 이해도가 낮은 상태에서 코드를 작성하고, 참조하여 기능이 동작하는 코드 작성방식으로 개발을 진행하여 불필요한 코드와 기술적 구현의 이유를 이해하지 못한 프로젝트인 부분이 아쉽습니다.
• 트러블 슈팅 기록 - 트러블 슈팅에 대한 문서화 작업을 체계적으로 기록하지 못한 부분이 아쉽습니다. 개발중에 트러블 슈팅이 발생하였을 때 기록을 남기지 못하여 프로젝트 최종 마무리 과정에서 트러블 슈팅이 있었던 로직을 기억하지 못하고 기록하지 못한 부분이 아쉽습니다.
• 개발 - 우리 프로젝트에는 다양한 기능이 추가되어 있어, 어떤 상황이 오더라도 유연하게 대처할 수 있다는 장점이 존재합니다.
  하지만 해당 기능이 꼭 필요한 것인지, 자세하게 알고 있는지, 어떤 장단점이 있는지에 대해 알고 개발을 했냐고 누가 물어볼 경우, 자신 있게 “네”라고 대답할 수 있는 것이 많지는 않다는 것이 아쉬웠습니다.
• ERD - 처음에 회의를 통해 어느 정도의 기능 스케일, ERD 기능에 대해 작성하였으나, 기능과 해당 기능에 필요한 ERD의 내용이 프로젝트를 진행하는 과정에서 변경되는 일이 발생하였습니다.
  ERD가 수정될 때마다 DB를 변경해야 하고, 변경 할 때마다 기존에 작성되어 있던 Table을 Drop 하거나 Entity, Dto와 같은 내용을 변경해야 한다는 문제가 발생합니다.
  그래도 컬럼이 추가되거나, 아무 관계가 없는 테이블이 추가되는 것은 리소스 낭비가 적었지만 TokenTable과 같이 새로운 관계가 추가되는 상황이 발생하기도 했다는 점이 아쉬웠습니다.
• 커뮤니케이션 - 이번 프로젝트에 있어 아쉬웠던 부분은 함수에 대한 교류가 부족했습니다. 이번 프로젝트에서는 getUserbyUserId가 있습니다.
  Post, Friend 모두 User Repository에서 유저 정보를 가져와야 했습니다. User Service를 통해 정보를 조회가 가능해야 했지만, UserService에는 해당 기능이 구현되어 있지 않았습니다.
  그 과정에서 Post, Friend 각각 Service단계에서 User Repository를 직접 사용하여 데이터를 불러오는 코드가 작성되게 되었고, 중복 코드가 발생했습니다.
• 개발 - 아무래도 실력이 부족한 게 제일 큰 문제였습니다.

 

Try - Problem에 대한 해결책, 당장 실행 가능한 것

• 개발 - 스프링의 이해도를 높이기 위해 진행한 프로젝트의 코드리뷰를 진행하여 각 기능의 코드적 구현 이해도를 높일 수 있는 컨퍼런스 진행을 하면 좋을 것 같습니다.
• 프로젝트 설계 - 프로젝트 설계과정에서 좀 더 원활한 소통이 가능하도록 다양한 아키텍처를 레퍼런스하면서 다양한 프로젝트 설계도의 장단점을 토론해 보면 좋을 것 같습니다.
• API 명세 - 개발하는 과정에서 수정이 일어나는 API 명세는 팀 노션에 즉각적으로 수정을 해주고, 팀원들에게 공유함으로써 변경되는 내용에 대한 대응이 유연할 수 있도록 문서 업데이트 개발 문화를 지향하도록 하면 좋을 것 같습니다.
• 트러블 슈팅 - 트러블 슈팅이 발생하였을때 체계적으로 문서화하여 작업할 수 있는 습관을 지향하도록 하면 좋을 것 같습니다. 다른 팀의 트러블 슈팅 기록을 참고하여 트러블 슈팅 문서 템플릿화를 한 후, 개발 진행을 하며 중간에 수시로 기록할 수 있도록 하겠습니다.
• ERD - ERD를 설계하기 전 모든 구현 내용을 펼쳐놓고, 어디까지 구현할 것인지, 해당 내용에 필요한 것은 무엇인지에 대해 면밀하게 검토하고 작성하여 후에 ERD, DB를 수정하는 작업이 발생하지 않게 하기로 했습니다.
• 개발 - 프로젝트를 진행하며 특정 기능이 추가될 경우, 해당 기능이 왜 우리 프로젝트에 필요한가? 오버 엔지니어링은 아닌가? 다른 기능과 중복되는 것은 없는가? 에 대해 면밀히 조사하고, 고민한 뒤 적용 시키는 방향으로 개발을 하기로 했습니다.
• 커뮤니케이션 - 함께 성장해 나가고 있는 과정에서 발생하는 성장통이라 생각합니다. 시간이 지나가며, 협업을 지속적으로 진행해 보는 과정에서 필요한 함수에 대해 서로 공유하고, 우선순위를 서로 맞춰 나갈 수 있을 것이라 생각합니다.
• 개발 - 밀린 강의를 듣고, 최대한 공부에 시간을 써봐야 할 것 같습니다.