게임 미니프로젝트 회고 : JavaScript canvas 이용

KPT는 각각 Keep, Problem, Try의 약자입니다. 이름에서 알 수 있듯 3가지 관점에서 업무를 돌아보고, 다음 액션 아이템을 도출해내는 데 도움이 되는 회고 템플릿이에요.

• Keep (프로젝트에서 만족했고, 앞으로의 업무에서 지속하고 싶은 부분)
• Problem (프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던 점)
• Try (Problem에 대한 해결 방식으로 다음 프로젝트에서 시도해볼 점)

무엇보다 KPT에서 중요한 관점은 Try입니다. 이번 프로젝트에서 아쉬웠던 점을 Try를 통해 어떻게 보완할 수 있을지 정리해보면서 구체적인 실천 방안을 세울 수 있다는 장점이 있어요.

 

[https://www.inflearn.com/pages/weekly-inflearn-41-20220215]

I. 프로젝트 개요

1. 프로젝트 이름 및 취지

(1) 이름 , git주소

JavaScript의 canvas를 이용한 게임 만들기

코딩타자연습

 

git 주소 : 

 

(2) 취지

코딩입문자의 경우 다양한 사유로 어려움이 상존한다. 특히 그 중에서 타자면에서 어려움의 원인은 두가지로 추정할수 있다.

첫번째 영어타자인 점, 두번째 익숙하지않은 특수기호(; ' " ` % & 등)인 점이 있다.

 

한편 타이핑의 익숙함과 더불어 필수적인 코딩 키워드나, 코드들을 수차례 반복으로 몸으로 익힐수 있게끔 하기 위해서 프로젝트 주제로 정하였다.

 

2. 프로젝트 일정

12월 30일 최초로 팀구성을 하고, 1월 10일까지는 설계와 개발에 필요하는 지식습득 기간이다.

1월 11일 본격적으로 사수-부사수 책임제로 팀 내 팀을 3개로 세분화하여 본격적으로 시작하였다

 

1월 18일을 데드라인으로 하였고 이보다 이르게 성공적으로 달성하였다

생각보다 기간이 넉넉하게 남아서 1월20일 발표일이전까지 리팩토링하였다.

 

 

II. 개인적인 개발 기록

본 개발기록은 하루에 내가 무엇을 했는지 성취감을 느끼기위해서 메모해둔것이다.

 

본메모의 구성은 다음과같다

문제, 개발하려는 기능 => 해결 => (또다른 문제) => 다시 해결

 

1/12 목

key값을 배열로 배열을 문자열로 어려웠음:

단순하지만 여러 절차를 거쳐야했음

 

인덱스값 얻기 어려웠음 : for문 쓰려고함

 

비교 이전에 인덱스 밸류 어려웠음 : 왜냐하면 input에 정수가 아닌 변수를

인덱스 값을 넣어도 아무것도 안보임

 

글씨체 마다 간격이 다름 :

고정간격 글꼴을 안써서 그럼

 

//

 

1/13 금

 

backspace를 누르면 두번 지워짐

: pop이 됐고, push가 안되서 그럼 / 통합해줌 그러나 backspace가 안먹음

: 결국 if문 맞는지 조건 안에 들어가기로 함 / 신중하게 하기위해 백업함

 

인덱스가 늦게 반응해서 삼각형 위치가 한텀 늦음

: 매번 입력할 때마다 인덱스 바꿈,/ 그러나 반복된코드임

: update에 넣어서 실시간 동기화 되게끔 함

엔터가 계속해서 입력이 됨

: 마지막 인덱스에만 작성되게끔 함

1/14,15 토일

 

- 노래방기능

노래방 기능은 다음인덱스 문자열을 출력만하면 됨

: 다만 이 경우에 undefined가 있어서 문제시됨 이 경우 삼항연산자로 해결이 가능함

: 그럼에도 두번앞의 인덱스 문자열은 해결하기가 다소 복잡함

 

-JSON 관련

: JSON 은 시도가 좋았으나, 문자열 value의 경우에 모든줄마다 내려쓰기 \n를 해주어야한다 어려움

 

-fileReader 관련

: html input 을이용한 방법이 있었으나, 그 외의 방법으로는 잘 찾기가어렵다

이미지 파일을 받아오는 방식도 고민해봤는데 의도되로 되지않음

 

-경과시간 관련

: 처음에 setTimeout 에 맞추어서 인위적으로 카운트를 했다 그러나 부정확함 /

 

//시간계산

// let second = 1; //적당속도

// this.second += 23;

// this.time++;

// this.second = 0;

// }

// if(this.time > 59){

// this.time = 0;

// this.minute ++;

// }

 

//

: Date() 클래스를 이용함 / 그러나 gettime() 등의 메소드는 Date() 인스턴스가 생성될 때 마다 갱신됨

: 결국 update()에 지속적으로 인스턴스 만들어주어야 함

/ 그러나 예상하지 못하게 시작시간 "초"가 분으로 바뀌어도 0초로 못바뀜

: 이러한 경우에도 생성자에 있었던 Date() 인스턴스도 조건문안에서 다시 갱신하게끔 해야한다.

1/16 월

-TPS를 만듬 / 이 경우 WPM방식을 차용해서 하려고했음

: 그러나 분단위로 계산이 어렵고 굳이 이러한 방식을 쓸필요가 없어서

초단위로 함// 그러나. 분자의 값을 처음에는 타이핑횟수를 만드려고했으나

굳이 그럴필요없이 score로 충분히 가능함

 

- dialogue를 만들필요가 있었음

이 경우 지난 강의시간것을 적용시키기 위해서 전반적인 이해가 필요했고

콜백함수의 전반적인 절차에 대해서 먼저 시각화 한 후 그대로 따라함

따라하니 됐음

 

- 종료창이 발생하더라도, 게임이 안멈추는 경우가 있는데

이런경우를 대비해서 pause를 실행해줌 다시시작이 문제인데, 다시시작은

pause를 false로 먼저바꾸고 run()을 해주면됨

 

- 계속 종료창의 경우 기존좌표로 손쉽게 그 범위를 잡을 수있어서 유용했음

이렇게 프레임을 잡아서 하는것이 유용해서 좋다

 

- 승패조건을 추가해서 좀 더 유동적으로 출력이 가능해서 좋다

 

 

1/17 화

- 합치기관련

각자의 기능은 합쳐졌다. 하지만 두개의 기능을 유기적으로 만든는 순간 연쇄적으로 버그가 발생하였다

그래서 오늘은 버그를 잡는달이 다수였던것같다.

 

-공룡 이미지 변경

공룡의 위치와 패배이후 행동이 바뀌지않았다. 사소하게 몇가지만 해주면 해결됨

 

- 승리 패배가 해당 순번의 게임에 승패가 구별되지않았다

/ 이유를 고찰해보니 승패여부에 대한 반환이 null로 되어있었다

/ null 은 falsy로서 패배가 나오게 되었다

/ 어디선가 승패에 대한 명확한 설정을 하면 좋다

/ 승의 경우 손쉽게 승리조건에 승을 넣으면된다 하지만 패의 경우 다른 클래스에서 정의해야하는 등 번거롭다

/ 쉬운방법으로 패배를 기본조건으로 하였다

 

- 두번째 패배는 (승리는 아님) 결과창이 안나온다.

이벤트 핸들러는 하나의 콜함수(승리조건)만 연결되는 것이 아니라 다수(패배도 추가)도 가능하다

 

- 승리 후 다음게임에서 글자당 이동거리가 업데이트 되지않음

최초 count 해주는 함수 내부에 처음에 0으로 재 선언 해준다.

 

- 결과창이 발생하지않아도 클릭이 되었다. 끝난 경우의 조건을 넣어서 이때만 되게끔 하였다

/ 이유는 결과창 클릭은 결국 결과창을 클릭하는 것이 아니라 x,y값에 클릭하는것에 불과하기 때문이다.

 

- 두번눌러야 게임이 다시 시작됨

/ 이유는 코드의 순서때문이다.

1/18 수

- 문제 난이도별 정렬기능

1/19목 - 리팩토링

1. 승패에 한 것 정하기 위함

- 승패 로직 정리

winlose의 기본값을 false로 함

변수명을 바꿔줌

 

iswin을 불리언

 

=> 승패조건을 서둘러서 주기위해서, 그리고

 

2. run()에 중복 없앰

---

1/21  토 : 또 리팩 (for 객체지향, 이벤트지향)

 

승리관련 이벤트 리스너 및 핸들러 추가함

무엇이 이벤트인지 고민을 해보니 수월해졌음

 

 

III. 프로젝트 회고

1. Keep (프로젝트에서 만족했고, 앞으로의 업무에서 지속하고 싶은 부분)

(1) 팀 관점

1) 팀장으로서 일정 관리를 할 때 넉넉하게 기간을 잡은 점이 뿌듯하다

 

2) 매일 아침 팀회의 및 스터디를 30~1시간가량 한 것이 팀 협업 및 학습에 도움이 되었다.

 

3) 개발경험에 따른 사수 - 부사수 책임제로 팀 내부를 세분화한 점이 문제발생및 해결을 수월하게 할수 있어서 도움이 되었다.

 

4) 개발의 우선순위(core 기능이 무엇인지)를 두어서 소기 목적을 빠르게 달성할 수 있어서 도움이 되었다.

 

5) 팀원들이 개발적 근거없이 주장을 하지않기 때문에 좌고우면 하지안았다.

 

(2) 개인관점

1) 지금 무엇이 문제고 무엇을 개발할지 그리고 그 과정을 메모장에 켜두고 명세시켜둔 점

관념적, 무의식적으로 비약해버리는 사고를 바로잡을 수있었음

 

2) 위와 연결해서 하나씩 목표를 정해두고 개발한점 덕분에 성취감을 느낄수 있었다

 

3) 개발일지를 메모를 해서 내가 무엇을 했는지 정리와 반성을 할수 있었음

 

4) 메인으로 개발하던 부분이 잘 되지않는 경우 자칫무기력해지거나 짜증이 날수도 있으나, 부차적인 기능 개발로 의도적 미루기를 한점

 

5) 아쉬웠던 부분 몇가지를 여유기간에 클린코드로 리팩토링하려고 노력한 점

 

 

2. Problem (프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던 점)

1) 클린코드

기능 개발 쫓긴나머지 스파게티코드가 발생한점

예컨데 ) 중복된 기능을 가진 함수를 만든점, 절차지향적으로 코딩을 한점

 

2) 객체지향 이벤트지향 프로그래밍

: 함수를 만들고 기존에 내가 익숙한 방식으로 코드를 짜고싶어서 반환값을 만들까 고민한점

: 이벤트 지향이 아니라 멤버변수의 this 남발로 스파게티 코드를 야기한점

: 결국 캡슐화를 하지못해서 버그의 연쇄작용으로 디버깅에 힘든점

 

3) 공식문서 MDN

: 공식문서 기반 개발이 아니라 블로그 기반 개발로 위험을 야기한점

: 공식문서가 익숙해질 수있는 기회를 놓친점

 

4) 팀내 다른팀의 개발에 관심이 소홀한 점

: 다른팀의 코드를 살펴보거나 배우려고 하지않아서 성장의 기회를 다소 놓친점

 

5) 리팩토링을 할 때 회피한 점

: 내가 개발한 부분에 물려버려서 그만보고 싶기 때문이다.

 

 

 

 

3. Try (Problem에 대한 해결 방식으로 다음 프로젝트에서 시도해볼 점)

1) 클린코드 => 정기적 코드리뷰

다음번 프로젝트를 할 때에는 팀원으로 하여금 의식적 제도적 코드리뷰를 하게끔 할것이다. 이로서 스파게티 코드를 막을수는 없으나 최소화 할수있 수 있다.

 

 

2) 객체지향프로그래밍 -> 캡슐화를 1순위로 생각하기!

일단 캡슐화만 잘 해놓더라도 추후에 코드수정에 효율은 훨씬 높일수 있으리라 생각된다.

 

3) MDN문서 익숙해지기 -> 검색시 1순위로 보기

공식문서를 먼저 보고 블로그를 보자

 

4) 다른팀 관심소홀 -> 코드리뷰를 제도적으로 마련하기

 

5) 리팩토링 회피

물리고 지겨워진 시점에서 한번 더 한다면 그 지점이 성장의 지점이라는 것으로 생각하기