여행 정보를 필요로 하는 사람들이 늘어나고 직접적인 여행을 가는 방법 대신 간접적인 경험을 할 수 있고 직접 가지 않더라도 그나라의 기념품을 교환해 간접적인 정서와 욕구를 모두 채울 수 있도록 커뮤니티를 제공하고 사용자의 편의를 도모함.
코로나로 인해 여행에대한 사람들의 인식 변화로 가고싶은 호기심과 막연한 두려움 사이에서 어려움을 겪고 있고 여행 자체에 대한 정보와 여행품(기념품)에 대한 열망을 원하는 사람들이 늘어남
- 23.04.14 - 23.05.02
- 팀장 : 이민형 - 마이페이지
- 부팀장 : 허은상 - 여행기, 헤더푸터,검색,여행일지 작성폼
- 팀원1 : 김도은 - 추천루트,여행품
- 팀원2 : 김진영 - 로그인,회원가입
- 팀원3 : 정아영 - 관리자페이지
- 팀장 : 이민형 - 메인페이지, 로그인,회원가입
- 부팀장 : 허은상 - 관리자페이지, 공지사항
- 팀원1 : 김도은 - 여행기
- 팀원2 : 김진영 - 마이페이지
- 팀원3 : 정아영 - QNA
여행일지를 작성하고 정보를 공유하며 여행품 교환을통해 간접적인 여행경험에 기여함
- 사용자의 여행일지 작성을 통한 다이어리 기능
- 다양한 사람들의 다양한 여행공간을 통한 정보 공유
- 여행품 교환을 통한 커뮤니티 형성
- 비싼 비용을 들이지 않고 여행 정보와 간접적인 경험을 누구나 느낄 수 있음
- java
- jQuery
- HTML, CSS, JS
- MySQL
- JDK 11.0.15
- JSON
- Sourcetree
- DBeaver
- Eclipse
- git, gitHub
- 프로젝트 부팀장, 서비스 기획 및 전반적인 구성, 엔티티(ERD) 설계
- 퍼블리싱 업무 : 여행기, 헤더푸터,검색,여행일지 작성폼
- 백엔드 업무 : 관리자페이지, 공지사항
- 여행기 목록
- 여행기 작성 폼
- 검색 시 홈 화면
- 여행기 상세보기
- 공지사항
화면 구성
- 회원 관리 (목록, 상세보기, 검색, 삭제)
- 여행기 관리 (목록, 상세보기/수정, 검색, 삭제)
- 공지사항 관리 (목록, 상세보기/수정, 검색, 삭제)
flow-chart
일단 가장 큰 느낀점은 JSP에 한계를 많이느꼈다.
JSP는 .jsp파일을 Jasper가 서블릿으로 변경해 화면까지 띄워주는 기술이다.
웹을 개발하는 패턴은 여러가지가 있지만 그 중 가장 보편적인 패턴인 mvc2 패턴으로 개발을 진행했다.
이 때 frontcontroller를 만들어 하나의 관계된 서비스를 컨트롤러 메서드를 사용해 처리를하고 다음 주소를 리턴하는 식으로 구상했는데 기능이 많아지면 frontcontroller 가 너무 길어지고 수많은 분기처리를 if문 또는 case문으로 해야하는 불편함이 존재했다.
또한 컨트롤러 부분에서도 request객체가 초기화되는 redirect 방식으로 다음 페이지를 연결할때 데이터를 주고받는 방식이나 ajax를 이용해 페이지이동없이 비동기 데이터 통신을 진행할때도 out객체를 써야하는 불편함이 존재했다. 그리고 모든 부분에서 Ouath 사용이 힘들거나 api 적용에도 제한이 많음을 느꼈다.
추후 스프링을 사용한 개발에서 jsp의 한계를 극복하고 더 많은 공부를 통해 더 많은 기능을 추가하고 구현하고 싶었다.
프로젝트 구상중 어려웠던 부분은 엔티티를 설계할 떄 존재했다.
우리는 세개의 게시판이 존재해 각각 게시판 테이블을 만들어 db를 설계했으나 첨부파일쪽에서 어려움을 겪었다.
모든 게시판 테이블은 첨부파일을 여러개 받을 수 있도록 구상했는데 슈퍼키와 서브키의 개념을 잘 알지 못해 반정규화로 진행하고자 했고 그럼에도 중복은 제거하고 싶어 FileVO테이블에 boardId와 boardType 을 받아 각 게시판 타입과 게시판 id로 연관짓자고 생각했다.
처음엔 그래서 boardType컬럼과 boardId컬럼 한개씩만으로도 충분하다고 생각했는데 실제로 테이블을 만들고 사용할 때 보니 한 컬럼에 여러개의 fk설정이 불가했다.
그래서 boardType이 아닌 각 게시판 테이블마다 fk로 받을 컬럼을 모두 추가했어야했다.
이 때 해결을 할 수는 있으나 모든 fk에 null값을 허용하고 정확히 한개의 컬럼만 값이 들어오고 나머지는 null값이 들어가도록 설계를 바꿔야했다.
db테이블에 null값이 허용된다는건 그리 좋지 않은 설계 방식이라고 생각한다.
먼저 설계 문제를 해결하기 위해 여러가지 공부를 통해 방법을 제시했고 그중 가장 좋은 방식은 각 게시판별로 파일테이블을 한개씩 만들어 1:1매칭을 해주는 것이였다.
엔티티를 설계할 때 연관관계의 1:1,1:N의 관계가 중요한데 1:N의 관계에선 컬럼으로 추가할 수 없고 연관테이블을 만들어야한다. 그래서 파일테이블을 각 게시판별로 세개를 만들어 1:N관계를 1:1테이블 매칭으로 만들어 하려고 했으나 각 게시판마다 파일은 똑같이 사용하는 엔티티라서 합칠 수 있는 방법은 없나 찾아보다 슈퍼키와 서브키를 찾았다.
슈퍼키와 서브키 방식은 공통된 컬럼을 묶은 테이블 하나를 만들고 각각이 따로 사용하는 컬럼은 서브키를 받은 테이블에서 정의해 부모자식의 상속관계처럼 사용하는 방식이다.
하지만 우리 프로젝트 같은경우 각 테이블이 모두 같은 컬럼을 사용하기 때문에 슈퍼키와 서브키보단 각 테이블별로 한개씩 1:1매칭 테이블을 만들어주는것이 조금더 좋은 방식이였다.
다음번엔 게시판자체에 공통된 요소들은 묶은 슈퍼테이블을 만들고 각 게시판마다 기능이 다른 부분만 컬럼으로 추가해 슈퍼키와 서브키방식으로 게시판 자체를 설계할 것이다.
우리는 모두가 프로젝트도 처음이고 사람도 적은 편이었다. 그래서 난항이 예상되고있었다.
그속에서 나는 어떡하면 모두가 협업의 능력을 끌어올릴 수 있을까 고민하다 대부분에 사람들이 깃허브나 깃사용할때 어려움을 겪는것을 깨닫고 혼자 찾아보고 정리하여 모두한테 오류가나거나 컨플릭났을 때 해결할 수 있도록 자료를 제공했다
또한 소심해서 어려움을 겪는 사람과 개인적인 대면을 통해 협업의 중요성을 같이 공유하고 적극적으로 참여하게 도와 제가 아니였다면 중간에 반드시 그만뒀을꺼다라는 말도 들었다.
슬랙을 통해여 서로 더 소통할 수 있도록 소통의 장을 만들고 혹시나 충돌이 생기면 중간에서 중재자 역할을 하며 팀을 이끌어 나갔다.
개발을 처음 시작할 땐 개인의 역량이 중요하고 개인적인 성향이 강한 직업이라고 생각했는데 항상 소통이 중요하다는 말을 뼈저리게 느끼며 같이 협업하고 공유할때 일의 효율과 성과는 두배 아니 그이상으로 뛴다는 것을 크게 느꼈다.
앞으로도 적극적으로 대화의 장을 열고 협업을 통해 일의 효율과 성과를 극대화 할 것이다.
코딩을 처음 시작한지 4개월정도 지난 시점에 첫 프로젝트가 진행되었고 너무 하고싶은것도 많고 구현해보고 싶은 기능도 많아 기대에 부푼 나머지 어려운 구현과 협업 그리고 각종 변수들에 대해 생각하지 못하고
너무많은 기능을 설계하고 어려울 수 있는 기능들을 설계해 팀원들이 힘들어 하는 모습을 보고 항상 욕심이 과해서 좋을건 없다고 생각이 들었다. 한정된 시간과 협업을 해야하는 프로젝트에서 내 욕심으로 프로젝트의 완성도가 떨어진 것 같아 팀원들에게 매우 죄송했고 나에대해서 돌아보게 되었다.
다음번 프로젝트에는 조금더 대화를통해 가능성을 생각하고 프로젝트 완성도를 높일 것이다.