[클린 코드] — 기술블로그+일상

2022.01.21

DAY 1

🔖 오늘 읽은 범위 : 추천사 & 들어가면서

😃 책에서 기억하고 싶은 내용을 써보세요.

큰 실무에서 실력을 쌓고 신뢰를 얻으려는 전문가는 먼저 작은 실무부터 실력을 쌓고 신뢰를 얻어야 하는 탓이다. (p. xxii)
“처음 왔을 때보다 캠프장을 더 깨끗이 치우고 떠나려고” 최선을 다했는가? 체크인하기 전에 코드를 깨끗하게 정리했는가? (p. xxviii)
코드는 결코 완벽하지 않으므로 자신의 코드 상태를 정직하게 말한다. (p. xxviii)
스스로 연습하고 실패도 맛봐야 한다. 남들이 시도하다 실패하는 모습도 봐야 한다. 그들이 넘어지고 일어서는 모습도 봐야 한다. 결정을 내리느라 고민하는 모습, 잘못된 결정으로 대가를 치르는 모습도 봐야 한다. (p. xxxii)

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

[장인 정신을 익히는 두 가지 과정]

장인에게 필요한 원칙, 패턴, 기법, 경험과 같은 지식을 습득해야 함
연습과 반복을 통한 체득...

자전거 타기에 관한 물리적인 지식을 가르칠 수는 있지만, 그래도 자전거를 처음 타는 사람이라면 100% 넘어진다는 예시가 기억에 남는다.

소감 3줄 요약

신은 세세함에 깃들어 있다.
제품 생명주기까지 고려해야 한다.
코드는 결코 완벽하지 않으므로 자신의 코드 상태를 정직하게 말한다.

2022.01.22

DAY 2

🔖 오늘 읽은 범위 : 1장, 깨끗한 코드(p.1 ~)

😃 책에서 기억하고 싶은 내용을 써보세요.

코드는 요구사항을 표현하는 언어 (p.3)
르블랑의 법칙. 나중은 결코 오지 않는다. (p.4)
깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길이라는 사실을 인정하리라. (p.6)
좋은 코드를 사수하는 일은 바로 우리 프록래머들의 책임이다. (p.7)

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

[나중은 결코 오지 않는다.]

나쁜 코드가 쌓일수록 팀 생산성은 떨어진다.
지금은 바쁘니 일단 대충 짜고 나중에 손보겠다고 생각하는 경우도 있고, 대충 짠 프로그램이 돌아간다는 사릴에 안도감을 느끼며 그래도 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 잇다.

처음 코드를 작성할 때 깨끗한 코드를 작성해야 한다. 코드 뿐만 아니라 나중에 손보겠다는 일이 몇가지 있었지만 책의 내용처럼 나중은 없었을지도 모른다. 이 책을 읽고 clean한 코드를 짜는 방법에 대해 얼른 배우고 싶다!!

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

르블랑의 법칙(leblanc’s Law) - 나중은 결코 오지 않는다.

소감 3줄 요약

앞으로 코드가 사라질 가망은 전혀 없다! 코드는 요구사항을 상세히 표현하는 수단이니까!
깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길이라는 사실을 인정하리라.
‘코드 감각’ (...) 깨끗한 코드를 작성하는 프로그래머는 빈 캔퍼스를 우아한 작품으로 바꿔가는 화가와 같다.

2022.01.23

DAY 3

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

😃 책에서 기억하고 싶은 내용을 써보세요.

깨끗한 코드는 한 가지에 ‘집중’한다. (p.10)
’명쾌한 추상화’ - 코드는 추측이 아니라 사실에 기반해야 한다. 반드시 필요한 내용만 담아야 한다. (p.11)
인간이 읽기 좋은 코드를 작성하라. (p.12)
깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. (p.12)
중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라. (p.14)

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

[얼른 깨끗한 코드를 작성해보고 싶다!]

항상 좋은 코드란 무엇인지 고민도 많이 했습니다. 하지만 어떤 코드가 깨끗한 코드인지 알 수 없었는데 이번 기회에 ‘클린 코드’를 읽으며 저도 드.디.어! 깨끗한 코드를 작성할 수 있게 되어 기쁩니다.

책의 내용을 하나하나 뜯어보면서 저도 깨끗한 코드를 작성할 수 있도록 노력할 겁니다!!!

소감 3줄 요약

깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다.
시간이 지나도 언제나 깨끗하게 유지해야 한다. 코드의 퇴보를 막아야 한다.

2022.01.24

DAY 4

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

😃 책에서 기억하고 싶은 내용을 써보세요.

의도를 분명히 밝혀라 (p.22)
그릇된 정보를 피하라 (p.24)
의미 있게 구분하라 (p.25)
발음하기 쉬운 이름을 사용하라 (p.27)
검색하기 쉬운 이름을 사용하라 (p.28)
인코딩을 피하라 (p.29)
- 헝가리식 표기법
  - 이제는 헝가리식 표기법이나 기타 인코딩 방식이 오히려 방해가 될 뿐이다.
- 멤버 변수 접두어
  - 접두어를 붙일 필요도 없다.
- 인터페이스 클래스와 구현 클래스
  - 둘 중 구현 클래스를 인코딩하겠다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

코드 짜는건 각자의 스타일이 있는 것이므로 뭐가 맞다고 할 수 같다고 생각했다. 그런데 깨끗한 코드, 그 중 의미 있는 이름을 작성해야 한다는 것을 알게 됐다.

지금까지는 내 마음대로 이름을 지었지만 클린 코드를 통해 이름을 어떻게 지어야 할지 조금은 알게 된 것 같다..!

소감 3줄 요약

의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.
단순히 이름만 고쳤는데도 함수가 하는 일을 이해하기 쉬워진다.
전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

2022.01.25

DAY 5

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

😃 책에서 기억하고 싶은 내용을 써보세요.

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. (p.33)
대충 훑어봐도 이해할 코드 작성이 목표다. (p.34)
적어도 표나 자료구조처럼 읽히는 코드를 짜는데만 집중해야 마땅하다. (p.38)

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

이제 ‘의미 있는 이름’을 읽는 건데 벌써부터 깨끗한 코드를 작성하는 것은 복잡하다는 생각이 든다...

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

기술이름이란 무엇일까?
문제 영역에서 가져오는 이름은 무엇을 말하는 것일까?

소감 3줄 요약

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.
대충 훑어봐도 이해할 코드 작성이 목표다.
적어도 표나 자료구조처럼 읽히는 코드를 짜는데만 집중해야 마땅하다.

2022.01.26 ~ 01.27

DAY 6, 7

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

😃 책에서 기억하고 싶은 내용을 써보세요.

함수를 만드는 첫째 규칙은 ‘작게!’다. 둘째 규칙은 ‘더 작게!’다. (p.42)
함수는 한 가지를 해야 한다. 그 한가지를 잘 해야 한다. 그 한가지만을 해야 한다. (p.44)
인수가 2-3개 필요하다면 일부를 독자적인 클래스 변수로 선언할 가능성을 짚어본다.x와 y를 묶었듯이 변수를 묶어 넘기려면 이름을 붙여야 하므로 결국은 개념을 표현하게 된다. (p.53)

Circle makeCircle(double x, double y, double radius); 
Circle makeCircle(Point center, double radius);

예외를 사용하면 코드가 깔끔해진다.
try/catch 블록을 별도 함수로 뽑아내는 편이 좋다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

여러 가지 일을 하는 함수를 만든 적이 있다. 하지만 그 함수는 프로그램 내에서 특정 페이지를 담당하기에 여러 가지 일을 한다고 생각하지 못했다.

예제 코드들을 보니 내가 전에 짠 코드들을 다시 한 번 봐야할 것 같다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

추상화 수준이 높다는 건 무슨 의미일까?
switch문을 추상팩토리에 꽁꽁 숨긴다.
p.51의 단항 형식 부분은 잘 이해가 가지 않으므로 다시 꼼꼼히 읽어봐야겠다.
출력 인수란 무엇인가?
- 출력 인수로 사용하라고 설계한 변수가 바로 this이기 때문이다.(p.56)를 보면 출력 인수는 this로 사용될 수 있는 것을 말하는 것 같다.
OCP(Open Closed Principle)
구조적 프로그래밍
AOP(Aspect Oriented Programming)
COP(Component Oriented Programming)

소감 3줄 요약

최대한 함수를 작게 만들어야 한다.
각 함수는 하나의 이야기만 담고 있어야 한다.
함수가 분명하고 정확한 언어로 깔끔하게 같이 맞아떨어져야 이야기를 풀어가기가 쉬워진다는 사실을 기억해야겠다.

2022.01.28 ~ 01.29

DAY 8, 9

🔖 오늘 읽은 범위 : 4장, 주석

😃 책에서 기억하고 싶은 내용을 써보세요.

코드를 깔끔하게 정리하고 표현력을 강화하는 방향으로, 그래서 애초에 주석이 필요 없는 방향으로 에너지를 쏟겠다. (p.69)
주석은 나쁜 코드를 보완하지 못한다. (p.69)
코드로 의도를 표현하라! (p.70)
좋은 주석 (p.70)
- 회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석을 넣으라고 명시한다.
- // Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved. // GNU General Public License 버전 2 이상을 따르는 조건으로 배포한다.
- 정보를 제공하는 주석
- 의도를 설명하는 주석
- 의미를 명료하게 밝히는 주석
- 결과를 경고하는 주석
- TODO 주석
- 중요성을 강조하는 주석
- 공개 API에서 Javadocs
나쁜 주석 (p.75)
- 주절거리는 주석
- 같은 이야기를 중복하는 주석
- 오해할 여지가 있는 주석
- 의무적으로 다는 주석
- 이력을 기록하는 주석
- 있으나 마나 한 주석
- 무서운 잡음
- 함수나 변수로 표현할 수 있다면 주석을 달지 마라
- 위치를 표시하는 주석
- 닫는 괄호에 다는 주석
- 공로를 돌리거나 저자를 표시하는 주석
- 주석으로 처리한 코드
- HTML 주석
- 주석을 달아야 한다면 근처에 있는 코드만 기술하라.
- 너무 많은 정보
- 모호한 관계
- 함수 헤더
- 비공개 코드에서 Javadocs

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

지금까지는 닫는 괄호에 항상 주석을 달았었다. 그런데 아주 짧은 코드여도 항상 닫는 괄호에 주석을 달았었다.

코드가 지저분해진 것 같았지만 주석을 단다는게 무조건 좋은 건줄 알았기 때문이다. 이제는 함수를 줄이려고 노력하고 주석을 최소화하려고 노력해야겠다.

소감 3줄 요약

코드로 의도를 표현할 방법은 없을까?
코드를 깔끔하게 정리하고 표현력을 강화하는 방향으로, 그래서 애초에 주석이 필요 없는 방향으로 에너지를 쏟겠다.
주석으로 나쁜 코드를 보완하려 하지 말자!

2022.01.30

DAY 10

🔖 오늘 읽은 범위 : 5장, 형식 맞추기

😃 책에서 기억하고 싶은 내용을 써보세요.

팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다. (p.96)
코드 형식은 의사소통의 일환이다. (p.96)
이름은 간단하면서도 설명이 가능하게 짓는다. 소스파일 첫 부분은 고차원 개념의 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사한다. 마지막에는 가장 저차원 함수와 세부 내역이 나온다. (p.98)
개념은 빈 행으로 분리한다. (p.98)
한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다. 호출하는 함수를 호출되는 함수보다 먼저 배치한다. (p.104)
가로로는 공백을 사용해 밀접한 개념과 느슨한 개념을 표현한다. (p.108)
팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다. 팀은 한 가지 규칙에 합의해야 한다. 그리고 모든 팀원은 그 규칙을 따라야 한다. (p.113)
한 소스 파일에서 봤던 형식이 다른 소스 파일에도 쓰이리라는 신뢰감을 독자에게 줘야 한다. (p.114)

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

이클립스를 사용할 때, 자동 정렬하면 자동으로 코드를 정렬해주면서 알아서 띄어쓰기도 해준다. 띄어쓰기를 하는 것은 그냥 본인의 선택이라고만 생각했는데 이번 장을 읽으면서 띄어쓰기 하나하나까지 잘 사용하면 클린한 코드를 만들 수 있다는 것을 알게 되었다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

변수는 사용하는 위치에 최대한 가까이 선언한다.(p.101)와 인스턴스 변수(p.103)에서 예제는 클린코드라는 걸까? 아니라는 걸까?
아니라면 어떻게 코드를 작성해야 한다는 걸까?

소감 3줄 요약

팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다.
코드 형식은 의사소통의 일환이다.
한 소스 파일에서 봤던 형식이 다른 소스 파일에도 쓰이리라는 신뢰감을 독자에게 줘야 한다.

2022.02.01

DAY 12

🔖 오늘 읽은 범위 : 6장, 객체와 자료 구조

😃 책에서 기억하고 싶은 내용을 써보세요.

인터페이스는 자료 구조를 명백하게 표현한다. (p.118)
자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다. (p.119)
객체 지향 코드
- 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다. (p.119)
- 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다. (p.122)
(자료 구조를 사용하는) 절차적인 코드
- 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다. (p.119)
- 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. (p.122)
디미터 법칙 (heuristic) (p.123)
- 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙
- 객체는 조회 함수로 내부 구조를 공개하면 안 된다는 의미
- 낯선 사람은 경계하고 친구랑만 놀아라.
기차 충돌은 일반적으로 조잡하다 여겨지는 방식이므로 피하는 편이 좋다. (p.123)
- ```
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
```
잡종 구조는 되도록 피하는 편이 좋다. (p.125)
뭔가를 하라고 말해야지 속을 드러내라고 말하면 안 된다. (p.125)

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

요즘 책을 읽으면서 지금까지 짰던 ‘좋아보였던’ 코드는 ‘클린’하지 않다는 것을 느끼는 중이다.

특히, 기차 충돌...

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

직교좌표계, 극좌표계

소감 3줄 요약

객체는 동작을 공개하고 자료를 숨긴다.
자료 구조는 별다른 동작 없이 자료를 노출한다.
시스템을 구현할 때, 무엇을 추가하는 유연성이 필요한지에 따라 객체나 자료구조를 적절하게 선택해야 한다.

2022.02.02 / 2022.02.04

DAY 13, 15

🔖 오늘 읽은 범위 : 7장, 오류 처리

😃 책에서 기억하고 싶은 내용을 써보세요.

오류가 발생하면 예외를 던지는 편이 낫다. (p.131)
예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다. (p.132)
먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다. (p.133)
예외를 던질 때는 전후 상황을 충분히 덧붙인다. (p.135)
오류 메시지에 정보를 담아 예외와 함께 던진다. (p.135)
실제로 외부 API를 사용할 때는 감싸기 기법이 최선이다. 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다. (p.137)
메서드에서 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은 더 나쁘다. (p.140)
깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. (p.142)

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

이번 장은 좀 어려웠다.

글만 읽은 느낌이므로 n번 읽어봐야할 것 같다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

OCP (Open Closed Principle)
외부 API (p.137)

소감 3줄 요약

오류가 발생하면 예외를 던지는 편이 낫다.
깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. 오류 처리를 프로그램 논리와 분리하면 독집적인 추론이 가능이 가능해지며 코드 유지보수성도 크게 높아진다.
이번 장은 어려웠으므로 n번 읽어보기

2022.02.06 ~ 02.07

DAY 17, 18

🔖 오늘 읽은 범위 : 9장, 단위 테스트

😃 책에서 기억하고 싶은 내용을 써보세요.

테스트 코드는 실제 코드 못지 않게 중요하다. (p.157)
테스트는 유연성, 유지보수성, 재사용성을 제공한다. 테스트 케이스가 있으면 변경이 쉬워지기 때문이다. (p.157)
가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다. 명료성, 단순성, 풍부한 표현력이 필요하다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다. (p.158)
(1) 테스트 자료를 만든다. (2) 테스트 자료를 조작한다. (3) 조작한 결과가 올바른지 확인한다.
API 위에다 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용하므로 테스트 코드를 짜기도 읽기도 쉬원진다. 이렇게 수현한 함수와 유틸리티는 테스트 코드에서 사용하는 특수 API가 된다. 숙련된 개발자라면 자기 코드를 좀 더 간결하고 표현력이 풍부한 코드로 리팩터링해야 마땅하다. (p.161)
테스트 API코드에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다. 단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다. (p.161)
컴퓨터 자원과 메모리가 제한적일 가능성이 높다. 하지만 테스트 환경은 자원이 제한적일 가능성이 낮다. 이것이 이중 표준의 본질이다. 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대개 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 철저히 무관하다. (p.164)
때로는 주저 없이 함수 하나에 여러 assert 문을 넣기도 한다. 단지 assert 문 개수는 최대한 줄여야 좋다는 생각이다. (p.165)
“테스트 함수마다 한 개념만 테스트하라” (p.166)
“개념 당 assert 문 수를 최소로 줄여라” ”테스트 함수 하나는 개념 하나만 테스트하라” (p.167)
F.I.R.S.T
- 빠르게 (Fast)
- 독립적으로 (Independent)
- 반복가능하게 (Repeatable)
- 자가검증하는 (Self-Validating)
- 적시에 (Timely)

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

취업 준비하다보면 TDD라는 단어를 자주 봤다. 무슨 의미인지 TDD는 어떻게 하는건지 몰랐다.

사실 책을 봐도 겉으로는 대강 무슨 내용인지는 알겠지만 무엇을 말하는지 자세하게는 아직도 모르겠다.

이번 장도 n회독 해야할 것 같다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

BUILD-OPERATE-CHECK 패턴
도메인에 특화된 언어 (DSL)
이것이 이중 표준의 본질이다. 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대개 메모리나 CPU 효율과 관련 있는 경우다. (p.164) 라는 문장을 다시 한 번 읽어봐야겠다.
TEMPLATE METHOD 패턴

소감 3줄 요약

테스트 코드는 지속적으로 깨끗하게 관리하자.
표현력을 높이고 간결하게 정리하자.
테스트 API를 구현해 도메인 특화 언어(Domain Specific Language, DSL)를 만들자.

저작자표시 비영리 변경금지

티스토리툴바