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

글의 목표

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

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

 

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

 2주차의 학습 목표는 여러 역할을 수행하는 큰 함수를 단일 역할을 수행하는 작은 함수들로 분리하는 것이었다. 3주차 학습 목표는 관련된 함수들을 묶어 클래스를 만들고, 객체들이 협력하여 하나의 큰 기능을 수행하도록 하는 것이다. 그런데 지금보니 Controller를 만들면서 이미 하나의 큰 기능을 수행하는 클래스를 구현해본 것 같다. 이 방법을 응용해, 3주차에는 클래스를 더 정교하게 만들고, 함수와 클래스에 대한 단위 테스트 작성에 집중해야겠다고 생각했다.

 또한 2주차 목표 중 하나였던 테스트 도구 사용법을 배우는 부분이 아직 쉽지 않았다. 테스트 코드를 잘 짜는 것과 디버깅을 통한 오류 수정에 익숙하지 않다 보니, 유튜브에서 강의를 찾아 급하게 배우려고 했는데 생각보다 강의가 많지 않았다. 아마 인프런에서 관련 강의를 찾아 천천히 배워야 할 것 같다.

 1주차에 함수 작성만으로도 시간이 오래 걸렸던 나였는데, 이제는 함수와 메서드를 작은 역할로 분리하고, 이를 클래스로 구성하여 하나의 큰 기능을 수행하도록 사고하는 과정까지 발전했다는 점이 뿌듯하다. 방향성을 제시해주는 테스트가 있고 이를 통과하면서 느껴지는 성취감 덕분에 성장하는 기분이 든다.

 

공통 피드백 확인

[README.md를 상세히 작성한다]

 나 자신에세 README.md 의 역할을 명확하게 알아보고 작성을 시작했는 지 물어본다면 아마 아니라고 대답할 것이다.. 무엇이든 궁금증을 가지고 "왜?"라는 질문을 던졌어야 하는데 리드미 파일에 대한 명확한 역할을 생각하지 못했나보다. 어쩌면 모두가 요구사항을 작성하는 파일이고 코드에 대한 설명이 되는 문서이니까 여기에 작성해야 하는 것 아닌가? 라는 생각을 했다.

근데 공통 피드백을 보니 "소스 코드 이전에 프로젝트의 개요를 소개하는 문서" 라고 적어주셨다. 요구사항에 대한 체크리스트만 담아서 관리하는 파일인가? 하는 막연한 결론을 내렸는데 "프로젝트의 개요"를 담은 문서가 되어야 한다는 것을 몰랐던 것 같다.

해당 프로젝트가 어떤 프로젝트인지, 주요 기능이 무엇인지 소개할 수 있다고 말씀해주셨다. 마크다운 문법을 활용하여 3주차의 리드미에는 어떤 코드 구현인지 간략한 설명을 추가한 리드미 파일을 작성해야겠다.

[기능 목록을 재검토한다]

 기능 목록을 작성할 때 클래스 설계와 구현, 메서드 설계와 구현 같은 상세한 내용은 포함하지 않는다. 

놀랍게도 피드백의 두 가지 중 한 가지만 동일하게 작성하였다.

예외 상황을 함께 정리한 것은 잘했지만 클래스 이름, 반환값 등은 언제든지 변경될 수 있어서 기능 목록을 작성할 때 포함하지 않는 것이 좋다고 한다.

반환값을 입력하고 예외사항을 추가해둔 2주차이다. 

결론적으로 구현 같은 상세한 내용은 포함하지 않는 것이 좋으니 최대한 기능 목록을 중심으로 작성해야겠다.

// 예시 (리드미 작성하면서 변동 가능)

프로젝트 주제 : 도서 관리 시스템 구축
- 도서 등록 기능

- [ ] 새 도서를 시스템에 등록한다.

- 예외상황

- [ ] 입력된 도서 정보가 누락된 경우

[기능 목록을 업데이트한다]

 리드미 파일의 기능 목록은 구현 과정에서 변경될 수 있기 때문에 처음에 작성할 때 부담을 갖는 것보다 지속적으로 업데이트 하는 것이 낫다고 한다.

1주차에는 처음 작성하는 리드미 파일인 만큼 작성에 많은 시간을 들였는데 2주차에는 기능 구현이 어려울 것 같아서 기능 목록을 빠르게 정리하고 개발에 들어가는 게 목표였다. 그러다보니 예외 사항 처리를 많이 못해서 아쉽게 끝났다.

이번에는 피드백을 반영하여 기능 목록을 작성하고 기능 목록대로 구현하면서 예외 사항을 바로바로 추가하여 살아있는 문서로 유지될 수 있도록 노력해보아야겠다.

[값을 하드 코딩하지 않는다]

 코드 내에서 문자열이나 숫자 값을 하드 코딩하지 않는다. 대신 상수(const)를 정의하고 의미 있는 이름을 부여하여 해당 값이 어떤 역할을 하는지 명확히 드러낸다. 

// 하드코딩 된 예
function calculateTotal(price) {
    return price * 0.1; // 여기서 0.1은 세율로 가정
}

// 상수를 사용한 코드

const TAX_RATE = 0.1;

function calculateTotal(price) {
    return price * TAX_RATE;
}

[구현 순서도 코딩 컨벤션이다]

클래스는 필드, 생성자, 메서드 순으로 작성한다.

gpt에게 위의 순서에 맞는 예시 클래스를 하나 작성해달라고 부탁해보았다.

class Person {
    // 필드 정의
    constructor(name, age) {
        // 생성자 정의 및 필드 초기화
        this.name = name;
        this.age = age;
    }

    // 메서드 정의
    displayInfo() {
        console.log(`이름: ${this.name}, 나이: ${this.age}`);
    }
}

// 객체 생성 및 사용 예시
const person1 = new Person("홍길동", 30);
person1.displayInfo();  // 출력: 이름: 홍길동, 나이: 30

필드는 클래스가 가지는 고유의 속성을 의미한다. 위의 코드에서는 name과 age가 Person 클래스의 필드가 된다.

그리고 생성자는 constructor를 의미한다. 클래스가 인스턴스화 될 때 (= 객체가 생성될 때) 자동으로 호출되는 특별한 함수를 의미한다. this 키워드를 통해 필드를 초기화한다.

마지막으로 displayInfo()가 메서드가 된다. 이렇게 필드, 생성자, 메서드 순으로 클래스를 작성해나가는 연습을 해야겠다.

[한 메서드가 한 가지 기능만 담당하게 한다]

2주차의 과제에서는 하나의 함수가 한 가지 동작만 하도록 만들어야 한다는 학습 목표를 받고, 클래스 객체를 만드는 법을 연습하다가 클래스의 메서드도 한 가지 기능만 담당하도록 분리하는 리팩토링을 진행했었다. 

이번 3주차에도 동작들을 최대한 분리해서 메서드를 만드는 과정을 거쳐야겠다.

아래와 같이 안내 문구 출력, 사용자 입력 처리, 유효값 검증 등의 작업이 한 함수에 포함되어있을 때 각기 다른 함수로 분리해보는 연습이 필요하다.

const userInput = () => {
  MissionUtils.Console.readLine("경주할 자동차 이름을 입력하세요(이름은 쉼표(,)를 기준으로 구분): ", (input) => {
    const carNames = input.split(",");
    for (int index = 0; index < carNames.length; index++) {
      if (carNames[index].length < 1 || carNames[index].length > 5) {
        throw new Error("[ERROR] 자동차 이름은 1자 이상 5자 이하만 가능합니다.");
      }
    }
    return carNames;
  });
};

 

▼ 분리 예시

// 사용자가 자동차 이름을 입력하도록 요청하는 함수
const getUserInput = () => {
  return MissionUtils.Console.readLine(
    '경주할 자동차 이름을 입력하세요(이름은 쉼표(,)를 기준으로 구분): '
  );
};

// 사용자가 입력한 자동차 함수 배열로 추출
const carName = (userInput) => {
  return userInput.split(',');
};

// 자동차 이름값이 유효한지 확인
const validateCarName = (carName) => {
  if (carName.length < 1 || carName.length > 5) {
    throw new Error('[ERROR] 자동차 이름은 1자 이상 5자 이하만 가능합니다.');
  }
};

// 실행 함수
const getCarNames = (userInput) => {
  const carNamesArray = carName(userInput);
  carNamesArray.forEach(validateCarName);
  return carNamesArray;
};

위와 같이 기능별로 함수를 나눌 수 있다. 함수를 사용하는 예시는 따로 작성하지 않았고, 어떻게 나누는지에 대해서만 감을 잡아보았다.

[메서드가 한 가지 기능을 하는지 확인하는 기준을 세운다]

여러 메서드에서 중복되는 코드가 있다면 이를 별도 메서드로 분리하는 것을 고려한다.메서드의 길이가 길어진다는 것은 여러 기능을 포하하고 있을 가능성이 커지므로 15라인이 넘지 않도록 구현하는 연습을 하면 의식적으로 분리하는 연습을 할 수 있다.

"15라인이 넘지 않게 코드를 작성하자" 와 같은 기준을 세우면 될 것 같다.

[테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리해본다]

테스트를 작성하면 기능의 정확성을 점검함을 넘어 코드의 즉각적인 피드백을 받을 수 있다. 테스트 작성 과정을 통해 구현한 기능의 문제를 빠르게 발견할 수 있을 뿌난 아니라, 코드의 구조와 의도를 명확히 이해하는데도 도움을 받을 수 있다고 한다. 

그러한 테스트 코드의 장점을 내 경험을 토대로 가장 공감하는 이유를 작성해보는 것이다.

[처음부터 큰 단위의 테스트를 만들지 않는다]

테스트의 핵심 목적 중 하나는 코드에 대해 빠르고 자주 피드백을 받는 것이다. 처음부터 큰 단위의 테스트를 작성하게 되면, 작성한 코드의 문제를 발견하기까지 시간이 오래 걸린다고 한다. 그렇기 때문에 최대한 작은 단위로 나눠서 테스트를 만들어가는 것이 효과적이라고 한다.

예시

큰 단위 테스트

• 자동차 경주 게임을 시작하여, 사용자가 이름과 진행 횟수를 입력하고, 게임을 진행한 후 결과를 확인한다.

작은 단위 테스트

• 무작위 값이 4 이상이면 자동차가 전진한다.
• 무작위 값이 3 이하이면 자동차가 전진하지 않는다.

[JavaScript에서 객체를 만드는 다양한 방법을 이해하고 사용한다]

JavaScript에서는 클래스를 사용하는 방법 이외에도 객체를 만드는 다양한 방법이 존재한다.

다양한 객체 생성 방식을 익히면 유연하게 코드를 설계할 수 있다.

나에게 가장 필요한 피드백이었을지도 모른다. 역시 유연하게 코드를 설계하기 위해서는 다양한 방법을 공부해나가는 것이 필수적인 것 같다.

두 가지 참고글을 확인하고 코드를 설계해나가야겠다. 현재의 계획은 리드미 파일 작성 -> 객체 생성 방법 공부 -> 기능 구현 순서이다!

▼ 자바스크립트 객체 만드는 다양한 방법

• https://developer.mozilla.org/ko/docs/Learn/JavaScript/Objects/Basics
• https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Classes

 

중간 KPT 회고

2주차에는 학습 목표에 맞춰 과제를 완성하려고 노력했다. 처음 기능을 봤을 때 1주차보다 더 어려워 보였고, 시험 기간과 겹쳐 시간적 여유도 부족했다. 그래서 테스트를 통과하는 것을 가장 큰 목표로 삼았고, 예외 사항까지 깊이 생각하지 못한 채 기능 구현에만 집중했던 것 같다.

두 번째 학습 목표는 테스트 도구를 사용하는 방법을 배우고, 프로그램이 제대로 작동하는지 테스트해보는 것이었다. 하지만 마지막 날까지 함수 분리와 기능 구현에 집중하다 보니 테스트 도구 사용이 익숙하지 않아서, 기본적인 문법으로 간단한 부분에 대해서만 빠르게 테스트 코드를 작성해볼 수 있었다.

또한 1주차와 달라진 점이라면, 이번에는 6기 분들이 만든 웹 서비스 CoReA: https://code-review-area.com/intro 사용해 맞리뷰를 받을 사람을 매칭받은 것이다 ㅎㅎ. 리뷰해주신 분들께 정말 감사했고, 나도 매칭된 분들께 리뷰를 해드리고 싶었지만… 나에게 매칭된 분들은 정말 대단한 분들이었다. 세 분 모두 리뷰해주신 분이 5분이 넘었고, 코드도 깔끔했다. 내 코드에도 부족한 점이 많다고 느끼는 나는 다른 분의 코드를 읽고 리뷰할 역량이 부족하다고 느꼈다. 그래서 리뷰를 달아드리지 못해 죄송했지만, 그 덕분에 좋은 코드를 읽어볼 수 있었다.

또한 6기 선배들의 서비스가 너무 잘 만들어져서 사용하는 데 어려움이 없었고, 덕분에 2주차에서 나의 부족한 점을 리뷰어 분들을 통해 알게 되어 큰 도움이 되었다. 나처럼 커뮤니티 사용에 익숙하지 않고 리뷰는 받아보고 싶은 초보자들은 한번 참가해봐도 괜찮은 서비스인 것 같다 ㅎㅎ

Keep (유지하면 좋은 점)

우선 함수와 메서드 분리는 최대한 작게 만든 것 같아서 3주차에도 잘 적용하여 기능에 따라 분리하는 것이 좋을 것 같다. 리뷰어분들도 함수를 최대한 분리한 부분에 대해서 칭찬해주셔서 기분이 좋았다. 그리고 내 목표였던 작은 함수로 잘 분리하고자 한 의도가 드러난 것 같아 뿌듯했다.

남겨주신 코멘트

따뜻한 리뷰어분들.. 그리고 이 분들의 리뷰도 달아드리고 싶어서 들어가보니 매우 고수셨던 ..

머쓱해하며 코드만 읽고 발을 뺐던..

그리고 커밋할 때 수정된 파일명을 <scope> 부분에 함께 입력하니 알아보기 편한 커밋을 만들 수 있었던 것 같다.

이렇게 기능 추가 커밋에  feat을 쓰고 괄호 안에 파일 명을 입력하니 훨씬 알아보기 쉬워진 것 같다. 이 두가지는 3주차 코드 작성에서도 가져가야 할 부분인 것 같다.

 Problem (고쳐야할 문제점)

늘 나의 행동에서 가장 아쉬운 점은 결국 꼼꼼하지 못했던 부분인 것 같다. 머리를 많이 썼거나 힘들다고 판단되면 빠르게 머리를 식혀주기 위해 꼼꼼함의 능력이 급격히 낮아진다. 철자를 틀리고, 상수를 넣는 파일에 함수를 마지막에 옮겨두는 등 생각이 짧아지는 순간을 최대한 줄여야 한다. 그리고 내가 직접 쓴 코드니 두번, 세번 제출하기 전에 확인하는 습관이 필요한 것 같다.

아마 2주차는 시간이 짧은 만큼 빨리 해야 한다는 생각에 실수한 부분이 많은 것 같다. 하지만 시간이 촉박한 순간들은 살면서 많이 있을 것이고 그때마다 실수할 수는 없는 노릇이니 자주 확인하는 습관을 기르는 것은 매우 중요할 것 같다. 그리고 철자가 틀리는 것은 리뷰어 분이 추천해주신 'Code Spell Checker'라는 확장자를 사용해보니 철자는 잘 잡을 수 있을 것 같아서 너무 감사했다. 

그리고 파일명의 역할에 맞춰서 함수를 입력하고, 스타일 가이드에 맞춰서 작성하도록 노력해야 하는 점이 필요하다.

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

 2주차에 디버거 과정을 잘 활용하지 못해서 아쉬움이 남았다. 3주차에는 2주차의 Try인 디버거 과정을 적극적으로 활용해보고, 테스트 코드를 잘 작성하여 단위별로 테스트를 진행하면서 코드를 작성해볼 생각이다. 이렇게 단위별로 테스트를 작성하고 기능별로 함수를 작게 분리하면 하나의 함수에 대해 여러 번 확인할 수 있어서, 이전에 부족했던 꼼꼼함을 보완할 수 있을 것이라고 생각된다.

또한 리뷰어분이 추천해주신 코드 안정성 방법들을 적용해볼 것이다. private 변수를 통해서 클래스 외부에서 직접적으로 접근하지 못하게 만드는 방법과 스타일 가이드에 맞춰 for반복문 대신 forEach, map을 사용하여 배열을 확인하는 과정을 거쳐야할 것 같다.

유저에게 입력받는 값을 `Constants.js`와 같은 파일에서 관리하면 유지관리성이 높아진다는 리뷰를 받고, 적극적으로 수용할 생각이다! 유지관리성이 높아지는 이유에 대해 찾아보니, 코드 가독성이 향상되고 중복 코드 방지가 가능해지며, 유저 입력 관련 값이 한 파일에 모여 있어 변경이 필요할 때 한 곳만 수정하면 된다는 장점이 있다. 

생각해보니, 하나의 파일에 모든 값들이 모여 있을 때, 특정 값을 수정하면서 다른 값들도 하나씩 모두 변경해줘야 했던 경험이 있다. (1주차) 이를 통해, 파일을 나눠 관리하는 방식이 확실히 코드 관리에 수월하다는 것을 느꼈다.

 

최종 Todo 정리

- [ ] 하드 코딩 하지 않기 위해 구글에 “javascript const” 검색하여 작성법 알아보기
- [ ] 메서드가 한 가지 기능을 하는지 확인하는 기준 세우기
- [ ] 테스트를 작성하는 이유에 대해 정리
- [ ] 자바스크립트 다양한 객체 생성 방법 익히기