Skip to content

2miri/springboot-final-project

Repository files navigation

집주인 몰~래 복덕복덕

[프로젝트소개]

세상에 집이 이렇게나 많은데 도대체 내가 살 집은 어디있는걸까?

여러분들의 발품을 최소한으로 하기 위한 익명의 자취방 리뷰 사이트!

인증을 통하여 실제 거주했던 분들만 리뷰 게시글 작성이 가능합니다

가감없는 자취방 리뷰를 참조해보세요

[개발 환경]

IDE : IntelliJ

Springboot 2.5.6

Project Type : Gradle

JDK11

Dependencies

  • Database : H2
  • Web / JPA / Security / Thymeleaf / OAuth2 / Mail / Lombok

프로젝트 인원 : 5명

프로젝트 기간 : 4주

[본인이 맡았던 기능 소개]

각자 기능을 맡았던 페이지들은 CSS까지 모두 담당하였습니다.

  • 웹사이트 이름 & 로고
  • 로그인
  • 아이디 찾기
  • 리뷰페이지 목록
  • 관리자페이지 (승인/거부)

[프로젝트 시연 영상]

[프로젝트 사용 화면]

▲ 메인페이지

검색창은 리뷰 페이지와 동일한 검색결과로 처리됩니다.

인기있는 리뷰글 (회전목마 형식) / 커뮤니티 인기글 / 자취방 꿀팁을 좋아요순으로 보여줍니다.

▲ 회원 가입

▲ 로그인

▲ 일반회원 로그인했을 때의 메인 화면

부트스트랩을 이용하여 프로필 바를 구현했습니다.

▲ 리뷰글 목록 (기본)

관리자가 승인한 리뷰글만 보이도록 합니다.

게시글 페이징은 무한스크롤 형식입니다.

하트를 누르면 좋아요 또는 좋아요 취소가 적용됩니다.

▲ 리뷰글 목록 (검색 옵션창을 눌렀을 때)

검색에서 옵션을 누르면 지역, 방형태 등 원하는 리뷰에 관련된 카테고리를 선택 할 수 있습니다.

옵션 / 포토리뷰 / 정렬은 각각의 기능을 누르면 바로 화면이 변환되도록 AJAX로 처리했으며,

선택한 카테고리/포토리뷰/정렬 모두 적용된 채 키워드 및 태그로 검색 가능합니다.

▲ 리뷰글 읽기 / 수정 / 삭제

지도 API를 이용하여 리뷰에 작성된 주소의 지도를 불러옵니다.

댓글과 대댓글 기능을 구현

▲ 리뷰글 쓰기

리뷰에 관련된 사진을 올리면 작성자가 바로 이미지를 보기 또는 삭제 할 수 있습니다.

▲ 관리자로 로그인했을 때의 메인화면

관리자로 로그인하면 관리자페이지라는 메뉴가 추가적으로 보입니다.

▲ 관리자페이지

사용자가 리뷰글을 작성하면 바로 리뷰 목록에 게시되는 것이 아니라

승인 대기 상태가 됩니다.

관리자는 승인 대기 상태인 게시물에 승인 / 거부 처리를 하고

승인이 됐을 때만 리뷰 게시판에 글이 보입니다.

▲ 관리자일때 리뷰 게시물 보기

일반 회원은 보이지 않는 리뷰 작성자가 글을 작성할때 해당 건물에 거주했는지에 관한 인증 파일이 보입니다.

인증 파일과 해당 글의 내용을 검토하고 승인 / 거부를 결정합니다.

▲ 커뮤니티글 목록

페이징처리를 하였으며, 검색 / 카테고리선택 / 정렬 기능이 있습니다.

▲ 커뮤니티글 쓰기

▲ 마이페이지

개인정보 변경, 내가 쓴 글(리뷰/커뮤니티), 로그아웃, 회원탈퇴

▲ 비밀번호 변경

▲ 아이디 찾기

[팀프로젝트를 하면서]

만족스러운 점

  1. 팀 회의를 하며 정했던 내가 맡은 페이지의 기능 그대로 구현하기
  2. 각각의 페이지를 정해진 기한내에 완수하기

이 두가지를 중요하게 생각하며 프로젝트를 시작했는데, 이것을 이룬것이 가장 만족스럽다.

힘들었던 점

  1. 여러 카테고리 중복 적용

    카테고리 갯수가 많지 않고 단일 선택이라면 레파지토리에서 findAllBy@ 이런식으로 간단하게 DB상에 검색이 가능하게 하면 되지만, 집 이라는 매개체의 특성상 방크기,건물,계약 등등 카테고리가 많고

    findAllBy@and@and@and... 이런식으로 하기에는 너무 길고

    가장 중요한건 사용자가 어떤 카테고리를 누를지 모르는데 총 22개의 카테고리를 경우의 수 별로 모두 메서드를 만들 수가 없었다.

    그러다 Spring Data JPA의 Specification을 알게 되었다.

    이 객체를 통해서 검색 조건을 추상화 할 수 있었다.

    리턴 자료형을 Specification<@>으로 두는 메서드를 만들고 해당 메서드 내부에서는 list와 switch문 그리고 자료형 Predicate를 이용해 알맞는 검색조건에 추가하는 방식으로 구현했다.

    Specifications을 사용하면 두개 이상의 specfication을 and나 or등으로 조합 할 수 있다.

    이것을 이용하여 레파지토리에서 findAll 메서드의 매개변수로 넣어주기만 하면 된다.

    예. findAll(Specification spec)

  2. AJAX

    AJAX를 진행할 때 이미지나 a태그를 교체하는 등의 간단하게 바꾸는 것은 어렵지 않았지만,

    무한스크롤을 할 때 페이징 처리를 하고 그 페이지에 해당되는 내용들의 게시물 목록을 불러와야 할 때 구글링을 아무리 해봐도 JSON으로 데이터를 넘기고 받아서 "@@@" + data + "@@@" 이런식으로 모두 하나하나 타이핑을 해야하는 방법이 대다수였다.

    게시글에 부트스트랩도 입혀야해서 모두 작성하기에는 너무 길고 비효율적이라 생각하였고, 나는 이미 만들어둔 게시판 목록의 div내의 thymeleaf양식을 그대로 쓰고 해당되는 data만 바꾸길 원했다.

    구글링, 유튜브, 까페 등 여러 곳에서 될 것같은 것들을 긁어모아

    Json이 아닌 ModelAndView로 넘기면 된다는 것을 찾고, 해당되는 게시글들의 페이징의 내용들을 담당하는 div를 통째로 복사하여 html파일을 따로 만든 후에 스크롤을 내릴때마다 append해주었다.

  3. 타임리프

    타임리프는 에러가 발생하면 에러메세지가 정확히 나오지 않을 때가 대부분이라 문법의 어떤 부분에서 에러가 났는지를 몰라서 문법을 모두 하나하나 보느라 굉장히 고생했다.

아쉬운 점

부트스트랩을 사용하여 더 예쁘고 트랜디하게 꾸미고 싶었는데

깔끔하게 꾸미는 것만으로도 시간이 많이 소요되어 아쉽다.

마감을 지키지 못하고 맡은 기능을 거의 구현하지 못한 사람이 있어서

급하게 다른 팀원들이 나눠서 맡았는데 시간이 너무 촉박했다.

처음 사이트를 만들자고 계획했던 전체적인 그림에서 빠진 기능들이 많아서 아쉽다

느낀 점

미니프로젝트 때에는 겹치는 부분이 없어서 느끼지 못했는데

팀프로젝트는 나만 열심히 한다고 되는 게 아니란 걸 깨달았다.

중간 마감일자에 각자 진도 상황을 보면 기능을 꼼꼼히 체크하지 못해 완성도가 떨어지는 분이 있는가 하면

진도를 정말 안나가고 여유롭게 하시는 분도 있었다.

내가 맡은 페이지를 기한 내에 다 해도 다른 사람들의 기능이나 디자인을 같이 체크해주느라 시간이 굉장히 촉박했다.

팀원들과 조율과 협업이 정말 중요하고 서로의 진도를 생각보다 자주 체크해야한다고 느꼈다.

그래도 결국 프로그래머는 자기 자신과의 싸움이다

내가 맡은 기능을 해내지 못하고 기능 구현을 줄이거나 바꿔버리면 프로젝트는 이마저도 완성하지 못했을 것이다.

진짜 열심히했고 내가 원래 맡았던 기능들은 모두 해내서 뿌듯하다.

About

메가아이티 파이널 프로젝트 - 자취방 익명 리뷰사이트

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors