[우아한테크코스 6기 프리코스] 2주차 회고

일주일 동안 진행했던 프리코스 과정을 회고하고 기록하려고 합니다.

코드 저장소 링크

어느덧 2주차에 접어들었습니다. 이번 주에는 다음과 같은 목표를 설정했습니다.

결과 최대한 추상화, 선언형 프로그래밍
더 다양한 상황 예측하기
각 함수별로 테스트 코드 작성하기
공통 피드백 지키기

지난주에 느꼈던 아쉬운 부분을 개선하고 다른 분들의 코드를 보면서 느꼈던 점과 크루들의 리뷰를 받고 반영해서 지난 주의 코드보다 더 나은 코드를 작성하는 것을 목표로 과제를 진행했습니다.

그리저 이전부터 테스트 코드를 작성하고 싶었는데, 마침 이번 주 목표가 함수를 분리하고 각 함수 별로 테스를 작성하는 것이었습니다. 프리코스만 진행해도 얻는게 정말 많다는 이야기를 몸소 경험할 수 있었습니다.

이번 주에도 구현을 하면서 고민을 많이하고 얻어가는 것이 많았습니다.

고민한 내용

🤔 자바스크립트스럽게 개발하려면 어떻게 해야 할까?

지난 주에 많은 크루들이 객체지향 프로그래밍과 MVC 패턴을 적용하고 서로서로 코드 리뷰를 진행했습니다.

이 중에 나온 코멘트 중에 제가 가볍게 던진 코멘트가 있었습니다.

while이나 for문의 사용을 지양하고 꼬리재귀를 사용하는 것이 어떻겠느냐에 대한 답변이었습니다. 저 역시 반복문의 사용을 최대한 줄이려고 노력하며 구현을 진행했기에 공감가는 제안이었습니다.

서로 리뷰를 진행하던 크루께서 자바스크립트스럽다라는 것에 대해서 무엇인지 질문해 주셨고 가볍게 던진 한 마디를 더 깊게 생각하게 되는 계기가 되었습니다.

자바스크립트는 이상하다.

자바스크립트는 정말로 독특하고 유연한 언어입니다. 이 언어는 객체지향 프로그래밍을 지원하지만, 완벽한 객체지향 언어는 아니며, 함수지향 프로그래밍을 지원하지만 완전한 함수지향 언어도 아닙니다. 이런 유연성은 개발자에게 자유로움을 주기도 하지만, 때로는 예기치 못한 오류를 발생시키기도 합니다.

그 어느 쪽에도 속하지 않고 발만 걸치고 있는 애매한 언어이지만 반대로 생각하면 어떤 것이든 표현이 가능한 다재다능한 언어라는 생각이 들었습니다.

어 그러면 특정 하나의 패턴이나 패러다임에 얽매이지 않고 모든 표현 법을 쓸 수 있지 않을까?

이를 바탕으로 나만의 자바스크립트 코딩 스타일을 개발하게 되었습니다.

• 만약 객체를 사용한다면 객체의 이름과 메소드의 이름을 통해 어떤 객체인지 명확하게 설명하자
• 객체의 메소드 동작 방식을 선언형 프로그래밍 스타일로 명시하려고 노력하자

객체와 메소드를 통해 이 객체가 무엇What인지 나타내고, 각 메소드는 선언형으로 어떻게How 동작하는지 표현할 수 있을 것 같다는 판단이었습니다.

App Class

// App.js
class App {
  constructor() {
    this.cars = [];
    this.winners = [];
  }

  createCar(nameString) { }
  startRace(attemps) { }
  printMoveResult() { }
  printWinners() { }
  async play() { }
}

export default App;

이런 식으로 표현할 수 있을 것 같습니다. 이 객체가 무엇인지 쉽게 파악이 가능 할 것 같네요.

App이라는 클래스는 cars, winners 배열 두개를 가지고 있고, 자동차를 만드는 기능, 경주를 시작하는 기능, 이동 결과를 출력하는 기능, 우승자를 출력하는 기능을 가지고 있구나

그럼 메소드를 선언형으로 어떻게 표현할 수 있을까요? play메소드를 예시로 설명하겠습니다.

 async play() {
    const carNames = await getUserInput(PROMPT.CAR_NAMES, isValidCarNameString);
    const apttempNumber = await getUserInput(PROMPT.ATTEMP_NUMBER, isValidAttempNumber);

    this.createCar(carNames);
    this.startRace(apttempNumber);
    this.printWinners();
  }

play메소드는 사용자에게 두 번 입력을 받고, 입력을 바탕으로 자동차를 만들고 경주를 시작하는 구나. 그리고 마지막엔 우승자를 출력하고 끝이나네

App의 다른 메소드들도 이런식으로 표현이 되어있습니다. 그리고 클래스 뿐 아니라 함수를 구현 할 때도 내부 연산을 선언형으로 표현해 더 직관적으로 느낄 수 있도록 노력했습니다.

🤔 테스트 코드를 어떻게 활용 해야할까

제가 이전부터 테스트 코드를 작성해보고 싶은 마음이 있었지만 처음으로 사용하려다보니 막상 어떤식으로 쓸 수 있을지 떠오르지 않았습니다.

저는 평소 설계를 중요시하고 있었으며, 테스트 코드를 바탕으로 함수를 설계할 수 있으니 어설프겠지만 각 함수마다 TDD를 해보자라고 마음먹었습니다.

함수를 구현하기 이전에 다양한 상황의 입력과 출력을 설계하고 이를 바탕으로 테스트 코드를 작성했습니다.

// InvalidTest.js

let result;
let input = '';

describe('유효성 검사 함수 테스트', () => {
  // 자동차 이름 입력 유효성 검사
  test('입력에 공백이 포함될 수 없다.', () => {
    input = 'pobi, woni,jun';
    result = isValidCarNameString(input);
    expect(result).toBeFalsy();
  });

  test('이름은 5자 이하만 가능하다.', () => {
    input = 'pobi,woni,juniiii';
    result = isValidCarNameString(input);

    expect(result).toBeFalsy();
  });

  test('이름은 빈 문자열이면 안된다.', () => {
    input = 'pobi,woni,,jun';
    result = isValidCarNameString(input);

    expect(result).toBeFalsy();
  });

  test('중복된 이름을 입력할 수 없다.', () => {
    input = 'pobi,pobi,jun';
    result = isValidCarNameString(input);

    expect(result).toBeFalsy();
  });
}

describe에 어떤 종류의 테스트들을 진행할 건지 명시를 해주고 유효하지 않은 입력 시나리오를 정의했습니다.
test에는 각 시나리오를 적고 input에 대한 output을 정의했습니다. test코드를 바탕으로 함수를 구현하고 테스트가 통과할 때 까지 코드를 수정했습니다.

2주차 프리코스에서 구현한 함수들, 클래스의 메소드들은 모두 TDD 방식으로 구현하였습니다.

좋았던 점

이번 주차는 예전부터 해보고 싶었던 경험을 할 수 있었습니다!!

나만의 코딩 스타일 만들기

우아한테크 콘서트에서 일정을 잘 지키는 사람의 공통점이 좋은 코드를 선택하는 본인만의 방법이 있다는 말을 들었던 적이 있습니다. 언젠가 만들어야지 하겠다는 생각을 하긴했지만 프로젝트를 완성하는데 급급해서 하지 못했습니다.

나는 어떤 개발자인지 어떻게 개발을 하는지에 대해서 대답하기 참 어려웠는데, 이제부턴 나는 코딩을 이렇게 하는 사람이야라고 말할 수 있을 것 같아요!

물론 취업을 하게되면 자신만의 코딩 스타일을 적용하지 못할지도 모르겠습니다. 하지만 아예 스타일이 없다는 것은 컨벤션 논의에서 자신의 의견을 제안할 기회조차 생기지 않을 것 같네요.

난생처음 써본 테스트 코드

테스트 코드를 짜기 위해 함수가 호출되는 시나리오도 생각해보고, 함수에 매개변수가 어떤 형태로 들어갔을 때 어떻게 형태로 결과가 도출되어야 하는지에 대한 깊은 고민을 했습니다.

Jest를 처음 사용해봤기 때문에 원래 작성되어 있던 테스트 코드들, StringTest.js와 ApplicationTest.js가 정말 많은 도움이 되었습니다. 이 코드를 보고 어떤 식으로 테스트 코드를 작성해야 하는지 알 수 있었어요.

플로우 차트를 그리는 것은 저에게 익숙한 설계 방식이었지만 테스트를 바탕으로 한 함수의 설계는 지금까지 경험해 본 적이 없었습니다. 뭔가 어설프고 읽기도 힘들고 "이렇게 해도 되나?"라는 의문이 드는 테스트 코드였지만 난생 처음으로 작성해봐서 뜻깊습니다!

아쉬운점

푸쉬는 더 신중하게!

저는 이번 과제를 진행하면서 강제 push를 두 번 진행했습니다. 오탈자가 있는 commit message를 원격 저장소에 push를 했기 때문인데요..

저 혼자서 과제를 진행하는 것이어서 큰 문제는 발생하지 않았지만 만약 팀프로젝트에서 이런 상황이 발생한다면 문제가 발생할 수 있다고 느꼈습니다. 강제 푸쉬를 진행한다면 이 저장소를 사용하고 있는 모든 사람이 다시 clone을 하고 모든 변경사항을 새로운 사본에 재적용해야 하기 때문이죠.

원격 저장소에 push를 하기 전에 반드시 여러번 확인하고 push를 진행해야 할 것 같습니다.

3주차 때는 !...

이번 주에는 코드리뷰에서 받았던 피드백도 적용시켜보고 이전부터 하고 싶었던 테스트 코드, 나만의 코딩 스타일 정하기와 같은 활동을 할 수 있었습니다.

크루들의 지난 미션을 잠시 살펴봤었는데요. 요구사항을 정말 꼼꼼히 분석하고 문서화를 기똥차게 해두신 분들이 많았습니다. 개발자는 개발 역량도 중요하지만 문서화와 같은 소프트 스킬이 있고 없고의 차이는 정말 크다고 생각합니다.

3주차에는 다른 크루들의 문서를 보고 인상 깊었던 부분들을 저의 문서에 적용해보고 싶습니다!