개요
- 개인적 발전을 위해 책 일부분을 읽고 인상깊은 구절들을 기록하여 모아봤습니다
- 모든 지적 재산권은 해당 책의 저자에게 있으며 문제가 될 경우 이 게시글은 삭제됩니다
나쁜 코드를 양산하면 기한을 맞추지 못한다
그럼에도 모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수 밖에 없다고 느낀다.
간단히 말해, 그들은 빨리 가려고 시간을 들이지 않는다
오히려 엉망진창인 상태로 인해 속도가 곧바로 늦어지고, 결국 기한을 놓친다
기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다
- p7
어떤 사람은 코드 감각을 타고난다. 어떤 사람은 투쟁해서 얻어야 한다
코드 감각이 있으면 좋은 코드와 나쁜 코드를 구분한다. 그뿐만이 아니다. 절제와 규율을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다
다시 말해, 깨끗한 코드를 작성하는 프로그래머는 빈 캔퍼스를 우아한 작품으로 바꿔가는 화가와 같다
- 이 부분을 읽으면서
Design is how it works라는 잡스님의 말이 떠올랐다
—
나쁜 코드는 나쁜 코드를 유혹한다
P9
깨끗한 코드란 한 가지를 잘 한다
나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다
깨끗한 코드는 한 가지에 ‘집중’한다
각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다
깨끗한 코드는 단순하고 직접적이며 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
좋은 소설과 마찬가지로 깨끗한 코드는 해결할 문제의 긴장을 명확히 드러내야 한다
코드는 추측이 아니라 사실에 기반해야 하며 반드시 필요한 내용만 담아야 하고 코드를 읽는 사람에게 프로그래머가 단호하다는 인상을 줘야 한다
깨끗한 코드란 읽기 쉬우면서 다른 사람이 고치기 쉽다
깨끗한 코드란 한가지만 잘하면서 읽기에도 쉽고 다른 사람이 고치기 쉽다
P10 ~ 11
‘주의’
깨끗한 코드는 주의 깊게 작성한 코드다
누군가 시간을 들여 깔끔하고 단정하게 정리한 코드다
세세한 사항까지 꼼꼼하게 신경쓴 코드다
주의를 기울인 코드다
p12
코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다
깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다
코드를 독해하느라 머리를 쥐어짤 필요가 없어야 한다
읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드다
명백하고 단순해 마음이 끌리는 코드가 깨끗한 코드다
이만큼 깨끗한 코드는 너무도 잘 짜놓은 코드라 읽는 이가 그 사실을 모르고 넘어간다
모든 뛰어난 설계처럼 설계자가 코드를 어이 없을 정도로 단순하게 설계했기 때문이다
“코드가 그 문제를 풀기 위한 언어처럼 보인다면” -> 언어를 단순하게 보이도록 만드는 책임이 우리에게 있다는 뜻이다!
특정 언어를 신봉하는 광신자가 아주 많다. 하지만 프로그램을 단순하게 보이도록 만드는 열쇠는 언어가 아니다. 언어를 단순하게 보이도록 만드는 열쇠는 프로그래머다!
P15
지금까지 우리가 경험한 바로는 이 책에서 설명하는 교훈이, 적어도 우리에게는, 절대적인 진리다
우리가 가르치는 교훈을 따른다면 우리가 만끽한 이익을 여러분도 만끽하리라 감히 장담한다. 하지만 우리 생각이 절대적으로 ‘옳다’라는 단정은 금물이다
P16
수십년에 걸친 경험과 반복적인 시행착오로 습득한 교훈과 기법이다. 그러므로 여러분이 동의하든 동의하지 않든 우리 시각을 이해하고 존중하려 애써주면 좋겠다
우리는 저자다
다음에 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하기 바란다
P17
코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다
새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다, 비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다.
잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다.
시간이 지나면서 엉망으로 전락하는 코드가 한둘이 아니다.
그러므로 우리는 적극적으로 코드의 퇴보를 막아야 한다
P18
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라
체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.
한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다.
변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다.
시간이 지날수록 코드가 좋아지는 프로젝트에서 작업한다고 상상해보라
지속적인 개선이야 말로 전문가 정신의 본질이 아니던가
예술에 대한 책을 읽는다고 해서 예술가가 된다는 보장은 없다
P19
이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다. ‘코드 감각’을 확실히 얻는다는 보장도 없다.
단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐이다
예술에 대한 책과 마찬가지로 이 책 역시 세세한 정보로 가득하다.
좋은 코드도 소개하고 나쁜 코드도 소개한다.
나쁜 코드를 좋은 코드로 바꾸는 방법도 소개한다.
다양한 경험적 교훈과 체계와 절차와 기법도 열거한다.
예제도 무수히 많이 보여준다. 나머지는 여러분에게 달렸다.
공연장으로 가다가 길을 잃은 연주회의 바이올리니스트가 길거리에서 한 노인에게 카네기 홀로 가는 방법을 물었다.
노인은 연주자와 그가 든 바이올린을 보고 이렇게 말했다
“연습해, 연습!”
P20
꾸준히 연습하자
—
발음하기 쉬운 이름을 사용하라
프로그래밍은 사회활동이기 때문이다
프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.
의미를 해독할 책임이 독자에게 있는 논문 모델이 아니라 의도를 밝힐 책임이 저자에게 있는 잡지 모델이 바람직하다.
코드를 읽을 사람도 프로그래머라는 사실을 명심한다. 그러므로 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.
모든 이름을 문제 영역(domain)에서 가져오는 정책은 현명하지 못하다.
같은 개념을 다른 이름으로 이해하던 동료들이 매번 고객에게 의미를 물어야 하기 때문이다.
적절한 프로그래머 용어가 없다면 문제 영역(domain)에서 이름을 가져온다.
그러면 코드를 보수하는 프로그래머가 분야 전문가에게 의미를 물어 파악할 수 있다.
