DAY 21

🔖 오늘 읽은 범위 : Final mission

---

🤓 책에서 기억하고 싶은 내용

Final mission을 위한 총정리

• 우리는 코드의 저자다. 독자와 잘 소통할 수 있는 깨끗한 코드를 쓸 책임이 있다
• 코드를 읽기 쉽게 만들면 짜기도 쉽다
• 중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기 → 진짜 문제에 신경 쓸 여유 생김
• 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.
• 변수가 길면 오히려 검색하기 쉽다.
• 발음하기 쉬운 이름을 사용하라 → 젠야무다힘즈 금지
• 예쁜이름은 사람에게 클래스는 컴파일러에게
• 추상적인 개념 하나에는 일관된 단어를 선택해 고수하라
• IDE의 자동완성을 생각해서라도 불필요한 접두사 다 붙이지말자
• 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다.
• 한가지(지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행) 만 해라
• 함수 인수는 적을 수록 좋다.
• 부수 효과를 일으키지 마라!
• 명령과 조회를 분리하라!
• 오류 코드보다 예외를 사용하라!
• 500줄을 넘지않는 평균 200줄의 파일로도 커다란 시스템을 구축할 수 있다
• 신문 기사처럼 작성하라: 추상화 → 세부적, 유사개념은 가까이
• 객체는 새 타입을 추가하기는 쉽지만 새 동작을 추가하기는 어렵다
• 자료 구조는 새 타입을 추가하는건 어렵지만 새 동작을 추가하기는 쉽다
• 우수한 개발자는 무조건 객체지향이 아니라 경우에 따라서는 절차지향의 자료구조도 잘 쓴다
• 오류보다 (미확인)예외를 활용하라
• 예외를 일으키는 try-catch 먼저 완성 시키고 로직을 추가하자
• Error wrapper class 를 활용해서 의존성을 줄이자
• 특수상황을 기본 값으로 리턴함으로서 불필요한 에러 처리(중단)를 제거
• NULL을 반환하지 말고 예외나 특수 객체를 반환
• 메서드로 NULL을 전달하지 말고 새로운 예외를 던지거나 assert문 활용
• 자동화된 단위 테스트 슈트는 변경이 쉬워지게 함 → 설계와 아키텍처를 최대한 깨끗하게 보존 가능
• 가독성은 실제 코드보다 테스트 코드에서 더 중요하다 → Build-Operate-Check 패턴
• 테스트 코드는 실제코드만큼 효율적일 필요는 없다 → 테스트 환경에서 수행되기 때문
• 개념 당 assert문 수를 최소로 줄이자
• 테스트 함수 하나는 개념 하나만 테스트
• 테스트는 Fast, Independent, Repeatable, Self-Validating, Timely 해야한다
• 클래스 책임의 개수는 작아야 한다 → 간결한 25단어 내외
• 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠넣기
• 클래스를 분리하여 응집도를 높여라
• 클래스를 작게 분리하여 변경하기 쉽도록 한다
• 구체적인 구현보다는 추상화를 통해 변경으로부터 격리한다
• SRP, OCP, DIP 원칙 지키기

1. 한가지(지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행) 만 해라

🥲 **Before**

const handleConnect = () => {
    let config = data[dbIdx];
    localStorage.setItem("alias", config.alias);
    localStorage.setItem("config", JSON.stringify(config));
    execPost("/connect", {
      config: config,
    })
      .then((res) => {
        console.log(res.data);
        if (res.data === "CONNECTED") {
          setIsConnected(true);
          history.push("/dashboard");
        }
      })
      .catch((err) => {
        console.log(err);
      });
  };

😍 **After**

const handleConnect = () => {
		let config = data[dbIdx];
		saveConnect();
    moveToDashboard();
  };

const saveConnect = () => {
  localStorage.setItem("alias", config.alias);
  localStorage.setItem("config", JSON.stringify(config));
}

const moveToDashbaord = () => {
		execPost("/connect", {
      config: config,
    })
      .then((res) => {
        console.log(res.data);
        if (res.data === "CONNECTED") {
          setIsConnected(true);
          history.push("/dashboard");
        }
      })
      .catch((err) => {
        console.log(err);
      });
}

• handleConnect에서 하는 일이 여러가지여서 각각의 함수로 분리하여 saveConnect와 moveToDashboard 를 수행
• argument에 대한 것은 함수 밖의 것을 써도 괜찮은건지 다시 검토가 필요하다

2. 발음하기 쉬운 이름을 사용하라

🥲 **Before**

const toYYYYMMDD = (date) =>
    new Date(date - date.getTimezoneOffset() * 60000)
      .toISOString()
      .split("T")[0];

😍 **After**

const generateDate = (date) =>
    new Date(date - date.getTimezoneOffset() * 60000)
      .toISOString()
      .split("T")[0];

• 책에서 genymdhms젠야무다힘즈 라는 이름을 봤을때는 박장대소했다. 하지만 나에게도 있었다.. 투와이와이와이와이엠엠디디 가...
• 당장 함수 이름을 바꿨다 → generateDate 로

3. NULL을 반환하지 말고 예외나 특수 객체를 반환

🥲 **Before**

function closePool(name) {
  if (Object.prototype.hasOwnProperty.apply(POOLS, [name])) {
    const pool = POOLS[name];
    delete POOLS[name];
    if (typeof pool.close === "function") {
      return pool.close();
    } else {
      return null;
    }
  }
}

😍 **After**

function closePool(name) {
  if (Object.prototype.hasOwnProperty.apply(POOLS, [name])) {
    const pool = POOLS[name];
    delete POOLS[name];
    if (typeof pool.close === "function") {
      return pool.close();
    } else {
      throw Error("Could not close pool")
    }
  }
}

• Pool을 close 할 수 없을 때 null을 return하는 것이 아니라 확실한 Error 을 throw 하는 것으로 변경

🤔 떠오르는 생각

• 일단 수정할 코드의 양이 부족했다. 지금까지 작성한 코드나 레포의 개수는 많다고 생각했으나 실제로 살펴보면 대부분의 코드가 프론트엔드이고 니꼬샘의 강의를 기반으로 이미 작은 함수로 잘 쪼개져 있어 예시를 찾기가 너무 어려웠다.

🔎 질문

📝 소감 3줄 요약

• 막상 나 자신의 코드에서 책의 내용을 적용하여 더러움을 찾으려니 어려웠다
• 청소할 거리를 만들 수 있게 스크래치부터 작성하는 코드의 양을 늘려야 겠다
• Refactoring은 정말 많은 시간과 노력을 들여 지속적으로 수행해야겠다