clean-code-typescript

KO | EN

gitlite — search

#python #llm #go #android #machine-learning #rust #deep-learning #linux #docker #awesome #kubernetes #awesome-list #pytorch #ios

clean-code-typescript

(★ 9,801)

TypeScript에 적용한 클린 코드 개념

파일 탐색기

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

.gitattributes
_config.yml
LICENSE
README.md

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# clean-code-typescript [![Tweet](https://img.shields.io/twitter/url/http/shields.io.svg?style=social)](https://twitter.com/intent/tweet?text=Clean%20Code%20Typescript&url=https://github.com/labs42io/clean-code-typescript)
TypeScript로 각색된 Clean Code 개념들.
[clean-code-javascript](https://github.com/ryanmcdermott/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. [번역본](#translations)
## 소개
![코드를 읽을 때 내뱉는 욕설의 횟수로 소프트웨어 품질을 측정하는 것을 풍자하는 유머러스한 이미지](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)의 소프트웨어 공학 원칙을 TypeScript에 맞게 각색했습니다. 이것은 스타일 가이드가 아닙니다. TypeScript에서 [읽기 쉽고, 재사용 가능하며, 리팩토링하기 쉬운](https://github.com/ryanmcdermott/3rs-of-software-architecture) 소프트웨어를 작성하기 위한 지침입니다.
여기에 있는 모든 원칙을 엄격하게 따를 필요는 없으며, 보편적인 동의를 얻을 수 있는 원칙은 그보다 더 적을 것입니다. 이것들은 지침에 불과하지만, \*Clean Code\*의 저자들이 오랜 시간에 걸쳐 축적한 집단적 경험을 바탕으로 성문화한 것입니다.
우리의 소프트웨어 공학이라는 장인은 겨우 50년 조금 넘었으며, 우리는 여전히 많은 것을 배우고 있습니다. 소프트웨어 아키텍처가 건축학 그 자체만큼 오래된다면, 그때쯤이면 우리가 따라야 할 더 엄격한 규칙이 생길지도 모릅니다. 지금으로서는 이 지침들이 여러분과 여러분의 팀이 생산하는 TypeScript 코드의 품질을 평가하는 시금석 역할을 하도록 하세요.
한 가지 더 말씀드리자면, 이것들을 안다고 해서 당장 더 나은 소프트웨어 개발자가 되는 것은 아니며, 수년 동안 이것들과 함께 일했다고 해서 실수를 하지 않는다는 뜻은 아닙니다. 모든 코드는 마치 진흙이 최종 형태로 빚어지듯 초안으로 시작합니다. 마지막으로 동료들과 함께 코드를 리뷰하면서 불완전한 부분을 깎아냅니다. 개선이 필요한 초안을 작성했다고 해서 자책하지 마세요. 대신 코드를 혼내주세요!
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
## 변수
### 의미 있는 변수 이름을 사용하세요
독자가 차이점을 알 수 있도록 이름을 구분하세요.
\*\*나쁨:\*\*
```ts
function between(a1: T, a2: T, a3: T): boolean {
return a2 <= a1 && a1 <= a3;
}
```
\*\*좋음:\*\*
```ts
function between(value: T, left: T, right: T): boolean {
return left <= value && value <= right;
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 발음할 수 있는 변수 이름을 사용하세요
발음할 수 없다면, 바보처럼 보이지 않고는 그 것에 대해 논의할 수 없습니다.
\*\*나쁨:\*\*
```ts
type DtaRcrd102 = {
genymdhms: Date;
modymdhms: Date;
pszqint: number;
}
```
\*\*좋음:\*\*
```ts
type Customer = {
generationTimestamp: Date;
modificationTimestamp: Date;
recordId: number;
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 동일한 타입의 변수에는 동일한 어휘를 사용하세요
\*\*나쁨:\*\*
```ts
function getUserInfo(): User;
function getUserDetails(): User;
function getUserData(): User;
```
\*\*좋음:\*\*
```ts
function getUser(): User;
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 검색 가능한 이름을 사용하세요
우리는 작성하는 것보다 더 많은 코드를 읽게 됩니다. 우리가 작성하는 코드는 읽기 쉽고 검색 가능해야 합니다. 프로그램을 이해하는 데 의미가 있는 변수들의 이름을 짓지 \*않음\*으로써 독자들에게 해를 끼치게 됩니다. 이름을 검색 가능하게 만드세요. [ESLint](https://typescript-eslint.io/) 같은 도구는 명명되지 않은 상수(매직 스트링 및 매직 번호로도 알려져 있음)를 식별하는 데 도움을 줄 수 있습니다.
\*\*나쁨:\*\*
```ts
// 86400000은 도대체 뭘 뜻하는 걸까요?
setTimeout(restart, 86400000);
```
\*\*좋음:\*\*
```ts
// 대문자로 된 명명된 상수로 선언하세요.
const MILLISECONDS\_PER\_DAY =

24 \* 60 \* 60 \* 1000; // 86400000
setTimeout(restart, MILLISECONDS\_PER\_DAY);
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 설명적인 변수명을 사용하세요
\*\*나쁨:\*\*
```ts
declare const users: Map;
for (const keyValue of users) {
// users 맵 순회
}
```
\*\*좋음:\*\*
```ts
declare const users: Map;
for (const [id, user] of users) {
// users 맵 순회
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 정신적 매핑을 피하세요
명시적인 것이 암묵적인 것보다 좋습니다.
\*명확성이 최고입니다.\*
\*\*나쁨:\*\*
```ts
const u = getUser();
const s = getSubscription();
const t = charge(u, s);
```
\*\*좋음:\*\*
```ts
const user = getUser();
const subscription = getSubscription();
const transaction = charge(user, subscription);
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 불필요한 문맥을 추가하지 마세요
클래스/타입/객체 이름이 이미 무언가를 말해주고 있다면, 변수 이름에 그것을 반복하지 마세요.
\*\*나쁨:\*\*
```ts
type Car = {
carMake: string;
carModel: string;
carColor: string;
}
function print(car: Car): void {
console.log(`${car.carMake} ${car.carModel} (${car.carColor})`);
}
```
\*\*좋음:\*\*
```ts
type Car = {
make: string;
model: string;
color: string;
}
function print(car: Car): void {
console.log(`${car.make} ${car.model} (${car.color})`);
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 단락 평가(short circuiting)나 조건문 대신 기본 매개변수를 사용하세요
기본 매개변수는 종종 단락 평가보다 더 깔끔합니다.
\*\*나쁨:\*\*
```ts
function loadPages(count?: number) {
const loadCount = count !== undefined ? count : 10;
// ...
}
```
\*\*좋음:\*\*
```ts
function loadPages(count: number = 10) {
// ...
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 의도를 문서화하기 위해 enum을 사용하세요
Enum은 코드의 의도를 문서화하는 데 도움을 줍니다. 예를 들어, 정확한 값 자체보다는 값들이 서로 다르다는 점이 중요할 때 유용합니다.
\*\*나쁨:\*\*
```ts
const GENRE = {
ROMANTIC: 'romantic',
DRAMA: 'drama',
COMEDY: 'comedy',
DOCUMENTARY: 'documentary',
}
projector.configureFilm(GENRE.COMEDY);
class Projector {
// Projector 선언
configureFilm(genre) {
switch (genre) {
case GENRE.ROMANTIC:
// 실행될 일부 로직
}
}
}
```
\*\*좋음:\*\*
```ts
enum GENRE {
ROMANTIC,
DRAMA,
COMEDY,
DOCUMENTARY,
}
projector.configureFilm(GENRE.COMEDY);
class Projector {
// Projector 선언
configureFilm(genre) {
switch (genre) {
case GENRE.ROMANTIC:
// 실행될 일부 로직
}
}
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
## 함수 (Functions)
### 함수 인수 (이상적으로는 2개 이하)
함수 매개변수의 수를 제한하는 것은 함수의 테스트를 쉽게 만들어 주기 때문에 엄청나게 중요합니다.
매개변수가 3개를 넘어가면 조합 폭발이 일어나서, 각각의 개별 인수에 대해 수많은 서로 다른 경우의 수를 테스트해야 하게 됩니다.
인수는 1개 또는 2개가 이상적이며, 가능하다면 3개는 피해야 합니다. 그 이상의 인수가 필요하다면 병합해야 합니다.
대개 인수가 2개를 넘는다면 그 함수는 너무 많은 일을 하려고 하는 것입니다.
그렇지 않은 경우라도, 대부분의 경우 상위 수준의 객체를 인수로 사용하는 것으로 충분합니다.
많은 인수가 필요하다고 느껴진다면 객체 리터럴(object literal) 사용을 고려해 보세요.
함수가 어떤 속성을 기대하는지 명확하게 만들기 위해 [구조 분해(destructuring)](https://basarat.gitbook.io/typescript/future-javascript/destructuring) 구문을 사용할 수 있습니다.
이 방식에는 몇 가지 장점이 있습니다:
1. 누군가 함수의 시그니처를 볼 때, 어떤 속성들이 사용되고 있는지 즉시 명확하게 알 수 있습니다.
2. 명명된 매개변수(named parameters)를 시뮬레이트하는 데 사용할 수 있습니다.
3. 구조 분해는 함수로 전달된 인수 객체의 지정된 원시 값들을 복제합니다. 이는 부수 효과(side effects)를 방지하는 데 도움이 됩니다. 참고: 인수 객체에서 구조 분해된 객체와 배열은 복제되지 **않습니다**.
4. TypeScript는 사용되지 않는 속성에 대해 경고를 주며, 이는 구조 분해 없이는 불가능한 기능입니다.
\*\*나쁨:\*\*
```ts
function createMenu(title: string, body: string, buttonText: string, cancellable: boolean) {
// ...
}
createMenu('

Foo', 'Bar', 'Baz', true);
```
\*\*Good:\*\*
```ts
function createMenu(options: { title: string, body: string, buttonText: string, cancellable: boolean }) {
// ...
}
createMenu({
title: 'Foo',
body: 'Bar',
buttonText: 'Baz',
cancellable: true
});
```
[type aliases](https://www.typescriptlang.org/docs/handbook/advanced-types.html#type-aliases)를 사용하여 가독성을 더욱 향상시킬 수 있습니다:
```ts
type MenuOptions = { title: string, body: string, buttonText: string, cancellable: boolean };
function createMenu(options: MenuOptions) {
// ...
}
createMenu({
title: 'Foo',
body: 'Bar',
buttonText: 'Baz',
cancellable: true
});
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 함수는 한 가지 일만 해야 합니다
이것은 소프트웨어 공학에서 단연코 가장 중요한 규칙입니다. 함수가 한 가지 이상의 일을 할 때, 함수를 조합하고 테스트하며 이해하기가 더 어려워집니다. 함수를 단 하나의 작업으로만 격리할 수 있다면 쉽게 리팩토링할 수 있고 코드가 훨씬 더 깔끔하게 읽힐 것입니다. 이 가이드에서 이것 외에 다른 아무것도 가져가지 못하더라도, 이 규칙만 지킨다면 많은 개발자보다 앞서게 될 것입니다.
\*\*Bad:\*\*
```ts
function emailActiveClients(clients: Client[]) {
clients.forEach((client) => {
const clientRecord = database.lookup(client);
if (clientRecord.isActive()) {
email(client);
}
});
}
```
\*\*Good:\*\*
```ts
function emailActiveClients(clients: Client[]) {
clients.filter(isActiveClient).forEach(email);
}
function isActiveClient(client: Client) {
const clientRecord = database.lookup(client);
return clientRecord.isActive();
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 함수 이름은 자신이 하는 일을 나타내야 합니다
\*\*Bad:\*\*
```ts
function addToDate(date: Date, month: number): Date {
// ...
}
const date = new Date();
// 함수 이름만으로는 어떤 것이 더해지는지 알기 어렵습니다
addToDate(date, 1);
```
\*\*Good:\*\*
```ts
function addMonthToDate(date: Date, month: number): Date {
// ...
}
const date = new Date();
addMonthToDate(date, 1);
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 함수는 단 하나의 추상화 수준만 가져야 합니다
추상화 수준이 두 개 이상인 경우, 보통 함수가 너무 많은 일을 하고 있는 것입니다. 함수를 분리하면 재사용성이 높아지고 테스트가 더 쉬워집니다.
\*\*Bad:\*\*
```ts
function parseCode(code: string) {
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:\*\*
```ts
const REGEXES = [ /\* ... \*/ ];
function parseCode(code: string) {
const tokens = tokenize(code);
const syntaxTree = parse(tokens);
syntaxTree.forEach((node) => {
// parse...
});
}
function tokenize(code: string): Token[] {
const statements = code.split(' ');
const tokens: Token[] = [];
REGEXES.forEach((regex) => {
statements.forEach((statement) => {
tokens.push( /\* ... \*/ );
});
});
return tokens;
}
function parse(tokens: Token[]): SyntaxTree {
const syntaxTree: SyntaxTree[] = [];
tokens.forEach((token) => {
syntaxTree.push( /\* ... \*/ );
});
return syntaxTree;
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 중복된 코드를 제거하세요
중복 코드를 피하기 위해 최선을 다해야 합니다.
중복 코드가 나쁜 이유는 로직을 변경해야 할 때 수정해야 할 곳이 한 곳 이상이기 때문입니다.
당신이 식당을 운영하면서 토마토, 양파, 마늘, 향신료 등 재고를 추적하고 있다고 상상해 보세요.
이 재고를 기록하는 목록이 여러 개라면, 토마토가 들어간 요리를 제공할 때마다 모든 목록을 업데이트해야 합니다.
목록이 단 하나뿐이라면, 업데이트할 곳도 오직 한 곳뿐입니다!
공통점이 많지만 약간 다른 두 가지 이상의 상황이 있어서, 비슷한 일을 하는 두 개 이상의 별도 함수를 강제로 만들어야 할 때 중복 코드가 자주 발생합니다. 중복 코드를 제거한다는 것은 이러한 다양한 일련의 작업을 단 하나의 함수로 처리할 수 있는 추상화를 만드는 것을 의미합니다.

function/module/class.
추상화를 올바르게 하는 것은 매우 중요하며, 이것이 바로 [SOLID](#solid) 원칙을 따라야 하는 이유입니다. 잘못된 추상화는 중복된 코드보다 더 나쁠 수 있으므로 주의해야 합니다! 그렇긴 하지만, 좋은 추상화를 만들 수 있다면 그렇게 하세요! 코드를 반복하지 마세요. 그렇지 않으면 무언가를 변경하고 싶을 때마다 여러 곳을 수정해야 하는 자신을 발견하게 될 것입니다.
\*\*Bad:\*\*
```ts
function showDeveloperList(developers: Developer[]) {
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: Manager[]) {
managers.forEach((manager) => {
const expectedSalary = manager.calculateExpectedSalary();
const experience = manager.getExperience();
const portfolio = manager.getMBAProjects();
const data = {
expectedSalary,
experience,
portfolio
};
render(data);
});
}
```
\*\*Good:\*\*
```ts
class Developer {
// ...
getExtraDetails() {
return {
githubLink: this.githubLink,
}
}
}
class Manager {
// ...
getExtraDetails() {
return {
portfolio: this.portfolio,
}
}
}
function showEmployeeList(employee: (Developer | Manager)[]) {
employee.forEach((employee) => {
const expectedSalary = employee.calculateExpectedSalary();
const experience = employee.getExperience();
const extra = employee.getExtraDetails();
const data = {
expectedSalary,
experience,
extra,
};
render(data);
});
}
```
추상화에 적합하다면 유니온 타입이나 공통 부모 클래스를 추가하는 것도 고려할 수 있습니다.
```ts
class Developer {
// ...
}
class Manager {
// ...
}
type Employee = Developer | Manager
function showEmployeeList(employee: Employee[]) {
// ...
});
}
```
코드 중복에 대해서는 비판적인 시각을 가져야 합니다. 때로는 중복된 코드와 불필요한 추상화 도입으로 인한 복잡성 증가 사이에 트레이드오프가 존재합니다. 서로 다른 두 모듈의 두 구현이 비슷해 보이지만 서로 다른 도메인에 속해 있는 경우, 공통 코드를 추출하는 것보다 중복이 허용되며 오히려 선호될 수 있습니다. 이 경우 추출된 공통 코드는 두 모듈 간의 간접적인 의존성을 유발합니다.
\*\*[⬆ back to top](#table-of-contents)\*\*
### Object.assign이나 구조 분해 할당을 사용하여 기본 객체 설정하기
\*\*Bad:\*\*
```ts
type MenuConfig = { title?: string, body?: string, buttonText?: string, cancellable?: boolean };
function createMenu(config: MenuConfig) {
config.title = config.title || 'Foo';
config.body = config.body || 'Bar';
config.buttonText = config.buttonText || 'Baz';
config.cancellable = config.cancellable !== undefined ? config.cancellable : true;
// ...
}
createMenu({ body: 'Bar' });
```
\*\*Good:\*\*
```ts
type MenuConfig = { title?: string, body?: string, buttonText?: string, cancellable?: boolean };
function createMenu(config: MenuConfig) {
const menuConfig = Object.assign({
title: 'Foo',
body: 'Bar',
buttonText: 'Baz',
cancellable: true
}, config);
// ...
}
createMenu({ body: 'Bar' });
```
또는 스프레드 연산자를 사용할 수 있습니다:
```ts
function createMenu(config: MenuConfig) {
const menuConfig = {
title: 'Foo',
body: 'Bar',
buttonText: 'Baz',
cancellable: true,
...config,
};
// ...
}
```
스프레드 연산자와 `Object.assign()`은 매우 유사합니다.
주요 차이점은 스프레드는 새로운 프로퍼티를 정의하는 반면, `Object.assign()`은 프로퍼티를 설정한다는 점입니다. 더 자세한 차이점은 [이 스레드](https://stackoverflow.com/questions/32925460/object-spread-vs-object-assign)에 설명되어 있습니다.
대안으로, 기본값을 가진 구조 분해 할당을 사용할 수 있습니다:
```ts
type MenuConfig = { title?: string, body?: string, buttonText?: string, cancellable?: boolean };
function createMenu({ title = 'Foo', body = 'Bar', buttonText = 'Baz', cancellable = true }: MenuConfig) {
// ...
}
createMenu({ body: 'Bar' });
```
`undefined`나 `null` 값을 명시적으로 전달함으로써 발생하는 부작용과 예기치 않은 동작을 방지하기 위해, TypeScript 컴파일러에

허용하지 않으려면 사용하세요.
TypeScript의 [`--strictNullChecks`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html#--strictnullchecks) 옵션을 참고하세요.
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*

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

\*\*나쁜 예:\*\*
```ts
function createFile(name: string, temp: boolean) {
  if (temp) {
    fs.create(`./temp/${name}`);
  } else {
    fs.create(name);
  }
}
```

\*\*좋은 예:\*\*
```ts
function createTempFile(name: string) {
  createFile(`./temp/${name}`);
}

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

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

### 부수 효과(Side Effect) 피하기 (파트 1)
함수는 값을 입력받아 다른 값을 반환하는 것 외의 다른 작업을 할 때 부수 효과를 발생시킵니다.
부수 효과란 파일 쓰기, 전역 변수 수정, 혹은 실수로 모르는 사람에게 전 재산을 송금하는 것과 같은 일을 말합니다.

물론 프로그램에서 부수 효과가 아예 필요 없는 것은 아닙니다. 이전 예시처럼 파일을 작성해야 할 수도 있습니다.
중요한 것은 이러한 작업을 수행하는 위치를 중앙화하는 것입니다. 특정 파일에 쓰는 여러 개의 함수나 클래스를 난잡하게 두지 마세요.
이를 수행하는 서비스는 단 하나만 두어야 합니다. 오직 단 하나만 말이죠.

핵심 포인트는 구조 없는 객체 간 상태 공유, 무엇이든 쓸 수 있는 가변 데이터 타입 사용, 부수 효과가 발생하는 위치의 중앙화 실패와 같은 흔한 함정들을 피하는 것입니다. 만약 이렇게 할 수 있다면, 대다수의 다른 프로그래머들보다 훨씬 더 행복한 개발자가 될 것입니다.

\*\*나쁜 예:\*\*
```ts
// 다음 함수에서 참조하는 전역 변수
let name = 'Robert C. Martin';

function toBase64() {
  name = btoa(name);
}

toBase64();
// 이 이름을 사용하는 다른 함수가 있다면, 이제 이 값은 Base64 값이 되어버립니다.
console.log(name); // 'Robert C. Martin' 출력을 기대했으나 'Um9iZXJ0IEMuIE1hcnRpbg=='가 출력됨
```

\*\*좋은 예:\*\*
```ts
const name = 'Robert C. Martin';

function toBase64(text: string): string {
  return btoa(text);
}

const encodedName = toBase64(name);
console.log(name);
```

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

### 부수 효과(Side Effect) 피하기 (파트 2)
브라우저와 Node.js는 JavaScript만 처리할 수 있으므로, 모든 TypeScript 코드는 실행이나 디버깅 전에 컴파일되어야 합니다. JavaScript에서 어떤 값은 변경 불가능(immutable)하며, 어떤 값은 변경 가능(mutable)합니다. 객체와 배열은 변경 가능한 값의 두 가지 종류이므로, 함수의 매개변수로 전달될 때 주의해서 다루어야 합니다. JavaScript 함수는 객체의 속성을 바꾸거나 배열의 내용을 변경할 수 있으며, 이는 쉽게 다른 곳에서 버그를 유발할 수 있습니다.

쇼핑카트를 나타내는 배열 매개변수를 받는 함수가 있다고 가정해 봅시다. 만약 이 함수가 구매할 아이템을 추가하는 등의 방식으로 쇼핑카트 배열을 변경한다면, 동일한 `cart` 배열을 사용하는 다른 모든 함수가 이 변경의 영향을 받게 됩니다. 이것이 좋을 수도 있지만, 나쁠 수도 있습니다. 나쁜 상황을 상상해 봅시다.

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

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

이 접근 방식과 관련하여 언급해야 할 두 가지 주의 사항이 있습니다:
1. 입력 객체를 실제로 수정하고 싶은 경우가 있을 수 있습니다.

ct이지만, 이 프로그래밍 방식을 도입하면 그러한 경우는 꽤 드물다는 것을 알게 될 것입니다. 대부분의 경우 부수 효과가 없도록 리팩터링할 수 있습니다! ([순수 함수](https://en.wikipedia.org/wiki/Pure\_function) 참고)
2. 커다란 객체를 복제하는 것은 성능 측면에서 매우 비용이 많이 들 수 있습니다. 다행히도, 객체와 배열을 수동으로 복제할 때만큼 메모리를 많이 소모하지 않고 빠른 방식으로 이러한 프로그래밍 접근을 가능하게 해주는 [훌륭한 라이브러리들](https://github.com/immutable-js/immutable-js)이 존재하기 때문에 실제로는 큰 문제가 되지 않습니다.

\*\*나쁜 예:\*\*
```ts
function addItemToCart(cart: CartItem[], item: Item): void {
cart.push({ item, date: Date.now() });
};
```

\*\*좋은 예:\*\*
```ts
function addItemToCart(cart: CartItem[], item: Item): CartItem[] {
return [...cart, { item, date: Date.now() }];
};
```

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

### 전역 함수에 작성하지 마세요
JavaScript에서 전역 공간을 오염시키는 것은 다른 라이브러리와 충돌을 일으킬 수 있고, API 사용자는 프로덕션 환경에서 예외가 발생하기 전까지는 문제가 생겼는지 전혀 알 수 없기 때문에 좋지 않은 관행입니다. 예를 들어, 두 배열의 차이점을 보여줄 수 있는 `diff` 메서드를 가지도록 JavaScript의 기본 Array 메서드를 확장하고 싶다고 가정해 봅시다. 새로운 함수를 `Array.prototype`에 작성할 수 있지만, 동일한 작업을 수행하려는 다른 라이브러리와 충돌할 수 있습니다. 만약 그 다른 라이브러리가 단순히 배열의 첫 번째 요소와 마지막 요소 사이의 차이를 찾기 위해 `diff`를 사용하고 있었다면 어떻게 될까요? 그렇기 때문에 클래스를 사용하고 단순히 전역 `Array`를 확장하는 것이 훨씬 더 나은 이유입니다.

\*\*나쁜 예:\*\*
```ts
declare global {
interface Array {
diff(other: T[]): Array;
}
}
if (!Array.prototype.diff) {
Array.prototype.diff = function (other: T[]): T[] {
const hash = new Set(other);
return this.filter(elem => !hash.has(elem));
};
}
```

\*\*좋은 예:\*\*
```ts
class MyArray extends Array {
diff(other: T[]): T[] {
const hash = new Set(other);
return this.filter(elem => !hash.has(elem));
};
}
```

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

### 명령형 프로그래밍보다 함수형 프로그래밍을 선호하세요
가능하다면 이러한 프로그래밍 스타일을 선호하세요.

\*\*나쁜 예:\*\*
```ts
const contributions = [
{
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 < contributions.length; i++) {
totalOutput += contributions[i].linesOfCode;
}
```

\*\*좋은 예:\*\*
```ts
const contributions = [
{
name: 'Uncle Bobby',
linesOfCode: 500
}, {
name: 'Suzie Q',
linesOfCode: 1500
}, {
name: 'Jimmy Gosling',
linesOfCode: 150
}, {
name: 'Gracie Hopper',
linesOfCode: 1000
}
];
const totalOutput = contributions
.reduce((totalLines, output) => totalLines + output.linesOfCode, 0);
```

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

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

\*\*나쁜 예:\*\*
```ts
if (subscription.isTrial || account.balance > 0) {
// ...
}
```

\*\*좋은 예:\*\*
```ts
function canActivateService(subscription: Subscription, account: Account) {
return subscription.isTrial || account.balance > 0;
}
if (canActivateService(subscription, account)) {
// ...
}
```

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

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

\*\*나쁜 예:\*\*
```ts
function isEmailNotUsed(email: string): boolean {
// ...
}
if (isEmailNotUsed(email)) {
// ...
}
```

\*\*좋은 예:\*\*
```ts
function isEmailUsed(email: string): boolean {
// ...
}
if (!isEmailUsed(email)) {
// ...
}
```

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

### 조건문을 피하세요
이것은 불가능한 일처럼 보입니다. 이 말을 처음 들으면 대부분의 사람들은 "`if` 문 없이 어떻게 아무것도 하지 않죠?"라고 말합니다. 대답은 많은 경우에 다형성을 사용하여 동일한 작업을 수행할 수 있다는 것입니다. 두 번째 질문은 대개 "좋습니다만, 왜 굳이 그렇게 해야 하죠?"입니다. 그에 대한 답은 우리가 앞서 배운 클린 코드 개념에 있습니다: 함수는 반드시 하나의 일만 해야 합니다. 클래스가 있을 때

`if` 문이 포함된 메서드나 함수를 작성할 때는 사용자에게 해당 함수가 한 가지 이상의 일을 한다는 신호를 주는 것입니다. 기억하세요, 단 한 가지 일만 하도록 만드세요.

\*\*나쁜 예:\*\*
```ts
class Airplane {
private type: string;
// ...
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();
default:
throw new Error('Unknown airplane type.');
}
}
private getMaxAltitude(): number {
// ...
}
}
```

\*\*좋은 예:\*\*
```ts
abstract class Airplane {
protected getMaxAltitude(): number {
// 하위 클래스와 공유하는 로직 ...
}
// ...
}
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)\*\*

### 타입 검사 피하기

TypeScript는 JavaScript의 엄격한 구문적 상위 집합이며 언어에 선택적 정적 타입 검사 기능을 추가합니다.
TypeScript 기능의 이점을 온전히 누리기 위해 변수, 매개변수, 반환값의 타입을 항상 지정하는 것을 선호하세요.
이렇게 하면 리팩터링이 훨씬 쉬워집니다.

\*\*나쁜 예:\*\*
```ts
function travelToTexas(vehicle: Bicycle | Car) {
if (vehicle instanceof Bicycle) {
vehicle.pedal(currentLocation, new Location('texas'));
} else if (vehicle instanceof Car) {
vehicle.drive(currentLocation, new Location('texas'));
}
}
```

\*\*좋은 예:\*\*
```ts
type Vehicle = Bicycle | Car;
function travelToTexas(vehicle: Vehicle) {
vehicle.move(currentLocation, new Location('texas'));
}
```

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

### 지나치게 최적화하지 않기

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

\*\*나쁜 예:\*\*
```ts
// 구형 브라우저에서는 캐시되지 않은 `list.length`를 매 반복마다 재계산하기 때문에 비용이 많이 듭니다.
// 최신 브라우저에서는 이 부분이 최적화되어 있습니다.
for (let i = 0, len = list.length; i < len; i++) {
// ...
}
```

\*\*좋은 예:\*\*
```ts
for (let i = 0; i < list.length; i++) {
// ...
}
```

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

### 죽은 코드(Dead code) 제거하기

죽은 코드는 중복 코드만큼이나 나쁩니다. 코드베이스에 남겨둘 이유가 없습니다.
호출되지 않는다면 제거하세요! 나중에 필요해지더라도 버전 히스토리에 여전히 저장되어 있습니다.

\*\*나쁜 예:\*\*
```ts
function oldRequestModule(url: string) {
// ...
}
function requestModule(url: string) {
// ...
}
const req = requestModule;
inventoryTracker('apples', req, 'www.inventory-awesome.io');
```

\*\*좋은 예:\*\*
```ts
function requestModule(url: string) {
// ...
}
const req = requestModule;
inventoryTracker('apples', req, 'www.inventory-awesome.io');
```

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

### 이터레이터와 제너레이터 사용하기

스트림처럼 사용되는 데이터 컬렉션을 다룰 때는 제너레이터와 이터러블을 사용하세요.
여기에는 몇 가지 좋은 이유가 있습니다:
- 호출자가 액세스할 항목 수를 결정한다는 점에서 호출자를 제너레이터 구현으로부터 분리합니다.
- 지연 실행(Lazy execution)을 통해 항목이 온디맨드로 스트리밍됩니다.
- `for-of` 구문을 사용하여 항목을 순회하는 기능이 기본적으로 지원됩니다.
- 이터러블을 사용하면 최적화된 이터레이터 패턴을 구현할 수 있습니다.

\*\*나쁜 예:\*\*
```ts
function fibonacci(n: number): number[] {
if (n === 1) return [0];
if (n === 2) return [0, 1];
const items: number[] = [0, 1];
while (items.length < n) {
items.push(items[items.length - 2] + items[items.length - 1]);
}
return items;
}
function print(n: number) {
fibonacci(n).forEach(fib => console.log(fib));
}
// 처음 10개의 피보나치 수 출력하기
```

.
print(10);
```
\*\*Good:\*\*
```ts
// Generates an infinite stream of Fibonacci numbers.
// The generator doesn't keep the array of all numbers.
function\* fibonacci(): IterableIterator {
let [a, b] = [0, 1];
while (true) {
yield a;
[a, b] = [b, a + b];
}
}
function print(n: number) {
let i = 0;
for (const fib of fibonacci()) {
if (i++ === n) break;
console.log(fib);
}
}
// Print first 10 Fibonacci numbers.
print(10);
```
`map`, `slice`, `forEach` 등 네이티브 배열처럼 메서드를 체이닝하여 이터러블(iterable)을 다룰 수 있게 해주는 라이브러리들이 있습니다. 이터러블을 다루는 고급 조작법의 예시는 [itiriri](https://www.npmjs.com/package/itiriri)를 참고하세요(비동기 이터러블 조작은 [itiriri-async](https://www.npmjs.com/package/itiriri-async) 참고).
```ts
import itiriri from 'itiriri';
function\* fibonacci(): IterableIterator {
let [a, b] = [0, 1];
while (true) {
yield a;
[a, b] = [b, a + b];
}
}
itiriri(fibonacci())
.take(10)
.forEach(fib => console.log(fib));
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
## 객체 및 자료구조 (Objects and Data Structures)
### Getter와 Setter를 사용하세요 (Use getters and setters)
TypeScript는 getter/setter 구문을 지원합니다.
동위를 캡슐화하는 객체의 데이터에 접근할 때 단순한 속성 조회보다 getter와 setter를 사용하는 것이 더 나을 수 있습니다.
"왜 그럴까요?"라고 물으실 수 있습니다. 그 이유는 다음과 같습니다:
- 객체 속성을 가져오는 것 이상의 작업을 수행하고 싶을 때, 코드베이스의 모든 접근자를 찾아가며 변경할 필요가 없습니다.
- `set`을 수행할 때 유효성 검사(validation)를 간단하게 추가할 수 있습니다.
- 내부 표현을 캡슐화합니다.
- 값을 가져오고 설정할 때 로깅과 에러 처리를 쉽게 추가할 수 있습니다.
- 서버에서 가져오는 등의 방식으로 객체의 속성을 지연 로딩(lazy load)할 수 있습니다.
\*\*Bad:\*\*
```ts
type BankAccount = {
balance: number;
// ...
}
const value = 100;
const account: BankAccount = {
balance: 0,
// ...
};
if (value < 0) {
throw new Error('Cannot set negative balance.');
}
account.balance = value;
```
\*\*Good:\*\*
```ts
class BankAccount {
private accountBalance: number = 0;
get balance(): number {
return this.accountBalance;
}
set balance(value: number) {
if (value < 0) {
throw new Error('Cannot set negative balance.');
}
this.accountBalance = value;
}
// ...
}
// 이제 `BankAccount`가 유효성 검사 로직을 캡슐화합니다.
// 언젠가 사양이 변경되어 추가적인 유효성 검사 규칙이 필요해지더라도,
// 의존하는 모든 코드는 그대로 둔 채 `setter` 구현부만 수정하면 됩니다.
const account = new BankAccount();
account.balance = 100;
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 객체에 private/protected 멤버를 지정하세요 (Make objects have private/protected members)
TypeScript는 클래스 멤버에 대해 `public` \*(기본값)*, `protected`, `private` 접근자를 지원합니다.
\*\*Bad:\*\*
```ts
class Circle {
radius: number;
constructor(radius: number) {
this.radius = radius;
}
perimeter() {
return 2 \* Math.PI \* this.radius;
}
surface() {
return Math.PI \* this.radius \* this.radius;
}
}
```
\*\*Good:\*\*
```ts
class Circle {
constructor(private readonly radius: number) {
}
perimeter() {
return 2 \* Math.PI \* this.radius;
}
surface() {
return Math.PI \* this.radius \* this.radius;
}
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 불변성(Immutability)을 선호하세요 (Prefer immutability)
TypeScript의 타입 시스템을 사용하면 인터페이스나 클래스의 개별 속성을 \*readonly\*로 표시할 수 있습니다. 이를 통해 함수형 방식으로 작업할 수 있습니다 (예상치 못한 값의 변경은 좋지 않습니다).
더 고급 시나리오를 위해, 타입 `T`를 받아 매핑된 타입(mapped types)을 사용하여 모든 속성을 읽기 전용으로 표시해 주는 내장 타입 `Readonly`가 있습니다 ([매핑된 타입](https://www.typescriptlang.org/docs/handbook/advanced-types.html#mapped-types) 참고).
\*\*Bad:\*\*
```ts
interface Config {
host: string;
port: string;
db: string;
}
```
\*\*Good:\*\*
```ts
interface Config {
readonly host: string;
readonly port: string;
readonly db: string;
}
```
배열의 경우, `ReadonlyArray`를 사용하여 읽기 전용 배열을 생성할 수 있습니다.
`push()`나 `fill()` 같은 변경 메서드는 허용되지 않지만, `conca

t()` 및 `slice()`는 배열의 값을 변경하지 않습니다.
\*\*나쁨:\*\*
```ts
const array: number[] = [ 1, 3, 5 ];
array = []; // 에러
array.push(100); // 배열이 업데이트됨
```
\*\*좋음:\*\*
```ts
const array: ReadonlyArray = [ 1, 3, 5 ];
array = []; // 에러
array.push(100); // 에러
```
[TypeScript 3.4에서는 읽기 전용 인수를 선언하는 것이 조금 더 쉬워졌습니다](https://github.com/microsoft/TypeScript/wiki/What's-new-in-TypeScript#improvements-for-readonlyarray-and-readonly-tuples).
```ts
function hoge(args: readonly string[]) {
args.push(1); // 에러
}
```
리터럴 값에는 [const assertions](https://github.com/microsoft/TypeScript/wiki/What's-new-in-TypeScript#const-assertions)을 사용하는 것이 좋습니다.
\*\*나쁨:\*\*
```ts
const config = {
hello: 'world'
};
config.hello = 'world'; // 값이 변경됨
const array = [ 1, 3, 5 ];
array[0] = 10; // 값이 변경됨
// 쓰기 가능한 객체가 반환됨
function readonlyData(value: number) {
return { value };
}
const result = readonlyData(100);
result.value = 200; // 값이 변경됨
```
\*\*좋음:\*\*
```ts
// 읽기 전용 객체
const config = {
hello: 'world'
} as const;
config.hello = 'world'; // 에러
// 읽기 전용 배열
const array = [ 1, 3, 5 ] as const;
array[0] = 10; // 에러
// 읽기 전용 객체를 반환할 수 있음
function readonlyData(value: number) {
return { value } as const;
}
const result = readonlyData(100);
result.value = 200; // 에러
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### type vs. interface
union이나 intersection이 필요할 때는 type을 사용하세요. `extends`나 `implements`를 사용하고 싶을 때는 interface를 사용하세요. 엄격한 규칙은 없으므로 본인에게 맞는 것을 사용하면 됩니다.
TypeScript에서 `type`과 `interface`의 차이점에 대한 더 자세한 설명은 이 [답변](https://stackoverflow.com/questions/37233735/typescript-interfaces-vs-types/54101543#54101543)을 참고하세요.
\*\*나쁨:\*\*
```ts
interface EmailConfig {
// ...
}
interface DbConfig {
// ...
}
interface Config {
// ...
}
//...
type Shape = {
// ...
}
```
\*\*좋음:\*\*
```ts
type EmailConfig = {
// ...
}
type DbConfig = {
// ...
}
type Config = EmailConfig | DbConfig;
// ...
interface Shape {
// ...
}
class Circle implements Shape {
// ...
}
class Square implements Shape {
// ...
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
## Classes
### 클래스는 작아야 합니다
클래스의 크기는 그 책임으로 측정됩니다. \*단일 책임 원칙(Single Responsibility principle)\*에 따라 클래스는 작아야 합니다.
\*\*나쁨:\*\*
```ts
class Dashboard {
getLanguage(): string { /\* ... \*/ }
setLanguage(language: string): void { /\* ... \*/ }
showProgress(): void { /\* ... \*/ }
hideProgress(): void { /\* ... \*/ }
isDirty(): boolean { /\* ... \*/ }
disable(): void { /\* ... \*/ }
enable(): void { /\* ... \*/ }
addSubscription(subscription: Subscription): void { /\* ... \*/ }
removeSubscription(subscription: Subscription): void { /\* ... \*/ }
addUser(user: User): void { /\* ... \*/ }
removeUser(user: User): void { /\* ... \*/ }
goToHomePage(): void { /\* ... \*/ }
updateProfile(details: UserDetails): void { /\* ... \*/ }
getVersion(): string { /\* ... \*/ }
// ...
}
```
\*\*좋음:\*\*
```ts
class Dashboard {
disable(): void { /\* ... \*/ }
enable(): void { /\* ... \*/ }
getVersion(): string { /\* ... \*/ }
}
// 남은 메서드들을 다른 클래스로 옮겨 책임을 분할합니다
// ...
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 높은 응집도와 낮은 결합도
응집도(Cohesion)는 클래스의 멤버들이 서로 관련되어 있는 정도를 정의합니다. 이상적으로는 클래스 내의 모든 필드가 각 메서드에 의해 사용되어야 합니다.
이때 우리는 클래스가 \*최대로 응집되어 있다\*고 말합니다. 하지만 실제로는 이것이 항상 가능하지도 않고, 권장되지도 않습니다. 그럼에도 응집도는 높게 유지하는 것이 좋습니다.
결합도(Coupling)는 두 클래스가 서로 얼마나 관련되어 있는지 또는 의존하는지를 나타냅니다. 한 클래스의 변경이 다른 클래스에 영향을 미치지 않는다면 결합도가 낮다고 합니다.
좋은 소프트웨어 설계는 \*\*높은 응집도(high cohesion)\*\*와 \*\*낮은 결합도(low coupling)\*\*를 가집니다.
\*\*나쁨:\*\*
```ts
class Use

rManager {
// Bad: 각 private 변수는 특정 메서드 그룹에 의해 각각 사용됩니다.
// 이는 클래스가 단일 책임 원칙보다 더 많은 책임을 지고 있다는 명백한 증거입니다.
// 단지 사용자의 트랜잭션을 가져오는 서비스를 생성하기 위해서만 필요하더라도,
// 여전히 `emailSender`의 인스턴스를 강제로 전달해야 합니다.
constructor(
private readonly db: Database,
private readonly emailSender: EmailSender) {
}
async getUser(id: number): Promise {
return await db.users.findOne({ id });
}
async getTransactions(userId: number): Promise {
return await db.transactions.find({ userId });
}
async sendGreeting(): Promise {
await emailSender.send('Welcome!');
}
async sendNotification(text: string): Promise {
await emailSender.send(text);
}
async sendNewsletter(): Promise {
// ...
}
}
```
\*\*Good:\*\*
```ts
class UserService {
constructor(private readonly db: Database) {
}
async getUser(id: number): Promise {
return await this.db.users.findOne({ id });
}
async getTransactions(userId: number): Promise {
return await this.db.transactions.find({ userId });
}
}
class UserNotifier {
constructor(private readonly emailSender: EmailSender) {
}
async sendGreeting(): Promise {
await this.emailSender.send('Welcome!');
}
async sendNotification(text: string): Promise {
await this.emailSender.send(text);
}
async sendNewsletter(): Promise {
// ...
}
}
```
\*\*[⬆ back to top](#table-of-contents)\*\*
### 상속보다 컴포지션을 선호하세요
Gang of Four의 [Design Patterns](https://en.wikipedia.org/wiki/Design\_Patterns)에서 유명하게 언급되었듯이, 가능하면 \*상속보다 컴포지션을 선호해야 합니다\*. 상속을 사용하는 좋은 이유도 많고 컴포지션을 사용하는 좋은 이유도 많습니다. 이 격언의 핵심은 여러분의 마음이 본능적으로 상속을 향할 때, 컴포지션이 문제를 더 잘 모델링할 수 있는지 고민해 보라는 것입니다. 어떤 경우에는 컴포지션이 더 나은 해결책이 됩니다.
그렇다면 "언제 상속을 사용해야 할까?"라는 의문이 들 수 있습니다. 그것은 직면한 문제에 따라 다르지만, 컴포지션보다 상속이 더 타당한 경우를 나타내는 적절한 목록은 다음과 같습니다.
1. 상속이 "has-a" 관계가 아닌 "is-a" 관계를 나타내는 경우 (Human->Animal 대 User->UserDetails).
2. 기본 클래스의 코드를 재사용할 수 있는 경우 (인간은 모든 동물처럼 움직일 수 있음).
3. 기본 클래스를 변경하여 파생 클래스에 전역적인 변경을 적용하고 싶은 경우 (모든 동물이 움직일 때 칼로리 소모량을 변경).
\*\*Bad:\*\*
```ts
class Employee {
constructor(
private readonly name: string,
private readonly email: string) {
}
// ...
}
// 직원은 세금 데이터를 "가지고" 있기 때문에 나쁩니다. EmployeeTaxData는 Employee의 한 종류가 아닙니다.
class EmployeeTaxData extends Employee {
constructor(
name: string,
email: string,
private readonly ssn: string,
private readonly salary: number) {
super(name, email);
}
// ...
}
```
\*\*Good:\*\*
```ts
class Employee {
private taxData: EmployeeTaxData;
constructor(
private readonly name: string,
private readonly email: string) {
}
setTaxData(ssn: string, salary: number): Employee {
this.taxData = new EmployeeTaxData(ssn, salary);
return this;
}
// ...
}
class EmployeeTaxData {
constructor(
public readonly ssn: string,
public readonly salary: number) {
}
// ...
}
```
\*\*[⬆ back to top](#table-of-contents)\*\*
### 메서드 체이닝을 사용하세요
이 패턴은 매우 유용하며 많은 라이브러리에서 흔히 사용됩니다. 코드를 표현력 있게 만들고 장황함을 줄여줍니다. 이러한 이유로 메서드 체이닝을 사용하고 코드가 얼마나 깔끔해지는지 확인해 보세요.
\*\*Bad:\*\*
```ts
class QueryBuilder {
private collection: string;
private pageNumber: number = 1;
private itemsPerPage: number = 100;
private orderByFields: string[] = [];
from(collection: string): void {
this.collection = collection;
}
page(number: number, itemsPerPage: number = 100): void {
this.pageNumber = number;
this.itemsPerPage = itemsPerPage;
}
orderBy(...fields: string[]): void {
this.orderByFields = fields;
}
build(): Query {
// ...
}
}
// ...
const queryBuilder = new QueryBuilder();
queryBuilder.from('users');
queryBuilder.page(1, 100)

);
queryBuilder.orderBy('firstName', 'lastName');
const query = queryBuilder.build();
```
\*\*Good:\*\*
```ts
class QueryBuilder {
private collection: string;
private pageNumber: number = 1;
private itemsPerPage: number = 100;
private orderByFields: string[] = [];
from(collection: string): this {
this.collection = collection;
return this;
}
page(number: number, itemsPerPage: number = 100): this {
this.pageNumber = number;
this.itemsPerPage = itemsPerPage;
return this;
}
orderBy(...fields: string[]): this {
this.orderByFields = fields;
return this;
}
build(): Query {
// ...
}
}
// ...
const query = new QueryBuilder()
.from('users')
.page(1, 100)
.orderBy('firstName', 'lastName')
.build();
```
\*\*[⬆ back to top](#table-of-contents)\*\*
## SOLID
### 단일 책임 원칙 (Single Responsibility Principle, SRP)
Clean Code에서 언급하듯, "클래스가 변경되어야 하는 이유는 단 하나뿐이어야 합니다." 비행기에 가방을 하나만 가져갈 수 있는 것처럼, 클래스 하나에 너무 많은 기능을 꾹 눌러 담고 싶은 유혹이 들기 쉽습니다. 이 방식의 문제점은 클래스의 개념적 응집력이 떨어지고 변경되어야 할 이유가 여러 개 생긴다는 것입니다. 클래스를 수정해야 하는 횟수를 최소화하는 것은 중요합니다. 하나의 클래스에 너무 많은 기능이 들어 있어 그중 일부를 수정할 때, 그것이 코드베이스의 다른 의존하는 모듈들에 어떤 영향을 미칠지 이해하기 어려워질 수 있기 때문입니다.
\*\*Bad:\*\*
```ts
class UserSettings {
constructor(private readonly user: User) {
}
changeSettings(settings: UserSettings) {
if (this.verifyCredentials()) {
// ...
}
}
verifyCredentials() {
// ...
}
}
```
\*\*Good:\*\*
```ts
class UserAuth {
constructor(private readonly user: User) {
}
verifyCredentials() {
// ...
}
}
class UserSettings {
private readonly auth: UserAuth;
constructor(private readonly user: User) {
this.auth = new UserAuth(user);
}
changeSettings(settings: UserSettings) {
if (this.auth.verifyCredentials()) {
// ...
}
}
}
```
\*\*[⬆ back to top](#table-of-contents)\*\*
### 개방-폐쇄 원칙 (Open/Closed Principle, OCP)
Bertrand Meyer가 언급했듯이, "소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고 수정에 대해서는 닫혀 있어야 합니다." 하지만 이게 무슨 뜻일까요? 이 원칙은 기본적으로 기존 코드를 변경하지 않고도 사용자가 새로운 기능을 추가할 수 있어야 함을 말합니다.
\*\*Bad:\*\*
```ts
class AjaxAdapter extends Adapter {
constructor() {
super();
}
// ...
}
class NodeAdapter extends Adapter {
constructor() {
super();
}
// ...
}
class HttpRequester {
constructor(private readonly adapter: Adapter) {
}
async fetch(url: string): Promise {
if (this.adapter instanceof AjaxAdapter) {
const response = await makeAjaxCall(url);
// transform response and return
} else if (this.adapter instanceof NodeAdapter) {
const response = await makeHttpCall(url);
// transform response and return
}
}
}
function makeAjaxCall(url: string): Promise {
// request and return promise
}
function makeHttpCall(url: string): Promise {
// request and return promise
}
```
\*\*Good:\*\*
```ts
abstract class Adapter {
abstract async request(url: string): Promise;
// code shared to subclasses ...
}
class AjaxAdapter extends Adapter {
constructor() {
super();
}
async request(url: string): Promise{
// request and return promise
}
// ...
}
class NodeAdapter extends Adapter {
constructor() {
super();
}
async request(url: string): Promise{
// request and return promise
}
// ...
}
class HttpRequester {
constructor(private readonly adapter: Adapter) {
}
async fetch(url: string): Promise {
const response = await this.adapter.request(url);
// transform response and return
}
}
```
\*\*[⬆ back to top](#table-of-contents)\*\*
### 리스코프 치환 원칙 (Liskov Substitution Principle, LSP)
매우 단순한 개념에 붙은 다소 겁나는 용어입니다. 공식적으로는 "S가 T의 하위 타입이라면, 프로그램의 바람직한 속성(정확성, 수행되는 작업 등)을 변경하지 않고도 T 타입의 객체를 S 타입의 객체로 교체할 수 있다(즉, S 타입의 객체는 T 타입의 객체를 대체할 수 있다)"라고 정의됩니다. 이것은

더욱 무서운 정의도 있습니다.
이에 대한 가장 좋은 설명은 부모 클래스와 자식 클래스가 있을 때, 부모 클래스와 자식 클래스를 잘못된 결과 없이 서로 바꿔서 사용할 수 있어야 한다는 것입니다. 이것이 여전히 헷갈릴 수 있으므로 고전적인 정사각형-직사각형 예시를 살펴보겠습니다. 수학적으로 정사각형은 직사각형이지만, 상속을 통한 "is-a" 관계로 모델링하면 금방 문제가 생깁니다.

**나쁜 예:**
```ts
class Rectangle {
constructor(
protected width: number = 0,
protected height: number = 0) {
}
setColor(color: string): this {
// ...
}
render(area: number) {
// ...
}
setWidth(width: number): this {
this.width = width;
return this;
}
setHeight(height: number): this {
this.height = height;
return this;
}
getArea(): number {
return this.width \* this.height;
}
}
class Square extends Rectangle {
setWidth(width: number): this {
this.width = width;
this.height = width;
return this;
}
setHeight(height: number): this {
this.width = height;
this.height = height;
return this;
}
}
function renderLargeRectangles(rectangles: Rectangle[]) {
rectangles.forEach((rectangle) => {
const area = rectangle
.setWidth(4)
.setHeight(5)
.getArea(); // 나쁜 예: Square의 경우 25를 반환합니다. 20이어야 합니다.
rectangle.render(area);
});
}
const rectangles = [new Rectangle(), new Rectangle(), new Square()];
renderLargeRectangles(rectangles);
```

**좋은 예:**
```ts
abstract class Shape {
setColor(color: string): this {
// ...
}
render(area: number) {
// ...
}
abstract getArea(): number;
}
class Rectangle extends Shape {
constructor(
private readonly width = 0,
private readonly height = 0) {
super();
}
getArea(): number {
return this.width \* this.height;
}
}
class Square extends Shape {
constructor(private readonly length: number) {
super();
}
getArea(): number {
return this.length \* this.length;
}
}
function renderLargeShapes(shapes: Shape[]) {
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)
ISP는 "클라이언트는 자신이 사용하지 않는 인터페이스에 의존하도록 강요받아서는 안 된다."라고 말합니다. 이 원칙은 단일 책임 원칙과 매우 밀접하게 연관되어 있습니다.
진정한 의미는 노출된 메서드를 사용하는 클라이언트가 전체를 한 번에 받지 않도록 항상 추상화를 설계해야 한다는 것입니다. 이는 또한 클라이언트에게 실제로 필요하지 않은 메서드를 구현해야 하는 부담을 지우지 않는 것도 포함합니다.

**나쁜 예:**
```ts
interface SmartPrinter {
print();
fax();
scan();
}
class AllInOnePrinter implements SmartPrinter {
print() {
// ...
}
fax() {
// ...
}
scan() {
// ...
}
}
class EconomicPrinter implements SmartPrinter {
print() {
// ...
}
fax() {
throw new Error('Fax not supported.');
}
scan() {
throw new Error('Scan not supported.');
}
}
```

**좋은 예:**
```ts
interface Printer {
print();
}
interface Fax {
fax();
}
interface Scanner {
scan();
}
class AllInOnePrinter implements Printer, Fax, Scanner {
print() {
// ...
}
fax() {
// ...
}
scan() {
// ...
}
}
class EconomicPrinter implements Printer {
print() {
// ...
}
}
```

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

### 의존성 역전 원칙 (Dependency Inversion Principle, DIP)
이 원칙은 두 가지 핵심적인 사항을 명시합니다.
1. 고수준 모듈은 저수준 모듈에 의존해서는 안 됩니다. 둘 다 추상화에 의존해야 합니다.
2. 추상화는 세부 사항에 의존해서는 안 됩니다. 세부 사항은 추상화에 의존해야 합니다.
처음에는 이해하기 어려울 수 있지만, Angular를 다뤄본 적이 있다면 의존성 주입(Dependency Injection, DI) 형태로 이 원칙이 구현된 것을 본 적이 있을 것입니다. 두 개념이 완전히 동일한 것은 아니지만, DIP는 고수준 모듈이 저수준 모듈의 세부 사항을 알거나 직접 설정하지 않도록 방지합니다. 이는 DI를 통해 달성할 수 있습니다. 이것의 가장 큰 장점은 모듈 간의 결합도를 줄여준다는 것입니다. 결합도는 개발에서 매우 나쁜 요

개발 패턴은 코드를 리팩토링하기 어렵게 만들기 때문에 피해야 합니다.
DIP는 대개 제어 역전(IoC) 컨테이너를 사용하여 달성합니다. TypeScript를 위한 강력한 IoC 컨테이너의 예로는 [InversifyJS](https://www.npmjs.com/package/inversify)가 있습니다.

\*\*나쁜 예:\*\*
```ts
import { readFile as readFileCb } from 'fs';
import { promisify } from 'util';

const readFile = promisify(readFileCb);

type ReportData = {
  // ..
}

class XmlFormatter {
  parse(content: string): T {
    // Converts an XML string to an object T
  }
}

class ReportReader {
  // BAD: We have created a dependency on a specific request implementation.
  // We should just have ReportReader depend on a parse method: `parse`
  private readonly formatter = new XmlFormatter();

async read(path: string): Promise {
    const text = await readFile(path, 'UTF8');
    return this.formatter.parse(text);
  }
}

// ...
const reader = new ReportReader();
const report = await reader.read('report.xml');
```

\*\*좋은 예:\*\*
```ts
import { readFile as readFileCb } from 'fs';
import { promisify } from 'util';

const readFile = promisify(readFileCb);

type ReportData = {
  // ..
}

interface Formatter {
  parse(content: string): T;
}

class XmlFormatter implements Formatter {
  parse(content: string): T {
    // Converts an XML string to an object T
  }
}

class JsonFormatter implements Formatter {
  parse(content: string): T {
    // Converts a JSON string to an object T
  }
}

class ReportReader {
  constructor(private readonly formatter: Formatter) {
  }

async read(path: string): Promise {
    const text = await readFile(path, 'UTF8');
    return this.formatter.parse(text);
  }
}

// ...
const reader = new ReportReader(new XmlFormatter());
const report = await reader.read('report.xml');

// or if we had to read a json report
const reader = new ReportReader(new JsonFormatter());
const report = await reader.read('report.json');
```

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

## 테스팅 (Testing)
테스팅은 코드를 배포하는 것보다 더 중요합니다. 테스트가 없거나 충분하지 않다면, 코드를 배포할 때마다 무엇인가가 깨지지 않았다는 확신을 가질 수 없을 것입니다.

어느 정도가 적절한 수준인지는 팀이 결정할 일이지만, 100% 커버리지(모든 구문과 분기 커버리지)를 달성하는 것은 매우 높은 신뢰도와 개발자의 마음의 평화를 얻는 방법입니다. 이는 훌륭한 테스트 프레임워크를 갖추는 것 외에도 좋은 [커버리지 도구](https://github.com/gotwarlost/istanbul)를 사용해야 한다는 것을 의미합니다.

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

### TDD의 3대 법칙
1. 실패하는 유닛 테스트를 통과시키기 위한 목적이 아니라면 프로덕션 코드를 작성할 수 없습니다.
2. 컴파일 실패도 실패이므로, 실패하기에 충분한 만큼을 초과하는 유닛 테스트를 작성할 수 없습니다.
3. 실패하는 단 하나의 유닛 테스트를 통과시키기에 충분한 양을 초과하는 프로덕션 코드를 작성할 수 없습니다.

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

### F.I.R.S.T. 규칙
클린 테스트는 다음 규칙을 따라야 합니다:

- \*\*Fast (빠르게)\*\*: 테스트는 자주 실행하고 싶기 때문에 빠르게 동작해야 합니다.
- \*\*Independent (독립적으로)\*\*: 테스트는 서로 의존하지 않아야 합니다. 독립적으로 실행되든, 어떤 순서로든 한꺼번에 실행되든 동일한 결과를 제공해야 합니다.
- \*\*Repeatable (반복 가능하게)\*\*: 테스트는 어떤 환경에서도 반복 가능해야 하며 실패할 변명이 없어야 합니다.
- \*\*Self-Validating (자체 검증 가능하게)\*\*: 테스트는 \*Passed(통과)* 또는 \*Failed(실패)* 중 하나로 결과를 알려주어야 합니다. 테스트가 통과했는지 확인하기 위해 로그 파일을 비교할 필요가 없어야 합니다.
- \*\*Timely (적시에)\*\*: 유닛 테스트는 프로덕션 코드 작성 전에 작성되어야 합니다. 프로덕션 코드를 작성한 후에 테스트를 작성한다면

테스트 작성하는 것이 너무 어렵다고 느낄 수 있습니다.
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 테스트당 하나의 개념만 다루기
테스트 역시 \*단일 책임 원칙(Single Responsibility Principle)\*을 따라야 합니다. 단위 테스트당 하나의 단언문(assert)만 작성하세요.
\*\*나쁜 예:\*\*
```ts
import { assert } from 'chai';
describe('AwesomeDate', () => {
it('handles date boundaries', () => {
let date: AwesomeDate;
date = new AwesomeDate('1/1/2015');
assert.equal('1/31/2015', date.addDays(30));
date = new AwesomeDate('2/1/2016');
assert.equal('2/29/2016', date.addDays(28));
date = new AwesomeDate('2/1/2015');
assert.equal('3/1/2015', date.addDays(28));
});
});
```
\*\*좋은 예:\*\*
```ts
import { assert } from 'chai';
describe('AwesomeDate', () => {
it('handles 30-day months', () => {
const date = new AwesomeDate('1/1/2015');
assert.equal('1/31/2015', date.addDays(30));
});
it('handles leap year', () => {
const date = new AwesomeDate('2/1/2016');
assert.equal('2/29/2016', date.addDays(28));
});
it('handles non-leap year', () => {
const date = new AwesomeDate('2/1/2015');
assert.equal('3/1/2015', date.addDays(28));
});
});
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 테스트 이름은 그 의도를 드러내야 합니다
테스트가 실패할 때, 테스트의 이름은 무엇이 잘못되었을지 알려주는 첫 번째 지표입니다.
\*\*나쁜 예:\*\*
```ts
describe('Calendar', () => {
it('2/29/2020', () => {
// ...
});
it('throws', () => {
// ...
});
});
```
\*\*좋은 예:\*\*
```ts
describe('Calendar', () => {
it('should handle leap year', () => {
// ...
});
it('should throw when format is invalid', () => {
// ...
});
});
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
## 동시성 (Concurrency)
### 콜백 대신 Promise를 선호하세요
콜백은 코드가 깔끔하지 않으며, 과도한 중첩\*(콜백 지옥, callback hell)\*을 유발합니다.
콜백 스타일을 사용하는 기존 함수를 Promise를 반환하는 버전으로 변환해 주는 유틸리티들이 있습니다.
(Node.js의 경우 [`util.promisify`](https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util\_util\_promisify\_original), 범용적인 용도로는 [pify](https://www.npmjs.com/package/pify), [es6-promisify](https://www.npmjs.com/package/es6-promisify)참고)
\*\*나쁜 예:\*\*
```ts
import { get } from 'request';
import { writeFile } from 'fs';
function downloadPage(url: string, saveTo: string, callback: (error: Error, content?: string) => void) {
get(url, (error, response) => {
if (error) {
callback(error);
} else {
writeFile(saveTo, response.body, (error) => {
if (error) {
callback(error);
} else {
callback(null, response.body);
}
});
}
});
}
downloadPage('https://en.wikipedia.org/wiki/Robert\_Cecil\_Martin', 'article.html', (error, content) => {
if (error) {
console.error(error);
} else {
console.log(content);
}
});
```
\*\*좋은 예:\*\*
```ts
import { get } from 'request';
import { writeFile } from 'fs';
import { promisify } from 'util';
const write = promisify(writeFile);
function downloadPage(url: string, saveTo: string): Promise {
return get(url)
.then(response => write(saveTo, response));
}
downloadPage('https://en.wikipedia.org/wiki/Robert\_Cecil\_Martin', 'article.html')
.then(content => console.log(content))
.catch(error => console.error(error));
```
Promise는 코드를 더 간결하게 만드는 데 도움이 되는 몇 가지 헬퍼 메서드를 지원합니다:
| 패턴 | 설명 |
| ------------------------ | ----------------------------------------- |
| `Promise.resolve(value)` | 값을 이행된(resolved) Promise로 변환합니다. |
| `Promise.reject(error)` | 에러를 거부된(rejected) Promise로 변환합니다. |
| `Promise.all(promises)` | 전달된 Promise들의 이행 값 배열로 이행되거나, 가장 먼저 거부된 Promise의 사유로 거부되는 새로운 Promise를 반환합니다. |
| `Promise.race(promises)`| 전달된 Promise 배열 중 가장 먼저 완료(settled)된 Promise의 결과/에러로 이행/거부되는 새로운 Promise를 반환합니다. |
`Promise.all`은 작업을 병렬로 실행해야 할 때 특히 유용합니다. `Promise.race`를 사용하면 Promise에 대한 타임아웃 같은 기능을 더 쉽게 구현할 수 있습니다.
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### Async/A

wait은 Promise보다 훨씬 더 깔끔합니다
`async`/`await` 문법을 사용하면 체인형 Promise보다 훨씬 더 깔끔하고 이해하기 쉬운 코드를 작성할 수 있습니다. `async` 키워드가 붙은 함수 내부에서는 (Promise에 사용될 때) `await` 키워드를 만나면 JavaScript 런타임이 코드 실행을 일시 중단하도록 지시할 수 있습니다.
\*\*나쁜 예:\*\*
```ts
import { get } from 'request';
import { writeFile } from 'fs';
import { promisify } from 'util';
const write = util.promisify(writeFile);
function downloadPage(url: string, saveTo: string): Promise {
return get(url).then(response => write(saveTo, response));
}
downloadPage('https://en.wikipedia.org/wiki/Robert\_Cecil\_Martin', 'article.html')
.then(content => console.log(content))
.catch(error => console.error(error));
```
\*\*좋은 예:\*\*
```ts
import { get } from 'request';
import { writeFile } from 'fs';
import { promisify } from 'util';
const write = promisify(writeFile);
async function downloadPage(url: string): Promise {
const response = await get(url);
return response;
}
// somewhere in an async function
try {
const content = await downloadPage('https://en.wikipedia.org/wiki/Robert\_Cecil\_Martin');
await write('article.html', content);
console.log(content);
} catch (error) {
console.error(error);
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
## 에러 처리 (Error Handling)
에러를 발생시키는(throw) 것은 좋은 일입니다! 이는 런타임이 프로그램에서 무언가 잘못된 부분을 성공적으로 감지했음을 의미하며, 현재 스택에서 함수 실행을 중단하고, (Node의 경우) 프로세스를 종료하며, 콘솔에 스택 추적(stack trace)과 함께 이를 알려줍니다.
### 에러 발생(throw) 또는 거부(rejecting) 시에는 항상 Error 객체를 사용하세요
JavaScript와 TypeScript에서는 어떤 객체든 `throw`할 수 있습니다. 또한 Promise도 어떤 이유(reason) 객체든 거부(reject)될 수 있습니다.
에러를 발생시킬 때는 `Error` 타입과 함께 `throw` 문법을 사용하는 것이 좋습니다. 상위 레벨의 코드에서 `catch` 문법으로 에러를 잡을 수 있기 때문입니다.
거기서 문자열 메시지를 잡는 것은 매우 혼란스러울 수 있으며 [디버깅을 더욱 고통스럽게 만듭니다](https://basarat.gitbook.io/typescript/type-system/exceptions#always-use-error).
같은 이유로 Promise를 거부할 때도 `Error` 타입을 사용해야 합니다.
\*\*나쁜 예:\*\*
```ts
function calculateTotal(items: Item[]): number {
throw 'Not implemented.';
}
function get(): Promise {
return Promise.reject('Not implemented.');
}
```
\*\*좋은 예:\*\*
```ts
function calculateTotal(items: Item[]): number {
throw new Error('Not implemented.');
}
function get(): Promise {
return Promise.reject(new Error('Not implemented.'));
}
// or equivalent to:
async function get(): Promise {
throw new Error('Not implemented.');
}
```
`Error` 타입을 사용하는 것의 장점은 `try/catch/finally` 문법에서 지원되며, 암시적으로 모든 에러가 디버깅에 매우 강력한 `stack` 속성을 갖게 된다는 것입니다.
`throw` 문법을 사용하는 대신 항상 커스텀 에러 객체를 반환하는 다른 대안들도 존재합니다. TypeScript는 이를 더욱 쉽게 만들어 줍니다.
다음 예시를 고려해 보세요:
```ts
type Result = { isError: false, value: R };
type Failure = { isError: true, error: E };
type Failable = Result | Failure;
function calculateTotal(items: Item[]): Failable {
if (items.length === 0) {
return { isError: true, error: 'empty' };
}
// ...
return { isError: false, value: 42 };
}
```
이 아이디어에 대한 자세한 설명은 [원본 게시물](https://medium.com/@dhruvrajvanshi/making-exceptions-type-safe-in-typescript-c4d200ee78e9)을 참조하세요.
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 잡은(caught) 에러를 무시하지 마세요
잡은 에러에 대해 아무것도 하지 않는 것은 해당 에러를 수정하거나 대응할 수 있는 능력을 아예 포기하는 것입니다. 에러를 콘솔에 기록(`console.log`)하는 것도 콘솔에 출력되는 수많은 메시지 속에 묻히기 쉽기 때문에 별로 낫지 않습니다. 어떤 코드를 `try/catch`로 감싸는 것은 그곳에서 에러가 발생할 수 있다고 생각한다는 의미이므로, 에러가 발생했을 때에 대비한 계획이나 코드 경로를 반드시 마련해야 합니다.
\*\*나쁜 예:\*\*
```ts
try {
functionThatMightThrow();
} ca

tch (error) {
console.log(error);
}
// or even worse
try {
functionThatMightThrow();
} catch (error) {
// ignore error
}
```
\*\*좋은 예:\*\*
```ts
import { logger } from './logging'
try {
functionThatMightThrow();
} catch (error) {
logger.log(error);
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 거부된 Promise를 무시하지 마세요
`try/catch`에서 잡힌 에러를 무시하지 말아야 하는 것과 같은 이유입니다.
\*\*나쁜 예:\*\*
```ts
getUser()
.then((user: User) => {
return sendEmail(user.email, 'Welcome!');
})
.catch((error) => {
console.log(error);
});
```
\*\*좋은 예:\*\*
```ts
import { logger } from './logging'
getUser()
.then((user: User) => {
return sendEmail(user.email, 'Welcome!');
})
.catch((error) => {
logger.log(error);
});
// 또는 async/await 구문 사용:
try {
const user = await getUser();
await sendEmail(user.email, 'Welcome!');
} catch (error) {
logger.log(error);
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
## 포맷팅
포맷팅은 주관적입니다. 여기에 있는 많은 규칙들처럼 반드시 따라야 하는 절대적인 규칙은 없습니다. 핵심은 포맷팅을 두고 \*논쟁하지 않는 것\*입니다. 이를 자동화할 툴은 널려 있습니다. 툴을 사용하세요! 엔지니어들이 포맷팅으로 논쟁하는 것은 시간과 돈의 낭비입니다. 따라야 할 일반적인 규칙은 \*일관된 포맷팅 규칙을 유지하는 것\*입니다.
TypeScript에는 [ESLint](https://typescript-eslint.io/)라는 강력한 툴이 있습니다. 이는 코드의 가독성과 유지보수성을 극적으로 향상시키는 데 도움을 주는 정적 분석 툴입니다. 프로젝트에서 참고할 수 있는 바로 사용할 수 있는 ESLint 설정들이 있습니다:
- [ESLint Config Airbnb](https://www.npmjs.com/package/eslint-config-airbnb-typescript) - Airbnb 스타일 가이드
- [ESLint Base Style Config](https://www.npmjs.com/package/eslint-plugin-base-style-config) - JS, TS 및 React를 위한 필수 ESLint 규칙 모음
- [ESLint + Prettier](https://www.npmjs.com/package/eslint-config-prettier) - [Prettier](https://github.com/prettier/prettier) 코드 포맷터를 위한 린트 규칙
또한 훌륭한 [TypeScript StyleGuide and Coding Conventions](https://basarat.gitbook.io/typescript/styleguide) 소스도 참고하세요.
### TSLint에서 ESLint로 마이그레이션하기
TSLint에서 ESLint로 마이그레이션하는 데 도움이 필요하다면 다음 프로젝트를 확인해 보세요:
### 일관된 대소문자 표기법 사용하기
대소문자 표기법은 변수, 함수 등에 대한 많은 정보를 알려줍니다. 이러한 규칙은 주관적이므로 팀에서 원하는 대로 선택하면 됩니다. 중요한 점은 무엇을 선택하든 상관없이 \*일관성을 유지하는 것\*입니다.
\*\*나쁜 예:\*\*
```ts
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() {}
type animal = { /\* ... \*/ }
type Container = { /\* ... \*/ }
```
\*\*좋은 예:\*\*
```ts
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'];
const discography = getArtistDiscography('ACDC');
const beatlesSongs = SONGS.filter((song) => isBeatlesSong(song));
function eraseDatabase() {}
function restoreDatabase() {}
type Animal = { /\* ... \*/ }
type Container = { /\* ... \*/ }
```
클래스, 인터페이스, 타입 및 네임스페이스 이름에는 `PascalCase` 사용을 선호합니다.
변수, 함수 및 클래스 멤버에는 `camelCase` 사용을 선호합니다.
상수에는 대문자 `SNAKE\_CASE` 사용을 선호합니다.
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 함수 호출자와 피호출자는 가까이 두어야 합니다
한 함수가 다른 함수를 호출하는 경우, 소스 파일에서 두 함수를 수직적으로 가깝게 배치하세요. 이상적으로는 호출자를 피호출자 바로 위에 두는 것이 좋습니다.
우리는 신문처럼 코드를 위에서 아래로 읽는 경향이 있습니다. 이 때문에 코드가 그렇게 읽히도록 작성하세요.
\*\*나쁜 예:\*\*
```ts
class PerformanceReview {
constructor(private readonly employee: Employee) {
}
private lookupPeers() {
return db.lookup(this.employee.id, 'peers');
}
private lookupManager() {
return db.look

up(this.employee, 'manager');
}
private getPeerReviews() {
const peers = this.lookupPeers();
// ...
}
review() {
this.getPeerReviews();
this.getManagerReview();
this.getSelfReview();
// ...
}
private getManagerReview() {
const manager = this.lookupManager();
}
private getSelfReview() {
// ...
}
}
const review = new PerformanceReview(employee);
review.review();
```
\*\*Good:\*\*
```ts
class PerformanceReview {
constructor(private readonly employee: Employee) {
}
review() {
this.getPeerReviews();
this.getManagerReview();
this.getSelfReview();
// ...
}
private getPeerReviews() {
const peers = this.lookupPeers();
// ...
}
private lookupPeers() {
return db.lookup(this.employee.id, 'peers');
}
private getManagerReview() {
const manager = this.lookupManager();
}
private lookupManager() {
return db.lookup(this.employee, 'manager');
}
private getSelfReview() {
// ...
}
}
const review = new PerformanceReview(employee);
review.review();
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### import 정리하기
깔끔하고 읽기 쉬운 import 문을 사용하면 현재 코드의 의존성을 빠르게 파악할 수 있습니다. `import` 문에 대해 다음 모범 사례들을 적용하세요:
- import 문은 알파벳순으로 정렬하고 그룹화해야 합니다.
- 사용되지 않는 import는 제거해야 합니다.
- 네임드 import는 알파벳순으로 정렬해야 합니다 (예: `import {A, B, C} from 'foo';`).
- import 소스는 그룹 내에서 알파벳순으로 정렬해야 합니다. 예: `import \* as foo from 'a'; import \* as bar from 'b';`
- 파일에서 타입만 가져오는 경우, 런타임에 이 import들이 제거되어 의존성 순환을 방지할 수 있도록 `import` 대신 `import type`을 사용하는 것을 선호합니다.
- import 그룹들은 빈 줄로 구분됩니다.
- 그룹은 다음 순서를 따라야 합니다:
- 폴리필 (예: `import 'reflect-metadata';`)
- Node 내장 모듈 (예: `import fs from 'fs';`)
- 외부 모듈 (예: `import { query } from 'itiriri';`)
- 내부 모듈 (예: `import { UserService } from 'src/services/userService';`)
- 부모 디렉토리의 모듈 (예: `import foo from '../foo'; import qux from '../../foo/qux';`)
- 동일한 디렉토리 또는 형제 디렉토리의 모듈 (예: `import bar from './bar'; import baz from './bar/baz';`)
\*\*Bad:\*\*
```ts
import { TypeDefinition } from '../types/typeDefinition';
import { AttributeTypes } from '../model/attribute';
import { Customer, Credentials } from '../model/types';
import { ApiCredentials, Adapters } from './common/api/authorization';
import fs from 'fs';
import { ConfigPlugin } from './plugins/config/configPlugin';
import { BindingScopeEnum, Container } from 'inversify';
import 'reflect-metadata';
```
\*\*Good:\*\*
```ts
import 'reflect-metadata';
import fs from 'fs';
import { BindingScopeEnum, Container } from 'inversify';
import { AttributeTypes } from '../model/attribute';
import { TypeDefinition } from '../types/typeDefinition';
import type { Customer, Credentials } from '../model/types';
import { ApiCredentials, Adapters } from './common/api/authorization';
import { ConfigPlugin } from './plugins/config/configPlugin';
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### TypeScript 별칭(alias) 사용하기
`tsconfig.json`의 `compilerOptions` 섹션에서 `paths`와 `baseUrl` 속성을 정의하여 더 깔끔한 import를 만드세요.
이렇게 하면 import 시 길어지는 상대 경로를 피할 수 있습니다.
\*\*Bad:\*\*
```ts
import { UserService } from '../../../services/UserService';
```
\*\*Good:\*\*
```ts
import { UserService } from '@services/UserService';
```
```js
// tsconfig.json
...
"compilerOptions": {
...
"baseUrl": "src",
"paths": {
"@services": ["services/\*"]
}
...
}
...
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
## 주석
주석의 사용은 주석 없이 표현하는 데 실패했음을 나타냅니다. 코드는 진실의 유일한 원천이어야 합니다.
> 나쁜 코드에 주석을 달지 말고, 다시 작성하세요.
> — \*Brian W. Kernighan과 P. J. Plaugher\*
### 주석 대신 자체 설명적인 코드를 선호하세요
주석은 변명이 아니라 요구사항이 아닙니다. 좋은 코드는 \*대부분\* 스스로를 설명합니다.
\*\*Bad:\*\*
```ts
// Check if subscription is
```

활성화되어 있습니다.
if (subscription.endDate > Date.now) { }
```
\*\*좋은 예:\*\*
```ts
const isSubscriptionActive = subscription.endDate > Date.now;
if (isSubscriptionActive) { /\* ... \*/ }
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 코드베이스에 주석 처리된 코드를 남겨두지 마세요
버전 관리 시스템이 존재하는 이유는 분명합니다. 예전 코드는 히스토리에 남겨두세요.
\*\*나쁜 예:\*\*
```ts
type User = {
name: string;
email: string;
// age: number;
// jobPosition: string;
}
```
\*\*좋은 예:\*\*
```ts
type User = {
name: string;
email: string;
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 변경 이력(Journal) 주석을 작성하지 마세요
버전 관리를 사용하고 있음을 기억하세요! 죽은 코드, 주석 처리된 코드, 특히 변경 이력 주석은 전혀 필요 없습니다. 히스토리를 확인하려면 `git log`를 사용하세요!
\*\*나쁜 예:\*\*
```ts
/\*\*
\* 2016-12-20: 모나드를 제거함, 이해하기 어려웠음 (RM)
\* 2016-10-01: 특수 모나드를 사용하여 개선 (JP)
\* 2016-02-03: 타입 검사 추가 (LI)
\* 2015-03-14: combine 구현 (JR)
\*/
function combine(a: number, b: number): number {
return a + b;
}
```
\*\*좋은 예:\*\*
```ts
function combine(a: number, b: number): number {
return a + b;
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### 위치 표식(Positional Markers)을 피하세요
이러한 표식은 대개 불필요한 소음만 더할 뿐입니다. 적절한 들여쓰기 및 포맷팅과 함께 함수 및 변수 이름이 코드의 시각적 구조를 표현하도록 하세요.
대부분의 IDE는 코드 블록을 접거나 펼칠 수 있는 코드 폴딩 기능을 지원합니다(Visual Studio Code [folding regions](https://code.visualstudio.com/updates/v1\_17#\_folding-regions) 참고).
\*\*나쁜 예:\*\*
```ts
////////////////////////////////////////////////////////////////////////////////
// Client class
////////////////////////////////////////////////////////////////////////////////
class Client {
id: number;
name: string;
address: Address;
contact: Contact;
////////////////////////////////////////////////////////////////////////////////
// public methods
////////////////////////////////////////////////////////////////////////////////
public describe(): string {
// ...
}
////////////////////////////////////////////////////////////////////////////////
// private methods
////////////////////////////////////////////////////////////////////////////////
private describeAddress(): string {
// ...
}
private describeContact(): string {
// ...
}
};
```
\*\*좋은 예:\*\*
```ts
class Client {
id: number;
name: string;
address: Address;
contact: Contact;
public describe(): string {
// ...
}
private describeAddress(): string {
// ...
}
private describeContact(): string {
// ...
}
};
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
### TODO 주석
코드에 향후 개선을 위한 메모를 남겨야 할 때는 `// TODO` 주석을 사용하세요. 대부분의 IDE는 이러한 주석을 위한 특별한 기능을 지원하므로 전체 할 일(todo) 목록을 빠르게 확인할 수 있습니다.
하지만 \*TODO\* 주석이 나쁜 코드를 정당화하는 핑계가 될 수는 없다는 점을 명심하세요.
\*\*나쁜 예:\*\*
```ts
function getActiveSubscriptions(): Promise {
// `dueDate`가 인덱싱되어 있는지 확인하세요.
return db.subscriptions.find({ dueDate: { $lte: new Date() } });
}
```
\*\*좋은 예:\*\*
```ts
function getActiveSubscriptions(): Promise {
// TODO: `dueDate`가 인덱싱되어 있는지 확인하세요.
return db.subscriptions.find({ dueDate: { $lte: new Date() } });
}
```
\*\*[⬆ 맨 위로 이동](#table-of-contents)\*\*
## 번역본
이 문서는 다른 언어로도 제공됩니다:
- ![br](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Brazil.png) \*\*브라질 포르투갈어\*\*: [vitorfreitas/clean-code-typescript](https://github.com/vitorfreitas/clean-code-typescript)
- ![cn](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/China.png) \*\*중국어\*\*:
- [beginor/clean-code-typescript](https://github.com/beginor/clean-code-typescript)
- [pipiliang/clean-code-typescript](https://github.com/pipiliang/clean-code-typescript)
- ![fr](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/France.png) \*\*프랑스어\*\*: [ralflorent/cl

ean-code-typescript](https://github.com/ralflorent/clean-code-typescript)
- ![de](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Germany.png) \*\*German\*\*: [mheob/clean-code-typescript](https://github.com/mheob/clean-code-typescript)
- ![it](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Italy.png) \*\*Italian\*\*: [Kornil/clean-code-typescript](https://github.com/kornil/clean-code-typescript)
- ![ja](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Japan.png) \*\*Japanese\*\*: [MSakamaki/clean-code-typescript](https://github.com/MSakamaki/clean-code-typescript)
- ![ko](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/South-Korea.png) \*\*Korean\*\*: [738/clean-code-typescript](https://github.com/738/clean-code-typescript)
- ![ru](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Russia.png) \*\*Russian\*\*: [Real001/clean-code-typescript](https://github.com/Real001/clean-code-typescript)
- ![es](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Spain.png) \*\*Spanish\*\*: [3xp1o1t/clean-code-typescript](https://github.com/3xp1o1t/clean-code-typescript)
- ![tr](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Turkey.png) \*\*Turkish\*\*: [ozanhonamlioglu/clean-code-typescript](https://github.com/ozanhonamlioglu/clean-code-typescript)
- ![uk](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Ukraine.png) \*\*Ukrainian\*\*: [KirillPd/clean-code-typescript](https://github.com/KirillPd/clean-code-typescript)
- ![vi](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/Vietnam.png) \*\*Vietnamese\*\*: [hoangsetup/clean-code-typescript](https://github.com/hoangsetup/clean-code-typescript)
번역이 완료되면 참고 자료가 추가될 예정입니다.
자세한 내용과 진행 상황은 이 [discussion](https://github.com/labs42io/clean-code-typescript/issues/15)을 확인해 주세요.
이 문서를 여러분의 언어로 번역함으로써 \*Clean Code\* 커뮤니티에 필수적인 기여를 하실 수 있습니다.
\*\*[⬆ 맨 위로](#table-of-contents)\*\*

clean-code-typescript

파일 탐색기

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

clean-code-typescript

파일 탐색기

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README