[회고] 우아한테크코스 4주차 회고 (FE)

우테코 프리코스 4주차 회고

4주차 - 🚀 다리 건너기

이번주가 마지막이다.

 

마지막 문제라서 그런지 조건이 제일 많다.

 

저번주에는 함수의 길이 제한이 15였지만, 이번주 과제는 10줄로 제한되었다.

 

또한, 기본적으로 주어지는 함수들과 클래스 파일 중 일부는 위치 이동이 가능하고 일부는 위치 이동이 안되기 때문에 어떤 파일이 이동 가능한 파일인지 확인해야 했다.

 

🏃‍♂️ 시작하며

이번 문제에서도 console을 이용해 사용자의 입력을 받아야 했다.

 

저번주에 함수안에서 함수를 호출하는 식으로 해결했지만 다른 좋은 방법이 있을 것 같아 시도해보았다.

 

하지만, 결국 해결하지 못하였고 저번주와 마찬가지로 .call을 사용하게 되었다.

 

(저번주에 깨달은 "과감함"의 중요성을 떠올리며 새로운 마음으로 다시 시작하였다...)

 

또한, 저번주 공통 피드백 속에 있던 문서를 읽어보니 다음과 같은 글이 있었다.

저번주에는 getter를 사용해서 데이터 그 자체를 꺼내와서 외부에서 로직을 수행해 원하는 데이터를 만들었다.

 

이번주는 저 피드백에 나와있는 대로 '객체에 메시지를 보내 일을 하도록' 만들기 위해 노력했다.

---

✨ 과정 및 배운점

관심없음

이번 과제를 진행하며 가장 신경썼던 부분이다.

 

서로가 서로의 로직에 관심이 없도록 설계하고자 노력했다.

 

예를 들어 Bridge 클래스는 게임에 진행되는 랜덤 다리에 대한 클래스이다.

 

이 Bridge 클래스 안에서 다리의 생성, 사용자의 입력을 랜덤 다리와 비교 등의 로직을 수행하도록 했다.

 

getter를 사용하긴 했지만, getter의 역할은 '객체에 메시지를 보내는 것'이다.

 

getter를 이용해 객체에 접근하면 데이터 그 자체를 반환하는 것이 아니라, 외부에서 원하는 데이터를 '만들어서' 반환한다.

get bridgeLength() {
	return this.#bridge.length;
}

위와 같은 방식을 사용하여 외부에서는 private 필드인 bridge를 그 자체를 반환 받는 것이 아니라 bridge의 길이를 가져갈 수 있도록 했다.

class BridgeGame {
    #index = 0;
    #result = [];
    #totalGame = 1;

    constructor(bridge) {
    	this.bridge = bridge;
    }

    get resultString() {
        const convertedResult = Utilities.convertResultToString(this.#result);
        return convertedResult;
    }

    get totalGameString() {
    	return `총 시도한 횟수: ${this.#totalGame}`;
    }
  }

마찬가지로 위와 같은 코드가 있을 때, 각 데이터를 직접 가져가서 연산을 하기 보다는 내부에서 처리하여 반환하도록 구현했다.

 

이번 과제도 MVC 모델을 참고했다.

src
 ├─── IO
 │  ├── InputView.js
 │  └── OutputView.js
 ├─── models
 │  ├── Bridge.js
 │  └── BridgeGame.js
 ├─── utils
 │  ├── Constants.js
 │  ├── MovingValidation.js
 │  ├── RetryValidation.js
 │  └── Utilities.js
 ├─── App.js
 ├─── BridgeMaker.js
 └─── BridgeRandomNumberGenerator.js

(App.js가 사실상 Controller의 역할)

---

추가적으로 문제 조건에 'else문 사용의 지양'이 있었다.

 

언제 if else문을 사용하면 좋은지 등을 함께 고민해보라는 요구사항이었다.

 

내 개인적인 생각은 "확장 및 변화에 유연한 대응"을 위해 if문으로 로직을 구성하는 것이 좋다고 생각했다.

 

이번 과제를 진행하면서도 1. 게임 승리, 2. 게임 패배, 3. 게임 진행의 세가지 분기점이 생겼다.

 

만약, if else를 이용해서 구성하게 된다면 아래와 같이 구성해야 한다. (본인도 처음에는 이렇게 작성했다)

if (게임 승리) {
	...
} else if (게임 패배) {
	...
} else
	...
}

만약, 여기서 새로운 분기가 추가된다면 마지막 else를 else if로 바꾸고 밑에 else문을 또 추가해야 한다.

 

또한, 마지막 else를 else if로 바꾸며 해당 로직을 수행하는 조건을 또 추가해야 한다.

 

또는 아래와 같은 형태가 나올 수 있다.

if (게임 승리) {
	...
} else if (게임 패배) {
	...
} else
	if (게임 진행) {
    	...
    } else {
    	...
    }
}

depth도 깊어지고 가독성도 점점 떨어지게 된다.

 

하지만, if문 만을 이용해 분기 처리를 하게 된다면 위의 코드는 아래와 같다.

if (게임 승리) {...}
if (게임 패배) {...}
if (!게임 승리 && !게임 패배) {...}

여기서 새로운 분기가 추가된다면 단순히 밑에 if문을 작성하기만 하면 된다.

 

따라서, 내가 느낀 'else문 사용 지양'의 장점은 "확장 및 변화에 유연한 대응"이라고 생각한다.

 

(위의 내용은 본인이 과제를 진행하며 느꼈던 사항이며 개인마다 느끼는 것에는 차이가 있을 수 있습니다. 생각이 틀렸을 수도 있고 잘못된 내용이 있을 수도 있습니다.)

---

💡 아쉬운 점

이번 과제와 우테코 전체 코스를 통틀어 아쉬움이 남는 것은 '단위 테스트 구현'이다.

 

나름 구현한다고 해봤지만 뭔가 어설픈 느낌이 든다.

 

이렇게 하는 것이 맞는지, 이런 기능까지 테스트를 해야 하는지 등 고민을 많이 했다.

 

결국, 주요 클래스와 핵심 메소드 위주로 테스트 코드를 작성하고, 리팩토링을 해야할 필요가 있는 부분에 테스트 코드를 작성한 후 리팩토링을 진행하였다.

 

또한, Jest에 있는 많은 기능들을 제대로 활용하지 못한 것 같다는 아쉬움이 남는다.

 

어떤 파트에서 어떤 프로젝트를 하던 규모가 커질수록 테스트의 중요성은 커질 것이다.

 

그 때를 대비하여 테스트 코드의 작성 방법과 테스트의 종류 등에 대해서 미리 학습해야 겠다는 생각이 들었다.

---

🏆 마무리

우테코 프리코스가 끝났다.

과제를 진행하며 배운점도 많고 부족한 점도 많이 발견했다.

 

이제 본인이 할 일은 자신이 발견한 자신의 부족한 점을 스스로 학습하는 것이다.

 

프리코스를 진행하며 어떻게 프로그램을 설계하고, 왜 특정 방법을 사용해야 하는지에 대한 고민을 많이 하게 되었다.

 

매주 과제를 진행하고 그 주차에 대한 피드백을 받고 다음 주차에 적용하고자 노력하는 과정은 매우 소중한 시간이였다.

 

처음에는 절차지향 프로그래밍만 사용하던 본인이 4주차가 지난 뒤 어느새 OOP로 설계를 하고 있고 console.log로 중간중간 확인하며 리팩토링 하다가 단위테스트를 구현하여 리팩토링을 하고 있었다.

 

수백명의 사람들과 커뮤니티를 형성하여 같은 주제로 의견을 주고 받을 수 있는것도 우테코의 장점이라고 생각한다.

 

합격 / 불합격 여부에 관계없이 많은 것을 배우고 느낄 수 있었다.