📚 [스터디 요약정리] 클린코드 Clean Code

💻 스터디기간

• 2023.09.11일 ~ 09.27일 (총 3주 소요)

🌟 목표

이 책은 주니어 개발자들에게 많이 추천되는 코딩 교과서라고 볼 수있다.

• 이 책을 통해 코드의 퀄리티를 높여보자.

• 조직 내 또는 사이드 프로젝트를 하면서 코드 리뷰를 할 시, 서로 크로스 체킹을 하면서 실수한 부분들을 보완하고 코드의 퀄리티를 높일 수 있는 기대효과를 볼 수 있다.

🌟 진행방식

• 일주일에 3챕터 씩 읽고 각자 한 챕터씩 발표 범위를 선택

• 모든 사람의 발표 범위를 예습 해와야 함

• 각자의 범위는 발표하고 질의 응답 진행

🌟 진행범위

✅ 1주차 깨끗한 코드, 의미 있는 이름, 함수

✅ 2주차 주석, 형식 맞추기, 객체와 자료 구조

✅ 3주차 경계, 단위 테스트, 클래스, 시스템, 창발성

~ 이후의 챕터들은 JAVA 언어의 얘기들이 많아서 생략했다.

---

🔖 1주차

📍클린코드를 왜 지향 해야 하는가?

유지보수를 하다보면 기존의 더러운 코드들이 나중에 유지보수 하기 힘들게 만든다.

마치 거친 정글을 탐험하는 것처럼 점점 숲속이 우거지고 코드 한 줄 수정할 때마다 많은 부분을 신경써야한다!

• 나쁜코드가 양상될수록 → 생산성은 기하급수적으로 떨어진다.

• 깨끗한 코드가 되기 위해선,중복을 피하라

• 한 기능만 수행하라

• 제대로 표현해라

• 작게 추상화 해라

  
  

📍보이 스카우트 교훈

처음 왔을때 보다 더 깨끗하게 해놓고 가자 → 조금씩이라도 좋으니 처음보다 조금이라도 나은 코드를 만들기 위해 노력하자.

한번에 다할 필요 없다.

if 절 하나만 바꿔도 더 나은 코드가 된다!

📍의미있는 이름

1. 발음하기 쉬운 이름을 사용하자

프로그래밍은 사회 활동이기 때문이다.

2. 검색하기 쉬운 이름을 사용하자

변수명에 숫자가 들어간다면 상수에 버그가 있을 경우 검색으로 찾아내기가 힘들다. 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다.

const int WORK_DAYS_PER_WEEK = 5;

3. 인코딩을 피하라

유형이나 범위정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다.

4. 변수 또는 상수명 이름

명사나 명사구가 적합하다.

// 👍 좋은예제
const Customer = a;
const WikiPage = b;
const Account = c;

// 👎 나쁜예제
const Processor = 1;
const Info = 2;
const Data = 3;

등과 같은 단어는 피하고 동사는 사용하지 않는 것이 좋다.

5. 기발한 이름은 피하라

재미를 유도하는 이름은 No

ex) HolyHandGrenade (= 수류탄) 이라는 함수명보다는 DeleteItems 라는 이름이 더 좋다.

특정 문화에서 사용하는 농담은 피하는 것이 좋다.

의도를 분명하고 솔직하게 표현하는 것이 바람직하다.

6. 한 개념에 한 단어만 사용하라

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를 들어, 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다. 어느 변수에서 어느 이름을 썼는지 기억하기 어렵다.

따라서 변수명은 독자적이고 일관적이어야 한다. 그래야 주석을 뒤져보지 않고도 프로그래머가 올바른 메서드를 선택한다.

7. 해법 영역에서 가져온 이름을 사용하라

전산용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.

ex) AccountVisitor, JobQueue 처럼 기술 개념에는 기술 이름이 가장 적합한 선택.

8. 의미 있는 맥락을 추가하라

스스로 의미가 분명한 이름이 없지 않다. 접두어를 붙이면 좋다.

ex) firstName, lastName, street, houseNumber, city, state, zipcode

이와 같이 지어서 변수를 훑어보면 주소라는 사실을 금방 알아챈다.

하지만 여기서 state라는 변수 하나만 사용한다면? 변수 state가 주소 일부라는 사실을 알아챌까?

• addr라는 접두어를 추가하여 addrFirstName / addrLastName / addrState 라 쓰면 맥락이 좀 더 분명해진다.

📍함수

1. 작게 만들어라
함수는 작을수록 좋다.
if, for 등의 블록이 한 줄이어야 한다.
들여쓰기 수준도 1, 2단 이어야만 한다.

2. 1가지만 해라
함수는 1가지 일만 해야 한다.
이 때 1가지 일이라는 것은 함수의 제목과 1:1 대응이 되는 일이다.
함수의 추상화 레벨이 동일한 작업만 수행한다면 1가지 일이라고 할 수 있다.
함수 안에서 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 일을 하는 셈이다.

3. 서술적인 이름을 사용하라.
파라미터의 순서를 외우는 것도 어렵다.
따라서 함수 이름 자체에 파라미터의 순서를 서술할 수도 있다.

객체 분해로 써도 좋을 듯. 순서도 상관없어진다.

4. 파라미터
파라미터는 적을수록 좋다. 4개를 넘어가는 것은 절대 안된다.
플래그 파라미터도 추하다.

동일한 개념을 나타내는 파라미터가 여러개 사용되는 경우에는 객체를 파라미터로 사용하여 파라미터의 갯수를 줄일 수 있다.

5. 부수 효과를 일으키지 마라
부수 효과를 일으킨다는 것은 프로젝트를 예상치 못하게 하고 함수가 여러 일을 한다는 것이다.

6. 오류 코드보다 예외를 사용하라
오류 코드는 if 등을 사용하여 실제로 데이터가 있는 곳에서 바로 처리해야한다. 하지만 예외 코드는 실제 데이터가 있는 곳에서 더 높은 차원에서 사용할 수 있게 된다. 따라서 예외 코드는 원래 코드에서 분리되어 깔끔하게 사용할 수 있다.

오류 처리도 한 가지 작업이다.
오류 처리만을 하는 함수가 있어야 마땅하다.

7. 반복하지 마라

8. 구조적 프로그래밍
함수가 짧다면 return, break, continue를 여러 차례 사용해도 괜찮다.

(함수형 프로그래밍과 상충되는 내용들)
굳이 파라미터로 받지 않아도 되는 정보들은 객체의 상태 this등을 이용하면 된다.

하지만 함수형 프로그래밍에서는 이런 것들을 지양해야 한다.
함수형 프로그래밍은 가변 상태를 최대한 피해야하기 때문이다.
따라서 함수형 프로그래밍의 가치관을 위해선 인자가 조금은 늘어나도 되지 않을까 싶다.

---

🔖 2주차

📍주석

"잘 달린 주석은 그 어떤 정보보다 유용하다.
경솔하고 근거 없는 주석은 코드를 이해하기 어렵게 만든다."
가 이번 장의 🌟핵심 포인트🌟라고 짚어 말할 수 있다.

우리는 코드로 의도를 표현하지 못해, 실패를 만회하기 위해 주석을 사용한다.

주석은 언제나 실패를 의미한다. 그래서 주석은 반겨 맞을 손님이 아니다. 진실은 한 곳에만 존재한다. 바로 코드다. 부정확한 주석은 독자를 현혹하고 오도한다.

1.주석은 나쁜 코드를 보완하지 못한다.
표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가 복잡하고 어수선하며 주석이 많이 달린 코드보다 좋다.

2. 코드로 의도를 표현하자

// 첫 번째 코드
// 직원에게 복지 혜탹을 받을 자격이 있는지 검사한다.
if((employee.flags & HOURLY_FLAG) &&
    (employee.age > 65 ))
   
// 두 번째 코드 
if(employee.isEligibleForFullBenefits())

두 번째 코드는 어떤가? 몇 초만 더 생각하면 코드로 대다수 의도를 표현할 수 있다.

3. 좋은 주석이란
어떤 주석은 필요하거나 유익하다.

• 법적인 주석
  회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣으라고 명시한다. 예를 들어, 각 소스 파일 첫머리에 주석으로 들어가는 저작권 정보와 소유권 정보는 필요하고도 타당하다.

• 정보를 제공하는 주석
  때로는 기본적인 정보를 주석으로 제공하면 편리하다.
  예를 들어, 다음 주석은 추상 메서드가 반환할 값을 설명한다.

// 테스트 중인 Responder 인스터스를 반환한다.
protected abstract Responder responderInstance();

위와 같은 주석이 유용하다 할지라도, 가능하다면, 함수 이름에 정보를 담는 편이 좋다.

• 의도를 설명하는 주석

주석으로 흥미로운 결정을 기록한 예제이다. 두 객체를 비교할 때 저자는 다른 어떤 객체보다 자기 객체에 높은 순위를 주기로 결정했다.

4. 결과를 경고하는 주석
다른 프로그래머에게 결과를 경고할 목적으로 주석을 사용한다. 예를 들어 다음은 특정 테스트 케이스를 꺼야하는 이유를 설명하는 주석이다.

// 여유 시간이 충분하지 않다면 실행하지 마시오
public void _testWithReallyBigFile()
{

}

5. TODO 주석
앞으로 할 일을 //TODO 주석으로 남겨두면 작업하기에 편하다.

// TODO 체크아웃 모델을 도입하면 ~~어쩌고 저쩌고
protected VersionInfo makeVersion()

6. HTML 코드 주석은 혐오다

// <p> gkdgkdl </p>

이런 주석은 혐555555555다

📍형식 맞추기

형식이 통일되지 않은 코드는 어수선하고 무성의해 보인다.
팀간의 코드 형식을 맞추는 것은 무엇보다 중요하다.
코드 형식은 크게 세로(행 길이)와 가로가 있다.

1. 세로 (행 길이)

• 행 길이는 짧을 수록 좋다.

• 신문 기사처럼 작성하라.

  • 이름만으로 설명이 가능하게 지어라

• 개념은 빈 행으로 분리하라.

• 서로 밀집한 코드 행은 세로로 가까이 두어라

  • 변수는 사용하는 위치에 최대한 가까이 두어라

  • 종속 함수도 가까이 두어라

  • 호출되는 함수는 호출하는 함수 아래에 두어라

  • 비슷한 동작을 하는 함수는 가까이 두어라

2. 가로

• 가로도 짧으면 좋다.

• 공백을 사용해 밀접한 개념과 느슨한 개념을 표현하라.

ex) 할당자는 좌우로 공백을 주어 분리된 개념이라는 인상을 준다.
함수와 인자는 서로 붙여서 밀접한 개념이라는 인상을 준다.

// 좌우에 공백이 들어간 할당자
cosnt a = 7;

// 좌우에 공백이 없는 함수와 인자
function add(a, b) {
  return a + b;
};

3. 들여쓰기

스코프를 들여쓰기로 표현하라.

ex) for, while, function internal…

📍객체와 자료 구조

1. 자료 추상화

• 클래스는 구현을 외부로 부터 숨기는게 좋다.

• 객체는 뒤로 데이터를 숨긴 채 데이터를 다루는 함수만 공개한다.

• 자료 구조는 자료를 그대로 공개하고 별다른 함수 제공 안함.

2. 절차지향 vs 객체 지향

• 절차적인 코드는 기존 자료구조를 변경하지 않으면서 새 함수를 추가하기 쉽다.

• 객체 지향코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.

3. 디미터 법칙

• 모듈은 자신이 조작하는 객체의 속사정을 몰라야한다는 법칙!
  즉, 객체는 조회 함수로 내부 구조를 공개하면 안된다는 의미

• 메서드 체이닝은 기차충돌을 일으킨다. 조잡하다

text.toLowerCase().push() ~~~ 어쩌고 저쩌고

// 이것이 메서드 체이닝이라고 한다. = 기차충돌이라 표현함

🤯 메서드 체이닝 나쁜건가?

객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출하면 안 된다.

객체 에겐 뭔가를 하라고 말해야한다. 속을 드러내라고 말하면 안된다. 선언형 프로그래밍과 비슷?

4. 자료전달객체 (DTO)

주로 백엔드에서 컨트롤러에서 받는 데이터를 매핑할때 쓰거나 레이어 사이에서 자료를 전달할때 쓰인다.

5. 결론

• 시스템을 구현할 때, 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합

• 새로운 동작을 추가하는 유연성이 필요하면 자료구조와 절차적인 코드가 더 적합.

• 편견 없이 최적인 해결책을 선택하자!

---

🔖 3주차

📍경계

1. 외부 코드 사용하기

패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려고 애쓴다.

한 예로, Map을 살펴보자. 이는 굉장히 다양한 인터페이스로 수많은 기능을 제공한다.

Map이 제공하는 기능성과 유연성은 확실히 유용하지만 그만큼 위험도 크다.

Map sensors = new HashMap();

Sensor 객체가 필요한 코드는 다음과 같이 Sensor 객체를 가져온다.

Sensor s = (Sensor)sensors.get(sensorId);

이와 같은 코드는 깨끗한 코드라 보기가 어렵다. 제네릭스를 사용하면 코드 가독성이 크게 높아진다.

Map<String, Sensor> sensors = new HashMap<Sensor>();

ps. Java라 뭔소린지 이해가 … 암튼 제네릭스를 사용하면 가독성이 높아진다에 중점을 두면 될듯

2. 경계 살피고 익히기

외부 코드를 사용하면 적은 시간에 더 많은 기능을 출시하기 쉬워진다.

만약 외부에서 가져온 패키지를 사용하고 싶다면 어디서 어떻게 시작하면 좋을까?

• 우리 자신을 위해 우리가 사용할 코드를 테스트하는 편이 바람직하다.

• 때로는 우리 버그인지 라이브러리 버그인지 찾아내느라 오랜 디버깅으로 골치를 앓는다.

외부 코드를 익히기도 어렵고 통합 하기도 어려운데, 이 두 가지를 동시에 하기에는 두 배나 어려움을 겪을 수가 있다.

간단한 테스트 케이스를 작성해서 외부 코드를 익혀보자. → 우리는 이를 🌟학습 테스트🌟 라고 부른다.

학습 테스트는 프로그램에서 사용하려는 방식대로 외부 API를 호출한다.

통제된 환경에서 API를 제대로 이해하는지 확인하는 셈이다. 학습 테스트는 API를 사용하려는 목적에 초점을 둔다.

3. log4j 익히기

아파치의 log4j라는 테스트를 통해서 코드의 명확성을 위해 테스트 한다는 내용들임…

4. 학습 테스트는 공짜 이상이다

학습 테스트는 이해도를 높여주는 정확한 실험이다.

5. 아직 존재하지 않는 코드를 사용하기

경계와 관련해 또 다른 유형은 아는 코드와 모르는 코드를 분리하는 경계다.

때로는 우리의 지식이 경계를 너머 미치지 못하는 코드 영역도 있다.

이 내용을 요약하자면, 사용할 api나 메서드, 함수 등등을 캡슐화하자. 그럼 내용이 바뀔 때 수정할 코드를 한곳으로 모았기 때문에 바꾸면서 테스트도 아주 편하게 진행될 수가 있다.

그럼 API 인터페이스가 나온 다음 경계 테스트 케이스를 생성해 우리가 API를 올바로 사용하는지 테스트할 수도 있다.

경계에 위치하는 코드는 깔끔히 분리한다. 또한 기대치를 정의하는 테스트 케이스도 작성 한다.

외부 패키지가 호출하는 코드를 가능한 줄여서 경계를 관리하자.

새로운 클래스로 경계를 감싸거나 아니면 어답터 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자. 어느 방법이든 코드 가독성이 높아지며, 경계 인터페이스를 사용하는 일관성도 높아지며, 외부 패키지가 변했을 때 변경할 코드도 줄어든다.

📍단위 테스트

1. 왜 테스트가 중요한가?

• 테스트는 유연성, 유지보수성, 재사용성을 제공한다.

  • 이는 테스트의 존재가 실제 코드의 변경을 자유롭게 해주기 때문이다.

• 그러므로 테스트도 실제 코드처럼 잘 작성해야한다.

2. TDD 법칙 세 가지

1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

3. 테스트의 기준은 일반 코드와 다르다.

• 이중 규칙!

• 실제 코드는 성능이 중요하지만 테스트 코드는 전혀 그렇지 않다.

• 따라서 테스트 코드는 효율적인 코드가 아니라 더욱 더 읽기 편하고 표현이 풍부한 코드가 되어야한다.

4. 그럼에도

• 테스트 코드에서 가장 중요한 것은 가독성이다.

5. 테스트도 함수다.

• 따라서 한가지 일만 해야한다.

• 테스트 당 개념 하나씩 테스트하라.

6. FIRST

• Fast

  • 테스트가 빠르지 않으면 외면 받아 결국 테스터의 역할을 수행할 수 없다.

• Independent

  • 각 테스트는 서로 의존하면 안된다.

  • 각 테스트는 어떤 순서로 실행해도 작동해야 한다.

  • 그렇지 않으면 테스트가 실패 하였을 때 문제의 원인을 찾는 것이 무척 어려워진다.

• Repeatable

  • 테스트 반복 가능해야 한다.

• Self-Validating

  • 테스트는 boolean 값으로 결과를 내야 한다.

• Timely

  • 테스트는 적시에 작성해야 한다.

  • 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

📍클래스

1. 클래스는 작아야 한다.

• 클래스는 함수와 다르게 물리적인 크기가 아닌 책임으로 크기를 결정한다.

2. 클래스 이름은 해당 클래스 책임을 기술해야 한다.

• 그렇지 못한다면 클래스의 크기가 너무 큰 것이다.
• 클래스 설명은 if, can, or, but을 사용하지 않고 25단어 내외로 가능해야 한다.

3. 단일 책임 원칙

• 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙

4. 응집도

• 클래스는 인스턴스 변수 수가 작아야 한다.

• 하나의 인스턴스 변수를 여러 메서드에서 사용하는 것은 응집도가 높은 것이다.

• 만약 몇명 메서드에서만 사용하는 인스턴스 변수가 많다면 클래스의 크기가 너무 크다는 것이다.

class Rectangle {
  constructor(height, width, color) {
    this.height = height;
    this.width = width;
    this.color = color;
  }
  calcArea() {
	return this.height * this.width;
  }
  showColor() {
	return this.color;
  }
}

📍창발성

1.창발적 설계로 깔끔한 코드 구현

대다수는 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 믿는다.

1. 모든 테스트를 실행한다.

2. 중복을 없앤다.

3. 프로그래머 의도를 표현한다.

4. 클래스와 메서드 수를 최소로 줄인다.

위 목록은 중요도의 순서 입니다.

2.단순한 설계 규칙 1 : 모든 테스트를 실행하라 !

설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. (문서로만 완벽하면 안됨)

테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템은 ‘테스트가 가능한 시스템’ 이다.

🌟 테스트 케이스가 많을수록 개발자는 테스트가 쉽게 코드를 작성한다. → 더 나은 설계가 얻어짐

결합도가 높으면 테스트 케이스를 작성하기가 어려움

테스트 케이스를 많이 작성할수록 개발자는 DIP와 같은 원칙을 적용하고 의존성 주입, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮춘다. 따라서 설계 품질은 더욱더 높아진다고 보면된다. ⬆️

*소프트웨어 공학에서 결합도(coupling) 또는 의존도는 어떤 모듈이 다른 모듈에 의존하는 정도를 나타내는 것이다.

*DIP란? 의존성 역전 원칙이라는 뜻이다.

• 상위 모듈은 하위 모듈에 의존해서는 안된다.

• 추상화는 세부 사항에 의존해서는 안된다.

• 의존 관계를 맺을 때 변화하기 쉬운 것에 의존하기 보다는 변화하지 않는 것에 의존 하라는 원칙이다.

🌟 “테스트 케이스를 만들고 계속 돌려라” 라는 간단하고 단순한 규칙을 따르면 시스템은 낮은 결합도와 높은 응집력이라는 목표를 저절로 달성한다. → 즉, 테스트 케이스를 작성하면 설계 품질이 높아진다. ⬆️

3.단순한 설계 규칙 2~4 : 리팩터링

테스크 케이스를 모두 작성했다면 이제 코드와 클래스를 정리해도 괜찮다.

구체적으로는 코드를 점진적으로 리팩터링 해나간다. → 코드를 정리하면서 시스템이 깨질까 걱정은 No ! 테스트 케이스가 있기 때문.

리팩터링 단계에서는 소프트웨어 설계 품질을 높이는 기법이라면 무엇이든 적용해도 괜찮다.

응집도를 높이고 ⬆️ 결합도를 낮추고 ⬇️ 관심사를 분리하고 🖐️ 시스템 관심사를 모듈로 나누고 🪓

함수와 클래스 크기를 줄이고 ⬇️ 더 나은 이름을 선택하는 등 다양한 기법을 동원한다. 🥳

이 단계는 단순한 설계 규칙 중 나머지 3개를 적용해 중복을 제거하고, 프로그래머 의도를 표현할 수 있고, 클래스와 메서드 수를 최소로 줄이는 단계이기도 하다.

4.중복을 없애라!

우수한 설계에서 중복은 커다란 적이다.

중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻함 ㅠㅠ 🪓

중복은 여러 가지 형태로 표출된다. 똑같은 코드도 당연히 중복이다.

비슷한 코드는 더 비슷하게 고쳐주면 리팩토링이 쉬워진다.

5.표현하라

소프트웨어 프로젝트 비용 중 대다수는 장기적인 유지보수에 들어간다.

코드를 변경하면서 버그의 싹을 심지 않으려며 유지보수 개발자가 시스템을 제대로 이해해야 한다.

😡 하지만 시스템이 점차 복잡해지면서 유지보수 개발자가 시스템을 이해 하느라, 보내는 시간은 점점 늘고 동시에 코드를 오해할 가능성도 점점 커짐 → 그러므로 코드는 💛개발자의 의도를 분명히 표현해야 한다.💛

개발자가 코드를 명백하게 짤 수록 다른 사람이 그 코드를 이해하기 쉬워지고 결함이 줄고 유지보수 비용이 적게든다.

6.의도를 분명하게, 명백한 코드를 짜기 위해선 ?

1. 좋은 이름을 선택한다. (이름과 기능을 완전 딴판으로 짜놓지 말란 소리)

2. 함수와 클래스 크기를 가능한 줄인다. 작은 클래스와 작은 함수는 이름 짓기도 쉽고, 구현도 쉽고, 이해도 쉽다.

3. 표준 명칭을 사용한다. 예를 들어, 디자인 패턴은 의사소통과 표현력 강화가 주요 목적이다. 클래스 이름에 패턴 이름을 넣어주는 것이 베스트 → 이렇게 하면 다른 개발자가 클래스 설계 의도를 이해하기 쉬움

4. 단위 테스트 케이스를 꼼꼼하게 작성한다.

5. 노력 !

• 표현력을 가장 높이는 가장 중요한 방법은 노력이다. 나중에 코드를 읽을 사람은 바로 자신일 가능성이 높다는 사실을 명심하자. 그러므로 자신의 작품을 조금 더 사랑하자 ! 함수와 클래스에 조금 더 시간을 투자하자

7.결론

📍 더 나은 이름을 선택하고, 큰 함수를 작은 함수 여럿으로 나누고, 자신의 작품에 조금만 더 주의를 기울이자. 주의는 대단한 재능이다.

클래스와 함수 수를 줄이는 작업도 중요하지만, 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다는 뜻이다.

이 책에서 소개하는 기법은 저자들이 수십년동안 쌓은 경험의 정수다.
단순한 설계 규칙을 따른다면 우수한 기법과 원칙을 단번에 활용할 수 있다.