[문희상] 1장, 2장 : 깨끗한 코드 , 의미 있는 이름

1장/문희상.md

@@ -0,0 +1,40 @@
+### p.2 코드가 존재하리라
+
+- 코드는 요구사항을 상세히 표현하는 수단이기에 사라질 가능성은 없다
+- 창의력과 직관을 보유한 우리 인간조차도 고객의 막연한 감정만 갖고는 성공적인 시스템을 구현하지 못한다
+
+### p.4 나쁜 코드
+
+- 나쁜 코드는 기능을 추가할수록 코드를 엉망으로 만들고 회사를 망하게 하기도 한다
+- 르블랑의 법칙(나중은 결코 오지 않는다)에 따라 나중에 리팩토링 할 생각은 하지 말자
+- 새 인력과 팀은 생산성을 높여야 한다는 극심한 압력에 나쁜 코드를 양산하기도 한다
+- 시간이 오래걸린다는 이유로 나쁜 코드를 만들어내는 것은 전문가답지 못한 행동이다
+
+### p.9 깨끗한 코드
+
+- 우아한 코드는 코드를 보는 사람에게 즐거움을 선사하는 코드다
+- CPU 자원을 효율적으로 사용하지 못하는 코드는 우아하지 못하다
+- 철저한 오류 처리도 우아한 코드가 되기 위해 필요하다
+- 깨끗한 코드는 가독성이 좋아 잘 쓴 문장처럼 깔끔하게 읽힌다
+- 또한 필요한 내용만 담아야 하며 다른 사람이 고치기도 쉬워야 한다
+- 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다
+
+### p.13 켄트 벡의 코드 규칙
+
+- 모든 테스트를 통과한다
+- 중복이 없다
+- 시스템 내 모든 설계 아이디어를 표현한다
+- 클래스, 메서드, 함수 등을 최대한 줄인다
+
+→ 중복, 표현력, 추상화를 고려하며 작성해보자
+
+### p.15 워드 커닝햄
+
+- 코드는 짐작했던 기능을 그대로 수행해야한다
+- 따라서 깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다
+- 언어를 단순하게 보이도록 만드는 책임은 프로그래머에게 있다
+
+### p.18 보이스카우트 규칙
+
+- 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다
+- 시간이 지날수록 코드가 좋아지는 프로젝트에서 작업하도록 하자

2장/문희상.md

@@ -0,0 +1,89 @@
+### p.22 의도를 분명히 밝혀라
+
+- 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다
+- 변수의 존재 이유는? 수행 기능은? 사용 방법은?에 대해서 코드만으로 답변이 가능해야한다
+- 코드의 단순성이 중요한 것이 아니라 코드의 함축성이 중요하다
+- 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다
+- 단순히 이름만 고쳤는데도 함수가 하는 일을 이해하기 쉬워진다
+
+### p.24 그릇된 정보를 피해라
+
+- 프로그래머는 코드에 그릇된 단서를 남겨서는 안된다
+- 서로 흡사한 이름을 사용하지 않도록 주의한다
+- 유사한 개념은 유사한 표기법을 사용해야하며, 일관성이 떨어지는 표기법은 그릇된 정보다
+- 소문자 L이나 대문자 )는 조심하자
+
+### p.25 의미 있게 구분하라
+
+- 연속적인 숫자를 덧붙인 이름은 아무런 정보를 제공하지 못하는 이름이다
+- 불용어를 추가한 이름 역시 아무런 정보를 제공하지 못한다
+- Info나 Data는 a, and, the와 마찬가지로 의미가 불분명한 불용어다
+- 읽는 사람이 차이를 명확하게 알 수 있도록 이름을 지어라(moneyAmount vs money)
+
+### p.27 발음하기 쉬운 이름을 사용하라
+
+- 발음하기 어려운 이름은 토론하기도 어렵다
+- 프로그래밍은 사회 활동이다
+- 또한 지적인 대화가 가능해진다
+
+### p.28 검색하기 쉬운 이름을 사용하라
+
+- 문자 하나를 사용하는 이름과 상수는 텍스트 코등서 쉽게 눈에 띄지 않는다는 문제점이 있다
+- 숫자 7은 7이 들어가는 파일 이름이나 수식이 모두 검색되기 때문에 까다롭다
+- e는 영어에서 가장 많이 쓰이는 문자로 변수 이름으로 적합하지 못하다
+- 이름 길이는 범위 크기에 비례해야 한다
+- 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다
+
+### p.29 인코딩을 피하라
+
+- 유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다
+- 인코딩은 불필요한 정신적 부담이다
+- 또한 거의 발음하기 어려우며 오타가 생기기도 쉽다
+- 클래스와 함수는 점차 작아지는 추세다
+- 멤버 변수에 m_ 이라는 접두어를 붙일 필요도 없다
+- 또한 인터페이스의 경우에도 이름에 접두러를 붙이지 않는 편이 좋다
+
+### p.31 자신의 기억력을 자랑하지 마라
+
+- 코드를 읽으며 변수 이름을 자신이 아는 이름으로 변환해야 한다면 그 변수 이름은 바람직하지 못하다
+- 문자 하나만 사용하는 변수 이름은 루프 범위가 아주 작고 다른 이름과 충돌하지 않을 때만 괜찮다
+- 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다
+
+### p.32 클래스 및 메서드 이름
+
+- 클래스 이름과 객체 이름은 명사나 명사구가 적합하다
+- Manage, Processor, Data, Info 등과 같은 단어는 피하고, 동사는 사용하지 않는다
+- 메서드 이름은 동사나 동사구가 적합하다
+- postPayment, deletePage, save 등이 좋은 예다
+- 생성자를 중복정의할 때는 정적 팩토리 메서드를 사용한다
+- 생성자 사용을 제한하려면 해당 생성자를 private로 선언한다
+
+### p.33 한 개념에 한 단어를 사용하라
+
+- 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다
+- 인텔리제이 같은 최신 IDE는 문맥에 맞는 단서를 제공한다
+- 마찬가지로, 동일 코드 기반에 controller, manager, driver를 섞어 쓰면 혼란스럽다
+
+### p.34 말장난을 하지 마라
+
+- 프로그래머가 같은 맥락이 아닌데도 ‘일관성’을 고려해 add라는 단어를 선택한다
+- 다른 맥락이라면 insert나 append 라는 이름이 적당하다
+- 대충 훑어봐도 이해할 코드 작성이 목표다
+
+### p.34 해법 영역에서 가져온 이름을 사용하라
+
+- 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다
+- 기술 개념에는 기술 이름이 가장 적합한 선택이다
+
+### p.35 의미 있는 맥락을 추가하라
+
+- 클래스, 함수, 이름 공간에 넣어 맥락을 부여해도 의미가 분명하지 않다면 접두어를 붙이자
+- 독자가 맥락을 유추해야 이해가 가능한 경우 변수의 의미가 불분명하다는 것이다
+- 맥락을 개선하면 함수를 쪼개기가 쉬워지므로 알고리즘도 더 명확해진다
+
+### p.37 불필요한 맥락을 없애라
+
+- Gas Station Deluxe라는 애플리케이션을 짠다고 모든 클래스 이름을 GSD로 시작하면 안된다
+- 이는 IDE를 방해하는 행위다
+- 일반적으로 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다
+- 이름에 불필요한 맥락을 추가하지 않도록 주의하자