clean-code-javascript

KO | EN

gitlite — search

#react #ai #typescript #golang #rust #linux #windows #awesome #kubernetes #awesome-list #security #ios #mcp #openai

clean-code-javascript

(★ 94,761)

JavaScript 환경에 맞게 적용된 Clean Code 개념들

파일 탐색기

최종 버전 다운로드 (.zip)

.gitattributes
LICENSE
README.md

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# clean-code-javascript

## 목차

1. [소개](#introduction)
2. [변수](#variables)
3. [함수](#functions)
4. [객체 및 자료 구조](#objects-and-data-structures)
5. [클래스](#classes)
6. [SOLID](#solid)
7. [테스팅](#testing)
8. [동시성](#concurrency)
9. [에러 핸들링](#error-handling)
10. [포매팅](#formatting)
11. [주석](#comments)
12. [번역](#translation)

## 소개

![코드를 읽을 때 내뱉는 욕의 횟수로 소프트웨어 품질을 측정하는 것을 풍자하는 이미지](https://www.osnews.com/images/comics/wtfm.jpg)

로버트 C. 마틴(Robert C. Martin)의 저서 [_Clean Code_](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)에 나오는 소프트웨어 공학 원칙들을 JavaScript에 맞게 적용한 것입니다. 이것은 스타일 가이드가 아닙니다. JavaScript에서 [읽기 쉽고, 재사용 가능하며, 리팩터링하기 쉬운](https://github.com/ryanmcdermott/3rs-of-software-architecture) 소프트웨어를 작성하기 위한 가이드입니다.

여기에 있는 모든 원칙을 엄격하게 따를 필요는 없으며, 모든 이가 보편적으로 동의하는 원칙은 더더욱 적을 것입니다. 이것들은 가이드라인일 뿐이지만, _Clean Code_의 저자들이 오랜 시간 동안 축적된 집단적 경험을 바탕으로 성문화한 것들입니다.

소프트웨어 공학이라는 장인은 겨우 50년이 조금 넘었으며, 우리는 여전히 많은 것을 배워나가고 있습니다. 소프트웨어 아키텍처가 아키텍처 자체만큼 오래된다면, 그때쯤이면 우리가 따라야 할 더 엄격한 규칙들이 생길지도 모릅니다. 지금으로서는, 이 가이드라인이 여러분과 여러분의 팀이 작성하는 JavaScript 코드의 품질을 평가하는 시금석 역할을 하도록 하세요.

한 가지 더: 이것들을 안다고 해서 당장 더 나은 소프트웨어 개발자가 되는 것은 아니며, 수년 동안 이것들과 함께 일했다고 해서 실수를 하지 않는 것은 아닙니다. 모든 코드는 젖은 점토가 최종 형태로 빚어지듯 초안에서 시작됩니다. 동료들과 함께 코드를 리뷰하면서 불완전한 부분들을 깎아내게 됩니다. 개선이 필요한 초안을 작성했다고 해서 자신을 자책하지 마세요. 대신 코드를 혼내주세요!

## **변수**

### 의미 있고 Pronounceable(발음하기 쉬운) 변수명을 사용하세요

**Bad:**

```javascript
const yyyymmdstr = moment().format("YYYY/MM/DD");
```

**Good:**

```javascript
const currentDate = moment().format("YYYY/MM/DD");
```

**[⬆ 맨 위로](#table-of-contents)**

### 동일한 유형의 변수에는 동일한 Vocabulary(어휘)를 사용하세요

**Bad:**

```javascript
getUserInfo();
getClientData();
getCustomerRecord();
```

**Good:**

```javascript
getUser();
```

**[⬆ 맨 위로](#table-of-contents)**

### 검색 가능한 이름을 사용하세요

우리는 작성하는 코드보다 읽는 코드가 훨씬 더 많습니다. 우리가 작성하는 코드가 읽기 쉽고 검색 가능하도록 만드는 것은 중요합니다. 프로그램 이해에 도움이 되는 의미 있는 이름을 변수에 부여하지 않음으로써, 우리는 코드를 읽는 사람들에게 피해를 줍니다.
이름을 검색 가능하게 만드세요. [buddy.js](https://github.com/danielstjules/buddy.js) 및 [ESLint](https://github.com/eslint/eslint/blob/660e0918933e6e7fede26bc675a0763a6b357c94/docs/rules/no-magic-numbers.md) 같은 도구들은 이름을 지정하지 않은 상수를 식별하는 데 도움을 줄 수 있습니다.

**Bad:**

```javascript
// 도대체 86400000은 무엇을 의미하는가?
setTimeout(blastOff, 86400000);
```

**Good:**

```javascript
// 대문자 명명된 상수로 선언하세요.
const MILLISECONDS_PER_DAY = 60 * 60 * 24 * 1000; //86400000;

setTimeout(blastOff, MILLISECONDS_PER_DAY);
```

**[⬆ 맨 위로](#table-of-contents)**

### 설명이 포함된 변수를 사용하세요

**Bad:**

```javascript
const address = "One Infinite Loop, Cupertino 95014";
const cityZipCodeRegex = /^[^,\\]+[,\\\s]+(.+?)\s*(\d{5})?$/;
saveCityZipCode(
  address.match(cityZipCodeRegex)[1],
  address.match(cityZipCodeRegex)[2]
);
```

**Good:**

```javascript
const address = "One Infinite Loop, Cupertino 95014";
const cityZipCodeRegex = /^[^,\\]+[,\\\s]+(.+?)\s*(\d{5})?$/;
const [_, city, zipCode] = address.match(cityZipCodeRegex) || [];
saveCityZipCode(city, zipCode);
```

**[⬆ 맨 위로](#table-of-contents)**

### Mental Mapping(신체적 매핑)을 피하세요

암시적인 것보다 명시적인 것이 좋습니다.

**Bad:**

```javascript
const locations = ["Austin", "New York", "San Francisco"];
locations.forEach(l => {
  doStuff();
  doSomeOtherStuff();
  // ...
  // ...
  // ...
  // 잠깐, `l`이 무엇을 의미하더라?
  dispatch(l);
});
```

**Good:**

```javascript
const locations = ["Austin", "New York", "San Francisco"];
locations.forEach(location => {
  doStuff();
  doSomeOtherStuff();
  // ...
  // ...
  // ...
  dispatch(location);
});
```

**[⬆ 맨 위로](#table-of-contents)**

### 불필요한 컨텍스트를 추가하지 마세요

클래스나 객체 이름이 무언가를 알려주고 있다면, 변수 이름에 그것을 반복하지 마세요.

**Bad:**

```javascript
const Car = {
  carMake: "Honda",
  carModel: "Accord",
  carColor: "Blue"
};

function paintCar(car, color) {
  car.carColor = color;
}
```

**Good:**

```javascript
const Car = {
  make: "Honda",
  model: "Accord",
  color: "Blue"
};

function paintCar(car, color) {
  car.color = color;
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 단락 평가(Short-circuiting)나 조건문 대신 기본 매개변수를 사용하세요

기본 매개변수는 종종 단락 평가보다 더 깔끔합니다. 이를 사용할 때 함수는 `undefined` 인자에 대해서만 기본값을 제공한다는 점을 유제해 두세요. `''`, `""`, `false`, `null`, `0`, `NaN`과 같은 다른 "falsy" 값들은 기본값으로 대체되지 않습니다.

**Bad:**

```javascript
function createMicrobrewery(name) {
  const breweryName = name || "Hipster Brew Co.";
  // ...
}
```

**Good:**

```javascript
function createMicrobrewery(name = "Hipster Brew Co.") {
  // ...
}
```

**[⬆ 맨 위로](#table-of-contents)**

## **함수**

### 함수의 인자는 이상적으로 2개 이하로 유지하세요

함수 파라미터의 개수를 제한하는 것은 함수 테스트를 더 쉽게 만들어 주기 때문에 엄청나게 중요합니다. 인자가 3개를 넘어가면 각각의 개별 인자에 대해 수많은 다른 경우의 수를 테스트해야 하는 조합 폭발(combinatorial explosion)로 이어집니다.

1개나 2개의 인자가 이상적인 경우이며, 가능하면 3개는 피해야 합니다. 그 이상의 인자는 통합되어야 합니다. 보통 인자가 2개보다 많다면 함수가 너무 많은 일을 하려고 하는 것입니다. 그렇지 않은 경우라면, 대부분의 경우 상위 수준의 객체를 인자로 전달하는 것으로 충분합니다.

JavaScript를 사용하면 많은 클래스 상용구 코드(boilerplate) 없이도 즉석에서 객체를 만들 수 있으므로, 많은 인자가 필요하다고 느껴질 때는 객체를 사용할 수 있습니다.

함수가 어떤 프로퍼티들을 기대하는지 명확하게 하려면 ES2015/ES6 구조 분해(destructuring) 구문을 사용할 수 있습니다. 이는 몇 가지 장점이 있습니다.

1. 누군가 함수 시그니처를 볼 때, 어떤 프로퍼티들이 사용되고 있는지 즉시 명확해집니다.
2. 명명된 파라미터(named parameters)를 시뮬레이트하는 데 사용할 수 있습니다.
3. 구조 분해는 또한 함수로 전달된 인자 객체의 지정된 원시 값들을 복사(clone)합니다. 이는 부수 효과(side effect)를 방지하는 데 도움이 될 수 있습니다. 참고: 인자 객체로부터 구조 분해된 객체와 배열은 복제되지 **않습니다**.
4. Linter는 구조 분해 없이는 불가능한 사용되지 않는 프로퍼티에 대해 경고해 줄 수 있습니다.

**Bad:**

```javascript
function createMenu(title, body, buttonText, cancellable) {
  // ...
}

createMenu("Foo", "Bar", "Baz", true);

```

**Good:**

```javascript
function createMenu({ title, body, buttonText, cancellable }) {
  // ...
}

createMenu({
  title: "Foo",
  body: "Bar",
  buttonText: "Baz",
  cancellable: true
});
```

**[⬆ 맨 위로](#table-of-contents)**

### 함수는 한 가지 일만 해야 합니다

이것은 소프트웨어 공학에서 단연코 가장 중요한 규칙입니다. 함수가 한 가지 이상의 일을 할 때, 함수를 조합하고, 테스트하고, 추론하기가 더 어려워집니다. 함수를 단 하나의 작업으로 격리할 수 있다면 쉽게 리팩터링할 수 있으며 코드가 훨씬 더 깔끔해질 것입니다. 이 가이드에서 이것 외에는 아무것도 가져가지 못한다고 하더라도, 여러분은 많은 개발자들보다 앞서게 될 것입니다.

**Bad:**

```javascript
function emailClients(clients) {
  clients.forEach(client => {
    const clientRecord = database.lookup(client);
    if (clientRecord.isActive()) {
      email(client);
    }
  });
}
```

**Good:**

```javascript
function emailActiveClients(clients) {
  clients.filter(isActiveClient).forEach(email);
}

function isActiveClient(client) {
  const clientRecord = database.lookup(client);
  return clientRecord.isActive();
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 함수명은 자신이 무엇을 하는지 나타내야 합니다

**Bad:**

```javascript
function addToDate(date, month) {
  // ...
}

const date = new Date();

// 함수 이름만으로는 무엇이 추가되는지 알기 어렵습니다.
addToDate(date, 1);
```

**Good:**

```javascript
function addMonthToDate(month, date) {
  // ...
}

const date = new Date();
addMonthToDate(1, date);
```

**[⬆ 맨 위로](#table-of-contents)**

### 함수는 오직 하나의 추상화 수준만 가져야 합니다

추상화 수준이 두 개 이상일 때 함수는 대개 너무 많은 일을 하고 있는 것입니다. 함수를 쪼개면 재사용성과 쉬운 테스트로 이어집니다.

**Bad:**

```javascript
function parseBetterJSAlternative(code) {
  const REGEXES = [
    // ...
  ];

const statements = code.split(" ");
  const tokens = [];
  REGEXES.forEach(REGEX => {
    statements.forEach(statement => {
      // ...
    });
  });

const ast = [];
  tokens.forEach(token => {
    // lex...
  });

ast.forEach(node => {
    // parse...
  });
}
```

**Good:**

```javascript
function parseBetterJSAlternative(code) {
  const tokens = tokenize(code);
  const syntaxTree = parse(tokens);
  syntaxTree.forEach(node => {
    // parse...
  });
}

function tokenize(code) {
  const REGEXES = [
    // ...
  ];

const statements = code.split(" ");
  const tokens = [];
  REGEXES.forEach(REGEX => {
    statements.forEach(statement => {
      tokens.push(/* ... */);
    });
  });

return tokens;
}

function parse(tokens) {
  const syntaxTree = [];
  tokens.forEach(token => {
    syntaxTree.push(/* ... */);
  });

return syntaxTree;
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 중복 코드를 제거하세요

중복 코드를 피하기 위해 최선을 다하세요. 중복 코드가 나쁜 이유는 로직을 변경해야 할 때 수정해야 할 곳이 한 군데 이상이기 때문입니다.

레스토랑을 운영하며 토마토, 양파, 마늘, 향신료 등 재고를 관리한다고 상상해 보세요. 이것을 기록하는 리스트가 여러 개라면, 토마토가 들어간 요리를 서빙할 때 모든 리스트를 업데이트해야 합니다. 리스트가 단 하나뿐이라면 업데이트할 곳도 오직 한 곳뿐입니다!

공통점이 많지만 차이점 때문에 동일한 작업을 많이 수행하는 두 개 이상의 약간 다른 것들이 있어서 중복 코드가 발생하는 경우가 종종 있습니다. 중복 코드를 제거한다는 것은 단 하나의 함수/모듈/클래스로 이러한 다양한 것들을 처리할 수 있는 추상화를 만든다는 것을 의미합니다.

올바른 추상화를 이끌어내는 것은 매우 중요하며, 이것이 _Classes_ 섹션에 명시된 SOLID 원칙을 따라야 하는 이유입니다. 나쁜 추상화는 중복 코드보다 더 나쁠 수 있으므로 조심하세요! 그렇긴 하지만, 좋은 추상화를 만들 수 있다면 그렇게 하세요! 코드를 반복하지 마세요. 그렇지 않으면 무언가를 변경하고 싶을 때 여러 곳을 수정하고 있는 자신을 발견하게 될 것입니다.

**Bad:**

```javascript
function showDeveloperList(developers) {
  developers.forEach(developer => {
    const expectedSalary = developer.calculateExpectedSalary();
    const experience = developer.getExperience();
    const githubLink = developer.getGithubLink();
    const data = {
      expectedSalary,
      experience,
      githubLink
    };

render(data);
  });
}

function showManagerList(managers) {
  managers.forEach(manager => {
    const expectedSalary = manager.calculateExpectedSalary();
    const experience = manager.getExperience();
    const portfolio = manager.getMBAProjects();
    const data = {
      expectedSalary,
      experience,
      portfolio
    };

render(data);
  });
}
```

**Good:**

```javascript
function showEmployeeList(employees) {
  employees.forEach(employee => {
    const expectedSalary = employee.calculateExpectedSalary();
    const experience = employee.getExperience();

const data = {
      expectedSalary,
      experience
    };

switch (employee.type) {
      case "manager":
        data.portfolio = employee.getMBAProjects();
        break;
      case "developer":
        data.githubLink = employee.getGithubLink();
        break;
    }

render(data);
  });
}
```

**[⬆ 맨 위로](#table-of-contents)**

### Object.assign을 사용하여 기본 객체 설정하기

**Bad:**

```javascript
const menuConfig = {
  title: null,
  body: "Bar",
  buttonText: null,
  cancellable: true
};

function createMenu(config) {
  config.title = config.title || "Foo";
  config.body = config.body || "Bar";
  config.buttonText = config.buttonText || "Baz";
  config.cancellable =
    config.cancellable !== undefined ? config.cancellable : true;
}

createMenu(menuConfig);
```

**Good:**

```javascript
const menuConfig = {
  title: "Order",
  // 사용자가 'body' 키를 포함하지 않았습니다.
  buttonText: "Send",
  cancellable: true
};

function createMenu(config) {
  let finalConfig = Object.assign(
    {
      title: "Foo",
      body: "Bar",
      buttonText: "Baz",
      cancellable: true
    },
    config
  );
  return finalConfig
  // config now equals: {title: "Order", body: "Bar", buttonText: "Send", cancellable: true}
  // ...
}

createMenu(menuConfig);
```

**[⬆ 맨 위로](#table-of-contents)**

### 플래그를 함수 파라미터로 사용하지 마세요

플래그는 사용자에게 이 함수가 한 가지 이상의 일을 한다는 것을 알려줍니다. 함수는 한 가지 일만 해야 합니다. 부울 값에 따라 다른 코드 경로를 타는 경우 함수를 분리하세요.

**Bad:**

```javascript
function createFile(name, temp) {
  if (temp) {
    fs.create(`./temp/${name}`);
  } else {
    fs.create(name);
  }
}
```

**Good:**

```javascript
function createFile(name) {
  fs.create(name);
}

function createTempFile(name) {
  createFile(`./temp/${name}`);
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 부수 효과(Side Effects) 피하기 (1부)

함수가 어떤 값을 입력받아 다른 값이나 값들을 반환하는 것 외에 다른 일을 한다면, 그 함수는 부수 효과를 발생시키는 것입니다. 부수 효과는 파일에 쓰기 작업을 하거나, 전역 변수를 수정하거나, 실수로 낯선 사람에게 전 재산을 송금하는 것일 수 있습니다.

물론 프로그램에서 가끔은 부수 효과가 필요할 때가 있습니다. 앞선 예제처럼 파일에 쓰기를 해야 할 수도 있습니다. 이때 우리가 해야 할 일은 이러한 작업을 중앙 집중화하는 것입니다. 특정 파일에 쓰기 작업을 하는 여러 개의 함수와 클래스를 두지 마세요. 이를 수행하는 단 하나의 서비스만 두세요. 오직 하나만요.

핵심 요점은 구조 없이 객체 간에 상태를 공유하거나, 무엇이든 쓸 수 있는 가변 데이터 타입을 사용하고, 부수 효과가 발생하는 곳을 중앙 집중화하지 않는 등의 일반적인 함정을 피하는 것입니다. 이 작업을 해낼 수 있다면, 당신은 대다수의 다른 프로그래머들보다 더 행복해질 것입니다.

**Bad:**

```javascript
// 다음 함수에 의해 참조되는 전역 변수.
// 만약 이 이름을 사용하는 다른 함수가 있다면, 이제 이 변수는 배열이 되어 코드가 망가지게 될 수 있습니다.
let name = "Ryan McDermott";

function splitIntoFirstAndLastName() {
  name = name.split(" ");
}

splitIntoFirstAndLastName();

console.log(name); // ['Ryan', 'McDermott'];
```

**Good:**

```javascript
function splitIntoFirstAndLastName(name) {
  return name.split(" ");
}

const name = "Ryan McDermott";
const newName = splitIntoFirstAndLastName(name);

console.log(name); // 'Ryan McDermott';
console.log(newName); // ['Ryan', 'McDermott'];
```

**[⬆ 맨 위로](#table-of-contents)**

### 부수 효과(Side Effects) 피하기 (2부)

JavaScript에서 일부 값은 변경 불가능하고(immutable), 일부는 변경 가능합니다(mutable). 객체와 배열은 변경 가능한 두 가지 종류의 값이므로 함수의 파라미터로 전달될 때 주의해서 다루는 것이 중요합니다. JavaScript 함수는 객체의 프로퍼티를 변경하거나 배열의 내용을 수정할 수 있으며, 이는 다른 곳에서 쉽게 버그를 유발할 수 있습니다.

쇼핑 카트를 나타내는 배열 파라미터를 받는 함수가 있다고 가정해 봅시다. 함수가 구매할 아이템을 추가하는 등 해당 쇼핑 카트 배열을 변경한다면, 동일한 `cart` 배열을 사용하는 다른 모든 함수가 이 추가에 의해 영향을 받게 됩니다. 이것이 멋진 일일 수도 있지만, 반대로 나쁠 수도 있습니다. 나쁜 상황을 상상해 봅시다.

사용자가 "Purchase" 버튼을 클릭하면 네트워크 요청을 생성하고 서버로 `cart` 배열을 전송하는 `purchase` 함수가 호출됩니다. 네트워크 연결 상태가 좋지 않아 `purchase` 함수가 요청을 계속 재시도해야 합니다. 자, 네트워크 요청이 시작되기 전에 사용자가 실수로 실제로 원하지 않는 아이템의 "Add to Cart" 버튼을 클릭했다면 어떻게 될까요? 그런 일이 발생하고 네트워크 요청이 시작되면, `cart` 배열이 수정되었기 때문에 purchase 함수는 실수로 추가된 아이템까지 함께 전송하게 될 것입니다.

훌륭한 해결책은 `addItemToCart` 함수가 항상 `cart`를 복제하고, 복제본을 수정한 뒤, 복제본을 반환하도록 하는 것입니다. 이렇게 하면 여전히 이전 쇼핑 카트를 사용하고 있는 함수들이 변경 사항에 영향을 받지 않도록 보장할 수 있습니다.

이 접근 방식에 대해 언급할 두 가지 주의사항:

1. 실제로 입력 객체를 수정하고 싶은 경우가 있을 수 있지만, 이 프로그래밍 관습을 채택하면 그러한 경우가 매우 드물다는 것을 알게 될 것입니다. 대부분의 것들은 부수 효과가 없도록 리팩터링할 수 있습니다!

2. 큰 객체를 복제하는 것은 성능 측면에서 비용이 많이 들 수 있습니다. 다행히도 [훌륭한 라이브러리들](https://facebook.github.io/immutable-js/)이 있어서 이러한 프로그래밍 접근 방식을 빠르고 개발자가 직접 객체와 배열을 복제하는 것만큼 메모리를 많이 소모하지 않도록 만들어 주기 때문에, 실제로는 큰 문제가 되지 않습니다.

**Bad:**

```javascript
const addItemToCart = (cart, item) => {
  cart.push({ item, date: Date.now() });
};
```

**Good:**

```javascript
const addItemToCart = (cart, item) => {
  return [...cart, { item, date: Date.now() }];
};
```

**[⬆ 맨 위로](#table-of-contents)**

### 전역 함수에 직접 쓰지 마세요

JavaScript에서 전역 객체를 오염시키는 것은 다른 라이브러리와 충돌할 수 있고, 프로덕션 환경에서 예외가 발생할 때까지 API 사용자는 아무것도 모르게 되기 때문에 나쁜 관습입니다. 예를 들어 생각해 봅시다: 두 배열 간의 차이점을 보여줄 수 있는 `diff` 메서드를 갖도록 JavaScript의 기본 Array 메서드를 확장하고 싶다면 어떻게 할까요? 새 함수를 `Array.prototype`에 작성할 수도 있지만, 이 경우 동일한 작업을 시도하는 다른 라이브러리와 충돌할 수 있습니다. 만약 그 다른 라이브러리가 단순히 배열의 첫 번째 요소와 마지막 요소 사이의 차이를 찾기 위해 `diff`를 사용하고 있었다면 어떻게 될까요? 이것이 바로 ES2015/ES6 클래스를 사용하고 단순히 전역 `Array`를 상속받는 것이 훨씬 더 좋은 이유입니다.

**Bad:**

```javascript
Array.prototype.diff = function diff(comparisonArray) {
  const hash = new Set(comparisonArray);
  return this.filter(elem => !hash.has(elem));
};
```

**Good:**

```javascript
class SuperArray extends Array {
  diff(comparisonArray) {
    const hash = new Set(comparisonArray);
    return this.filter(elem => !hash.has(elem));
  }
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 명령형 프로그래밍보다 함수형 프로그래밍을 선호하세요

JavaScript는 Haskell 같은 언어처럼 순수 함수형 언어는 아니지만, 함수형 성향을 가지고 있습니다. 함수형 언어들은 더 깔끔하고 테스트하기 쉬울 수 있습니다. 가능할 때 이 스타일의 프로그래밍을 선호하세요.

**Bad:**

```javascript
const programmerOutput = [
  {
    name: "Uncle Bobby",
    linesOfCode: 500
  },
  {
    name: "Suzie Q",
    linesOfCode: 1500
  },
  {
    name: "Jimmy Gosling",
    linesOfCode: 150
  },
  {
    name: "Gracie Hopper",
    linesOfCode: 1000
  }
];

let totalOutput = 0;

for (let i = 0; i < programmerOutput.length; i++) {
  totalOutput += programmerOutput[i].linesOfCode;
}
```

**Good:**

const totalOutput = programmerOutput.reduce(
  (totalLines, output) => totalLines + output.linesOfCode,
  0
);
```

**[⬆ 맨 위로](#table-of-contents)**

### 조건문을 캡슐화하세요

**Bad:**

```javascript
if (fsm.state === "fetching" && isEmpty(listNode)) {
  // ...
}
```

**Good:**

```javascript
function shouldShowSpinner(fsm, listNode) {
  return fsm.state === "fetching" && isEmpty(listNode);
}

if (shouldShowSpinner(fsmInstance, listNodeInstance)) {
  // ...
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 부정 조건문을 피하세요

**Bad:**

```javascript
function isDOMNodeNotPresent(node) {
  // ...
}

if (!isDOMNodeNotPresent(node)) {
  // ...
}
```

**Good:**

```javascript
function isDOMNodePresent(node) {
  // ...
}

if (isDOMNodePresent(node)) {
  // ...
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 조건문을 피하세요

이것은 불가능한 일처럼 보입니다. 처음 이 말을 들을 때, 대부분의 사람들은 "`if` 문 없이 어떻게 아무것도 안 하라는 거지?"라고 말합니다. 대답은 많은 경우에 다형성(polymorphism)을 사용하여 동일한 작업을 수행할 수 있다는 것입니다. 두 번째 질문은 보통 "음, 그건 좋지만 왜 그렇게 하고 싶어 할까?"입니다. 대답은 앞에서 배운 클린 코드 개념입니다: 함수는 오직 한 가지 일만 해야 합니다. `if` 문이 있는 클래스와 함수가 있다면, 그것은 사용자에게 해당 함수가 한 가지 이상의 일을 하고 있음을 알리는 것입니다. 기억하세요, 단 한 가지만 하세요.

**Bad:**

```javascript
class Airplane {
  // ...
  getCruisingAltitude() {
    switch (this.type) {
      case "777":
        return this.getMaxAltitude() - this.getPassengerCount();
      case "Air Force One":
        return this.getMaxAltitude();
      case "Cessna":
        return this.getMaxAltitude() - this.getFuelExpenditure();
    }
  }
}
```

**Good:**

```javascript
class Airplane {
  // ...
}

class Boeing777 extends Airplane {
  // ...
  getCruisingAltitude() {
    return this.getMaxAltitude() - this.getPassengerCount();
  }
}

class AirForceOne extends Airplane {
  // ...
  getCruisingAltitude() {
    return this.getMaxAltitude();
  }
}

class Cessna extends Airplane {
  // ...
  getCruisingAltitude() {
    return this.getMaxAltitude() - this.getFuelExpenditure();
  }
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 타입 검사 피하기 (1부)

JavaScript는 타입이 없으므로(untyped) 함수가 모든 타입의 인자를 받을 수 있습니다. 때로는 이러한 자유로움 때문에 곤경에 처하기도 하며 함수 내부에서 타입 검사를 하고 싶어지는 유혹을 받게 됩니다. 이를 피할 수 있는 방법은 많이 있습니다. 가장 먼저 고려해야 할 것은 일관된 API입니다.

**Bad:**

```javascript
function travelToTexas(vehicle) {
  if (vehicle instanceof Bicycle) {
    vehicle.pedal(this.currentLocation, new Location("texas"));
  } else if (vehicle instanceof Car) {
    vehicle.drive(this.currentLocation, new Location("texas"));
  }
}
```

**Good:**

```javascript
function travelToTexas(vehicle) {
  vehicle.move(this.currentLocation, new Location("texas"));
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 타입 검사 피하기 (2부)

문자열이나 정수 같은 기본 원시 값을 다루고 있고 다형성을 사용할 수 없는데도 여전히 타입 검사를 해야 할 것 같다면, TypeScript 사용을 고려해 봐야 합니다. TypeScript는 표준 JavaScript 구문 위에 정적 타이핑을 제공하므로 일반 JavaScript의 훌륭한 대안입니다. 일반 JavaScript에서 수동으로 타입 검사를 할 때의 문제는 이를 잘 해내기 위해 너무 많은 코드가 추가되어, 얻게 되는 가짜 "타입 안전성"이 잃어버린 가독성을 보상해주지 못한다는 점입니다. JavaScript를 깔끔하게 유지하고, 좋은 테스트를 작성하고, 코드 리뷰를 잘 받으세요. 그렇지 않다면 이 모든 것을 TypeScript와 함께 하세요(앞서 말했듯이 훌륭한 대안입니다!).

**Bad:**

```javascript
function combine(val1, val2) {
  if (
    (typeof val1 === "number" && typeof val2 === "number") ||
    (typeof val1 === "string" && typeof val2 === "string")
  ) {
    return val1 + val2;
  }

throw new Error("Must be of type String or Number");
}
```

**Good:**

```javascript
function combine(val1, val2) {
  return val1 + val2;
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 지나친 최적화를 하지 마세요

최신 브라우저는 런타임에 내부적으로 많은 최적화를 수행합니다. 많은 경우에 최적화를 하고 있다면 그저 시간을 낭비하고 있는 것뿐입니다. [최적화가 부족한 부분을 확인할 수 있는 좋은 자료들](https://github.com/petkaantonov/bluebird/wiki/Optimization-killers)이 있습니다. 최적화가 가능하고 수정될 때까지는 그곳을 목표로 삼으세요.

**Bad:**

```javascript
// 오래된 브라우저에서는 캐시되지 않은 `list.length`를 사용한 각 반복이 `list.length` 재계산 때문에 비용이 많이 들 수 있습니다.
// 최신 브라우저에서는 이 부분이 최적화되어 있습니다.
for (let i = 0, len = list.length; i < len; i++) {
  // ...
}
```

**Good:**

```javascript
for (let i = 0; i < list.length; i++) {
  // ...
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 죽은 코드(Dead Code)를 제거하세요

죽은 코드는 중복 코드만큼이나 나쁩니다. 코드베이스에 유지할 이유가 없습니다. 호출되지 않는다면 없애버리세요! 여전히 필요하다면 버전 관리 기록에 안전하게 남아있을 것입니다.

**Bad:**

```javascript
function oldRequestModule(url) {
  // ...
}

function newRequestModule(url) {
  // ...
}

const req = newRequestModule;
inventoryTracker("apples", req, "www.inventory-awesome.io");
```

**Good:**

```javascript
function newRequestModule(url) {
  // ...
}

const req = newRequestModule;
inventoryTracker("apples", req, "www.inventory-awesome.io");
```

**[⬆ 맨 위로](#table-of-contents)**

## **객체 및 자료 구조**

### Getter와 Setter를 사용하세요

객체의 데이터를 접근할 때 단순히 객체의 프로퍼티를 직접 조회하는 것보다 getter와 setter를 사용하는 것이 더 나을 수 있습니다. "왜요?"라고 물으실 수 있습니다. 자, 여기에 그 이유들을 정리되지 않은 목록으로 나열합니다:

- 객체 프로퍼티를 가져오는 것 이상의 추가 작업을 수행하고 싶을 때, 코드베이스의 모든 접근자를 찾아가며 변경할 필요가 없습니다.
- `set`을 수행할 때 유효성 검사(validation)를 간단하게 추가할 수 있습니다.
- 내부 표현을 캡슐화합니다.
- getter와 setter를 사용할 때 로깅 및 에러 핸들링을 추가하기 쉽습니다.
- 서버에서 가져오는 등 객체의 프로퍼티를 지연 로딩(lazy load)할 수 있습니다.

**Bad:**

```javascript
function makeBankAccount() {
  // ...

return {
    balance: 0
    // ...
  };
}

const account = makeBankAccount();
account.balance = 100;
```

**Good:**

```javascript
function makeBankAccount() {
  // 이 부분은 비공개(private)입니다.
  let balance = 0;

// "getter", 아래에서 반환되는 객체를 통해 공개(public)됩니다.
  function getBalance() {
    return balance;
  }

// "setter", 아래에서 반환되는 객체를 통해 공개(public)됩니다.
  function setBalance(amount) {
    // ... 잔액을 업데이트하기 전에 유효성 검사
    balance = amount;
  }

return {
    // ...
    getBalance,
    setBalance
  };
}

const account = makeBankAccount();
account.setBalance(100);
```

**[⬆ 맨 위로](#table-of-contents)**

### 객체가 private 멤버를 갖도록 하세요

클로저를 통해 달성할 수 있습니다 (ES5 및 그 이하 버전).

**Bad:**

```javascript
const Employee = function(name) {
  this.name = name;
};

Employee.prototype.getName = function getName() {
  return this.name;
};

const employee = new Employee("John Doe");
console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe
delete employee.name;
console.log(`Employee name: ${employee.getName()}`); // Employee name: undefined
```

**Good:**

```javascript
function makeEmployee(name) {
  return {
    getName() {
      return name;
    }
  };
}

const employee = makeEmployee("John Doe");
console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe
delete employee.name;
console.log(`Employee name: ${employee.getName()}`); // Employee name: John Doe
```

**[⬆ 맨 위로](#table-of-contents)**

## **클래스**

### ES5 순수 함수보다 ES2015/ES6 클래스를 선호하세요

고전적인 ES5 클래스를 위한 읽기 쉬운 클래스 상속, 생성자, 메서드 정의를 얻는 것은 매우 어렵습니다. 상속이 필요하다면(그렇지 않을 수도 있음을 유념하세요) ES2015/ES6 클래스를 선호하세요. 하지만 더 크고 복잡한 객체가 필요해질 때까지는 클래스보다 작은 함수를 선호하세요.

**Bad:**

```javascript
const Animal = function(age) {
  if (!(this instanceof Animal)) {
    throw new Error("Instantiate Animal with `new`");
  }

this.age = age;
};

Animal.prototype.move = function move() {};

const Mammal = function(age, furColor) {
  if (!(this instanceof Mammal)) {
    throw new Error("Instantiate Mammal with `new`");
  }

Animal.call(this, age);
  this.furColor = furColor;
};

Mammal.prototype = Object.create(Animal.prototype);
Mammal.prototype.constructor = Mammal;
Mammal.prototype.liveBirth = function liveBirth() {};

const Human = function(age, furColor, languageSpoken) {
  if (!(this instanceof Human)) {
    throw new Error("Instantiate Human with `new`");
  }

Mammal.call(this, age, furColor);
  this.languageSpoken = languageSpoken;
};

Human.prototype = Object.create(Mammal.prototype);
Human.prototype.constructor = Human;
Human.prototype.speak = function speak() {};
```

**Good:**

```javascript
class Animal {
  constructor(age) {
    this.age = age;
  }

move() {
    /* ... */
  }
}

class Mammal extends Animal {
  constructor(age, furColor) {
    super(age);
    this.furColor = furColor;
  }

liveBirth() {
    /* ... */
  }
}

class Human extends Mammal {
  constructor(age, furColor, languageSpoken) {
    super(age, furColor);
    this.languageSpoken = languageSpoken;
  }

speak() {
    /* ... */
  }
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 메서드 체이닝(Method Chaining)을 사용하세요

이 패턴은 JavaScript에서 매우 유용하며 jQuery나 Lodash 같은 많은 라이브러리에서 볼 수 있습니다. 코드를 표현력 있고 장황하지 않게 만들어 줍니다.
그런 이유로 저는 메서드 체이닝을 사용하고 코드가 얼마나 깔끔해지는지 살펴보라고 말합니다. 클래스 함수 안에서 모든 함수의 끝에 단순히 `this`를 반환하면, 그 뒤에 추가적인 클래스 메서드들을 체이닝할 수 있습니다.

**Bad:**

```javascript
class Car {
  constructor(make, model, color) {
    this.make = make;
    this.model = model;
    this.color = color;
  }

setMake(make) {
    this.make = make;
  }

setModel(model) {
    this.model = model;
  }

setColor(color) {
    this.color = color;
  }

save() {
    console.log(this.make, this.model, this.color);
  }
}

const car = new Car("Ford", "F-150", "red");
car.setColor("pink");
car.save();
```

**Good:**

```javascript
class Car {
  constructor(make, model, color) {
    this.make = make;
    this.model = model;
    this.color = color;
  }

setMake(make) {
    this.make = make;
    // NOTE: 체이닝을 위해 this를 반환합니다.
    return this;
  }

setModel(model) {
    this.model = model;
    // NOTE: 체이닝을 위해 this를 반환합니다.
    return this;
  }

setColor(color) {
    this.color = color;
    // NOTE: 체이닝을 위해 this를 반환합니다.
    return this;
  }

save() {
    console.log(this.make, this.model, this.color);
    // NOTE: 체이닝을 위해 this를 반환합니다.
    return this;
  }
}

const car = new Car("Ford", "F-150", "red").setColor("pink").save();
```

**[⬆ 맨 위로](#table-of-contents)**

### 상속보다 컴포지션(Composition)을 선호하세요

Gang of Four의 [_Design Patterns_](https://en.wikipedia.org/wiki/Design_Patterns)에서 유명하게 언급되었듯이, 가능하면 상속보다 컴포지션을 선호해야 합니다. 상속을 사용할 훌륭한 이유도 많고 컴포지션을 사용할 훌륭한 이유도 많습니다.
이 격언의 핵심 요점은 여러분의 마음이 본능적으로 상속을 향한다면, 컴포지션이 문제를 더 잘 모델링할 수 있는지 생각해 보라는 것입니다. 어떤 경우에는 그렇습니다.

그렇다면 "언제 상속을 사용해야 할까?"라는 의문이 들 수 있습니다. 그것은 직면한 문제에 따라 다르지만, 상속이 컴포지션보다 더 말이 되는 경우를 나타내는 괜찮은 목록은 다음과 같습니다:

1. 상속이 "is-a" 관계를 나타내며 "has-a" 관계를 나타내지 않는 경우 (Human->Animal 대 User->UserDetails).
2. 기본 클래스의 코드를 재사용할 수 있는 경우 (Human은 모든 동물처럼 움직일 수 있다).
3. 기본 클래스를 변경하여 파생 클래스에 전역적인 변경을 적용하고 싶은 경우. (동물이 움직일 때의 칼로리 소모량을 모두 변경).

**Bad:**

```javascript
class Employee {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

// ...
}

// 직원은 세금 데이터를 "가지고(have)" 있기 때문에 나쁩니다. EmployeeTaxData는 Employee의 한 종류가 아닙니다.
class EmployeeTaxData extends Employee {
  constructor(ssn, salary) {
    super();
    this.ssn = ssn;
    this.salary = salary;
  }

// ...
}
```

**Good:**

```javascript
class EmployeeTaxData {
  constructor(ssn, salary) {
    this.ssn = ssn;
    this.salary = salary;
  }

// ...
}

class Employee {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

setTaxData(ssn, salary) {
    this.taxData = new EmployeeTaxData(ssn, salary);
  }
  // ...
}
```

**[⬆ 맨 위로](#table-of-contents)**

## **SOLID**

### 단일 책임 원칙 (Single Responsibility Principle, SRP)

Clean Code에서 언급하듯이, "클래스가 변경되어야 하는 이유는 단 하나 이상여서는 안 됩니다." 비행기에 수트케이스를 하나만 들고 탈 수 있는 것처럼, 클래스에 많은 기능을 쑤셔 넣고 싶은 유혹에 빠지기 쉽습니다. 이 문제점은 클래스가 개념적으로 응집력이 없어지고 변경되어야 할 이유가 여러 개 생기게 된다는 것입니다. 클래스를 변경해야 하는 횟수를 최소화하는 것은 중요합니다. 너무 많은 기능이 하나의 클래스에 들어 있고 그중 일부를 수정하면, 그것이 코드베이스의 다른 의존적인 모듈에 어떤 영향을 미칠지 이해하기 어려워질 수 있기 때문에 중요합니다.

**Bad:**

```javascript
class UserSettings {
  constructor(user) {
    this.user = user;
  }

changeSettings(settings) {
    if (this.verifyCredentials()) {
      // ...
    }
  }

verifyCredentials() {
    // ...
  }
}
```

**Good:**

```javascript
class UserAuth {
  constructor(user) {
    this.user = user;
  }

verifyCredentials() {
    // ...
  }
}

class UserSettings {
  constructor(user) {
    this.user = user;
    this.auth = new UserAuth(user);
  }

changeSettings(settings) {
    if (this.auth.verifyCredentials()) {
      // ...
    }
  }
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 개방-폐쇄 원칙 (Open/Closed Principle, OCP)

버트랜드 메이어(Bertrand Meyer)가 말했듯이, "소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고 수정에 대해서는 닫혀 있어야 합니다." 하지만 그게 무슨 뜻일까요? 이 원칙은 기본적으로 기존 코드를 변경하지 않고 사용자가 새로운 기능을 추가할 수 있도록 해야 한다는 것을 말합니다.

**Bad:**

```javascript
class AjaxAdapter extends Adapter {
  constructor() {
    super();
    this.name = "ajaxAdapter";
  }
}

class NodeAdapter extends Adapter {
  constructor() {
    super();
    this.name = "nodeAdapter";
  }
}

class HttpRequester {
  constructor(adapter) {
    this.adapter = adapter;
  }

fetch(url) {
    if (this.adapter.name === "ajaxAdapter") {
      return makeAjaxCall(url).then(response => {
        // 응답을 변환하고 반환합니다.
      });
    } else if (this.adapter.name === "nodeAdapter") {
      return makeHttpCall(url).then(response => {
        // 응답을 변환하고 반환합니다.
      });
    }
  }
}

function makeAjaxCall(url) {
  // 요청하고 프로미스를 반환합니다.
}

function makeHttpCall(url) {
  // 요청하고 프로미스를 반환합니다.
}
```

**Good:**

```javascript
class AjaxAdapter extends Adapter {
  constructor() {
    super();
    this.name = "ajaxAdapter";
  }

request(url) {
    // 요청하고 프로미스를 반환합니다.
  }
}

class NodeAdapter extends Adapter {
  constructor() {
    super();
    this.name = "nodeAdapter";
  }

request(url) {
    // 요청하고 프로미스를 반환합니다.
  }
}

class HttpRequester {
  constructor(adapter) {
    this.adapter = adapter;
  }

fetch(url) {
    return this.adapter.request(url).then(response => {
      // 응답을 변환하고 반환합니다.
    });
  }
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 리스코프 치환 원칙 (Liskov Substitution Principle, LSP)

매우 간단한 개념에 붙은 무서운 용어입니다. 공식적으로는 "만약 S가 T의 서브타입이라면, 프로그램의 바람직한 속성(정확성, 수행되는 작업 등)을 변경하지 않고도 타입 T의 객체를 타입 S의 객체로 치환할 수 있다(즉, 타입 S의 객체는 타입 T의 객체를 대체할 수 있다)"라고 정의됩니다. 훨씬 더 무서운 정의네요.

이에 대한 가장 좋은 설명은 부모 클래스와 자식 클래스가 있을 때, 기본 클래스와 자식 클래스가 잘못된 결과 없이 상호 교환되어 사용될 수 있다는 것입니다. 이것도 여전히 헷갈릴 수 있으니 고전적인 Square-Rectangle(정사각형-직사각형) 예제를 살펴보겠습니다. 수학적으로 정사각형은 직사각형이지만, 상속을 통한 "is-a" 관계로 모델링하면 금방 곤경에 빠지게 됩니다.

**Bad:**

```javascript
class Rectangle {
  constructor() {
    this.width = 0;
    this.height = 0;
  }

setColor(color) {
    // ...
  }

render(area) {
    // ...
  }

setWidth(width) {
    this.width = width;
  }

setHeight(height) {
    this.height = height;
  }

getArea() {
    return this.width * this.height;
  }
}

class Square extends Rectangle {
  setWidth(width) {
    this.width = width;
    this.height = width;
  }

setHeight(height) {
    this.width = height;
    this.height = height;
  }
}

function renderLargeRectangles(rectangles) {
  rectangles.forEach(rectangle => {
    rectangle.setWidth(4);
    rectangle.setHeight(5);
    const area = rectangle.getArea(); // BAD: 정사각형에 대해 25를 반환합니다. 20이어야 합니다.
    rectangle.render(area);
  });
}

const rectangles = [new Rectangle(), new Rectangle(), new Square()];
renderLargeRectangles(rectangles);
```

**Good:**

```javascript
class Shape {
  setColor(color) {
    // ...
  }

render(area) {
    // ...
  }
}

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }

getArea() {
    return this.width * this.height;
  }
}

class Square extends Shape {
  constructor(length) {
    super();
    this.length = length;
  }

getArea() {
    return this.length * this.length;
  }
}

function renderLargeShapes(shapes) {
  shapes.forEach(shape => {
    const area = shape.getArea();
    shape.render(area);
  });
}

const shapes = [new Rectangle(4, 5), new Rectangle(4, 5), new Square(5)];
renderLargeShapes(shapes);
```

**[⬆ 맨 위로](#table-of-contents)**

### 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)

JavaScript에는 인터페이스가 없으므로 이 원칙은 다른 원칙만큼 엄격하게 적용되지 않습니다. 하지만 JavaScript의 타입 시스템 부재에도 불구하고 여전히 중요하고 관련성이 높습니다.

ISP는 "클라이언트는 자신이 사용하지 않는 인터페이스에 의존하도록 강요받아서는 안 된다"고 말합니다. JavaScript에서는 덕 타이핑(duck typing) 덕분에 인터페이스가 암시적 계약(implicit contracts)이 됩니다.

JavaScript에서 이 원칙을 보여주는 좋은 예는 거대한 설정 객체를 요구하는 클래스들입니다. 클라이언트가 수많은 옵션을 설정하도록 요구하지 않는 것이 유익한데, 대부분의 경우 모든 설정이 필요하지 않기 때문입니다. 이를 선택사항으로 만드는 것은 "비대한 인터페이스(fat interface)"를 방지하는 데 도움이 됩니다.

**Bad:**

```javascript
class DOMTraverser {
  constructor(settings) {
    this.settings = settings;
    this.setup();
  }

setup() {
    this.rootNode = this.settings.rootNode;
    this.settings.animationModule.setup();
  }

traverse() {
    // ...
  }
}

const $ = new DOMTraverser({
  rootNode: document.getElementsByTagName("body"),
  animationModule() {} // 대부분의 경우, 탐색할 때 애니메이션이 필요하지 않습니다.
  // ...
});
```

**Good:**

```javascript
class DOMTraverser {
  constructor(settings) {
    this.settings = settings;
    this.options = settings.options;
    this.setup();
  }

setup() {
    this.rootNode = this.settings.rootNode;
    this.setupOptions();
  }

setupOptions() {
    if (this.options.animationModule) {
      // ...
    }
  }

traverse() {
    // ...
  }
}

const $ = new DOMTraverser({
  rootNode: document.getElementsByTagName("body"),
  options: {
    animationModule() {}
  }
});
```

**[⬆ 맨 위로](#table-of-contents)**

### 의존성 역전 원칙 (Dependency Inversion Principle, DIP)

이 원칙은 두 가지 핵심적인 내용을 명시합니다:

1. 고수준 모듈은 저수준 모듈에 의존해서는 안 됩니다. 둘 다 추상화에 의존해야 합니다.
2. 추상화는 세부 사항에 의존해서는 안 됩니다. 세부 사항은 추상화에 의존해야 합니다.

처음에는 이해하기 어려울 수 있지만, AngularJS를 사용해 보았다면 의존성 주입(Dependency Injection, DI) 형태로 이 원칙이 구현된 것을 본 적이 있을 것입니다. 동일한 개념은 아니지만, DIP는 고수준 모듈이 저수준 모듈의 세부 사항을 알지 못하고 설정하지 않도록 유지해 줍니다. 이는 DI를 통해 달성할 수 있습니다. 이것의 엄청난 장점은 모듈 간의 결합도(coupling)를 낮춘다는 것입니다. 결합도는 코드를 리팩터링하기 어렵게 만들기 때문에 매우 나쁜 개발 패턴입니다.

앞서 언급했듯이 JavaScript에는 인터페이스가 없으므로 의존하는 추상화는 암시적 계약입니다. 즉, 객체/클래스가 다른 객체/클래스에 노출하는 메서드와 프로퍼티를 말합니다. 아래 예제에서 암시적 계약은 `InventoryTracker`를 위한 모든 Request 모듈이 `requestItems` 메서드를 가질 것이라는 점입니다.

**Bad:**

```javascript
class InventoryRequester {
  constructor() {
    this.REQ_METHODS = ["HTTP"];
  }

requestItem(item) {
    // ...
  }
}

class InventoryTracker {
  constructor(items) {
    this.items = items;

// BAD: 특정 요청 구현에 대한 의존성을 생성했습니다.
    // requestItems가 요청 메서드(`request`)에만 의존하도록 해야 합니다.
    this.requester = new InventoryRequester();
  }

requestItems() {
    this.items.forEach(item => {
      this.requester.requestItem(item);
    });
  }
}

const inventoryTracker = new InventoryTracker(["apples", "bananas"]);
inventoryTracker.requestItems();
```

**Good:**

```javascript
class InventoryTracker {
  constructor(items, requester) {
    this.items = items;
    this.requester = requester;
  }

requestItems() {
    this.items.forEach(item => {
      this.requester.requestItem(item);
    });
  }
}

class InventoryRequesterV1 {
  constructor() {
    this.REQ_METHODS = ["HTTP"];
  }

requestItem(item) {
    // ...
  }
}

class InventoryRequesterV2 {
  constructor() {
    this.REQ_METHODS = ["WS"];
  }

requestItem(item) {
    // ...
  }
}

// 의존성을 외부에서 생성하고 주입함으로써, 웹소켓을 사용하는 멋진 새 요청 모듈로 쉽게 대체할 수 있습니다.
const inventoryTracker = new InventoryTracker(
  ["apples", "bananas"],
  new InventoryRequesterV2()
);
inventoryTracker.requestItems();
```

**[⬆ 맨 위로](#table-of-contents)**

## **테스팅**

테스팅은 배포보다 더 중요합니다. 테스트가 없거나 불충분한 양의 테스트가 있다면, 코드를 배포할 때마다 아무것도 망가뜨리지 않았음을 확신할 수 없습니다. 적절한 수준이 무엇인지를 결정하는 것은 팀에 달려 있지만, 100% 커버리지(모든 구문과 분기)는 매우 높은 신뢰와 개발자의 마음의 평정을 얻는 방법입니다. 이는 훌륭한 테스팅 프레임워크를 갖추는 것 외에도 [좋은 커버리지 도구](https://gotwarlost.github.io/istanbul/)를 사용해야 함을 의미합니다.

테스트를 작성하지 않을 변명은 없습니다. [많은 훌륭한 JS 테스트 프레임워크](https://jstherightway.org/#testing-tools)가 있으므로 팀이 선호하는 것을 찾으세요. 팀에 맞는 것을 찾았다면 도입하는 모든 새로운 기능/모듈에 대해 항상 테스트를 작성하는 것을 목표로 삼으세요. 선호하는 방법이 TDD(테스트 주도 개발)라면 아주 좋지만, 핵심은 기능을 출시하거나 기존 코드를 리팩터링하기 전에 커버리지 목표에 도달하고 있는지 확인하는 것입니다.

### 테스트당 단일 개념

**Bad:**

```javascript
import assert from "assert";

describe("MomentJS", () => {
  it("handles date boundaries", () => {
    let date;

date = new MomentJS("1/1/2015");
    date.addDays(30);
    assert.equal("1/31/2015", date);

date = new MomentJS("2/1/2016");
    date.addDays(28);
    assert.equal("02/29/2016", date);

date = new MomentJS("2/1/2015");
    date.addDays(28);
    assert.equal("03/01/2015", date);
  });
});
```

**Good:**

```javascript
import assert from "assert";

describe("MomentJS", () => {
  it("handles 30-day months", () => {
    const date = new MomentJS("1/1/2015");
    date.addDays(30);
    assert.equal("1/31/2015", date);
  });

it("handles leap year", () => {
    const date = new MomentJS("2/1/2016");
    date.addDays(28);
    assert.equal("02/29/2016", date);
  });

it("handles non-leap year", () => {
    const date = new MomentJS("2/1/2015");
    date.addDays(28);
    assert.equal("03/01/2015", date);
  });
});
```

**[⬆ 맨 위로](#table-of-contents)**

## **동시성**

### 콜백 대신 프로미스(Promises)를 사용하세요

콜백은 깔끔하지 않으며 과도한 중첩을 유발합니다. ES2015/ES6에서는 프로미스가 내장된 전역 타입입니다. 사용하세요!

**Bad:**

```javascript
import { get } from "request";
import { writeFile } from "fs";

get(
  "https://en.wikipedia.org/wiki/Robert_Cecil_Martin",
  (requestErr, response, body) => {
    if (requestErr) {
      console.error(requestErr);
    } else {
      writeFile("article.html", body, writeErr => {
        if (writeErr) {
          console.error(writeErr);
        } else {
          console.log("File written");
        }
      });
    }
  }
);
```

**Good:**

```javascript
import { get } from "request-promise";
import { writeFile } from "fs-extra";

get("https://en.wikipedia.org/wiki/Robert_Cecil_Martin")
  .then(body => {
    return writeFile("article.html", body);
  })
  .then(() => {
    console.log("File written");
  })
  .catch(err => {
    console.error(err);
  });
```

**[⬆ 맨 위로](#table-of-contents)**

### Async/Await은 프로미스보다 훨씬 더 깔끔합니다

프로미스는 콜백의 매우 깔끔한 대안이지만, ES2017/ES8은 훨씬 더 깔끔한 솔루션을 제공하는 async와 await를 도입했습니다. `async` 키워드가 앞에 붙은 함수만 있으면 `then` 체인 함수 없이 명령형으로 로직을 작성할 수 있습니다. 오늘날 ES2017/ES8 기능을 활용할 수 있다면 이것을 사용하세요!

**Bad:**

```javascript
import { get } from "request-promise";
import { writeFile } from "fs-extra";

**Good:**

```javascript
import { get } from "request-promise";
import { writeFile } from "fs-extra";

async function getCleanCodeArticle() {
  try {
    const body = await get(
      "https://en.wikipedia.org/wiki/Robert_Cecil_Martin"
    );
    await writeFile("article.html", body);
    console.log("File written");
  } catch (err) {
    console.error(err);
  }
}

getCleanCodeArticle()
```

**[⬆ 맨 위로](#table-of-contents)**

## **에러 핸들링**

에러를 throw하는 것은 좋은 일입니다! 이는 런타임이 프로그램에서 무언가 잘못된 것을 성공적으로 식별했음을 의미하며, 현재 스택에서 함수 실행을 중단하고, (Node에서) 프로세스를 종료하며, 스택 추적(stack trace)과 함께 콘솔에 알림으로써 당신에게 알려주고 있는 것입니다.

### 잡은 에러를 무시하지 마세요

잡은 에러(caught error)를 가지고 아무것도 하지 않는 것은 해당 에러를 수정하거나 반응할 수 있는 능력을 아예 없애버리는 것입니다. 에러를 콘솔에 로깅하는 것(`console.log`)도 콘솔에 출력된 수많은 항목들 속에 쉽게 묻힐 수 있기 때문에 그리 낫지 않습니다. 어떤 코드든 `try/catch`로 감싸는 것은 그곳에서 에러가 발생할 수 있다고 생각한다는 의미이므로, 에러가 발생했을 때의 계획을 세우거나 코드 경로를 만들어야 합니다.

**Bad:**

```javascript
try {
  functionThatMightThrow();
} catch (error) {
  console.log(error);
}
```

**Good:**

```javascript
try {
  functionThatMightThrow();
} catch (error) {
  // 한 가지 옵션 (console.log보다 더 눈에 띔):
  console.error(error);
  // 다른 옵션:
  notifyUserOfError(error);
  // 다른 옵션:
  reportErrorToService(error);
  // 혹은 이 세 가지 모두 수행!
}
```

### 거부된 프로미스(rejected promises)를 무시하지 마세요

`try/catch`에서 잡은 에러를 무시하지 말아야 하는 것과 같은 이유입니다.

**Bad:**

```javascript
getdata()
  .then(data => {
    functionThatMightThrow(data);
  })
  .catch(error => {
    console.log(error);
  });
```

**Good:**

```javascript
getdata()
  .then(data => {
    functionThatMightThrow(data);
  })
  .catch(error => {
    // 한 가지 옵션 (console.log보다 더 눈에 띔):
    console.error(error);
    // 다른 옵션:
    notifyUserOfError(error);
    // 다른 옵션:
    reportErrorToService(error);
    // 혹은 이 세 가지 모두 수행!
  });
```

**[⬆ 맨 위로](#table-of-contents)**

## **포매팅**

포매팅은 주관적입니다. 여기에 있는 많은 규칙처럼 반드시 따라야 하는 엄격하고 빠른 규칙은 없습니다. 핵심 요점은 포매팅을 가지고 싸우지 말라는 것입니다. 이를 자동화할 [수많은 도구들](https://standardjs.com/rules.html)이 있습니다. 사용하세요! 엔지니어들이 포매팅을 두고 논쟁하는 것은 시간과 돈의 낭비입니다.

자동 포매팅의 범주에 속하지 않는 것들(들여쓰기, 탭 대 스페이스, 큰따옴표 대 작은따옴표 등)은 지침을 위해 여기를 참고하세요.

### 일관된 대소문자 사용법을 지키세요

JavaScript에는 타입이 없으므로 대소문자는 변수, 함수 등에 대해 많은 것을 말해 줍니다. 이 규칙들은 주관적이므로 팀이 원하는 대로 선택할 수 있습니다. 핵심은 여러분 모두가 무엇을 선택하든 일관성을 유지하는 것입니다.

**Bad:**

```javascript
const DAYS_IN_WEEK = 7;
const daysInMonth = 30;

const songs = ["Back In Black", "Stairway to Heaven", "Hey Jude"];
const Artists = ["ACDC", "Led Zeppelin", "The Beatles"];

function eraseDatabase() {}
function restore_database() {}

class animal {}
class Alpaca {}
```

**Good:**

```javascript
const DAYS_IN_WEEK = 7;
const DAYS_IN_MONTH = 30;

const SONGS = ["Back In Black", "Stairway to Heaven", "Hey Jude"];
const ARTISTS = ["ACDC", "Led Zeppelin", "The Beatles"];

function eraseDatabase() {}
function restoreDatabase() {}

class Animal {}
class Alpaca {}
```

**[⬆ 맨 위로](#table-of-contents)**

### 함수 호출자와 피호출자는 가까이 두어야 합니다

함수가 다른 함수를 호출한다면 소스 파일에서 두 함수를 수직으로 가깝게 유지하세요. 이상적으로는 호출자를 피호출자 바로 위에 두세요. 우리는 신문처럼 코드를 위에서 아래로 읽는 경향이 있습니다. 이 때문에 코드가 그렇게 읽히도록 만드세요.

**Bad:**

```javascript
class PerformanceReview {
  constructor(employee) {
    this.employee = employee;
  }

lookupPeers() {
    return db.lookup(this.employee, "peers");
  }

lookupManager() {
    return db.lookup(this.employee, "manager");
  }

getPeerReviews() {
    const peers = this.lookupPeers();
    // ...
  }

perfReview() {
    this.getPeerReviews();
    this.getManagerReview();
    this.getSelfReview();
  }

getManagerReview() {
    const manager = this.lookupManager();
  }

getSelfReview() {
    // ...
  }
}

const review = new PerformanceReview(employee);
review.perfReview();
```

**Good:**

```javascript
class PerformanceReview {
  constructor(employee) {
    this.employee = employee;
  }

perfReview() {
    this.getPeerReviews();
    this.getManagerReview();
    this.getSelfReview();
  }

getPeerReviews() {
    const peers = this.lookupPeers();
    // ...
  }

lookupPeers() {
    return db.lookup(this.employee, "peers");
  }

getManagerReview() {
    const manager = this.lookupManager();
  }

lookupManager() {
    return db.lookup(this.employee, "manager");
  }

getSelfReview() {
    // ...
  }
}

const review = new PerformanceReview(employee);
review.perfReview();
```

**[⬆ 맨 위로](#table-of-contents)**

## **주석**

### 비즈니스 로직 복잡성이 있는 것에만 주석을 남기세요

주석은 사과이지 요구사항이 아닙니다. 좋은 코드는 _대체로_ 스스로 설명합니다.

**Bad:**

```javascript
function hashIt(data) {
  // 해시
  let hash = 0;

// 문자열의 길이
  const length = data.length;

// data의 모든 문자를 순회합니다.
  for (let i = 0; i < length; i++) {
    // 문자 코드를 가져옵니다.
    const char = data.charCodeAt(i);
    // 해시를 만듭니다.
    hash = (hash << 5) - hash + char;
    // 32비트 정수로 변환합니다.
    hash &= hash;
  }
}
```

**Good:**

```javascript
function hashIt(data) {
  let hash = 0;
  const length = data.length;

for (let i = 0; i < length; i++) {
    const char = data.charCodeAt(i);
    hash = (hash << 5) - hash + char;

// 32비트 정수로 변환합니다.
    hash &= hash;
  }
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 주석 처리된 코드를 코드베이스에 남겨두지 마세요

버전 관리가 존재하는 이유는 따로 있습니다. 옛 코드는 히스토리에 남겨두세요.

**Bad:**

```javascript
doStuff();
// doOtherStuff();
// doSomeMoreStuff();
// doSoMuchStuff();
```

**Good:**

```javascript
doStuff();
```

**[⬆ 맨 위로](#table-of-contents)**

### 저널 주석(Journal comments)을 남기지 마세요

기억하세요, 버전 관리를 사용하세요! 죽은 코드, 주석 처리된 코드, 그리고 특히 저널 주석은 필요하지 않습니다. 히스토리를 가져오려면 `git log`를 사용하세요!

**Bad:**

```javascript
/**
 * 2016-12-20: 모나드 제거, 이해하지 못했음 (RM)
 * 2016-10-01: 특수 모나드를 사용하여 개선 (JP)
 * 2016-02-03: 타입 검사 제거 (LI)
 * 2015-03-14: 타입 검사가 포함된 combine 추가 (JR)
 */
function combine(a, b) {
  return a + b;
}
```

**Good:**

```javascript
function combine(a, b) {
  return a + b;
}
```

**[⬆ 맨 위로](#table-of-contents)**

### 위치 표지(Positional markers)를 피하세요

이것들은 대개 소음만 더할 뿐입니다. 함수 및 변수 이름과 적절한 들여쓰기 및 포매팅이 코드에 시각적 구조를 부여하도록 하세요.

**Bad:**

```javascript
////////////////////////////////////////////////////////////////////////////////
// Scope Model Instantiation
////////////////////////////////////////////////////////////////////////////////
$scope.model = {
  menu: "foo",
  nav: "bar"
};

////////////////////////////////////////////////////////////////////////////////
// Action setup
////////////////////////////////////////////////////////////////////////////////
const actions = function() {
  // ...
};
```

**Good:**

```javascript
$scope.model = {
  menu: "foo",
  nav: "bar"
};

const actions = function() {
  // ...
};
```

**[⬆ 맨 위로](#table-of-contents)**

## 번역

이 문서는 다른 언어로도 제공됩니다:

- ![am](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Armenia.png) **Armenian**: [hanumanum/clean-code-javascript/](https://github.com/hanumanum/clean-code-javascript)
- ![bd](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Bangladesh.png) **Bangla(বাংলা)**: [InsomniacSabbir/clean-code-javascript/](https://github.com/InsomniacSabbir/clean-code-javascript/)
- ![br](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Brazil.png) **Brazilian Portuguese**: [fesnt/clean-code-javascript](https://github.com/fesnt/clean-code-javascript)
- ![cn](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/China.png) **Simplified Chinese**:
  - [alivebao/clean-code-js](https://github.com/alivebao/clean-code-js)
  - [beginor/clean-code-javascript](https://github.com/beginor/clean-code-javascript)
- ![tw](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Taiwan.png) **Traditional Chinese**: [AllJointTW/clean-code-javascript](https://github.com/AllJointTW/clean-code-javascript)
- ![fr](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/France.png) **French**: [eugene-augier/clean-code-javascript-fr](https://github.com/eugene-augier/clean-code-javascript-fr)
- ![de](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Germany.png) **German**: [marcbruederlin/clean-code-javascript](https://github.com/marcbruederlin/clean-code-javascript)
- ![id](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Indonesia.png) **Indonesia**: [andirkh/clean-code-javascript/](https://github.com/andirkh/clean-code-javascript/)
- ![it](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Italy.png) **Italian**: [frappacchio/clean-code-javascript/](https://github.com/frappacchio/clean-code-javascript/)
- ![ja](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Japan.png) **Japanese**: [mitsuruog/clean-code-javascript/](https://github.com/mitsuruog/clean-code-javascript/)
- ![kr](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/South-Korea.png) **Korean**: [qkraudghgh/clean-code-javascript-ko](https://github.com/qkraudghgh/clean-code-javascript-ko)
- ![pl](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Poland.png) **Polish**: [greg-dev/clean-code-javascript-pl](https://github.com/greg-dev/clean-code-javascript-pl)
- ![ru](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Russia.png) **Russian**:
  - [BoryaMogila/clean-code-javascript-ru/](https://github.com/BoryaMogila/clean-code-javascript-ru/)
  - [maksugr/clean-code-javascript](https://github.com/maksugr/clean-code-javascript)
- ![es](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Spain.png) **Spanish**: [tureey/clean-code-javascript](https://github.com/tureey/clean-code-javascript)
- ![es](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Uruguay.png) **Spanish**: [andersontr15/clean-code-javascript](https://github.com/andersontr15/clean-code-javascript-es)
- ![rs](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Serbia.png) **Serbian**: [doskovicmilos/clean-code-javascript/](https://github.com/doskovicmilos/clean-code-javascript)
- ![tr](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Turkey.png) **Turkish**: [bsonmez/clean-code-javascript](https://github.com/bsonmez/clean-code-javascript/tree/turkish-translation)
- ![ua](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Ukraine.png) **Ukrainian**: [mindfr1k/clean-code-javascript-ua](https://github.com/mindfr1k/clean-code-javascript-ua)
- ![vi](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Vietnam.png) **Vietnamese**: [hienvd/clean-code-javascript/](https://github.com/hienvd/clean-code-javascript/)
- ![ir](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Iran.png) **Persian**: [hamettio/clean-code-javascript](https://github.com/hamettio/clean-code-javascript)

**[⬆ 맨 위로](#table-of-contents)**

clean-code-javascript

파일 탐색기

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

clean-code-javascript

파일 탐색기

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README