[우아한테크코스 4기 프리코스] 1주차 후기

1주차 과제 제출 이후 피드백 문서와 다른 사람의 코드를 보고 느낀점을 정리하려고 한다.

1주차 과제로 성장한 점

• 비즈니스 로직과 UI 로직을 구분하여 둘의 관심사를 분리하도록 하는 프로그래밍에 도전해보았다.

• lint와 code formatter 툴을 활용하면 더 빠른 시간에 문제점을 파악하여 해결할 수 있고, formatter를 통해 코드에 통일감을 줄 수 있다는 것을 알게 되었다.

• 명확한 의미를 갖는 네이밍에 대해 고민해보았고, 이번 과제에서 축약하여 표현하는 것이 왜 안좋은지에 대해 판단해보았다.

• 피드백을 통해 공백라인의 의미를 둘 수 있음을 깨닫게 되었다.

• 함수를 분리하여 하나의 함수가 하나의 일만을 하도록 구현해보았다.

• 값을 직접 코딩하였을 때의 문제점이 있을 수 있음을 깨닫게 되어 값들을 상수화 하였다.

공백라인에 의미를 줄 수 있다

다음은 제출한 풀리퀘의 내 코드의 일부이다.

  initDOM() {
    this.form = document.querySelector("form");

    this.input = document.querySelector("form input");

    this.result = document.querySelector("#result");

    this.restart = document.createElement("button");

    this.restart.setAttribute("id", "game-restart-button");

    this.restart.textContent = "재시작";
  }

위와 같이 짠 이유는 공백을 두면 눈의 피로가 덜 할것이며, 이는 가독성과 연관된다고 생각했기 때문인데 이렇게 짜게 되면 공백에 의미를 둘 수 없게된다.

예를 들어 공백을 다음과 같이 준다면 이를 읽는 개발자는 대게 의미를 파악할 수 있게 된다.

  initDOM() {
    // form과 관련된 DOM을 가져오는 코드구나
    this.form = document.querySelector("form");
    this.input = document.querySelector("form input");

    // 결과 화면과 관련된 DOM을 가져오는 코드구나
    this.result = document.querySelector("#result");
    
    // 재시작 버튼과 관련된 DOM을 만드는 코드구나
    this.restart = document.createElement("button");
    this.restart.setAttribute("id", "game-restart-button");
    this.restart.textContent = "재시작";
  }

공백을 의미있게 사용한다면 위와 같이 할 수 있을것이라 생각한다. 피드백에 따라 내 코딩 방식 ( 공백 라인에 의미를 두지 않고 눈의 피로를 덜기 위해 모든 라인을 공백으로 구분하는)이 좋지 않았음을 깨닫게 되었고 개선할 수 있었다.

eslint와 prettier의 사용

사실 이전 까지 이 둘의 쓰임이 필수적이라고 생각하지는 않았다. 하지만 1주차 과제에서 이를 필요하다고 느끼게 된 지점이 있는데, 다음과 같은 부분에서 이를 느끼게 되었다.

다음은 1주차 과제에서 결과 객체를 가지고 결과 템플릿 문자열을 만드는 함수이다. 딱히 문제 없어 보이지만, 다음 코드는 프로그래밍 요구사항을 지키지 못한 코드이다.

  static convertResultToString(result) {
    if (result[STRIKE] === FULL_COUNT) {
      return FINISH;
    }
    if (result[STRIKE] === ZERO_COUNT && result[BALL] === ZERO_COUNT) {
      return NOTHING;
    }

    if (result[STRIKE] !== ZERO_COUNT && result[BALL] !== ZERO_COUNT) {
      return `${result[BALL]}${BALL} ${result[STRIKE]}${STRIKE}`;
    }

    if (result[STRIKE] === ZERO_COUNT) {
      return `${result[BALL]}${BALL}`;
    }

    if (result[BALL] === ZERO_COUNT) {
      return `${result[STRIKE]}${STRIKE}`;
    }
  }

❌ 1. 함수 라인 수가 15라인이 넘어간다.
❌ 2. 공백 라인은 일종의 컨벤션인데, 이를 지키지 못하였다. (통일되지 못함)

만약 eslint의 도움을 받는다면 ? 다음과 같이 ide에서 한번에 오류가 있음을 파악할 수 있다. 피드백 문서에도 이러한 사항이 기술되어 있어 다음 과제에는 eslint를 적용하려 한다.

이번 과제를 통해 eslint-prettier 가 프로그래밍 요구사항을 지키는데 들어가는 비용을 줄이고, 코드에 통일감을 줄 수 있다는 것을 알게되었다. (만약 협업하는 상황이었다면, 더 큰 문제가 발생하였을것이다.)

프로젝트 목표에 신경쓸 것

어떤 프로젝트던 프로젝트 목표가 있기 마련이다. 다른 이유를 들어 이 목표를 무시하는 개발자가 있다면 그게 좋은 개발자일까 싶다고 평소에 생각하였는데, 이번 과제에서 내가 그랬다. 가독성에 너무 신경쓴 나머지 함수의 분리 라는 프로젝트 목표를 제대로 지키지 못하였다.

다음 코드는 함수 라인이 15라인이 넘어갔기에 함수의 분리를 지키지 못한 코드이다. (함수의 라인수를 줄이는 가장 좋은 방법은 함수를 분리하는 것이다)

  static convertResultToString(result) {
    if (result[STRIKE] === FULL_COUNT) {
      return FINISH;
    }
    if (result[STRIKE] === ZERO_COUNT && result[BALL] === ZERO_COUNT) {
      return NOTHING;
    }

    if (result[STRIKE] !== ZERO_COUNT && result[BALL] !== ZERO_COUNT) {
      return `${result[BALL]}${BALL} ${result[STRIKE]}${STRIKE}`;
    }

    if (result[STRIKE] === ZERO_COUNT) {
      return `${result[BALL]}${BALL}`;
    }

    if (result[BALL] === ZERO_COUNT) {
      return `${result[STRIKE]}${STRIKE}`;
    }
  }

이번 과제를 통해 프로젝트의 목표에 집중하는 개발자가 되어야겠다고 느끼게 되었다.

의미는 명확하게

딱 나에게 하는 말같았다. 이번 프로젝트에서 변수명, 함수명을 지을때 의미를 명확하게에 신경쓰기 보다 이름이 너무 길어져 읽는데 방해되는 것은 아닌가에 더 신경쓴 것 같다.

다음은 제출한 코드 중 일부인데, 단순히 checkValidation 이라고만 한다면, 어떤 것을 점검하는지 명확하게 알 수 없다.

export function checkValidation(str) {
  return (
    checkNumeric(str) &&
    checkLengthThree(str) &&
    checkNotDuplicate(str) &&
    checkExcludeZero(str)
  );
}

다음과 같이 이름을 짓는다면 위 코드보단 더 좋은 코드일 것이라고 생각된다. 의미가 인풋에 입력된 텍스트를 검증하는 함수구나라는 것을 한눈에 파악할 수 있다.

export function checkValidationOfInputText(str) {
  return (
    checkNumeric(str) &&
    checkLengthThree(str) &&
    checkNotDuplicate(str) &&
    checkExcludeZero(str)
  );
}

평소에도 변수명 함수명을 지을때 축약을 하곤하는데, 축약은 지양해야겠다고 느끼게 되었다.