[우테코 5기 프론트엔드] 프리코스 3주차 피드백 정리

💡 함수(또는 메서드) 라인에 대한 기준 정하기

• 하나의 메서드가 하나 일만 할 수 있도록 코딩 하기.
• 만약 한 메서드가 15 라인이 넘어간다면, 메서드를 더 나눌 수 있는지 고민해보자. (공백포함) 🤔

💡 발생할 수 있는 예외상황을 고민해보자

• 항상 예외상황을 고려하면서 프로그래밍 하는 습관이 필요하다.
• 예외상황을 처리할 수 있어야 한다.

💡 비지니스 로직과 UI 로직의 구분하기

• ❓비지니스 로직이란?
  • 유저의 눈에는 보이지 않지만, 유저가 바른 결과물을 올바르게 도출 할 수 있도록 짜여진 코드 로직
• ❓UI 로직 이란?
  • 유저에게 의사결정을 할 수 있도록 입력을 제공하며, 결과를 외부 서비스/DB/UI에 업데이트하는 로직
• 비즈니스 로직과 UI 로직을 한 클래스가 담당하지 않도록 하기.
• 단일 책임의 원칙에도 위배된다.

💡 객체의 상태 접근을 제한하기

• 최대한 private 필드로 생성하여, 외부에서 직접 접근하는 방식을 최소화하기.
• 객체 내부적으로 사용하는 변수나 메소드에 사용자가 접근함으로서 개발자가 의도하지 못한 객체의 로직을 보호하기 위함이다.
• 사용자에게 객체를 조작 할 수 있는 수단만을 제공함으로서 결과적으로 객체의 사용에 집중 할 수 있도록 하기 위함 이다.
• 더불어 데이터를 조금 더 안전하게 보관할 수 있게 된다.

💡객체는 객체스럽게 사용하기

• 객체 데이터를 꺼내려 하지 말고, 데이터를 객체에게 쥐어주고 필요한 결과값을 반환하도록 만들자.

💡필드의 수를 줄이기 위해 노력하기

• 필드가 많으면, 버그 발생률을 높일 수 있다.
• 중복되거나, 불필요한 필드가 있는지 체크한다.

💡예외 케이스도 꼼꼼하게 테스트하기

• 결함이 자주 발생하는 부분 중 하나는 경계값이므로 꼼꼼하게 확인해야 한다.

💡테스트 코드도 리펙토링하기

• 반복적으로 하는 부분을 중복되지 않게 만들기
• 파라미터만 바뀌는 건 아래 코드와 같이 줄이기

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

💡테스트를 위한 코드는 구현하지 말기

• 테스트를 위해 # prefix를 바꾸는 경우는 없다
• 테스트 코드에서만 사용되는 메서드는 구현하지 말기

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

• 단위 테스트가 어려운 코드를 단위 테스트가 가능하도록 리펙토링하기
• 테스트하기 어려운 부분은 단위 테스트하지 않아도 된다