프로젝트 소개 및 회고, 강사님 피드백

프로젝트 소개

https://github.com/Jyebin/shinhan_team2_omok

목적

• 웹 소켓을 활용한 실시간 오목 게임 구현 및 웹 소켓 공부
• 수업 때 배운 JSP, Servlet, AJAX 활용

기능

1. 사용자 인증 : session 활용
2. 실시간 대전 : 웹소켓 활용
3. 랜덤 입장 기능 : 빠른 대전
4. 사용자 커스텀 입장 가능 : 랜덤 코드를 활용해 입장 가능
5. 실시간 채팅 : 웹 소켓 활용
6. 랭킹 : 이긴 횟수로 cnt
7. 사용자 검색 : 사용자의 닉네임을 통해 검색

화면 구성

1. LandingPage

   

2. RegisterPage
   

   

3. MainPage

   

4. EnterRoom
   

   

5. RandomGame
   

   

   
   5-1. CustomGame
   

   

6. Logout || Unregister
   

   

친구랑 play 하는 법

1. git에서 코드를 다운받고, tomcat 서버를 설정한다.
2. 친구와 같은 wifi에 연결하고, ip주소를 확인한다.
   1. wifi 설정
      

      

   2. 세부 사항
      

      

   3. ip 주소 확인
      

      

3. 코드 파일에서 전체 검색을 누른 후, 9090을 검색한다.
   
4. 2번에서의 ip주소를 검은 줄의 ip주소로 바꾼 후, 서버를 실행한다.
5. http://2번에서의 ip주소:9090/landing으로 접속하여 즐겁게 게임한다.

회고

역할 분담을 하는 것은 좋지만 그렇다고 너무 경계를 나누고 상대방의 코드를 전혀 모르면 안된다는 것을 느꼈다. 내가 언제 어느 파트의 에러를 수정하게 될 지 모르고, 내 코드와 다른 사람의 코드를 연결한 후에 수정을 해야 하는 상황이 발생할 수도 있기 때문이다.

또한, 에러가 발생했을 시에만 강사님께 찾아가지 말고, 설계 단계에서부터 상담을 요청하여 개발 중간에 구조를 변경하는 일을 최소화시켜야겠다고 생각하였다.
(방 입장 시에도 소켓이 필요한 점을 인지하지 못해 초반에는 CustomGameServlet, RandomGameServlet으로 나눴지만 후반에 방 입장을 하기 위해 CreateRoomServlet을 만들어 설계가 살짝 복잡해진 문제가 있었기 때문)
참고로 강사님께서는 관리가 더 편하다고 말씀하시며 다음과 같은 방식을 추천해 주셨다.

업무 단위로 폴더를 나눔 -> user package면 패키지 안에 dao, vo, servlet이 들어가도록

프로젝트 시 시간이 부족할 것 같다는 이유로 잘 하는 파트, 할 줄 아는 파트만 맡으면 안된다는 마음가짐으로 참여하였다. 그래서 실제로 어려운 파트에도 도전해 보았고, 사고 능력이 올랐다는 것이 체감되었다.

프로젝트를 마무리하면 안쓰는 파일 삭제하는 것이 좋으며, 우리의 프로젝트에서는 코드 들여쓰기 등의 정렬을 잘해서 좋았다는 피드백을 받았다. 더 발전하기 위하여 프로젝트 시 생겼던 의문점에 대하여 여쭤본 질문과 답변은 다음과 같다.

Q : 하나의 파일에 코드가 몇 줄 이상 넘어가지 않아야 좋은가?
A : 명확한 기준이 존재하지는 않지만, 코드의 가독성과 유지보수성을 높이는 방법을 계속 생각하면서 짜면 코드 및 파일이 간결해질 것임

Q : 꼭 하나의 메소드가 하나의 기능을 수행하도록 해야하나?
A : service같은 경우에는 질문을 지키기 힘듦. 로직 단위로 작성하는 것이 좋음. 재사용 할 수 있는 메소드의 경우에는 쪼개는게 맞으며, 도메인 단위는 하나로 묶는 것이 맞음

Q : 컨트롤러를 여러 개 작성하는 것이 좋은가? 이렇게 되면 하나의 기능만 수행하지만 파일이 너무 많아진다.
A : 파일보다 기능별로 함수를 묶는 것이 좋음. 그러므로 컨트롤러는 무조건 하나로 짜는 것이 좋음

Q : 우테코에서는 switch문을 꼭 안쓰는 것이 규칙인데, 실제로도 이러나?
A : 실제로도 switch문은 잘 쓰지 않기 때문에 규칙을 되도록이면 지키려고 하면서 코드를 작성하는 것이 좋을 것 같음. 남이 봐도 쉽게 익힐 수 있는 코드를 짜는 것이 좋기 때문

Q : 에러 코드를 상세히 짜면 공격에 오히려 취약해질 수 있다는데, 어떻게 해야하나?
A : 에러 코드는 개발자들끼리의 소통 도구이기 때문에 상세히 작성하는 것이 좋다. 다만, 이 에러 코드가 user에게 공개되면 해커들에게 정보를 제공하는 것이기 때문에 에러 페이지를 만들어 사용자에게는 정보를 노출하지 말아야 한다.
원래 응답 코드는 서버에서 내려주기 때문에 최대한 세세하게 해 주는 것이 좋음. api랑 애플리케이션이랑 다름. 화면에 보여줄 때에는 너무 상세하게 보여주지만 말고, api를 쓸 때는 상세하게 해 주는 것이 좋음.
즉, api에 대한 응답값은 상세하게 작성해 주는 것이 좋음

Q : 주석은 어떻게 다는 것이 좋은가?
A : 통상적으로는 주석을 짧고 굵게(서술하듯 X. 핵심 키워드만) 작성하는 것이 좋음. 하지만, 기본적으로는 많이 쓸수록 좋음. 이해도를 높이는 데 도움이 되기 때문

Q : 개발 순서를 정하는 기준은 어떻게 하는 것이 좋은가?
A : 핵심기능의 변경으로 의해 다른 로직이 변경될 수 있으니 핵심 기능을 먼저 공유하고 개발을 진행하는 것이 좋음