코드가 존재하리라
: 코드는 요구사항을 표현하는 언어 (잘짜여진 요구사항은 테스트 케이스로 써도 좋다)
- 스스로 요구사항을 결정하는 기계가 나타나지 않는다면, 코드는 존재하리라
나쁜 코드
: 고행(wading) = 나쁜코드를 헤쳐나감
: 르블랑의 법칙(leblanc's Law) = 나중은 결코오지 않는다.
- 밀린 업무로 급하게 작성된 나쁜코드는 이후에도 고쳐지지 않는다.
나쁜 코드로 치르는 대가
: 해독 + 생산성 저하
: 원대한 재설계의 꿈 막대한 투자비용&시간
- 깨끗한 코드를 만드는 것이 비용을 절감 + 전문가로 살아남는 길
- 나쁜코드는 모두 우리의 탓이다. (고객이나 일정, 변경되는 설계의 문제가 아니다.)
우리는 전문가 답지 못했다.
우리가 의사 였다면? 바쁘다고 손도 안씻고 환자를 볼순 없지 않은가?
- 좋은 코드를 사수하는건 프로그래머의 책임이다.
원초적 난제
기한을 맞추기 위한 나쁜 코드 양산
BUT 결과적으로는, 나쁜코드 = 생산속도 저하 = 기한을 맞추기 못하게됨
- 그러니까 깨끗한 코드가 답이다.
깨끗한 코드라는 예술?
: 나쁜코드는 장애물
: 빠르게 가기 위해서는 깨끗한 코드가 답
: 잘그린 그림을 구별 하는 능력 <> 그림을 잘그리는 능력
- 코드감각 = 단순히 나쁜 코드를 구별 하는것만 이 아닌, 좋은코드로 변화 시킬 방안을 생각
깨끗한 코드란?
비야네 스트롭스트룹(Bjarne Stroustrup)
: 우아한 = 보기에 즐거운 코드
: 효율 = 속도 + CPU
: 나쁜코는 나쁜 코드를 유혹 한다. ( 일단 창문이 깨지고 나면, 쇠퇴하는 과정이 시작된다.)
: 오류처리 = 세세한 사항 까지 꼼꼼히 ( 메모리누수, 경쟁상태, 일관성 없는 명명법 )
: 한 가지에 집중한다.
그래디 부치(Grady Booch)
: 가독성이 좋은 코드 ( 깨끗한 코드는 잘 쓴 문장처럼 읽혀야 한다. )
: 의도를 숨기지 않는다.
: 명쾌한 추상화와 단순한 제어문
'큰big'데이브 토마스(Dave Thomas)
: 가독성이 좋은 코드 ( 작성자가 아니어도 읽고 고치기 쉬움 )
: 단위 테스트 + 인수 테스트 존재
: 하나의 목적을 달성하는 방법은 하나
: 의존성을 최소 + API는 명확하며 최소
마이클 페더스(Michael Feathers)
: 주의 깊게 짜여진 코드
론 제프리스(Ron Jeffries)
: 모든 테스트를 통과한다.
: 중복이 없다.
: 시스템 내 모든 설계 아이디어를 표현한다.
: 클래스, 메서드, 함수 들을 최대한 줄인다.
- 중복 줄이기 + 표현력 높이기 + 초반부터 간단한 추상화 고려
워드 커닝햄(Ward Cunnningham)
: 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드 ( 깨끗한 코드는 독해 할필요가 없다. )
: 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드
우리는 저자다
: Javadoc에서 @author = 저자
: 독자와 소통할 책임이 있다.
: 새로운 코드를 작성하기 위해 기존코드를 수없이 읽는다. 그러므로, 읽기 쉬운 코드를 짜야한다.
보이스카우트 규칙
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
- 시간이 지날수록 코드가 좋아지는 프로젝트를 만들자.
📌 객체지향 프로그래밍의 5원칙 (SOLID)
-
SRP: 단일 책임 원칙(single responsibility principle)
하나의 클래스는 하나의 책임.
중요한 기준은 변경이다. 변경이 있을때, 파급효과가 적으면 잘한것.
-
OCP: 개방-폐쇄 원칙 (Open/closed principle)
확장에는 열려 있으나, 변경에는 닫혀 있어야 한다.
다형성 - 인터페이스를 구현한 새로운 클래스를 만들어 새로운 기능을 구현
Object obj = new obj1();
Object obj = new obj2();
구현객체를 변경하려면, 클라이언트 코드를 변경해야 한다.
-
LSP: 리스코프 치환 원칙 (Liskov substitution principle)
하위 클래스는 인터페이스의 규약을 지켜야한다. 단순히 컴파일 에러 수준 아님.
ex. 자동차의 엑셀은 앞으로 가야한다. 뒤로가면 안됨.
-
ISP: 인터페이스 분리 원칙 (Interface segregation principle)
특정 클라인언트를 위한 인터페이스가 여러 범용 인터페이스 하나보다 낫다.
-
DIP: 의존관계 역전 원칙 (Dependency inversion principle)
추상화에 의존해야지, 구체화에 의존하면 안된다. = 역할에 의존해야함.
