클린코드 규칙 총정리

1. 철학

나쁜 코드가 나쁜 이유

생산성 저하

• 나쁜 코드는 팀 생산성을 저하시킨다.
• 기술부채를 만들어 수정을 더 어렵게 한다.

클린 코드

• 성능이 좋은 코드
• 의미가 명확한 코드 === 가독성이 좋은 코드
• 중복이 제거된 코드
• 생산성 상승

창발적 설계 4번째 규칙

실용적 관점에서 타협한다 === 과도한 설계 NO

• 여러가지 규칙에 극단적으로 심취해 클래스와 메서드를 무수하게 만들지 말라.
• 결국 좋은 코드를 만드는 이유는 생산성을 올리기 위한 것이다.
• 실용적인 관점에서 타협해야 한다.
• 개집 짓는데 사람 집 지으면 안된다.

보이스카우트 룰

전보다 더 깨끗한 코드로 만든다.

2. 공동 창작 매너

함께 코드를 공동 창작하고 소비하는 나와 동료 개발자들을 위한 매너
네이밍 + 함수 + 주석 + 포매팅

Team Coding Convention

팀의 코딩 스타일에 관한 약속
우리 팀의 컨벤션이 가장 중요하다.

3. 객체 지향 패턴

캡슐화(Encapsulation)

객체의 실제 구현을 외부로부터 감추는 방식

외부 코드와 호환하기 - Adapter 패턴

외부 코드를 호출할 때, 우리가 정의한 인터페이스 대로 호출하기 위해 사용하는 패턴

낮은 결합도, 높은 응집도

• 결합도 : 다른 모듈간의 의존도
• 응집도 : 모듈 내부의 기능 집중도

SOLID 원칙

객체 지향 설계의 5가지 원칙

• SRP : 단일 책임 원칙 - 한 클래스는 하나의 책임만 가져야 한다.
• OCP : 개방-폐쇄 원칙 - 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• LSP : 리스코프 치환 원칙 - 서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다.
• ISP : 인터페이스 분리 원칙 - 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다.
• DIP : 의존성 역전 원칙 - 상위 모델은 하위 모델에 의존하면 안된다. 둘 다 추상화에 의존해야 한다. 추상화는 세부 사항에 의존해서는 안된다. 세부 사항은 추상화에 따라 달라진다.

4. 오류 처리

Unchecked Exception을 사용하자

Exception 가계도

• Exception 을 상속하면 Checked Exception
• RuntimeException을 상속하면 Unchecked Exception

실무 예외 처리 패턴

• getOrElse : 예외 대신 기본 값을 리턴한다. (null이 아닌 값, 도메인에 맞는 기본 값)
• getOrElseThrow : null 대신 예외를 던진다 (기본값이 없다면)

5. 테스트

Test Pyramid

• Unit
• Integration
• E2E

FIRST 원칙

• Fast : 빠르게
• Independent : 독립적으로
• Repeatable : 반복 가능하게
• Self-Validating : 자가검증하는
• Timely : 적시에

6. 개선

점진적으로 개선하기

• 앗! 뭔가 잘못되고 있어
• 테스트 코드를 작성한다
• 점진적으로 개선한다

코드에 접근하는 시각

• 오픈 소스 접근법
• Spring 프로젝트 접근법

7. IDE 활용

IDE를 활용해 점진적으로 개선하기

• 코드 블럭을 메서드로 추출할 수 있다.