TMProject (Today Menu)

---

프로젝트 개요

프로젝트 소개

"오늘 뭐 먹지?"라는 질문은 모두에게 공통적인 고민일 것입니다. 이런 고민을 해결하기 위한 방법 중 하나가 저희의 웹사이트에 오늘의 메뉴를 공유하는 것입니다. 이를 통해 저희는 매일 무엇을 먹었는지, 어떤 식사를 즐겼는지를 서로 공유할 수 있습니다.

이러한 공유는 단순히 메뉴 선택에 대한 고민을 덜어주는 것뿐만아니라 뭘 먹는지를 공유함으로써, 우리는 서로의 일상을 이해하고, 다른 사람들의 식사 스타일을 알수있습니다.

그러므로 저희의 웹사이트에 매일 우리의 식사를 공유하는 것은 단순히 '오늘 뭐 먹지?'라는 고민을 해결하는 것 이상의 가치를 가지고 있습니다. 그것은 우리의 식사로서 일상을 공유하고 그 사람에 대한 이해도 높일수 있는 그러한 SNS서비스가 될수있습니다.

기능

---

• 사용자 인증 기능

  • 회원가입 기능
    • 계정정보 규칙 적용
  • 로그인 및 로그아웃 기능
    • JWT 활용
    • 사용자는 자신의 계정으로 서비스에 로그인하고 로그아웃 가능

• 계정 관리

  • 프로필 수정 기능
    • 이름, 한 줄 소개와 같은 기본적인 정보 수정
    • 비밀번호 규칙 적용

• 게시물 CRUD 기능

  • 게시물 작성, 조회, 수정, 삭제 기능
    • 게시물 조회를 제외한 나머지 기능들은 전부 인가(Authorization) 개념이 적용되어야 하며 이는 JWT와 같은 토큰으로 검증 가능.
    • 오로지 본인만 게시글 수정/삭제 가능.

• 댓글 CRUD 기능

  • 댓글 작성, 조회, 수정, 삭제 기능
    • 댓글 조회를 제외한 나머지 기능들은 전부 인가(Authorization) 개념이 적용되어야 하며 이는 JWT와 같은 토큰으로 검증 가능.
    • 오로지 본인만 댓글 수정/삭제 가능.

• 좋아요 기능

  • 게시물 및 댓글 좋아요/좋아요 취소 기능
    • 사용자가 게시물이나 댓글에 좋아요를 남기거나 취소할 수 있어야 합니다.
    • 이 때, 본인이 작성한 게시물과 댓글에 좋아요는 남길 수 없도록 해본다.

• 팔로우 기능 구현

  • 특정 사용자를 팔로우/언팔로우를 할 수 있으면 너무 좋습니다.
  • 팔로우 기능이 구현되었다면 팔로우하는 사용자의 게시물을 볼 수 있어야 한다

---

역할 담당

• 진유록

  게시물 CRUD 기능,댓글 CRUD 기능

• 문정현

  좋아요 기능,팔로우 기능

• 박지환

  사용자 인증 기능,계정 관리

팀소개

6시에 밥먹조?

팀 이름이 6시엔 밥먹조???

1. 일정한 시간에 식사를 하는 것은 생활 패턴의 규칙성을 의미하죠.
   팀의 업무도 일정하고 규칙적으로 진행됨을 상징합니다!

2. '밥 먹는 시간’을 정해둠으로서 팀원들이 함께 정확한 시간적인 소통하는 것입니다!
   (ex:6시에 저녁 맛있게드세요 라며 일상적인 대화를 할수있음을 의미합니다).
   팀워크의 중요성과 서로간의 소통을 강조합니다.

3. '6시'라는 시간은 일반적으로 저녁전의 하루 마무리 시간으로 봅니다.
   그렇다면 하루를 마무리 짓는 중요한 시간을 정해둠으로서
   어느정도의 계획을 마무리했는지 돌아보며 남은 할일들을 생각하는 시간을 가질수 있습니다.

4. '빠르게 많은 걸 하자'는 목표에 따라,
   '6시엔 밥먹조'는 효율적이고 빠르게 일을 처리하여
   6시에는 모두가 밥을 먹을 수 있는 시간이 되도록 하자는 의미이기도 합니다.

5. 밥이라는 것은 우리의 일상에 중요한 부분이기에
   서로에게 도움이 되고 서로에게 중요한 사람이 되자는 의미를 가지고있습니다.

   따라서 이 이름은 "규칙적이고 효율적인 업무 진행",
   "팀워크와 소통의 중요성",
   "하루를 마무리 지으며 하지 못한 일들을 생각하며 수행" ,
   "서로에게 의미있는 팀원이 되자" 라는 많은 의미를 담은 팀명입니다!
   절대 가볍게 지은것이 아니란 말입니다!

Keep

• 체계적인 Git 사용: 각각 기능에 맞는 브랜치를 사용하여 서로 겹치지않고 각각의 맡은바를 완벽히 할수있게 되었다.
• 꾸준한 기록 유지: 오류들이 발생할떄마다 기록을 하여 어떠한 오류가 있었는지 어떻게 해결했는지 팀원들과의 공유
• 적극적인 소통 : 누구하나 빠지지않고 많은 소통을 나누며 오류를 겪으며 서로가 도와주며 해결하는 문화를 구축
• 목표 달성: 해당 역할을 적절히 분담하여 각자의 역할을 다 했고 이에 처음에 설계했던 목표보다 많은 성과를 이루어내며 달성
• 피드백 문화 구축 : 지속적인 피드백 공유를 통해 서로의 오류를 찾아주고 발전해 나아가는 문화 구축

Problem

• 트랜잭션 성능 최적화 :너무 길거나 복잡한 트랜잭션은 데이터베이스 리소스를 과도하게 점유하고, 시스템의 성능을 저하시킬 수 있다.특히 대용량 데이터 처리나 높은 동시성 요구 사항이 있는 애플리케이션에서 성능 저하가 두드러질 수 있다.
  
• 트랜잭션 경계 설정 : 경계가 명확하지 않거나 잘못 설정되면, 예상치 못한 방식으로 데이터베이스 상태가 변경될 수 있다. 예를 들어, 하나의 트랜잭션 내에서 수행되어야 할 여러 작업들이 서로 다른 트랜잭션으로 분리되어 처리되면 데이터 무결성에 문제가 생길 수 있다.
  
• [JUnit] Argument(s) are different! Wanted : Mockito를 사용해 단위 테스트를 작성하다가, 예상한 인자와 실제로 전달된 인자가 다를 때 발생한다.
  이는 mock 객체와 실제 객체를 혼용하거나, 
  메서드 호출 시 인자의 순서와 타입이 예상과 다를 때 일어난다
  
• Count query validation failed : Pageable 객체를 파라미터로 사용하는 JPA Repository에서 
  Page<Board>와 같은 페이징 처리를 추가할 때 발생한다. 
  @Query 어노테이션으로 커스텀 쿼리를 작성하고 있지만, 
  복잡한 쿼리에서 Count 쿼리를 스프링 데이터 JPA가 정상적으로 생성하지 못할 때 이런 문제가 생긴다.
  
• 공유 자원 처리

Try

• 트랜잭션 성능 최적화
  • 작업 최적화: 트랜잭션 내에서 수행되는 각 작업의 효율성을 높인다. 예를 들어, 불필요한 데이터베이스 조회를 최소화하거나, 쿼리 최적화를 통해 데이터베이스 응답 시간을 단축시킨다.
  • 트랜잭션 분할: 큰 트랜잭션을 여러 개의 작은 트랜잭션으로 분할하여 각각 독립적으로 처리한다. 이 방식은 특히 배치 처리나 대용량 데이터 처리에 유용하다.
  • 캐싱 전략 사용: 반복적으로 동일한 데이터에 접근하는 경우, 캐시를 사용하여 데이터베이스 접근을 최소화한다. 이는 응답 시간을 단축시키고 데이터베이스 부하를 줄이는 데 도움이 된다.
  • 비동기 처리 고려: 가능한 경우, 비동기 처리를 사용하여 트랜잭션의 처리 시간을 단축시킨다. 예를 들어, 사용자 응답과 무관한 데이터 처리는 비동기 방식으로 처리하여 사용자 경험을 개선할 수 있다.
• 트랜잭션 경계 명확화: 각 트랜잭션의 시작과 끝을 분명하게 정의한다. 이는 데이터베이스 작업의 일관성과 무결성을 보장하는 데 필수적이다.
  • @Transactional 사용: Spring 프레임워크에서는 @Transactional 애너테이션을 사용하여 트랜잭션 경계를 설정한다. 이 애너테이션을 클래스나 메소드 레벨에 적용하여 해당 범위 내의 모든 데이터베이스 작업을 하나의 트랜잭션으로 묶을 수 있다.
• [JUnit] Argument(s) are different! Wanted Mock 객체와 실제 객체를 혼용하지 않도록 주의한다.
  메서드 호출 시 인자의 순서와 타입이 예상과 일치하는지 확인한다.
  기본 타입(long, int 등)과 래퍼 클래스(Long, Integer 등)를 혼동하지 않도록 주의한다.
  
• Count query validation failed @Query 어노테이션을 사용해 직접 Count 쿼리를 제공한다.
  예: @Query(value = "쿼리문", countQuery = "Count 쿼리")
  @EntityGraph 어노테이션을 사용한다. 
  @EntityGraph는 기본적으로 Fetch join을 사용하며, N + 1 문제도 방지한다..

팀원별 느낀점

진유록

백엔드에서의 CRUD 기능 구현과 HTML 구조 설정에 중점을 두었습니다. 프로젝트의 주된 목표는 효율적인 백엔드 구조와 사용자 친화적인 프론트엔드 인터페이스를 조화롭게 통합하는 것이었습니다.

백엔드 개발에서 가장 주요한 작업 중 하나는 데이터 처리와 관련된 트랜잭션의 관리였습니다. 트랜잭션 처리의 중요성을 깊이 인식하는 기회를 가졌습니다.

프론트엔드 개발과 관련해서는, HTML 구성에는 성공적으로 다가갔으나, AJAX와 JavaScript를 활용한 비동기 통신과 사용자 인터페이스의 동적 업데이트 구현에 어려움을 겪었습니다. 이러한 과정에서 프론트엔드 개발의 복잡성을 체감하고, 특히 실시간으로 화면을 갱신하는 기능 구현에 대한 도전을 경험했습니다.

팀원들과의 협업은 이 프로젝트의 또 다른 성공 요인이었습니다. 각자의 역할이 명확히 분담되어 있었고, 코드의 통합과 버전 관리에서의 원활한 협력을 통해 프로젝트의 진행을 원활하게 유지할 수 있었습니다. Git을 사용한 버전 관리는 코드의 안정성을 보장하며 변경 사항을 효율적으로 관리하는 데 크게 기여했습니다. 더불어, RESTful API 설계와 같은 백엔드 개발 작업에서 협업 능력을 강화하는 중요한 기회가 되었습니다.(난 한것이 없는거 같은데 완성된거같은느낌…)

이 프로젝트를 통해 다양한 문제를 직접 경험하고, 해결하기 위한 다양한 접근 방식을 시도해볼 수 있었습니다.

문정현

어쩜 이리도 훌륭한 팀원들을 만났는지 저는 성불할것 같습니다
security 뚝딱뚝딱 만드는 지환님 정말 멋있어요 (나도 시큐리티 잘하고 싶어요!)
또 수많은 api 샤샥 만들어서 그 많은 api 테스트 코드 작성을 했는데 프론트쪽 마크업까지 만드는 유록님(당신은 잠도 없습니까?)
부족한 저랑 같이 프로젝트 진행하느라 수고하셨고 팀원분들게 감사하고 또 감사합니다 다들 멋진 개발자로 거듭날 것임이 틀림없습니다.

박지환

유록님 : View부분 작성하느라 고생 많으셨습니다. 디자인 관련해서 한수 배우고 싶을 정도로 예쁘게 만들어주셨고 그 외에도 맡은 역할 잘해주셨고 분위기 많이 업 시켜주셔서 감사했습니다!

정현님 : 이번에 Test code 작성하고 트러블 슈팅 쓰신거 봤는데... 와 진짜 고민 많이 하신 티가 나더라고요... 제가 너무 초라해져서 그만 말씀드리겠습니다 ㅋㅋ

제가 고민을 많이 하는 탓에 코드를 작성하는 속도가 좀 느려서 답답했을지도 모르겠다는 생각 많이 했습니다... 그래도 정현님, 유록님께서 많이 도와주셔서 제가 맡은 역할을 완수하는데 성공하지 않았나 싶습니다. 두 분 다 너무 고생 많으셨습니다!