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

[choisohyun]

인상깊었던 책의 내용과 인상깊었던 이유
현업 등 코드에 반영할 수 있는 방법과 생각
관련 아티클이나 이해를 돕는 자료를 첨부
새롭게 알게된 점이나 이해가 어려웠던 점

[BEMELON]

p.143 완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성해 실행하는 게 낫다
p.148 문제가 생길 가능성이 있는 경계 조건을 생각해보고 그 부분을 집중적으로 테스트하자

테스트를 작성했다! 의 만족감을 느끼고 배포하는 경우가 많은데, 테스트 작성한 개수가 중요한게 아님을 다시 한번 깨달았네요

p.150 테스트가 프로그래밍 속도를높여준다는 사실에는 변함이 없다. 그동안 나는 프로그램에서 발생할 수 있는 모든 경우를 테
스트하기 위한 다양한 기법을 봐왔다. 이런 기법이 도움되는 것은 분명하지만, 너무 빠져들 필요는 없다.

테스트로 효율적으로 작성하고 있었는 지, 테스트라는 핑계로 불필요한 일정 잡고 있지는 않았던 건지 다시 한번 생각.. 😢
테스트를 효율적으로 작성하는 방법에 대해서 고민을 하게 됐습니다

[jamongsalguclub]

p.143 테스트를 너무 많이 만들다 보면 오히려 필요한 테스트를 놓치기 쉽기 때문에 아주 중요한 포인트다.
p.150 그렇다면 테스트를 어느 수준까지 해야 할까? ... 또, 테스트를 너무 많이 작성하다 보면 오히려 의욕이 떨어져 나중에는 하나도 작성하지 않게 될 위험도 있다. 따라서 위험한 부분에 집중하는 게 좋다.

테스트 코드를 작성할 때, 어디서부터 어디까지 혹은 테스트 해야 할까? 라는 고민이 생기는데,
위험도 혹은 중요도를 기준으로 우선 순위가 높은 로직에 대한 테스트 코드를 작게라도 먼저 작성 해보면 좋을 것 같다는 생각이 드네요.

[blan19]

p.143 나는 적은 수의 테스트만으로 큰 효과를 얻고 있다. 잘못될까봐 가장 걱정하는 영역을 집중적으로 테스트하는데, 이렇게 해서 테스트에 쏟는 노력의 효과를 극대화하는 것이다.

매번 테스트 코드를 작성할 때, 귀찮다는 생각이 먼저 들었습니다. 돌이켜 보니 테스트 코드를 효율적으로 작성하지 않고 양으로 때우고 있는 부분이 많아 테스트 코드에 쏟는 노력이 과도했었던 것 같네요
효율적으로 테스트 코드를 작성하는 노력을 기울여야 하겠다는 생각이 들었습니다.

[choisohyun]

리팩터링은 '언제' 하느냐에 대한 명쾌한 답, 냄새 나면 당장 갈아라
주석을 많이 달았던 기능이 하나 있는데, 왜 주석을 많이 달게 됐었는지 알게 되었습니다...
테스트를 너무 많이 만들다 보면 오히려 필요한 테스트를 놓치기 쉽다.는 말이 인상깊었습니다. 중요한 유닛테스트만 한다고 하면 꽤 괜찮게 하고 있는 거일 수도 있겠습니다. 그치만 E2E 테스트가 없다보니 유닛테스트로 통과하더라도 UI에서 틀리면 무용지물이라는 생각이 들었습니다. UX 플로우도 간단하게 중요한 것만 다시 시도해 봐야겠습니다.

[RAINBOWJYP]

3장에서 예시로 나열해준 키워드가 뭔지 너무 궁금해졌습니다! 전부 이해할 수 없었지만 어떤 리팩터링 방법이 있는지 기대가 됩니다. 주석을 달기보단 주석이 필요없는 코드를 작성하고, 미래 확장성을 위해 고려된 코드는 실제로 사용되면 다행이지만 그렇지 않다면 쓸데없는 낭비이니 치워버리는 등의 얘기를 보고 작은 공감을 했습니다.
일정에 치이고... 할거 많고... 테스트 코드 작성할 시간에 기능 몇개 더 만들자 라는 불편한 생각으로 방치된 나.
자가 테스트 코드를 한 몸처럼 받아들여야할 때가 온 것 같습니다. 테스트도 리팩터링의 중요한 역할임을 다시 한 번 느낄 수 있었습니다.
근데 "작성 중인 코드는 최소한 몇 분 간격으로 테스트하고" 이 말을 보고 잠깐 기계 마음으로 이입을 할 뻔 했습니다.

[LastCow9000]

• 3장은 책에 쓰여진 리팩터링 기법들을 언제 사용해야 하는 지에 대한 파트입니다. 아직 리팩터링 기법들에 대한 지식이 없어서 100% 이해하기가 어려웠습니다. 책을 모두 읽은 후 다시 3장을 읽어봐야겠습니다.
• 테스트 커버리지 100%는 달성을 목표로 해서 개발 속도를 느리게 하는 것이 비효율적이라는 것에 동의합니다.

[hamo-o]

주석을 남겨야겠다는 생각이 들면, 가장 먼저 주석이 필요 없는 코드로 리팩터링해본다.

타입스크립트에 익숙하기 때문에 자바스크립트 코딩을 할 때는 jsDoc을 꼭 사용했는데요. 아무 생각 없이 모든 코드에 설명을 다는 것이 아니라 꼭 필요한 코드에만 설명을 달고, 되도록 필요 없는 코드로 리팩터링해봐야겠습니다!

성의 없는 요소

• 본문 코드를 그대로 쓰는 것과 진배없는 함수
• 실질적으로 메서드가 하나뿐인 클래스

추측성 일반화로 인한 성의 없는 요소를 만들었다는 것을 깨달았습니다. 너무 기능 단위 분리에 집중해서 놓친 부분인 것 같습니다.

테스트는 위험 요인을 중심으로 작성해야 한다.

• 단순히 필드를 읽고 쓰는 접근자는 테스트 X
• 너무 많은 테스트를 만들면 필요한 테스트를 놓치기 쉽다.

최근 진행하고 있는 과제에서 TDD를 시도했는데, 위 내용을 간과하고 있다는 생각을 하게 되었습니다. 실제로 중요한 요구사항을 놓치기도 해서 꼭 위험 요인을 먼저 테스트 하는게 좋을 것 같아요.

describe("province", () => {
  const asia = new Province(sampleProvinceData()); // 이렇게 하면 안 된다.
  
  it("shortfall", function () {
    expect(asia.shortfall).toBe(5);
  });

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

처음으로 테스트 코드 작성을 제대로 연습해보고 있는데, 정확하게 제 코드랑 같아서 민망해졌네요. 개별 테스트 실행 시마다 픽스처 생성하도록 수정해야겠습니다.

이외에도 책을 읽으면서 많은 부분에서 굉장히 찔렸네요. 뒷부분에서 해결 방법을 배우고 빨리 제 코드에 적용해보고 싶습니다!!