Clean Code
chapter 01.깨끗한 코드
이 장에서는 깨끗한 코드에 대한 명사들의 생각과 저자인 밥아저씨의 견해를 담았다.
C++창시자인 비야네 스트롭스트룹
- 나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다. 성능을 최적으로 유지해야 사람드이 원칙없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다 깨끗한 코드는 한 가지를 제대로 한다
그래디 부치
- 깨끗한 코드는 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
Big 데이븐 토마스
- 깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 깨끗한 코드에는 의미있는 이름이 붙는다. 특정 목적을 달성하는 방법은 하나만 제공한다. 의존송은 최소이며 각 의존성을 명확히 정의한다. API는 명확하며 최소로 줄였다. 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기 대문에 문학적으로 표현해야 마땅하다.
마이클 페더스
- 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로.
론 제프리스
- 모든테스트를 통과한다
- 주옥이 없다
- 시스템 내 모든 설계 아이디어를 표현한다
- 클래스, 메서드, 함수 등을 최대한 줄인다.
워드 커닝햄
- 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다. 코드가 그 문제를 풀기위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다.
저자 밥아저씨(로버트 C 마틴)
- 이 책에서 말하겠다..ㅎㅎ
보이스카우트 법칙 : 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라!
Chapter02. 의미 있는 이름
- 의도를 분명히 밝혀라.
- 가장 쉬워보이지만 어려운 규칙이라고 생각. 이름만으로 내가 하고자하는 것을 분명히 밝히는것.
- 클래스 이름은 명사, 메서드 이름은 동사
Chapter03. 함수
함수는 작게
- 중첩구조가 생길만큼 함수가 커지면 안된다. : 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안된다.
한가지만 해라
- 함수를 만드는 이유는 큰 개념을 다름 추상화 수준에서 여러단계로 나눠 수행하기 위함.
함수당 추상화 수준은 하나로
- 함수가 한가지 작업만 하려면 함수 내 문장이 추상화 수준이 동일 해야한다.
위에서 아래로, 내려가기 규칙
- 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한번에 한 단계칙 낮아진다. 이런걸 내려가기 규칙.
switch문
- switch문을 저차원 클래스에 숨기고 절대로 반복하지 않는 방법은 다형성을 이용하는 것.
서술적인 이름 사용
함수인수
이상적인 인수 개수는 0개다. 다음은 1개, 다음은 2개다. 3개 이상은 피하는 것이 좋다. 4개 이상은 특별한 이유가 필요하다.
플래그 인수는 안좋다. 왜냐면 함수가 한가지만 하는 규칙을 위반하는것이기 때문이다. 나누는게 좋다?
부수효과를 만들지 말아라(함수가 결과값 외에 다른 상태로 변경하는 것)
명령과 조회를 분리
- 함수는 뭔가를 수행하거나 답하거나 둘 중 하나만 한다.
- 객체 상태를 변경하거나, 객체 정보를 반환하거나 해야한다. 둘다하면 안된다.
오류코드 보다 예외를 사용.
- 반복하지 마라!!!! 객체지향 프로그래밍은 코드를 부모 클래스로 몰아 중복을 없앤다.
- 구조적 프로그래밍. 함수는 return문이 하나여야 하며, 루프 안에서 break, continue 를 사용해선 안된다. (함수를 작게 만드면 간혹 가능하다)
- 함수를 어떻게 짜죠?
- 소프트웨어 짜는 행위는 글짓기와 비슷하다. 논문이나 기사를 작성할때는 먼저 생각을 기록한 후 읽기 좋게 다듬는다. 초안은 대개 서투르고 어수선 하므로 원하는 대로 읽힐 때까지 말을 다듬고 문장을 고치고 문단을 정리하다.
- 처음에는 길고 복잡하고 들여쓰기 단계도 많고 중복 르푸도 많고, 인수 목록도 길다 하지만 나는 그 서투른 코드를 빠짐없이 테스트 하는 단위테스트 케이스도 만든다. 그런다음 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거하고, 메스드를 줄이고 순서를 바꾼다. 때로는 전체 클래스를 쪼갠다. 이와중에도 코드는 항상 단위 테스트를 통과한다.
Chapter04. 주석
주석이 필요없는 것이 가장 좋다. 주석을 다는 것은 실패를 만회하는 거나 다름 없다. 그러므로 주석이 필요한 상황에 처하면 곰곰히 생각하라. 상황을 역전해 코드로 의도를 표현할 방법이 없는지 생각한다.
그래도 주석을 달아야 한다면,
- 법적인 주석 : 저작권
- 의미를 명료하게 밝히는 주석
- TODO주석
- 중요성 강조하는 주석
Chapter05. 형식맞추기
- 적절한 행길이 : 짧을수록 좋고 200줄을 넘지 앟는다 (더 짧아야하는걸로 알고 있는데..)
- 신문기사처럼 작성 : 최 상단에는 큰 개념, 내려갈수록 작은 개념으로.
- 서로 밀접한 개념은 세로로가까이.
- 변수는 최대한 가까이.
- 인스턴스 변수는 처음에
- 종속함수는 호출하는 함수를 호출되는 함수보다 먼저 배치
- 가로 형식 맞추기. 120자 정도.
- 들여쓰기.
<출저: 클린코드, 로버트 C. 마틴, 인사이트>
댓글 없음:
댓글 쓰기