[클린코드] 1장. 깨끗한 코드
* 본 내용은 로버트 C. 마틴이 지은 Clean Code 한글 번역판의 내용을 제가 정리하면서 추가 및 첨삭한 것입니다.
코드?
- 요구사항을 상세히 표현하는 수단.
나쁜코드?
- 일정 문제, 흥미롭지 않은 업무, 산적한 업무들로 인해 대충 실행만 되도록 짠 코드
* 나쁜 코드는 나중에 수정하겠다고 생각하고 실행되는것에 안도하지만, 나중은 결코 오지 않는다. (르블랑의 법칙)
나쁜코드의 영향
- 나쁜 코드는 개발 속도를 크게 떨어뜨린다.
- 매번 얽히고 설킨 코드를 해독해서 얽히고 설킨 코드에 더하게 된다.
- 팀의 코드 생산성은 더욱 떨어지게 된다.
- 생산성이 낮아지자, 새 인력이 투입되지만,
새인력은 현재 설계에 대해 이해할 시간이 부족하여 나쁜 코드를 더욱 양산하게 된다.
- 재설계에 대한 필요성이 생겨,
재설계를 시도하지만, 현재 고객의 니즈에 바로바로 대응할 수 없어
기존 시스템의 유지 보수 개발팀과, 재설계 개발팀이 나뉘게 된다.
- 관리자들은 이미 잘 동작하고 있는 기존의 시스템을 사용하려 하고,
재설계 및 개발을 진행한 팀은 기존 시스템의 기존 기능과 추가되는 기능들까지 모두 개발하여야 하기에
개발이 더딜 수 밖에 없어, 개발 리소스의 낭비, 그리고 또 다른 나쁜 코드를 양산하게 된다.
프로그래머의 태도
- 관리자 보다는 프로그래머가 더 전문가 임을 자각해야 한다.
- 나쁜 코드의 위험성을 이해하지 못하는 관리자의 말을 그대로 따르는 행동은 전문가 답지 못하다.
- "기한을 맞추는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관"임을 명심해야 한다.
깨끗한 코드란?
비야네 스트롭스트룹
- 효율적이고 간단한 논리
- 전략에 의거한 철저한 오류 처리
- 깨끗한 코드는 "한가지"를 똑바로 한다.
그래디 부치
- 깨끗한 코드는 잘 쓴 문장처럼 읽혀야 한다 (가독성)
- 명쾌한 추상화와 단순한 제어문
- 반드시 필요한 내용만 담아야 한다.
데이브 토마스
- 다른 사람이 고치기 쉬운 코드 (가독성)
- 단위 테스트와 인수테스트의 유무 (TDD)
- 명확하고 최소한의 코드로 작성
마이클 페더스
- 주의 깊게 작성한 코드
- 더 이상 손댈 코드가 없을 정도로 세세한 사항까지 꼼꼼하게 신경 쓴 코드
론 제프리스
- 모든 테스트를 통과하는 코드
- 중복을 최소화한 코드
- 제대로 표현한 코드 (메소드 및 변수명 등)
- 작게 추상화하라 (컴포넌트)
|
새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. |
=> 클린코드
클린 코드를 작성하기 위한 객체지향의 5원칙 (SOLID)
| 원칙 | 설명 |
| SRP (The Single Reponsibility Principle) |
단일 책임의 원칙 |
| OCP (The Open Closed Principle) |
개방 폐쇄의 원칙 |
| LSP (The Liskov Subsitution Principle) |
상속 받은 클래스는 기반 클래스를 대체할 수 있어야 한다. 인터페이스, 예외처리에 이르기 까지 동일한 규격으로 다형성 및 확장성을 확보 OCP가 이루어지기 위해서는 LSP가 만족되어야 한다. |
| ISP (The Interface Segregation Principle) |
클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다. 인터페이스의 단일 책임. 하나의 책임만을 가지는 작은 규모의 인터페이스로 분리 |
| DIP (The Dependency Inversion Principle) |
추상화에 의존해야 하며, 구체화에 의존하면 안 된다. 즉, 하위의 모듈이 상위 모듈에 정의한 추상 타입(인터페이스)에 의존 |
* 응집도 높은 코드 : 클래스에 연관된 기능 및 책임들이 구현되어 있고, 원하는 기능만을 수행하도록 되어 있는 코드
* 결합력이 낮은 코드 : 다른 클래스와의 연관 관계가 최소한으로 되어 있어, 다른 클래스에 대한 의존성이 낮은 코드