Team

🗃️ Github

GitHub - nanoda1802/tower-defense

📽️ 시연 영상

https://www.youtube.com/watch?v=T_XWpQ6_xSs

🗒️ 발표 자료

https://docs.google.com/presentation/d/1NM8CE7_DXhBj2OD4rMiLL5CxNRbpytgF5VGHCHvpN6o/edit#slide=id.p

KPT 회고

[keep]

• 성실한 참여도
• ?? 교수님이 맛있었습니다
• 건강한 의견 교류
• ?? 가장 큰 장점 : 교수님 짱
• 기획 단계의 아이디어 생성 활발함 기분이가 좋았음 ㅇㅈ 드립니다
• 그런게없어도 이정도한 우리가 짱이다
• 비록 손이 남더라도 함께 해주며 다른 팀원들을 북돋아 주는 분위기 아주 나이스 해씀니다
• 아잇 ㅋㅋ
• 앞으론 참고하겠슴니다? ^^
• 깃헙 활용 괜찮게 했다 →
  • 깃헙 버근지… 머지를 내가 잘못 한 건지…

[problem]

• 코드 통일성 부족 → 각자의 기존 스타일대로 코드를 작성하고 로직을 구현했기에, 상호 교류가 되지 않는 개별적인 코드의 종합이란 인상이 있었습니다
• 서버와 클라이언트에 대한 이해가 팀원 마다 다름. 어떤 데이터를 어디서 관리해야하는가?
• 실시간 통신 소켓에 대한 이해도 부족 → 1요청 1응답 구조는 소켓에 적합하지 않은데, 기본 구조의 방향성이 적절하지 않음
• 아직 기본 기능도 구현되지 않았는데 이후에 것들을 너무 이르게 염두를 하고 구현을 했다 -> 와이어 프레임 부족.. 모호한 기준으로 인한 구현 단계에서 혼란
• 분업이 유동적이지 못 해따 → 손이 남는 인원들 발생
• 담당 업무별 난이도 격차가 심해 팀원별 작업 강도 차이가 심해따
• 다른 조원의 코드에 대해 이해하기 위한 노력이 과하게 들어가야 했다 (try이에 리뷰~~)
• 구해조…. 살려조… 유언
• 참고 하라고 ㅋㅋ

[try]

• 코드 컨벤션 단계에 시간과 노력 할애하기 + 경험이 쌓이면 더 효율적인 규칙 설정이 가능할 것이라 생각합니당
• 이제는 통신 방식에 맞게 로직 구현하기
• 설계 단계 체계화 한명이 쿠데타를 …. 정권을 잡아… 주도적으로…….
• 각자 작성한 코드의 의도와 흐름을 설명하는 시간 갖기

👣 진행 중 업무 현황

• 이기환 - 로그인/회원가입(Redis 연동 : 플레이 내역, 최고 기록)
• 송원빈 - HQ, Client
• 주용찬 - Wave
• 김제훈 - Monster
• 황종하 - game
• 김의중- Tower

💬 기능 구현 리스트

• [ ] register-handler
• [ ] auth-mw
• [ ] account-router
  • [ ] 회원가입 API
  • [ ] 로그인 API
• [ ] helper
  • [ ] 게임 시작
  • [ ] 게임 종료
• [ ] wave-handler, wave-model
  • [ ] 검증
  • [ ] 서버에 웨이브 정보 기록
  • [ ] 클라에 응답 및 정보 전달
• [ ] tower-handler, tower-model
  • [ ] 검증
  • [ ] 서버에 획득 타워 정보 기록
  • [ ] 클라에 응답 및 정보 전달
  • [ ]
• [ ] monster-handler, monster-model, gold-model
  • [ ] 검증
  • [ ] 서버에 처치 몬스터 정보 기록
  • [ ] 서버에 획득 골드 정보 기록
  • [ ] 클라에 응답 및 정보 전달
• [ ] position-handler, position-model
• [ ]

📌 프로젝트 준비

🤖 ERD 설계

API 명세서

패킷 구조 설계

Code Convention

와이어 프레임

기획 설계

아이디어 뱅크

🌞 계획표

요일 별 상시 업무 [D-5] (1)

Node.js 7기 기획 특강

핸들러.txt