Clean Code

hwibaski·2022년 1월 21일

노개북 노마드코더

Book

목록 보기

1/2

DAY 1

🔖 오늘 읽은 범위 : 시작 ~ 들어가면서, 처음 ~ p.36

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

사소한 곳에서 발휘하는 정직은 사소하지 않다.(p.12)
시란 영원히 미완성이라 끝없는 재작업이 필요하며 포기할 때에만 끝난다. - 폴 발레리(p.16)

📌 간단한 소감?

[TPM(Total Productive Management)의 5S 원칙]
1. 정리 (정렬)
2. 정돈 (체계화)
3. 청소
4. 청결 (표준화)
5. 생활화 (규율)

소프트웨어 개발을 제조업의 관리 원칙과 비교하는 것이 인상깊었다. 그리고 실제로 Lean이 위의 TPM(1950년대 일본 제조업계의 품질 관리론)을 토대로 만들어졌다고 한다. 소프트웨어 개발도 제조업과 마찬가지로 무언가(코드)를 생산해내는 것들을 살펴보고, 기름치고, 관리해야한다.

개발을 진행할 때 일정이나 기능 구현에 만족하는 경우가 많았다. "깨끗한 코드를 작성했는가?"라는 질문을 받는다면 자신있게 그렇다라고 대답할 수는 없을 것 같다. 저자는 더러운 코드를 뜯어고치는 작업, 즉 유지보수가 새로운 코드를 작성하는 일보다 더욱 빈번하게 일어난다고 한다. 그러므로, 개발자는 조금 더 건축 업계의 수리공이나 자동차 업계의 수리공처럼 생각해야한다고 말하는 부분에 공감한다.

📌 소감 3줄 요약

사소한 것은 사소하지 않다.
유지보수가 새로운 기능 개발보다 빈번하므로 깨끗한 코드를 작성하는 기술, 더러운 코드를 뜯어고치는 기술은 필수이다.

DAY 2

🔖 오늘 읽은 범위 : 1장. 깨끗한 코드

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

우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다는 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다. (p.4)
주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다. 주변 코드를 읽기가 어려우면 새 코드를 짜기도 어렵다. 그러므로 급하다면, 서둘러 끝내려면, 쉽게 짜려면, 읽기 쉽게 만들면 된다. (p.18)
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라. (p.19)

📌 간단한 소감?

'코드가 쓰레기가 된 것의 책임은 프로그래머에게 있다'는 점이 와닿았다. 실무를 경험해보지 않아서 모르겠지만, 많은 요구사항과 시간의 압박에도 프로그래머로서 좋은 코드를 써야할 의무가 있음을 강조하고 있다. "나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다."

[다양한 관점의 깨끗한 코드]

세세한 사항까지 꼼꼼하게 처리하는 코드
한 가지를 잘 수행하는 코드
가독성이 좋은 코드
다른 사람이 고치기 쉬운 코드(테스트가 케이스가 없는 코드는 깨끗한 코드가 아니다!)
중복이 적은 코드, 작게 추상화한 코드

📌 소감 3줄 요약

깨끗한 코드를 쓰는 것은 프로그래머의 책임이다.
깨끗한 코드는 단숨에 써지지 않는다. 연습하자

DAY 3

🔖 오늘 읽은 범위 : 2장. 의미 있는 이름

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

동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다. DeviceManager와 ProtocolController는 기본적으로 어떻게 다른가? 정말 둘 다 Driver가 아닌가? 어째서 둘 다 Manager가 아닌가? 정말 둘 다 Driver가 아닌가? 이름이 다르면 독자는 당연히 클래스도 다르고 타입도 다르리라 생각한다.(p.33)
여느 코드 개선과 노력과 마찬가지로 이름 역시 나름대로 바꿨다가는 누군가 질책할지도 모른다. 그렇다고 코드를 개선하려는 노력을 중단해서는 안된다. (p.38)

📌 간단한 소감?

내가 살아온 시간 중에 이름이 이렇게 중요하다고 생각됐던 건 지금 이 시기가 처음이다. 이름짓기로 이렇게 고민한 적이 있었나 되돌아보게된다. 역시 없다. 코드 내에서의 이름은 정말 중요했다. 함수나 변수 이름을 보면 대충 어떤 동작을 하겠구나하고 예측이 가능해야 한다고 생각한다. 그리고 그에 대한 근거가 책에 잘 정리가 되어 있어서 반가웠다.
개인적으로 네이밍이 얼마나 구체적이어야 하는지에 대한 고민이 있었다. 긴 네이밍은 구구절절 설명하는 느낌이 들고 코드가 간결해보이지 않았다. 그래서 고민을 했다. '코드를 짧아야 해'라는 생각을 하고 있었다. 그릇된 생각을 하고 있었던 것 같다. 코드는 짧아야 한다라기 보다 명료해야한다고 생각을 고쳐먹는 중이다. 명료한 코드가 짧을 수는 있지만, 코드가 짧다고 명료한 코드는 아니었다.

📌 소감 3줄 요약

코드를 개선하려는 노력을 중단해서는 안된다.
명료한 네이밍을 하자.

DAY 4

🔖 오늘 읽은 범위 : 3장. 함수

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

작게 만들어라.
한 가지만 해라.
함수당 추상화 수준은 하나로.
서술적인 이름을 사용해라.
함수에서 이상적인 인수 개수는 0개이다.
부수효과를 일으키지 마라.
명령과 조회를 분리하라.
오류 코드보다 예의를 사용하라.
반복하지 마라.

📌 간단한 소감?

함수 파트내에서 짧은 섹션마다 유용한 내용들이 정말 많다. 아직 잘 와닿지 않는 개념도 있었다. 출력 인수와 입력 인수이다. 출력 인수를 최대한 피해야 한다고 하는데 이게 자바스크립트에서는 어떠한 경우가 있는지 모르겠다. 입력의 상태를 변경하는 것을 출력인수라고 한다. 아래와 같은 함수의 인수를 이야기하는 것인지 정확히 모르겠다.

인수를 전달할 때는 보통 입력으로 간주한다. 입력의 상태를 변경하는 것을 출력인수라 하> 고, 이는 최대한 피해야 한다. https://aroundck.tistory.com/329

const obj = {
  name: 'hwimin',
  age: 30,
};

const chanegeFieldOfObject = (obj) => {
  obj.name = '';
};

chanegeFieldOfObject(obj);
console.log(obj); // { name: '', age: 30}

프로그래밍을 하면서 추상화라는 개념을 알게 모르게 굉장히 많이 들었다. 들을때마다 추상화가 무엇인지 검색을 해봐도 잘 와닿지 않았다. 충분한 예제들을 보고 시간이 지나고 다시 추상화에 대해서 공부해보니 어떠한 개념인지 알게 됐다. 함수를 작성한다는 것 자체가 추상화 작업 중 하나이다. 숫자 2개를 받아서 값을 리턴하는 함수를 만들었다. 1과 2를 직접 더하는 코드를 짤 수도 있지만 두 개의 값을 더해주는 함수를 만들어줌으로써 내부적으로는 어떠한 일이 일어나는지 생각하지 않고, 두 숫자를 더한다는 사실에 집중할 수 있게 됐다.

// 1. 
const add = (num1, num2) => num1 + num2

const result = add(1, 2)

// 2.
const result2 = 1 + 2

추상화는 필요한 부분, 중요한 부분을 통합하여 하나로 만드는 것을 말합니다. 다음의 요소들을 살펴 봅시다. 아래의 세 가지 내용은 모두 '사각형'과 관련된 것입니다.
[도형], [네 개의 각], [네 개의 변]
나열되어 있는 세 가지 요소들을 일일히 언급하지 않고, '사각형'이라고 부르는 것이 추상화의 한 예라고 할 수 있습니다. 그림을 그릴 때에도 완전히 동일하게 그리지 않고 중요한 특징들만 모아서 표현하는 것 역시 추상화라고 할 수 있죠. 스마트폰의 애플리케이션 아이콘 역시 그 특징을 잡아 추상화해서 만든 것이랍니다.
이처럼 추상화는 여러 가지 요소들을 하나로 통합하는 방향성을 가지고 있습니다. 한 가지 문제를 여러가지로 쪼개서 나눠보는 '문제 분할'과 반대의 개념이지요. 추상화를 이용하여 핵심적인 것만을 남겨 표현하게 되면, 복잡한 내용도 한 눈에 알아볼 수 있어 이해하기 쉽다는 장점이 있습니다.
[네이버 지식백과] 추상화 [abstraction] (천재학습백과 초등 소프트웨어 용어사전)