2주차: 3장 코드에서 나는 악취 ~ 5장 리팩터링 카탈로그 보는 법

[choisohyun]

5장은 패스합니다.
코드작성, 주관식, 객관식, 단어퀴즈 등 자유롭게 문제를 작성해 코멘트로 달고, 답변을 그 밑에 작성합니다.

목차명	질문	답변
3장	3 @blan19	3 @blan19
3장	2 @RAINBOWJYP	1 @choisohyun
3장	4 @LastCow9000	5 @w00khyung
3장	8 @hamo-o	2 @RAINBOWJYP
4장	7 @BEMELON	6 @ssuojae
4장	6 @ssuojae	4 @LastCow9000
4장	1 @choisohyun	7 @BEMELON
4장	5 @w00khyung	8 @hamo-o

[LastCow9000]

4번 질문

1. 긴 함수(3.3)에서 추출할 코드 덩어리를 찾아내는 방법은 어떠한 것들이 있을까요?
2. 전역 데이터가 좋지 않은 이유는 무엇일까요?

[w00khyung]

1. 한 가지 좋은 방법은 주석을 참고하는 것입니다. 주석이 설명하는 코드와 함께 함수로 빼내고, 함수 이름은 주석 내용을 토대로 짓습니다. 조건문이나 반복문도 추출 대상의 실마리를 제공합니다. 조건문은 조건문 분해하기(10.1절)로 대응하고, 거대한 switch문을 구성하는 case문마다 함수 추출하기(6.1절)를 적용해서 각 case의 본문을 함수 호출문 하나로 바꿉니다. 같은 조건을 기준으로 나뉘는 switch문이 여러 개라면 조건부 로직을 다형성으로 바꾸기(10.4절)을 적용합니다. 반복문도 그 안의 코드와 함께 추출해서 독립된 함수로 만듭니다.
2. 전역 데이터는 코드베이스 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다는 게 문제입니다. 버그가 발생했을 때, 그 원인이 되는 코드를 찾아내기가 굉장히 어렵습니다.

[w00khyung]

5번 질문

Q. 다음과 같이 테스트 코드를 작성했을 때, 어떤 문제점이 생길 수 있고 어떻게 개선할 수 있을까요?

describe("province", () => {
  const asia = new Province(sampleProvinceData()); 
  
  it("shortfall", function () {
    expect(asia.shortfall).toBe(5);
  });

  it("profit", function () {
    expect(asia.profit).toBe(230);
  });
});

[hamo-o]

문제

공유 객체인 asia 의 값이 수정되었을 때, 이 픽스처를 사용하는 또 다른 테스트가 실패할 수 있습니다.
즉 순서에 따라서 성공할수도, 실패할수도 있는 불명확한 테스트가 됩니다.

개선

개별 테스트를 실행할 때마다 픽스처를 새로 만들면 모든 테스트를 독립적으로 구성할 수 있어 위 문제가 해결됩니다.

describe("province", () => {
  let asia;
  beforeEach(function() {
    asia = new Province(sampleProvinceData());
  });
  
  it("shortfall", function () {
    expect(asia.shortfall).toBe(5);
  });

  it("profit", function () {
    expect(asia.profit).toBe(230);
  });
});

[hamo-o]

추가로 부끄럽지만 제 과제 테스트코드의 일부인데요.

describe("sum()", () => {
  const calculator = new Calculator();
  test("한자리 숫자와 구분자 문자열이 주어졌을 때 숫자의 합 반환", async () => {
    calculator.init([], "1,2,3");
    expect(calculator.sum()).toBe(6);
  });

  test("여러자리 숫자와 구분자 문자열이 주어졌을 때 숫자의 합 반환", async () => {
    calculator.init([], "12,345");
    expect(calculator.sum()).toBe(357);
  });

  /* ... */

});

위 예제와 같은 방법으로 수정이 가능할 것 같습니다.

describe("sum()", () => {
  let calculator;
  beforeEach(function() {
    calculator =  new Calculator();
  });

  test("한자리 숫자와 구분자 문자열이 주어졌을 때 숫자의 합 반환", async () => {
    calculator.init([], "1,2,3");
    expect(calculator.sum()).toBe(6);
  });

  test("여러자리 숫자와 구분자 문자열이 주어졌을 때 숫자의 합 반환", async () => {
    calculator.init([], "12,345");
    expect(calculator.sum()).toBe(357);
  });

  /* ... */

});

[hamo-o]

8번 질문

1. 데이터 뭉치임을 어떻게 판별할 수 있을까요?
2. 아래 설명에 맞는 용어 (a), (b)를 작성해주세요.

• (a): 단일 책임 원칙(SRP)이 제대로 지켜지지 않을 때 문제가 되는 악취입니다.
• (b): 코드를 변경할 때마다 자잘하게 수정해야 하는 클래스가 많을 때 문제가 되는 악취입니다.

[RAINBOWJYP]

A1. 데이터 뭉치는 여러 메서드에서 동일한 데이터 조합이 사용될 때를 의미하는 것 같습니다. 데이터 뭉치임을 확인하려면 값을 삭제해봅니다. 그랬을 때 나머지 데이터만으로는 의미가 없다면 객체로 환생하면 좋을 데이터 뭉치입니다.

A2.
(a) 뒤엉킨 변경
(b) 산탄총 수술

[choisohyun]

1번 - 4장

Q. 테스트코드를 작성할 때 경계 조건을 어떤 관점에서 생각해 보면 좋을까요?

[BEMELON]

A.
책을 그대로 이용하자면.. 자기의 코드를 적으로 돌리며 프로그램을 망가뜨리는 방법 이라 하지만, 범위의 유효성 등을 파악하는 관점에서 생각해보면 좋을 것 같습니다

[RAINBOWJYP]

2번 질문

---

Q1. 함수 이름을 지으려는데 마땅한 이름이 생각나지 않습니다... 어떤 고민을 하면 좋을까요?
Q2. 전역 데이터를 왜 주의해야할까요?

[choisohyun]

A1. 함수 설계에 근본적인 문제가 있을 수 있습니다. 혼란스러운 이름을 정리하면서 코드를 간결하게 만들면 함수 이름을 짓는 데에 도움이 될 것입니다.
A2. 코드 베이스 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다는 문제가 있습니다. '유령 같은 원격작용'처럼 버그는 끊임없이 발생하는데 원인이 되는 코드를 찾아내기가 어렵습니다. 전역 데이터의 대표적인 형태는 전역 변수지만 클래스 변수와 싱글톤에서도 같은 문제가 발생합니다.
이를 방지하기 위해 변수 캡슐화하기 리팩터링을 사용합니다. 또한 접근자 함수를 클래스나 모듈에 집어넣고 접근 범위를 최소로 줄이는 것도 좋습니다.

[BEMELON]

7번 질문

---

1. 버그가 발생하였고, 해결과 동시에 회귀 테스트를 최대한 줄이고자 한다면 어떠한 식으로 해결해야 할까요?

[suojae]

1. 일단 버그가 발생되었음을 확인하면 해당 버그를 확인할 수 있는 단위테스트 코드를 작성합니다. 버그를 해결하기 전에 버그를 노출시키는 테스트를 작성함으로써, 동일한 문제가 재발하지 않도록 조치를 취합니다.
2. 테스트의 범위를 과도하게 넓히지 않고, 실제 문제를 다루는 테스트에 집중합니다. 책에서는 테스트 커버리지보다는 리스크 기반 테스트에 집중해야 한다고 말합니다. 모든 경우를 테스트하려는 것보다는 리스크가 높은 부분이나 복잡한 부분에 집중하는 것이 효율적입니다

[suojae]

6번 질문

문제1. 결과값으로 실패하는 케이스인 테스트 코드를 작성해야할까요? 작성해야한다면 왜일까요?
문제2. 테스트를 해야한다면 어떤 조건을 테스트하는게 좋을까요?
문제3. fixture가 테스트에서 중요한 이유는 무엇인가요?

[LastCow9000]

1. 실패 케이스를 테스트해야 하는가라는 것으로 이해하고 작성하겠습니다.
   • 작성해야 합니다. 버그로 인해 함수가 잘못된 결과를 반환할 수도 있기 때문입니다.
2. 해당 함수를 실행한 결과가 옳게 나온 조건과 틀리게 나온 조건, 경계 값을 테스트하면 좋습니다.
3. 테스트가 올바르게 수행될 수 있도록 하는 사전 조건이기 때문입니다. 특히 다른 곳에서 또 같은 fixture가 쓰일 경우, 오염 방지를 위해 beforeEach 구문을 사용하는 것이 좋습니다.

[blan19]

3번 질문

Q. 데이터 불변성을 왜 지켜야 할까요?
Q. 반복문이나 조건에 대한 로직 처리에 있어서 고차 함수를 사용한다면 명령형 프로그래밍 방식보다 무조건적으로 좋을까요?

[blan19]

1. 데이터의 불변성을 지키지 않고 원본 데이터를 수정한다면, 그 데이터를 참조하고 있는 다른 부분에서 예상하지 못한 동작을 야기할 수 있습니다. 그렇기 때문에 복사본을 만들어 원하는 수정을 하는 것이 좋습니다.

2. 팀 단위 프로젝트에서 고차 함수를 사용해 로직의 분리를 자주 사용해 프로그래밍 한다면 함수의 볼륨도 작아지고 조건도 생략할 수 있어 가독성과 유지보수성에서 좋을 수 있습니다. 처음에는 오히려 명령형 프로그래밍보다 가독성이 떨어질 수가 있다고 생각합니다. 하지만 팀이 고차 함수를 통한 로직 분리에 익숙해지는 궤도에 오른다면 생산성은 명령형 프로그래밍보다 좋다고 생각합니다.