View
560
Download
7
Category
Preview:
Citation preview
Clean Code
코드 품질 척도WTFs/MINUTE
–Jo
“Let There Be Code!”
나쁜 코드
나쁜 코드에 단 주석이 회사 보너스 지급도 안해 , 보너스는 그냥 잊어버려 ! 그리고 이 회사 오지마 . 난 이미 떠날 준비가 되어있어 . 이 프로젝트 버그 겁나많아ㅠ . 넌 진짜로 오래버티지 못할거야 . 그럼 행운을 !
– 르블랑의 법칙
“ 나중은 결코 오지 않는다 .”
태도
– 딜버트
“ 나쁜코드에 대한 책임은 전적으로 프로그래머에게 있답니다 .”
원초적 난제
모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다 .
BUT
진짜 전문가는 나쁜 코드를 양산하면 기한을 맞추지 못한다는 것을 안다 .
깨끗한 코드를 작성하는 프로그래머는 빈 캔버스를 우아한 작품으로 바꿔가는 화가와 같다 .
보이스카우트 규칙
“ 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라 .”
여러가지 설계원칙• SRP(The Single Responsibility Principle)• OCP(The Open Closed Principle)• LSP(The Leskov Substitution Principle)• DIP(The Dependency Inversion Principle)• ISP(The Interface Segregation Principle)
SRP
• 클래스에는 한 가지 , 단 한 가지 변경 이유만 존재해야 한다
OCP
• 클래스는 확장에 열려 있어야 하며 변경에 닫혀 있어야 한다
LSP
• 상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다 .
DIP
• 추상화에 의존해야 하며 , 구체화에 의존하면 안된다 .
ISP
• 클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다 .
의미 있는 이름
의도를 분명히 밝혀라• int d; // 경과 시간 ( 단위 : 날짜 ) - 값과 단위가 필요• int elapsedTimeInDays;
그릇된 정보를 피하라• XYZControllerForEfficientHandlingOfStrings• XYZControllerForEfficientStorageOfStrings
겁나 비슷함
규칙 s
• 의미 있게 구분하라 getActiveAccount();getActiveAccounts();
getActiveAccountInfo();
규칙 s
• 발음하기 쉬운 이름을 사용하라
genymdhms (generate date, year, month, day, hour, minute, second)
규칙 s• 검색하기 쉬운 이름을 사용하라• 인코딩을 피하라• 기억력 자랑 바람직하지 않은것• 한 개념에 한 단어를 사용하라 ( 일관성 있는 어휘 )• 기발한 이름은 피하라• 말장난을 하지마라• 의미 있는 맥락을 추가하라• 불필요한 맥락을 없애라
함수
함수를 만드는 규칙 1
작게
함수를 만드는 규칙 2
더 작게
한가지만 해라
– 지난 몇십년 동안 프로그래머들에게 주어진 충고
“ 함수는 한 가지를 해야 한다 . 그 한 가지를 잘 해야 한다 . 그 한 가지만을 해야 한다 .”
함수당 추상화 수준은 하나로 !
위에서 아래로 코드 읽기내려가기 규칙
서술적인 이름을 사용하라
– 워드
“ 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다 .”
함수 인수
이상적인 인수 개수는 0 개 , 다음은 1 개 다음은 2 개다 .3 항은 피하는 편이 좋다 .
4 개 이상은 특별한 이유가 필요하다 . 특별한 이유가 있어도 사용하면 안된다 .
Boolean Parameter is ugly.
명령과 조회를 분리하라
함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야한다 .
객체 상태를 변경하거나 아니면 객체 정보를 반환하거나…
주석
– 브라이언 W. 커니핸 , P.J. 플라우커
“ 나쁜 코드에 주석을 달지 마라 . 새로 짜라 .”
주석은 필요악이다 .
주석은 나쁜 코드를 보완하지 못한다 .
코드로 의도를 표현하라 .
좋은 주석
정말로 좋은 주석은 , 주석을 달지 않을 방법을 찾아낸 주석이라는 사실을 !
좋은 주석 s• 법적인 주석• 의도를 설명하는 주석• 정보를 제공하는 주석• 의미를 명료하게 밝히는 주석• 결과를 경고하는 주석• TODO 주석• 중요성을 강조하는 주석
나쁜 주석
프로그래머가 주절거리는 독백…
나쁜 주석 s• 주절거리는 주석• 같은 이야기를 중복하는 주석• 오해할 여지가 있는 주석• 의무적으로 다는 주석• 이력을 기록하는 주석• 있으나 마나 한 주석• 함수나 변수로 표현할 수 있다면 주석을 달지 마라• 닫는 괄호에 다는 주석• 위치를 표시하는 주석 ///////// HERE ///////////
객체와 자료구조
절차적인 코드는 기존 자료구조를 변경하지 않으면서 새 함수를 추가하기 쉽다 . 반면 , 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다 .
디미터 법칙
모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다 .
TDD
One Assert Per One Test
TDD 법칙 3 가지• 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다 .• 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다 .• 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다 .
깨끗한 테스트 코드• 테스트 코드는 실제 코드 못지 않게 중요하다 .• 테스트는 유연성 , 유지 보수성 , 재사용성을 제공한다 .
깨끗한 테스트 코드• 깨끗한 테스트 코드를 만들기 위해서는 3 가지가 필요하다 .
• 가독성 , 가독성 , 가독성
테스트당 개념 하나• given-when-then• precondition-invocation-assertion
테스트 함수당 Assertion 하나
• One Assertion Per One Test Function
F.I.R.S.T• Fast-빠르게• Independent- 독립적으로• Repeatable- 반복가능하게• Self-Validating- 자가검증하는• Timely- 적시에
클래스
클래스는 작아야 한다 .
클래스 이름에 Processor, Manager, Super 등과 같이 모호한 단어가 있다면 클래스에다 여러 책임을 떠안겼다는 증거다 .
단일 책임 원칙은 클래스나 모듈을 변경할 이유가 하나뿐이어야 한다는 원칙이다 .
클래스는 인스턴스 변수 수가 작아야 한다 .
응집도가 높다 - 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다 .
DIP - 상세한 구현이 아니라 추상화에 의존해야 한다
수십여 년 동안 쌓아온 경험에서 얻은 교훈이라면 , 프로그래밍은 과학보다 공예에 가깝다는 사실이다 . 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다 .
– 밥아저씨
END
Reference
• Clean Code
Recommended