세미프로젝트, 파이널프로젝트 2번의 팀프로젝트를 경험하면서 지난 프로젝트의 느낀점과 설계과정 등에 대한 내용을 정리 할 필요성을 느꼈다. 이러한 개발과정을 개발일지를 통해 시리즈로 편찬하면서 어떤 생각과 과정으로 개발했는지 다시 되돌아보려고 한다.
그리고 추가하고 싶은 기능은 여기다가 남겨서 기록하려고 한다.
개요
1. 협업도구는 무엇으로 할까?
- ERDCloud
2. DB설계 시 고려사항
3. 느낀 점
4. 참고
1. 협업도구는 무엇으로 할까?
협업도구 필요조건
1. 6명이 모두 공유할 수 있을 것
2. 언제든지 수정, 확인이 가능할 것
3. 사용방법이 어렵지 않을 것
DB설계는 언제든지 수정할 수 있는 도구가 적절하다. 그래서 세미프로젝트에 사용했던 ERDCloud를 그대로 사용했다. 6명이 동시에 수정과 공유가 가능했기 때문에, 실시간으로 의견을 반영할 수 있었고 기억해야 될 부분은 메모를 통해 기록으로 남겼다.
- 장점 : 6명 동시공유가 가능하다. 메모장 기능. 실시간으로 수정 가능하다. 공개/비공개를 선택할 수 있다.
- 단점 : 사용 설명이 좀 부족하다는 점. 모든 테이블 작성 시 엔터를 꼭 해줘야 한다는 점.
이건 내가 부족한 점이기도 하지만, ERDCloud는 DB 상관관계에 대한 설명이 부족하다. 기본적으로 사이트가 영어로 구성되어있고, 상관관계 아이콘에 대한 설명이 부족해서 이해하기 어려웠다. 유투브는 간단한 활용부분만 나와있고, 세세한 부분은 나와있지 않아서 처음에 좀 헤맸다. 팀원들도 상관관계에 대해 정확하게 이해하진 못했다. 하지만 아이콘이 직관적이고 간단하기 때문에 Primary Key, Foreign Key만 정확히 쓸 줄 안다면 이용하는데 어렵지는 않다.
기본적으로 오픈라이브러리로 되어있고, 팀으로 만들 경우에는 공개로 만들어진다. 이 덕분에 사람들이 만든 라이브러리를 마음껏 구경할 수 있다!!
특히 우리처럼 초보자들에겐 잘 만들어진 DB 정보가 부족했기 때문에, 몇몇 게시판을 참고할 수 있어서 좋았다.
하지만 검색어가 '제목'에 한정되어 있기 때문에, 만약 '게시판'으로 만들지 않은 DB는 검색되지 않는다....ㅜ
우리팀만 해도 팀프로젝트명으로 만들어서 검색에 나타나지는 않기 때문에..
추후에 DB테이블도 검색되는 기능이 만들어졌음 좋겠다.
2. DB설계 시 고려사항
나는 좋은 DB란 복수된 부분이 없고, 최대한 사용하기 쉽게 만들어져야 좋은 DB라고 생각한다. 두 번의 프로젝트 모두 DB를 수없이 고쳤음에도 불구하고, 막상 프로젝트에 들어가면 수정을 거듭했다.
이번 포스팅을 통해 DB설계 시 고려해야 할 사항을 내가 느꼈던 점으로 정리해보고자 한다.
화면 설계는 꼼꼼하게 하자
제로웨이스트 쇼핑몰을 주로 참고하여 원래있던 기능에서 보완하는 쪽으로 목표를 잡았다. 팀원들도 의욕이 넘쳐서 새로운 기능을 추구하는 부분이 많았다. 언제나 목표는 높게 잡는 한국 사람!!^0^..
실제로 어떻게 구동되는지 하나도 몰랐기 때문에, 백엔드 부분인 관리자는 감으로 스케치했다^^...
이 감은 얼마 지나지 않아 잘못되었다는 것을 깨달았다...
대충 이렇게 구현되겠지라고 생각하는 것은 마치 혼자서 오리배를 타는 심정이랄까... 혼자서 삽질은 열심히 하지만 앞으로 나아가지 않는다ㅜ..
화면 설계는 아주 꼼꼼하고 세세하게 해야한다. 나는 아래와 같이 구매평 작성을 눌렀을 때, 제품 1개만 구매했을 경우 구매평 작성이 뜨고 여러 개 구매했을 경우는 구매내역을 선택하는 화면이 뜨도록 설계했다. 구매내역을 선택하면, 구매평을 쓸 수 있는 화면이 뜬다.
즉, 이 화면을 누르면 다음 화면이 어떻게 나오는지 세세하게 다듬어야 한다.
나는 구매평때문에 애를 많이 먹었는데, 처음에 구매평 작성 시 단순히 구매평을 작성하는 것만 생각했지 구매평을 어디서 눌러서 구매평 작성화면으로 넘어가는 지를 생각하지 못했다. 이런 사소한 것 때문에 시간을 많이 잡아먹기도 했고, 이후 구매평 작성조건 때문에 DB를 수정하기도 했다.
화면에 있는 정보가 다가 아니다
위는 주문하기(장바구니) 화면으로, 결제하기를 눌렀을 때 현재 화면을 어떻게 넘겨야될지 고민했다. 선생님은 현재 화면을 DB에 저장하지 않고 HTML로 넘기라고 말씀하셨고, 나포함 팀원들 모두 간단히 그렇구나 하고 넘어갔다.
그런데 막상 화면을 설계하고보니 주문하기에 각 제품의 정보를 끌어와야 되고, 수량, 가격, 할인 등을 표시해야 되는데 이걸 구현하려면 DB에 정보를 저장해야했다.
주문하기뿐만 아니라 주문하기, 결제하기, 배송지, 주문내역 관리 등등..단순히 생각나는 것만 나열해도 이 정도로 나온다. 즉, 주문을 하게 될 경우 장바구니부터 주문내역 관리까지 이 모든 내용을 저장하고 관리해야한다.
사용자 입장에서는 보이지않는 백엔드는 이 모든 것을 관리해야 한다.
테스트 계정 DB를 만들자
위에서도 말했다 싶이 나는 구매평에서 애를 먹었는데, 막판까지 구매평 DB를 수정하느라 시간을 좀 소요했다. 몇 가지 이유가 있었는데, 다음과 같다.
- 구매평을 한 번 작성하면, 다시 작성 할 수 없다.
- 구매평을 언제 작성할 수 있게 할 것인가?
- 구매평을 수정하거나 삭제 할 경우, 적립금은 어떻게 할 것인가?
- 한 제품에 여러개 구매를 한 경우, 어떤 구매평을 작성하게 할 것인가?
처음에는 이 요소를 다 고려하지 못했다. 아마 고려하면 더 많은 조건이 나올 수도 있을 것 같다.
DB를 고쳐야 하는데, 팀프로젝트라 하나를 고쳐서 잘 못 되면 일이 커질 것 같았다. 그리고 실제로도 일이 커지기도 했다!!
그래서 나는 테스트 계정을 만들어 더미데이터로 이상이 없는지 확인한 뒤, 팀원들에게 의견을 구하고 본 계정에 추가했다. 시간이 다소 걸리기는 했지만, 위에 걸었던 조건은 해결할 수 있었다.
3. 느낀 점
실제로 본 DB에 새로운 기능을 추가한다는 것은 꽤나 부담이라고 한다. 그래서 배달의민족 개발자는 토이프로젝트를 적극 권장한다고 한다. 이런 과정이 일종의 테스트 역할은 한다는 것이다. 나도 이번 프로젝트를 하면서 혼자 만들어봤던 기능을 넣어봤다가 나중에 빼본 경험이 있다. Ajax를 한 번도 안 써봐서 어떻게든 JavaScript로 해결해보려고 했다.
그런 과정에서 JSP랑 Controller를 얼마나 갈아엎었는지 모르겠다... (소위 삽질)
근데 그 과정이 없었다면, Ajax도 못 해봤을 것이고 찜하기는 엄두도 못냈을 것 같다.
실무를 간다면 화면부터 설계 그리고 구현에 이르기까지 전 과정이 이렇다는 대략의 감을 익힌 것 같다.
4. 🤗참고
