(작성중) Clean Code 클린코드

Title: Clean Code 클린 코드 : 애자일 소프트웨어 장인 정신
Author: Robert C. Martin

후속책 PPP Principles, Patterns, Practices

---

1. 깨끗한 코드

깨끗한 코드란

• 중복이 없다
• 한 기능만 수행한다
• 논리가 간단하고, 원칙없는 최적화는 하지 않는다
• 테스트 (Unit Test, Indext Test)가 있다
• 클래스, 메소드, 함소 등을 최대한 줄인다. 작게 추상화 한다(?)
• Leblanc의 법칙 -> 절대 내가 돌아가서 최적화는 하지 않는다. 작성할 때부터 좋은 코드로 만든다.

 

[참고] OOP 5대 원리

SRP,  Single Responsible Principle 단일책임원칙

• A class should have only one reason to change. # 클래스가 변경될 이유는 단 하나여야 한다.
• 하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다
• Book 클래스 -> Reader와 Author 액터가 있을 수 있다 https://siyoon210.tistory.com/155

OCP, Open Closed Principle 개방폐쇄법칙 https://nesoy.github.io/articles/2018-01/OCP

• 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다.
• 무엇이 변하는 것인지. 무엇이 변하지 않는 것인지 구별하자.

LSP, Liskov Substitution Principle 리스코프 치환 법칙 https://nesoy.github.io/articles/2018-03/LSP

• 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다. 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.
• 해결방법: 상속 관계를 제거한다. 또는 특정 메소드를 자식 클래스로 옮긴다.

ISP, Interface Segregation Principle 인터페이스 분리 법칙

• 소프트웨어 설계자는 사용하지 않는 것에 의존하지 않아야 한다

DIP, Dependency Inversion Principle 의존성 역전 법칙  

• 고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대로 의존해서는 안 된다. 대신 세부사항이 정책에 의존해야 한다.

 

2. 의미있는 이름

1. (뭘 하는 변수인지) 의도를 분명히 밝혀라
1. 존재 이유? 수행 기능? 사용 방법?
2. If문의 플래그에 조건으로 Boolean 을 반환하는 함수를 넣어도 된다 = 인자로 boolean값을 직접 사용하지 마라.
2. 오해를 일으키는 표현을 이름으로 쓰지 마라
1. 원래 있는 함수 이름, O나 l 등..
3. 의미있게 구분하라
1. source, destination 처럼
4. 의미 있는 단어를 써라 (없는 단어를 지어내지 마라)
5. 검색하기 쉬운 이름을 써라 -> 이름의 길이는 적용 범위 크기에 비례해야 한다
1. i,j 등은 작은 메소드에서 로컬 변수로만 적당함
2. 상수는 대문자로 표현해서 사용 MAX_INT 같은.
6. 인코딩을 최소화 하고(피한다)
7. 클래스 이름, 객체 이름: 명사나 명사구. 동사는 사용하지 않는다.
1. Customer, WikiPage, Account, AddressParser
2. 피할것 : Manager, Processor, Data, Info 등과 같은 단어
8. 메서드 이름: 동사, 동사구
1. postPayment, deletePage, save 등
2. get, set, is 등도 좋음 (Java)
9. 추상적인 개념 하나에 단어 하나 사용
1. Fetch, retrieve, get 중 하나 / controller, manager, driver 중 하나
2. Add와 개념이 다른 새로운 함수는 insert 또는 append가 적당

이름 짓는 요령

1. 해법 영역 이름 : queue, visitor 등
2. 해법 영역 적당한 이름이 없으면 문제에서 나온 이름을 사용한다
3. 맥락을 추가한다 (또는 접두어를 추가한다. firstName -> addFirstName)

 

3. 함수

함수: 프로그램의 가장 기본 단위

함수를 짜는 순서 - 원래 처음부터 탁! 짜내지 못한다.

1. 일단 만든다 (초안)
2. 단위 테스트를 철저하게 만든다
3. 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다.
4. 메소드 수를 줄이고 순서를 줄인다. 계속 단위테스트는 통과해야 한다.

함수를 만드는 규칙

1. 작게 만들어라
1. if, else 등의 문 안에 들어가는 내용은 한 줄이어야 한다 (헐 충격;;)

1. 한 가지만 해라
   1. ABC -> doA(), doB(), doC()  그 안에서 또 doBasicA() doAnotherA()식..
1. "함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다."
2. 한가지란? 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 하는 것. 여러 섹션으로 나누기 어렵다
2. 함수내 추상화 레벨은 모두 동일해야 한다!
1. 예: getHtml()은 추상화 수준이 높고 .append("\n")은 낮은 것
1. 코드의 내려가기 규칙: 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다.
3. 서술적인 이름을 쓸 것 (동사 + 명사 처럼) 짐작가는 이름들을 일관되게 지어라

1. 인수 - 인수 갯수는 적을 수록 좋다! (0이 최고!) 3개 이상은 가능한 피한다.
   1. 함수에 질문을 던진다. fileExists("My File")
   2. 인수를 뭔가로 변환해 결과를 반환한다 fileOpen("MyFile")
   3. 이벤트 갯수(????) passwordAttemptsFailedNtimes(int attempts)
1. 유일하게 1개 정도 괜찮은 경우 셋. 인수가 세개 정도 되면 인수를 클래스 하나로 묶어서 주는 것이 낫지 않은지 생각해본다 (예: int x, int y -> Point center)
2. 절대로 인수에 bool 값을 넘기지 마라 ㅠㅠ
3. 단일항: 동사/명사 write(name) writeField(name)
   함수에 인수를 넣는다 assertExpectedEqualsActual(expected, actual)
2. 객체를 업데이트하는 함수는함수가 속한 객체 상태를 변경하는 것이 낫다
1. appendFooter(report) 보다 report.appendFooter()이 낫다는 것.

1. 함수는 뭔가를 수행하거나, 반환을 하거나 둘 중에 하나다! (둘다 하면 안됨)
2. 에러 코드를 반환하는 것보다는 try catch 예외 처리가 낫다

1. Try catch 안에는 있는 내용을 별도 블록을 가진 함수로 처리하는 것이 낫다

 

4. 주석

• 주석은 없을 수록 좋다. 주석이 필요할때마다 생각한다 -> 코드로 표현할 방법은 없을까?

좋은 주석

1. 법적인 주석 Copyright, 라이선스 등
2. 의도를 설명하는 주석 (알고리즘 같은)
3. 경고 주석 (오래 걸린다...등)
4. TODO 주석
5. 중요성을 강조하는 주석

나쁜 주석

1. 같은 이야기를 중복하는 주석
2. 닫는 괄호에 다는 주석
3. 주석으로 처리한 코드 -> 차라리 소스 코드 관리 프로그램을 손에 익혀라 ㅜㅜ

 

5. 형식 맞추기

• 팀원끼리는 코드 형식을 맞춘다
• 개념은 빈 행으로 분리한다
• 서로 밀접한 개념은 세로로 가까이 둬야 한다 (되도록 한 파일에 둔다)
• 연관성 = 한 개념을 이해나는데 다른 개념이 중요한 정도
• Dependency(종속함수, 호출하는 함수) 가까이 두고, 호출하는 함수 아래에 호출되는 함수를 둔다
• 소스코드가 고차원에서 저차원으로 자연스럽게 내려가면서 읽힌다
• 가장 중요한 개념을 맨 위에, 간단하게 표현한다. 세세한 내용은 아래에 둔다.

 

6. 객체와 자료구조

• 클래스: 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다
• 절차적인 코드(자료구조) vs. 객체지향적인 코드
• 자료 구조를 사용하는 절차적 코드는 기본 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽고, 객체지향적인 코드는 기존 함수를 변경하지 않고도 새 클래스를 추가하기 쉽다.
• = 절자척 코드는 새 자료구조 추가가 어렵고(모든 함수를 고쳐야 하고), 객체 지향 코드는 새 함수를 추가하기 어렵다(모든 클래스를 고쳐야 한다).  ㅡㅡ?
• = 새로운 자료타입을 추가하는 유연성이 필요하면 객체를, 새로운 동작을 추가하는 유연성이 필요하면 자료구조와 절차적인 코드를 사용한다.
• 디미터 법칙 : 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙 (객체는 자료를 숨기고 함수를 공개한다 = 객체는 동작을 공개하고 자료를 숨긴다. )
• 객체는 "무엇을 한다"를 표기해야하며, 속내를 드러내면 안된다.
  예시: obj.createScratchFileStream

 

7. 오류처리

• TDD + 예외처리(try except)로 코드를 작성한다
• 확인되지 않은 오류(Unchecked error)를 사용한다 - ?
• 예외에 의미를 제공한다 (앞 뒤 context) - 실패 연산 이름, 실패 유형. 필요하다면 로깅도.
• 예외처리용 클래스를 이용한 감싸기 기법 (외부 API를 활용할때 유용하다). 비즈니스 논리와 오류 처리를 분리한다!
  : error를 내는 객체를 local 클래스 객체 하나로 감싸서, 내부에서 한번 예외 처리를 해주고, 남은 예외 처리 유형들만 밖에서 해주는 식 -> 예외 처리를 유형별로 묶어서 처리할 수 있다!

8. Boundaries 외부코드 통합할때

외부 코드를 통합시킬때 경계를 깔끔하게 처리하는 기법과 기교를 안내하는 Chapter

 

• 가능한 경계를 줄이고, 외부 코드에 dependency를 낮춘다. 방법은 캡슐화, 또는 새로운 클래스로 감싸기다.
• 새클래스: 외부 API의 객체(인스턴스)를 외부로 넘기지 않는다 (처음 처리하는 클래스 안에서만 처리하도록 한다)
• ADAPTER 패턴* - ?? 캡슐화 방법 - 설계 패턴 기법 중 하나.
• 외부 패키지 코드는 학습테스트를 해보고 (Learning Tests) 익힌다. 예상대로 도는지 검증하기 위해서.
• 추가 버전이 나왔을때도 나의 코드와 합치기 전에 호환성을 확인할 수 있다
• 아직 붙이지 않은 외부 코드를 사용해야 할때는 fake 클래스나 구현 인터페이스를 만들어서 사용한다

 

*ADAPTER 패턴 - https://jusungpark.tistory.com/22

 

 

 

9. 단위 테스트 Unit Tests

TDD 법칙 세 가지

1. 실패하는 단위테스트를 작성할때까지 실제 코드를 작성하지 않는다
2. 컴파일은 잘되지만 실행이 실패하는 정도로만 테스트 코드를 작성한다

현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다

 

• 테스트 코드에는 가독성이 중요하다. 가독성. 가독성. 가독성.
• 테스트 구조
• BUILD-OPERATE-CHECK