Clean Code - A Handbook of Agile Software Craftsmanship
Robert. C. Martin
Object Mentor의 대표인 Robert. C. Martin의 2008년 8월에 출간된, "클린 코드를 작성하는 핸드북" 정도가 되겠다.
Steve Mcconnell의 Code Complete가 개발 전체를 망라한리스트이고,
Martin Fowler의 Refactoring이 작성된 후의 코드 덩어리를 재구성하는 것이고,
Kent Beck의 구현패턴(Implementation Patterns)는 오브젝트 관점의 행위에 관한 것이고,
Brian W.kernighan과 Rob Pike의 the Practice of Programming은 코드 단위의 연습이고,
Steve Maguire의 Writing Solide Code는 버그 없는 코드를 작성하기 위한 가이드 라인이고,
Clean Code는 Robert C. Martin의 이전의 책 Agile Software Development, Principles, Patterns, and Practices 처럼 에세이적인 개념서이다.
WTF - What The Fuck - 깨끗한 코드는 한 마디로 통한다.
1.Clean Code
Clean Code란 무엇인가?
Bjarne Stroustrup, C++의 발명자
"나는 나의 코드가 우아하고, 효율적이기를 바란다.로직은 버그를 숨기기 힘들도록 직설적이야 한다. 관리하기 쉽도록 의존성은 최소화 해야 한다. 에러핸들링은 완벽하게 명료한 전략을 따라야 한다.
성능 최적화는 비원칙으로 코드를 지저분하게 만들도록 유혹해서는 안된다. 클린코드는 반드시 한가지를 잘 해야 한다."
2. Meaningful Names
Use Intention-Revealing Names - 의도를 알 수 있는 이름을 사용해라
Avoid Disinformation - 의미 없는 요소를 제거하라
Make Meaningful Distinctions - 의미적으로 구별 가능하도록 만들어라
Use Pronounceable Names - 발음하기 좋은 이름을 사용해라
Use Searchable Names - 탐색 가능한 이름을 사용해라
Avoid mental mappings - 머리속으로 연결 시켜야 하는 요소를 제거해라
Class Name - A class name should not be a verb - class 이름은 '동사'이어서는 안된다.
Method Name - Methods should have verb or verb phrase names - 메소드 이름은 동사를 가져야 하거나, 동사적이어야 한다.
Don`t be Cute - 귀여운 이름으로 짖지 마라
Pick one word per Concept - 개념 한개당 한개의 단어를 선택해라, ('선택하다' 의미를 가지는 오브젝트의 단어는 pick , choice, choose, select 등이 될 수 있으나, 한가지를 선택해서 일관성을 유지해라)
Don`t Pun
3. Functions
Small! - 느낌표를 달았듯이 작아야 한다.
Do One thing - Functions Should Do One Thing. They Should Do It Well, They Should Do It Only - 한가지를 해야하고, 그것을 잘 해야 하고, 그것만 해야 한다.
Use Descriptive Names - 설명적인 이름을 사용해라
Prefer Exceptions to Returning Error Codes - 에러코드가 아니라 예외를 반환해라
Don`t Repeat Yourself - Don`t ReInvent the Wheel과 같은 뜻으로 , 직접 만들지 말고 이미 잘 정의 되어 있는 것을 사용해라
4. Comments
"Don`t comment bad code - rewrite it" - 나쁜 코드를 설명하기 위해서 코멘트를 달지 말고, 코드를 재 작성해라
Explain Yourself in Code - 코드 그 자체로서 설명해라
7. Error Handling
Define the Normal Flow - 특이한 구조가 아닌 정상적인 흐름을 따르도록 정의해라
Don`t Return Null - null을 반환하지 말라, null을 반환하는 메소드가 있다면, 그 메소드를 사용하는 코드에서는 항상 null 체크를 필요로한다.
Don`t Pass Null - 파라미터로 null을 전달하지 말아라, 정상적인 경우라면 대부분의 경우에서 null을 전달 받아 올바르게 동작하는 것은 존재 할 수 없다. 전달하기 전에 완전한 파라미터를 전달해라
10. Classes
Class Should be Small - 클래스는 작아야 한다.
Cohesion - 응집성이 있어야 한다. 클래스는 자신이 알아야 할 요소들 만으로 정의 되어야 하고, 알아야만 한다는 것은 응집성이 있음을 증명한다.
Maintaining Cohesion Results in Many small Classes
11. Systems
Seperate Constructing a System from using it - 시스템의 사용과 시스템의 구축을 분리 해라. 사용과 구축이 연관을 가진다면, 사용의 작은 변경에도 구축 부분이 변경되어야 함을 의미한다.
16. Refactoring
First, Make it Works - 첫번째는, 작동하게 만들어라
Then Make It Right - 그 후에 , 올바르게 만들어라.
17. Smell and Heuristics - 냄새 와 경험적 판단의 추가
Comments
C1:Inapropriate Information - 불필요한 정보
C2: Obsolete Comment - 유효기간이 지난 코멘트 (코드 또는 로직이 변경 되었는데도 코멘트는 변경하지 않는다면, 이를 읽는 자신 또는 다른 개발자는 혼란을 겪게된다.)
C3: Redandunt Comment - 중복되는 코멘트 (코드가 중복되지 않았다면, 중복되는 코멘트가 존재할 수가 없다. 중복되는 코멘트와 코드 자체가 나쁜 냄새이다.)
C4: Poorly Written Comment - 엉터리 코멘트 <- 말할 필요가 없다.
C5: Commented-Out Code
Environment
E1: Build Requires More than One Step
E2: Test Require More than One Step
Functions
F1: Too Many Arguments - 너무 많은 파라미터를 전달한다.
F2: Output Arguments
F3: Flag Arguments
F4: Dead Function
Clean Code 프리젠테이션
Clean Code 슬라이드
'교양서' 카테고리의 다른 글
| 소프트웨어 아키텍처 문서화 (0) | 2009/04/08 |
|---|---|
| 부의 미래 와 대한민국의 과제 (Revolutionary wealth, 앨빈 토플러, 하이디 토플러) (9) | 2009/04/07 |
| Clean Code - A Handbook of Agile Software Craftsmanship (3) | 2009/04/03 |
| 구텐베르크 은하계(부제-활자인간의 형성) - 웹2.0 과 웹3.0의 미래 (3) | 2009/03/29 |
| 소트웍스 앤솔러지 (The ThoughtWorks Anthology) - 소프트웨어 기술과 혁신에 관한 에세이 (1) | 2009/03/13 |
| 개발자 기획자가 꼭 읽어야 할 책 - 미디어의 이해 (0) | 2009/03/10 |






