Transcript Clean_Code_Note

Clean Code Note
애자일 소프트웨어의 장인정신?!
1장. 들어가면서
• 코드의 품질을 측정하는 유일한 척도
= 분당 내지르는 WTF!의 횟수
• 나쁜코드는 그 코드의 생산성을 감소시킨
다 결국 나쁜코드의 해독->수정 반복은 생
산성을 0로까지 이르게 하고 결국 새로운
시스템을 창출하기 위해 TF팀을 구성하게
된다.
클린코드?
• 비얀 스트라우스트럽(C++의 아버지)
– 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 하고, 의
존성을 최대한 줄여야 유지보수가 쉬워진다.
– ‘우아하면’서 효율적인 코드를 비얀 스트라우스트럽은 말한다.
– ‘보기에 즐거운’ 코드를 중시한다.
• 그래디 부치
– 단순하고 직접적이다. 잘 쓴 문장처럼 읽히고, 설계자의 의도를
숨기지 않는다. 명쾌한 추상화와 단순한 제어문으로 가득하다
– 그래디는 명쾌하고, 마치 클라이막스를 넘어서 결말을 향해 가는
명작처럼 긴장감과 문제를 명쾌하게 해결할 수 있는 코드를 중
시한다.
• 데이브 토마스
– 클린코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다, 단위
테스트 케이스와 수용 테스트 케이스가 존재하며 의미가 있는
이름을 가진다. API는 명확하며 최소로 줄였다.
– 마찬가지로 ‘가독성’을 중시하였다. 하지만 그는 ‘테스트 케이스
가 없다면 진정한 클린코드가 아니다.’ 라고 말한다.
• 마이클 페더
– 클린코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치
려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을
고려했고, 고칠 궁리를 하다보면 언제나 제자리로 돌아온다.
– 한마디로 ‘주의’다. 코드를 주의 깊게 짜는 방법. 을 말한다.
• 존 레프리
– 모든 테스트를 통과하고, 중복이 최소화 되었으며, 시스템 내 모
든 설계 아이디어를 표현하고, 클래스 메소드 함수 등이 최대한
줄인 것을 말한다.
– 중복을 피하라! 한가지 기능만 충실하라! 제대로 표현하라! 작게
추상화하라!
우리는 글을 쓴다.
• 실질적으로 코드 작성할때 자신의 행동을 되돌려 보면
상당수는 자신이 작성한 코드를 읽는데 시간을 투자할
것이다.
• 아마 10:1의 비율정도로 읽는 시간이 많다. 그러니 우리
는 누구보다 쉽게 읽을 수 있는 글을 쓰는 것이 중요하
다.
• 짤 짜는 것이 다는 아니다. 잘 짜고 나면 우리는 그것을
유지하고 보수할 책임이 있다.
• 체크아웃 할 때 체크인 보다 더 세밀하게 검토한다면 코
드는 나빠지지 않는다.
– 긴 함수를 분할하고, if를 줄이고, 중복을 줄이는 사사로운 행위
는 코드를 유지하는데 좋은 습관이다.
1장을 마치며…
• 예술에 대한 책을 읽는다도 다 예술가가 되지는 않는다.
• 읽고 느낀다고 다가 아니다.
“연습해, 연습!”
2장. 의미 있는 이름
• 네이밍에 관하여!
• 우리는 변수에도 이름을 붙이고, 함수에도 이름을 붙인
다. 파일에도 이름을 붙인다. 이름을 잘 지으면 복이오나
니
의도를 분명히 밝혀라
• 의도를 분명히 밝힌 좋은 이름을 짓는 대는 시간이 오래
걸린다. 하지만 좋은 이름으로 인해 절약하는 시간은 그
보다 많다.
–
–
–
–
–
–
Int d; -> 시간과 아무른 의미가 없어 보인다.
Int elapsedTimeDays;
Int dayssinceCreation;
Int DaysSinceModification;
Int fileAgeInDays;
->위의 변수들은 시간의 표현이 명확하다.
Public List<int[]> getThem(){
List<int[]> list1 = new arrayList<int[]>();
for(int[] x: theList)
if(x[0] == 4)
list1.add(x);
return list1;
}
//의미를 해독하기 어렵다.
Public List<Cell>getFlaggedCells(){
List<Cell> flaggedCells = new ArrayList<Cell>();
for(Cell cell : gameBoard)
if(cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;
}
// 훨씬 명확하고 어떤 기능을 하는지 읽을 수 있다.
그릇된 정보를 피하라
• 컨테이너 유형에는 컨테이너 이름을 쓰지않는 편이 유용
하다. List는 프로그래머에게 특별하다.
• AccountList라는 변수보다는 AccountGroup,
bunchOfAccount 등이 유용하다.
• 흡사한 이름을 피하라. 겁나게 햇갈린다.
• L,O,1,0(숫자)와 같이 표기식에서 헷갈리는 것은 최대한
멀리하자. 아니 쓰더라도 좀 보기 쉽게 읽기 쉽게 쓰자.
– 1ist 와 같은 현상이 발생하지 않으리란 법 없다.
의미있게 구분하라
• 연속적인 숫자를 붙이는 이름은 결코 정보를 제공하지
못한다.
• Info,Data와 같은 용어들은 a,an,the와 같은 접두어와 같
다.
• NameString과 Name의 차이는 무엇인가?
• Customer 와 CustomerObject의 차이는 무엇인가?
발음하기 쉬운 이름을 사용하라
• 사람들은 단어에 능숙하다. 우리의 두뇌에서 상당부분
은 단어라는 개념만 전적으로 처리한다. 그리고 단어들
은 발음이 가능하다. 두뇌를 사용하게 하자. 그러니 우린
읽기 쉬운 이름을 사용하자.
검색하기 쉬운 이름을 사용하라
• 문자 하나를 사용하면 검색하가 겁나 힘들다. ‘e’는 영어
단어에서 정말 많이 쓰이는 단어이고, 숫자7은 어디에 언
제 쓰일지 모른다.
• 간단한 메서드에서 로컬 변수나 한 문자를 사용하는것이
좋지 전역적으로 한문자나 상수를 사용하는것은 좋은 선
택이 아니다.
인코딩을 피하라
• 헝가리식 표기법은 옛날 어쩔 수 없이 사용된 표기법 중
하나이다. Java나 고급언어들은 컴파일러들이 타입을 다
알아서 처리해준다. (똑똑하다)
• C/C++은 해주지 않는다. 물론 float과 int의 연산들은 해
주지만 모든 객체들에게 해주지는 않는다. C/C++은 Low
Level이다보니 어쩔 수 없다. Prefix정돈 해주자.
클래스 이름과 메소드 이름
• 클래스 이름은 명사나 명사구가 적당하다.
Manager,Processor,Data,Info등의 단어는 피하고, 동사는
최대한 함수들에게 넘겨주자
• 메소드 이름은 동사가 적합하다. deletePage, save와 같
은 예가 있다.
• 너무 기발한 이름은 사람을 피곤하게 한다.
• 개념 하나에 단어 하나를 사용하는게 좋다. 한 클래스에
fetch,retrieve, get과 같은 단어가 제각각 들어간다면 사
용자로썬 혼란스럽다.
• 말장난을 하지 마라. 대충 봐도 쉽게 이해되도록 코드를
짜는게 목적이다.
• 코드를 읽는 사람 = 프로그래머다. 전문적 용어 패턴의
이름들을 사용하는 것은 오히려 이해에 도움이 될 때도
있다.
• 의미있는 맥락을 추가하는것이 좋다. 일반적으로
firstName,lastName,street,houseNumber,city,state,zipco
de와 같은 것들이 주소라는 것은 금방 알아챈다. 하지만
state하나라면? 그것은 상태인지 미국의 주를 나타내는
것인지 모른다 그러니 접두어 addr이나 address와 같은
것을 붙이면 맥락이 더욱 분명해진다.
• 하지만 불필요한 맥락은 없애야 한다. 클래스의 이름을
공통되게 통일된 접두어를 붙이거나 하면 곤란하다.
• 일반적으로 짧은 이름이 긴이름 보다 좋지만 의미가 분
명해야 한다.