개요
유명한 책이라 작년 여름쯤 사서 읽어보다가 말았다.
짧게 읽었는데도 도움이 되는 내용들이 많았다.
최근에 프로젝트를 진행하면서 다시 한 번 필요성을 느꼈고 틈틈히 읽어가기로 했다.
책에도 적혀있던데 "나중은 없다."
조금씩이라도 지금 해나가야 한다.
아래부터는 책을 읽으면서 기록해두고 싶은 내용들을 정리해본 것이다.
내용
이 책에서는 깨끗한 변수 이름, 깨끗한 함수, 깨끗한 클래스를 만드는 방법을 소개한다.
좋은 코드도 소개하고 나쁜 코드도 소개한다. 나쁜 코드를 좋은 코드로 바꾸는 방법도 소개한다.
10pg, 나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다. 깨끗한 코드는 한 가지에 집중한다. 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한 길만 걷는다.
11pg, 깨끗한 코드란 다른 사람이 고치기 쉽다고 단언한다. 실제로 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다.
12pg, 아무리 코드가 우아해도, 가독성이 높아도, 테스트 케이스가 없으면 깨끗하지 않다.
14pg, 중복을 피하라, 한 기능만 수행하라, 제대로 표현하라, 작게 추상화하라. 이 책 내용을 요약했다.
- 표현력
표현력은 의미 있는 이름을 포함한다. 뿐만 아니라
객체가 여러 기능을 수행한다면 여러 객체로 나눈다. 메서드가 여러 기능을 수행한다면 메서드 추출(Extract Method) 리팩터링 기법을 적용해 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메서드 여러개로 나눈다.
15pg, 읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드다.
22pg, 변수나 함수, 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다.
변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
헷갈릴 수 있는, 애매한 이름을 사용하지 마라.
27pg, 발음하기 쉬운 이름을 사용하라
28pg, 검색하기 쉬운 이름을 사용하라. 이런 관점에서 긴 이름이 짧은 이름보다 좋다.
30pg,
phoneString 같은 변수명은 타입이 바뀌어도 이름은 바뀌지 않아서 읽기 어렵고 오도할 가능성도 커진다.
이제는 멤버 변수에 m_이라는 접두어를 붙일 필요도 없다. 클래스와 함수는 접두어가 필요 없을 정도로 작아야 마땅하다.
32pg,
클래스 이름과 객체 이름은 명사나 명사구가 적합하다. Customer, WikiPage 등이 좋은 예다.
메서드 이름은 동사나 동사구가 적합하다. postPayment, deletePage 등이 좋은 예다.
접근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.
33pg, 한 개념에 한 단어를 사용하라. 예를 들어 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다. 예를 들어 지금까지 구현한 add 메서드에서는 기존 값을 더하는 개념이었고, 새로 작성하는 메서드에서는 집합에 값 하나를 추가하는 것이라면 insert나 append라는 이름이 적당할 것이다.
느낀점
주석을 단다는 건 의도를 분명히 드러내지 못했다는 내용이 눈에 들어왔다.
이름 잘 짓는 게 중요하다는 말에도 공감을 했다. 이름을 명확히 안 지으니까 다른 것들이랑 헷갈려서 작업을 하다가 계속 멈칫하고 돌아보게 되는 일이 많았기 때문이다.
적용
책을 읽으면서 조금씩이라도 리팩토링을 해보기로 했다.
현재 작업하고 있는 프로젝트에서 한 함수 안에 여러 기능이 길게 적혀진 부분이 있었는데
세부 기능별로 함수를 쪼개보았다. 아래 링크는 구체적인 커밋 내역이고
결과물은 아래와 같다.
private fun drawCourse() {
createDepartureMarker()
createRouteMarker()
deleteRouteMarker()
}
'독서 > Clean Code' 카테고리의 다른 글
클린코드(~45pg) (0) | 2023.03.15 |
---|