[JS][우테코] 프리코스 3주차 공통 피드백을 통한 KPT회고

글의 목표

3주차 공통 피드백을 통해 3주차의 코드를 되돌아보고 4주차를 시작해볼 생각이다.

※ 해당 글은 우아한테크코스에서 올려준 3차 공통 피드백을 참고하여 작성되었습니다. 공통 피드백은 프리코스 참여자들에게 개별적으로 공유된 링크가 존재하며, 저는 해당 링크는 공유할 수 없고 공통 피드백을 확인하는 과정에서의 생각들을 해당 글에 정리해보았습니다.

 

3주차 프리코스 과정에 대한 후기

3주차 학습 목표는 관련 함수들을 묶어 클래스를 만들고, 이 객체들이 협력하여 하나의 큰 기능을 수행하도록 하는 것이었다. 더불어 클래스와 함수에 대한 단위 테스트를 통해 의도한 대로 정확하게 작동하는지를 검증하는 것이 중요했다. 단위 테스트에서 ‘단위’의 의미를 명확히 정의하는 것이 조금 어려웠지만, 일단 코드 작성 중 자잘하게 테스트가 필요하다고 느껴지는 함수들을 하나씩 테스트하면서 진행했다. 그래도 2주차 때는 익숙하지 않아서 제대로 작성하지 못했던 테스트 코드들이 이번에는 조금 더 자연스럽게 다가와 뿌듯했다. 1주차에는 npm run start를 무한 반복하며 테스트했었는데, 이제는 직접 테스트 코드를 작성하고 npm run test로 오류가 나는 부분만 찾아 수정하게 되었다는 점에서 스스로 꽤 발전했다고 느낀다... 😭

합격 여부를 떠나서, 3주차까지 온 것만으로도 자랑스럽다. 처음 시작할 때는 파이썬으로 반복문을 활용한 함수 하나 정도 만들줄 알았던 내가 과연 자바스크립트로 기능 하나를 구현해낼 수 있을지 의문이었고, 이전 기수들이 작성한 코드들은 이해조차 되지 않았다. 하지만 이제는 내가 작성한 코드들을 모두 이해하고, 오류가 나면 바로 수정할 부분을 파악할 수 있을 정도로 성장했다는 사실이 새삼 실감이 난다.

처음에는 기능을 하나씩 구현하면서 파일을 어떻게 분리하는 게 좋을지, 분리한 파일들을 어느 폴더에 넣어야 디렉터리를 깔끔하게 정리할 수 있을지 고민했는데, 그렇게 체계를 잡아가는 과정이 생각보다 재미있었다. 원래 큰 카테고리로 묶어 정리하는 걸 좋아하는 성향이라, 코딩을 하면서 디렉터리를 구성해가는 것도 꽤 흥미로웠다.

이제는 테스트 코드도 어느 정도 익숙해졌고, 함수와 메서드를 가장 작은 단위로 나눠서 하나의 클래스로 묶고, 해당 클래스를 객체로 인스턴스화하여 이 객체들이 협력해 하나의 큰 기능을 수행하는 controller까지 만들 수 있게 되었다. 이러한 과정은 1, 2, 3주 중 어느 한 주라도 제대로 진행하지 않았다면 얻기 어려운 결과였다고 생각한다. 물론 누군가에게는 쉬운 작업일 수 있고, 이미 1주차부터 그 방법을 알고 진행하는 사람들도 있었겠지만, 1주차에 App.js에 절차 지향적으로만 코드를 작성하던 나에게는 지금의 성장이 굉장히 크게 다가온다.

 

공통 피드백 확인

[ 함수(메서드) 라인에 대한 기준도 적용한다 ]

  3주차에 각 함수(메서드)의 길이를 15라인으로 제한하는 규칙이 있었다. 이 규칙을 main()함수에도 동일하게 적용하며 공백 라인도 한 라인으로 간주한다고 피드백되어있다 만약 함수가 15라인을 초과한다면, 역할을 더 분명하게 나눌 수 없는지 고민하고  분리해보아야 겠다.

 해당 기준을 적용하면 코드의 가독성과 유지보수성을 높일 수 있기 때문에 함수 분리 또는 클래스 분리는 고려해야 하는 사항이다. 

[ 예외 상황에 대한 고민한다 ]

 예외 상황을 모두 고려하여 프로그래밍을 하는 것이 정상적인 상황을 구현하는 것보다 훨씬 어렵다고 한다. 그런 것 같다.. 나는 3주차에 아주 치명적인 예외 상항을 놓쳤다. 로또 구매 금액 입력 시 음수 값을 고려하지 않은 것이다 ㅠ 

기능 구현이 상대적으로 쉽고 가벼웠던 1주차에는 예외 상황에 대해 고민하는 것이 쉬웠다. 하지만 2, 3주차가 되면서 구현이 어려울 것 같아서 예외 상황을 많이 파악하지 못한 채로 구현만 시작했으니 끝날때도 제대로 확인해내지 못한 것이 아쉬웠다. 

예외 상황을 구현하면서 중간중간 추가하면 될 것 이라고 생각했는데 구현에 급급하여 제대로 예외 상황을 추가하지 못한 것 같다. 그래서 이번에는 공통 피드백에 따라 예외를 미리 고려하여 프로그램이 잘못된 결과를 내지 않도록 준비해야 겠다.

(혹시 숨겨진 테스트 코드가 음수 입력값을 걸러내지 못하여 내 기능은 작동에서 마이너스를 받는 건 아닐까..^^)

<저번 주차 예외 사항>

• 로또 구입 금액에 1000 이하의 숫자를 입력
• 당첨 번호에 중복된 숫자를 입력
• 당첨 번호에 1~45 범위를 벗어나는 숫자를 입력
• 당첨 번호와 중복된 보너스 번호를 입력

 

[ 비즈니스 로직과 UI 로직의 분리한다 ]

 굉장히.. 실수하고 있었다. 누가 알려주지 않으면 모르는 것인가..ㅠ 비즈니스 로직의 class에 UI 로직을 열심히 넣어서 단일 책임 원칙에 위배된 코드를 3주간 작성하고 있었다. UI 로직은 화면에 데이터를 표시하거나 입력을 받는 역할을 담는다. 그래서 View 클래스에 별도로 분리하는 것이 좋다고 한다. MVC 패턴에 대해 공부해두고 차례대로 파일의 필요성을 파악하면서 만들어나가려고 했는데 View에 대해서는 생각 못했었다니.. 아쉬움이 남는다.

그래도 피드백 덕분에 알게된 사항이기 때문에 오히려 더 기억에 오래 남을 것 같다. UI 로직과 비즈니스 로직을 혼재하는 것은 단일 책임 원칙(SRP)에 위배된다.! 

▼ 단일 책임 원칙 더보기 (네이버 지식백과 스크랩)

 

[ 객체의 상태 접근을 제한한다 ]

 필드는 private class 필드로 구현해야 한다. 이유를 명확히 찾지 못해서 기존에 하던대로 Lotto 필드를 제외한 모든 필드를 public으로 구현했다. 이쯤부터.. 슬슬 공통 피드백을 읽으면서 모든 피드백의 내용이 내 코드에 포함되어있는 것과 같은 기분이 들면서 슬펐다..^^ 난 정말 동작만 하는 트레쉬를 만든 것인가

대충 2번이 내 코드일듯

프라이빗 필드가 필요한 이유에 대해 스스로 찾아보라는 피드백이 존재하여 찾아보고 블로깅해보았다..

https://sundery.tistory.com/222

 

[ 객체는 객체답게 사용한다 ]

 나의 객체들은 객체다웠는가 (No)

3주차 파일에 Lotto.js에 Lotto 객체랑 numbers 프라이빗 필드가 있었다. 근데 이 numbers 필드를 어떻게 잘 써야 할지 모르겠어서 유효성 검사 클래스를 따로 만들어서 객체로 만들고, 그걸로 Lotto 파일 안의 numbers 유효성 검사를 했다. 사실 Lotto 객체 파일 안에서 numbers 값을 관리하게 만들고, LottoGame 객체에서 Lotto를 가져와서 쓰는 방식으로 해야 했는데, 나는 Lotto 객체를 그런 존재로 만들지 못했다.. 오히려 엉뚱한 파일에 그런 객체를 만들었다는 것 ;; 

지금 생각해보니 Bonus와 Lotto 번호를 나누려다가 굳이 나누지 않았는데 오히려 나누는 것이 정답이었던 것 같다.

▼ 잘못된 사용 예시

class Lotto {
   #numbers


   constructor(numbers) {
       this.#numbers = numbers
   }


   getNumbers() {
       return this.#numbers
   }
}


class LottoGame {
   play() {
       const lotto = new Lotto(...)


       // 숫자가 포함되어 있는지 확인한다.
       lotto.getNumbers().contains(number)


       // 당첨 번호와 몇 개가 일치하는지 확인한다.
       lotto.getNumbers().stream()...
   }
}

 

▼  올바른 사용 예시

class Lotto {
   #numbers


   constructor(numbers) {
       this.#numbers = numbers
   }


   contains(number) {
       // 숫자가 포함되어 있는지 확인한다.
       return ...
   }


   matchCount(other) {
       // 당첨 번호와 몇 개가 일치하는지 확인한다.
       return ...
   }
}


class LottoGame {
   play() {
       const lotto = new Lotto(...)


       lotto.contains(number)
       lotto.matchCount(...)
   }
}

참고글 : https://tecoble.techcourse.co.kr/post/2020-04-28-ask-instead-of-getter/ 

getter를 사용하는 대신 객체에 메시지를 보내자

💡 : 난 getter를 남용하였구나

 

[ 필드(인스턴스 변수)의 수를 줄이기 위해 노력한다 ]

 필드의 수가 많아지면 객체의 복잡도가 증가하고, 관리가 어려워지며, 버그가 발생할 가능성도 높아진다. 따라서 필드에 중복이 있거나 불필요한 필드가 없는지 확인하고 최소화해야 한다.

이 피드백은.. 나와 같은 사람들이 많았는지 궁금해지는 피드백이었다. 왜냐하면 

3주차의 LottoController의 필드;;

;;;; 혹시 내거 보고 충격 먹으셔서 공통 피드백에 작성하신게 아닐까 하는 정도로 많은 수의 필드

이쯤되니 내 마음대로 코드를 짜는.. 정말 즐기기만 하는 프리코스 유저가 아닐까..

그래도 지금이라도 알았으니 피드백에 작성된 방식처럼 나도 필드를 한번 .. 줄여보는 방안을 고안해야겠다.

예시로는 아래처럼

class LottoResult {
   #result = new Map()
   #profitRate
   #totalPrize
}

 

 

필드가 많으면 중복이 있거나 불필요한 필드가 없는 지 확인하고 최소화해야 한다고 한다.

위와 같은 경우는 profitRate와 totalPrize는 당첨 내역(result)만 있어도 모두 구할 수 있는 값이므로 하나의 필드로 줄일 수 있다고 한다.

class LottoResult {
   #result = new Map()


   calculateProfitRate() { ... }


   calculateTotalPrize() { ... }
}

그래서 나도 한번 내 것을 줄여본다면..

class LottoController {
  constructor() {
    this.ticket = new Ticket();
    this.jackpot = new Jackpot();
    this.lottos = [];
    this.winnings = [];
    this.bonus = null;
    this.cost = 0;
    this.prize = 0;
    this.ranks = { 5: 0, 4: 0, 3: 0, 2: 0, 1: 0 };
  }

여기서 lottos는 사용자가 얻은 랜덤 로또 숫자를 담는 배열이고 winnings는 당첨 숫자이다. 또한 cost는 비용에 관한 것인데 cost와 lottos가 연관이 되어있기 때문에 ticket 필드와 중복되며 jackpot 또한 winnings와 bonus 번호에 대한 값을 담고 있기 때문에 중복된다. 그리고 ranks 값을 통해 prize값이 나오기 때문에 이 두개도 중복된다. 그러므로 prize와 ranks는 최종 결과값이기 때문에 result 필드로 중복된다.

아래와 같이 줄일 수 있다.

class LottoController {
  constructor() {
    this.#ticket = new Ticket();
    this.#jackpot = new Jackpot();
    this.#lottos = []; 
    this.#winnings = []; 
    this.#bonus = null; 
    this.#result = {}; 
  }
}

아무래도 여기서 더 줄이려면 클래스의 캡슐화를 잘 해서 객체만 가져왔어야하는데 그렇게 코드를 구현하지 못하니 위와 같이 줄이게 되고 이렇게 되면 줄여도 필드의 개수는 많다.. 

객체 지향적인 설계가 필요하다는 게 더 크게 와닿는다.

 

[ 성공하는 케이스 뿐만 아니라 예외 케이스도 테스트한다 ]

 다행히도 예외 케이스에 대해서 테스트를 진행했다 (얏호)

테스트 케이스를 많이 작성한 건 아니지만 성공과 예외 테스트 모두 작성하려고 했으며 예외 테스트의 ERROR 문구도 계속 잘못 작성하여 수정을 거치는.. 상황도 많았다.

예외 케이스 테스트도 더 자세히 작성하고 성공한 케이스도 잘 작성하도록 노력해야겠다.

 

[ 테스트 코드도 코드다 ]

 테스트 코드도 리팩토링이 필요하다. 반복적으로 수행하는 부분은 중복을 제거하여 유지보수성을 높이고 가독성을 향상시켜야한다. 지금보니 나의 테스트 코드는 그냥 단순히 파라미터 값만 바뀌게 만들었던 것 같다. 얻어가는 게 너무 많은 공통 피드백이다..

> 중복되는 테스트 코드를 파라미터화된 테스트 코드로 리팩토링 (예시)

test.each([["999"], ["0"], ["-123"]])("천원 미만의 금액에 대한 예외 처리", (input) => {
   expect(() => {
     const app = new App(input);
     app.play();
   }).toThrow();
 }
);

 

[ 테스트를 위한 코드는 구현 코드에서 분리되어야 한다 ]

 테스트를 위해 구현 코드를 변경하는 것은 좋지 않은 습관이라고 한다. 테스트를 더 쉽게 하기 위해 접근 제어자를 변경하고, 메서드를 구현 코드에 추가하는 경우가 있다고 한다. 그러나 이렇게 하면 구현 코드가 테스트에 종속되고, 캡슐화가 깨지며 코드의 일관성이 저해된다고 한다. 아래의 두 케이스를 잘기억하고 유의해보자.

• 테스트를 위해 # prefix를 바꾸는 경우
• 테스트 코드에서만 사용되는 메서드

 

[ 단위 테스트하기 어려운 코드를 단위 테스트하기 ]

테스트가 어려운 코드는 외부로 분리하여 테스트 하는 것이 좋다고 한다. 예시를 보니 바로 이해가 되었다.

A : 

const MissionUtils = require("@woowacourse/mission-utils");


class Lotto {
   #numbers


   constructor() {
       this.#numbers = Randoms.pickUniqueNumbersInRange(1, 45, 6)
   }
}
---
class LottoMachine {
   execute() {
       const lotto = new Lotto()
   }

위의 numbers 필드 자체가 랜덤 숫자를 받고 있는 것으로 선언되어있다. 이렇게 되면 내부의 필드에 선언되어있는 숫자를 테스트 해야하기 때문에 어려우므로 외부로 분리하는 시도를 하는 것이 좋다.

B :

const MissionUtils = require("@woowacourse/mission-utils");


class Lotto {
   #numbers


   constructor(numbers) {
       this.#numbers = numbers
   }
}


class LottoMachine {
   execute() {
       const numbers = Randoms.pickUniqueNumbersInRange(1, 45, 6)
       const lotto = new Lotto(numbers)
   }
}

Random 값으로 랜덤성을 테스트해야 하는데 그러려먼 Random 값의 결과가 고정되어야 한다. 하지만 A의 상황에서는 Lotto에 직접 의존하므로 랜덤 요소를 포함하게 되어 테스트 결과가 매번 달라질 수 있다. Application, LottoMachine, Lotto를 독립적으로 테스트 하기 어려워진다. 

하지만 B의 상황이 되면 LottoMachine에서 Randoms를 참조하고 이 결과를 Lotto에 전달하기 때문에 Lotto에서 Randoms 값을 받아 고정된 결과 하나만 가지고 테스트가 가능하게 된다.

이렇게 되면 독립적인 단위 테스트가 가능하기 때문에 분리하여 Lotto가 테스트하기 쉬운 상태가 되기 때문에 B처럼 분리하는 것이 좋다.  

참고글 : https://tecoble.techcourse.co.kr/post/2020-05-07-appropriate_method_for_test_by_parameter/

메서드 시그니처를 수정하여 테스트하기 좋은 메서드로 만들기

 

중간 KPT 회고

로또의 랜덤 값과 당첨 번호를 매칭하여 당첨 통계 결과를 계산하는 부분이 가장 어려웠고, 이 부분이 핵심 기능이었다. 어떻게 해야 할지 막막했는데, 요구사항에서 else 사용을 지양하라는 지침 덕분에 if만으로 메서드를 작성하는 방식을 익히게 되었다. else를 지양하는 이유를 찾아보니 코드의 가독성을 높이고 복잡성을 줄여준다는 것을 알게 되었다. else를 사용하면 코드의 중첩도가 높아져 읽기 어렵고, 수정이나 로직 확장 시 실수가 발생하기 쉬우므로 if와 return을 적절히 활용해 명확하게 작성하는 것이 좋다는 점을 배웠다.

구현에 집중하다 보니 음수 값을 처리하는 예외 상황을 빠뜨린 것이 기억에 남는다. 1주차부터 신경 썼던 예외 상황을 3주차에 고려하지 못했다는 점이 아쉬웠다. 하지만 코드를 작성하면서 객체 지향적으로 설계하는 법을 체감할 수 있었다. 메서드를 15줄 이내로 작성해야 했기에 기능 단위를 최대한 분리하다 보니, 객체별로 작업할 수 있도록 구성하게 되었고, 자연스럽게 객체와 연관된 함수나 상수, 유효성 검사 파일들을 디렉터리별로 관리하고 기능별로 파일을 분리하게 되었다.

아쉬운 점은 View 클래스로 UI 로직을 분리하지 못한 것이다. 이로 인해 비동기 함수를 많이 사용하게 되었고, Lotto 클래스를 활용해 객체를 분리하려 했으나 UI 로직과의 통합이 어려워 따로 분리된 파일을 만들게 되었다. Lotto 클래스 파일을 통해 우아한테크코스의 의도를 충분히 이해하고 반영했어야 했는데, 그 부분을 놓친 것이 아쉽다. 다만 공통 피드백 덕분에 프라이빗 필드를 생성해 활용하는 법을 알게 되었고, 동작하는 코드에만 집중하다 놓쳤던 개념들을 제대로 이해할 수 있는 계기가 되어 의미가 깊었다.

결론적으로, 공통 피드백을 통해 3주차에 테스트 코드 작성법을 배우면서 예외 테스트에서 값이 동일할 경우 파라미터화된 테스트로 중복을 줄이는 방법도 알게 되었다. 또한 프라이빗 필드를 사용하는 방식과 객체 지향 설계의 필요성을 코드 작성 과정에서 체감할 수 있었다. 리팩토링 없이 완벽한 설계를 하기는 어렵고, 유지보수와 가독성을 높이며 결합도를 낮추기 위해서는 객체와 메서드가 잘 분리되어야 한다는 점을 리팩토링을 통해 깨닫게 되었다.

Keep (유지하면 좋은 점)

• 기능별로 파일을 분리하고 디렉터리를 구분하는 과정 거치기
  • 이 과정은 코드의 구조를 명확히 하고 가독성을 높여주는데 도움을 주었다. 파일을 구분하니 리팩토링을 할 때도 관리가 용이했기 때문에 앞으로도 습관화해야 하는 것 같다.
• 테스트 코드를 기능 구현할 때 마다 작성하는 것
  • 단위별로 기능을 구현할 때마다 테스트가 필요한 부분은 바로바로 작성하는 것으로 목표로 삼고 3주차를 진행했다. 아직 습관화되진 않았지만 의식적으로 테스트 코드를 작성하고 검증하는 과정을 거쳐야 할 것 같다. 
• 함수(메서드) 길이를 제한하는 기준을 지킨 것
  • 길이를 제한하여 기능 단위로 최대한 분리하여 메서드를 설계한 점은 객체 지향 설계에서 필요한 것 같다. 
  • 길이를 줄이기 위해서 기능을 분리하면 객체를 어떻게 분리하여 활용해야 하는 지 감이 잡히는 것 같다. 
  • 또한 클래스와 메서드의 역할이 명확해지는 것 같아 기준을 잘 잡아서 그 기준에 맞춰 설계해야 할 것 같다.

 

 Problem (고쳐야할 문제점)

• 프라이빗 필드를 사용하지 않아 객체 지향 설계 원칙을 지키지 못한 것
• 비즈니스 로직과 UI 로직을 분리하지 않아 단일 책임 원칙을 위배한 것
• 예외 상황을 충분히 고려하지 못한 것
• 클래스에서 getter를 남용한 것
• 필드를 불필요하게 남발하여 캡슐화하지 못한 것

 

Try (Problem을 기반으로 보완하여 새로 시도해볼 점)

• 프라이빗 필드를 사용하여 객체 지향 설계 원칙을 지켜 코드 구조를 설계할 것
• View 클래스를 만들어서 비즈니스 로직과 UI로직을 철저히 분리할 것
  • View 폴더에 InputView.js와 OutputView.js를 설계하여 명확히 구분하여 사용할 것이다.
• 예외 상황을 사전에 충분히 정의하고 설계하기
  • 기본적인 예외 상황을 충분히 고려한 후에 구현을 시작하고 그 이후에 추가적으로 고려해야 할 예외 상황을 추가하는 것으로 습관을 들인다.
  • 테스트 코드를 작성할 때 반복되는 테스트는 파라미터화된 테스트로 리팩토링 할 것 
• get 메서드를 사용하여 객체 값을 외부에서 변경 가능하도록 하는 것이 아니라 객체 메시지를 활용하여 객체 내부의 메서드로 작업을 수행하도록 할 것
• 필드를 최소화하고 캡슐화를 강화하기위해 필드의 역할과 관련성에 따라 클래스 구조 최적화하기

 

결론

KPT 회고의 사항과 공통 피드백을 잘 반영하여 코드를 설계하고 동작하는 코드를 구현하되, 원칙은 지켜 설계된 코드로 리팩토링 하는데에 집중해보고자 한다.