[우테코] 프리코스 2주차 회고

지금까지 개발공부를 하면서 가장 큰 성장을 느꼈던 주차

 

🔗 2주차_과제_PR

[자동차 경주] 김상윤 미션 제출합니다. by yuncic · Pull Request #2 · woowacourse-precourse/javascript-racingcar-

 

 

2주차 프리코스가 끝이났다.

아직 과제를 두 개밖에 안해봤지만 벌써 성장하고 발전한게 여러가지다.

주차가 진행될수록 점점 우테코에 꼭 붙고싶다는 생각이 강해진다.

단순히 코드를 작성하는 역량말고도 개발자의 시선에서 가독성과 유지보수 차원에서도 성장하는 느낌을 받고있다.

이참에 글쓰기 역량도 키워보고 싶다는 욕심이 생겨서 회고글도 열심히 써볼 생각이다.

이번 회고부터는 KPT 방식에 맞춰서 써보기로 했다!

 

잘하고 있는 점, 지속해야할 것들

 

먼저 사람들의 피드백을 흘려듣기보다 그 피드백을 객관적으로 받아들인다.

내가 당시 왜 그런 코드를 짜고, 그런 설계를 했는지 차근차근 돌아보고 사고과정의 원인부터 파악한다.

그러다보니 근본적인 문제해결이 가능해지고 문제 해결 적용이 원활하게 되는것 같다.

 

그리고 개발 자체를 즐기는 것 같다.

지금까지는 혼자서 정해진 틀 없이 아무렇게나 개발을해서 재밌는줄 알았다.

그런데 우테코 2주차째 정해진 규칙과 받은 피드백에 의해서 소프트웨어 기본 원칙을 지키며 개발을 해보니,

개발의 매력을 더 느끼게됐고 더 재밌어졌다.

얼른 3주차가 기대되고 아직 제대로 공개되지 않은 4~5주차 과제도 설렌다.

이런 마음가짐과 정신상태를 가지고 개발자로서의 삶을 살아가면 삶이 재밌을 것 같다.

 

내가 부족했던 점과 개선했던 사항들

 

1주차때 내가 부족한점을 정리하자면 다음과 같다.

 

1. 파일 구분 X (모듈화와 책임분리 적용 X)

2. TDD 형식 개발 X

3. 추가적인 TEST 케이스 추가 X

4. 변수명 어색

5. 의미 없는 주석

 

이중에서 제일 문제였던건 App.js 한 클래스에 모든 기능을 다 때려박은것이라고 생각했다.

다른 사람들의 코드를 보니 기능별로 파일을 구분하고 있었고, 하나의 함수당 한 가지 일만 하도록 했다.

그리고 상수명을 작성할 때 값을 컴파일 타임에 알 수 없는 값이면 대문자로 쓰지 말았어야하는데,

런타임때 정해지는 값인 변수를 풀 대문자로 작성해버렸었다.

 

이런 잘못들을 중심으로 개선해보고자 집중했다.

 

1. 파일 구분

1주차 때 App.js 에 모든 기능을 다 때려박았던 방면, 2주차에는 기능과 역할에 따라 파일을 세분화 했다.

 

2. TDD 방식으로 구현을 해보려고 했으나... 당시 테스트 파일이 이해가 안됐을 뿐더러 감이 잡히질 않았다.
그래서 일단 기능 구현 -> 테스트 코드 추가 식으로 진행했다.

테스트 코드를 작성해보기 위해 ApplicationTest.js 코드를 뜯어보니 그제서야 Jest에 대한 감이 잡혔다.

다음 주차 과제부턴 무조건 TDD 방식으로 해봐야지

 

3. 이번 주차 과제에서는 6개의 추가 테스트를 작성해 보았다.

// 여기서부터 추가 테스트

  test("공동 우승자 테스트", async () => {

    const MOVING_FORWARD = 4;
    const STOP = 3;
    const inputs = ["pobi,woni,yun", "1"];
    const logSpy = getLogSpy();

    mockQuestions(inputs);
    mockRandoms([MOVING_FORWARD, MOVING_FORWARD, MOVING_FORWARD]);

    const app = new App();
    await app.run();

    expect(logSpy).toHaveBeenCalledWith(expect.stringContaining("최종 우승자 : pobi, woni, yun"))
  })

  test("공백 포함 이름 테스트", async () => {
    const inputs = ["   pobi,       yun", "1"];
    const logSpy = getLogSpy();

    mockQuestions(inputs);
    mockRandoms([4, 3])

    const app = new App();
    await app.run();

    expect(logSpy).toHaveBeenCalledWith(expect.stringContaining("pobi : -"));
    expect(logSpy).toHaveBeenCalledWith(expect.stringContaining("yun : "));
  })

  test("여러 라운드 경주 테스트", async () => {
    const inputs = ["pobi,woni", "3"];
    const logSpy = getLogSpy();

    mockQuestions(inputs);
    mockRandoms([4, 4, 3, 3, 5, 5, 4, 3, 2, 4, 4, 3]);
    // 1R: pobi +1, woni +1
    // 2R: pobi +1, woni +1
    // 3R: pobi +2, woni +2
    // 4R: pobi +3, woni +2
    // 5R: pobi +3, woni +3
    // 5R: pobi +4, woni +3

    const app = new App();
    await app.run();

    expect(logSpy).toHaveBeenCalledWith(expect.stringContaining("최종 우승자 : pobi"));
  })

  test("전진이 없을 때", async () => {
    const inputs = ["pobi, jun, woni","4"];
    const logSpy = getLogSpy();

    mockQuestions(inputs);
    mockRandoms([1,1,2,2,3,3,3,3]);

    const app = new App();
    await app.run();

    expect(logSpy).toHaveBeenCalledWith(expect.stringContaining("최종 우승자 :"))
  })

  test("예외 테스트(입력값 X)", async () => {
    const inputs = [""];
    mockQuestions(inputs);

    const app = new App();

    await expect(app.run()).rejects.toThrow("[ERROR]");
  })

  test("에외 테스트(시도 횟수 음수)", async () => {
    const inputs = ["pobi, woni", "-1"];
    mockQuestions(inputs);

    const app = new App();

    await expect(app.run()).rejects.toThrow("[ERROR]")
  })
});

다른 사람들은 테스트 케이스를 막 20개씩 추가하고 하던데

같은 상황에 값만 변화를 주는 식의 테스트케이스 추가는 의미가 있나? 싶어서 각각 다른 케이스인 테스트 코드만 추가했다.

 

4. 저번주차에 입력값을 받는 상수명을 `INPUT_STRING` 이라고 정의 했었다.

하지만 입력값을 받는 상수는 컴파일때가 아닌 런타임때 정해지는 값이기 때문에 대문자로 작성할 필요가 없다는 피드백을 받았다.

런타임 컴파일타임에 대한 개념도 자세하게 알고있지 않았을 뿐더러, 그런 불문율을 아예 몰랐던 나는 신선한 자극을 받았다.

그래서 이번엔 컴파일때 정해진 상수들은 대문자 + SNAKE_CASE로 변수명을 작성했고,

런타임때 정해지는 값들(입출력과 관련된 변수들)은 camelCase로 작성했다.

단순히 변수명에 관한 불문율을 깨달은게 아니라, 개발자 세계의 코드 가독성에 대한 문화를 깨우친 느낌이라 그 이상의 가치가 있었다.

 

5. 1주차에는 누가봐도 의도가 보이는 코드에도 주석을 달았었다.

누군가 내 코드를 본다는 경험도 처음이었고, 뭔가 주석을 열심히 달면 되게 열정있어보이고 꼼꼼해보여서 그랬던것같다.

하지만 관련 피드백을 받고 나서 애초에 의도가 명확히 들어나도록 코드를 작성했고, 그러다보니 가독성과 변수명 지정에 대해 깊은 고민을 하게 된 것 같다.

유일하게 달은 주석은 테스트 코드에서 햇갈려 보일 수 있었던 라운드 진행과정에 대한 것만 달았다.

 

 

시도해볼 것들과 생각해볼 것들

 

다음엔 무조건 TDD 방식을 사용하여 구현할 것이다.

테스트 케이스도 내가 생각했을 때 예외 상황이나 테스트 해볼 절대적인 양이 많다고 판단되면 기능에 따라 구분해볼 계획이다.

리드미 작성도 뭔가 어색하다는 느낌을 받았기에 더 많은 자료와 피드백을 참고하여 발전시켜보겠다.

 

선배와 오버엔지니어링에 대한 대화를 나눴다.

잘하는 사람들이 테스트 코드를  기능단위로 나눠서 파일을 구분한다해서 그대로 따라해보려는 생각을 잠시 했었다.

그런데 이번 주차 테스트코드는 위에서 말했듯 똑같은 상황에 값만 조금 다르게 해서 여러번 하는 테스트는 의미가 없다 판단해서

각기 다른 상황으로만 테스트코드를 추가했는데 그 양이 6개 밖에 나오지 않았다.

이정도 양을 굳이 파일을 구분해서 나눠야할 필요가 있나? 싶었다.

마찬가지로 "다른 사람들이 해서" , "멋있어 보여서" 근거 없이 판단 기준 없이 따라하는건 오히려 독이 될 수 있다는 걸 느꼈다.

코딩에 답은 없다.

로직이 달라도 파일구조가 달라도 같은 결과값을 뱉을 수 있다.

 

나는 이런 이념하에 확실한 나만의 원칙을 정해나갈거고,

스스로 판단하고 항상 이유가 있는 코드를 작성하는 개발자가 되기 위해 노력하겠다.