-
우리가 클린코드를 추구하는 이유 코드가 잘 읽힌다 = 이해가 잘된다 = 유지보수 하기가 수월하다 = 우리의 시간과 자원이 절약된다 클린코드라 지칭하는 수많은 원칙들, 조언들 => 당연히 지키면 좋다, 왜? 클린코드를 관통하는 아주 중요한 주제 => 추상
-
프로그램의 정의
- 프로그램 = 데이터 + 코드
- 데이터 자체가 추상화 레벨을 가지고 있다.
- 데이터가 식재료라면 코드는 요리방법이다.
- 추상과 구체
- 추상 : 뽑을 추, 코끼리 상 => 중요한 정보는 가려내어 남기고, 덜 중요한 정보는 생략하여 버린다.
- 구체 <-> 추상
- 추상화 레벨 : 구체에서 추상으로 가는 과정의 레벨
- 고수준 : 추상화 레벨이 높다 => 저수준 : 추상화 레벨이 낮다 Ex) 기계어 => 프로그래밍 언어 / 하드웨어 => 운영체제 => 애플리케이션
- 적절한 추상화는 복잡한 데이터와 복잡한 로직을 단순화하여 이해하기 쉽도록 돕는다.
- 추상으로부터 구체를 유추하지 못하는 경우
- 추상화 과정에서 중요한 정보를 부각시키지 못했다
- 해석자가 동일하게 공유하는 문맥(Context)이 없다
- 서로 다른 도메인에서는 전혀 다르게 해석될수 있다.
- 잘못된 추상화가 야기하는 side effect 는 정말 크다
- 적절한 추상화는 해당 도메인의 문맥 안에서 정말 중요한 핵심 개념만 남겨서 표현하는 것
- 이름 짓기
- 이름을 짓는다는 행위는, 추상적 사고를 기반으로한다. => 가장 단순하면서도, 아주 중요한, 고도의 추상적 사고 행위
- 표현하고자 하는 구체에서 정말 중요한 핵심 개념만을 추출하여 잘 드러내는 표현
- 우리 도메인의 문맥 안에서 이해되는 용어
- 단수와 복수를 구분하기
- 이름 줄이지 않기
- 좋은 코드를 보고 습득하기
- ex. pool, candidate, threshold
- 메서드와 추상화
- 잘 쓰여진 글이라면, 한 문단의 주제는 반드시 하나다 => 잘 쓰여진 코드라면, 한 메서드의 주제는 반드시 하나다.
- 메서드 선언부
- 메서드 선언부 = 반환타입 메서드명 (파라미터) {메서드 구현부}
- 메서드 시그니처 = 메서드명 (파라미터)
- 메드명
- 추상화된 구체를 유추할 수 있는, 적절한 의미가 담긴 이름
- 파라미터와 연결지어 더 풍부한 의미를 전달할 수도 있다.
- 파라미터
- 파라미터의 타입, 개수, 순서를 통해 의미를 전달 🌟
- 파라미터는 외부 세계와 소통하는 창
- 반환타입
- 메서드 시그니처에 납득이 가는, 적절한 타입의 반환값 돌려주기 -> 반환 타입이 boolean인데, 이게 이 메서드에서 무엇을 의미하는거지?
- void 대신 충분히 반환할 만한 값이 있는지 고민해보기 -> 반환값이 있다면 테스트도 용이해 진다.
- 추상화 레벨
- 하나의 세계 안에서는, 추상화 레벨이 동등해야 한다.
- 추상화 레벨을 주변과 동등하게 해야한다.
- 메서드를 추출한다는 의미는 로직이 길어서 줄이기 위해서나 메서드 자체에 의미를 부여하기 위해서도 있지만 중요한건 추상화 레벨을 동등하게 맞춰줌으로써 코드를 읽는 사람의 사고가 자연스럽게 흘러갈수 있도록 하는것이다.
- 뇌 메모리 적게 쓰기
- 뇌는 한가지 일만 할수있다.(멀티태스킹이 된다는 것은 일처리의 전환이 빠르다는것)
- 뇌 메모리에 적게 올릴수록 당연히 읽기 좋은 코드가 된다.
- Early return
- else의 사용을 지양
- 사고의 depth 줄이기
- 중첩 분기문, 중첩 반복문
- 무조건 1depth로 만들어라 가 아니다. => 보이는 depth를 줄이는 데에 급급한 것이 아니라, 추상화를 통한 사고 과정의 depth를 줄이는 것이 중요 => 2중 중첩 구조로 표현하는 것이 사고하는 데에 더 도움이 된다고 판단한다면, 메서드 분리보다 그대로 놔두는 것이 더 나은 선택일 수 있다. 때로는 메서드를 분리하는 것이 더 혼선을 줄 수도 있다.
- 사용할 변수는 가깝게 선언하기