😀 책에서 기억하고 싶은 내용을 써보세요.
3.1 기이한 이름
- 코드를 명료하게 표현하는 데 가장 중요한 요소 하나는 바로 ‘이름'이다.
- 그래서 함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 신경 써서 이름을 지어야 한다.
- 마땅한 이름이 떠오르지 않는다면 설계에 더 근본적인 문제가 숨어 있을 가능성이 높다.
3.2 중복 코드
- 똑같은 코드 구조가 여러 곳에서 반복된다면 하나로 통합하여 더 나은 프로그램을 만들 수 있다.
- 코드가 중복되면 각각을 볼 때마다 서로 차이점은 없는지 주의 깊게 살펴봐야 하는 부담이 생긴다.
3.3 긴 함수
- 간접 호출의 효과, 즉 코드를 이해하고, 공유하고, 선택하기 쉬워진다는 장점은 함수를 짧게 구성할 때 나오는 것이다.
- 짧은 함수로 구성된 코드를 이해하기 쉽게 만드는 가장 확실한 방법은 좋은 이름이다. 함수 이름을 잘 지어두면 본문 코드를 볼 이유가 사라진다.
- 함수 이름은 동작 방식이 아닌 ‘의도(intention)’가 드러나게 짓는다.
3.5 전역 데이터
- 전역 데이터가 조금뿐이라면 감당할 수 있겠지만, 많아지면 걷잡을 수 없게 된다.
- 우리는 전역 데이터가 아주 조금만 있더라도 캡슐화하는 편이다. 그래야 소프트웨어가 진화하는 데 따른 변화에 대처할 수 있다.
3.7 뒤엉킨 변경
- 코드를 수정할 때는 시스템에서 고쳐야 할 딱 한 군데를 찾아서 그 부분만 수정할 수 있기를 바란다.
- 이렇게 할 수 없다면 뒤엉킨 변경과 산탄총 수술 중 하나가 풍긴다.
- 뒤엉킨 변경은 단일 책임 원칙(Single Responsibility Principle, SRP)이 제대로 지켜지지 않을 때 나타난다.
- 즉, 하나의 모듈이 서로 다른 이유들로 인해 여러 가지 방식으로 변경되는 일이 많을 때 발생한다.
- 예컨대 지원해야 할 데이터베이스가 추가될 때마다 함수 세 개를 바꿔야 하고, 금융 상품이 추가도릴 때마다 또 다른 함수 네 개를 바꿔야 하는 모듈이 있다면 뒤엉킨 변경이 발생했다는 뜻이다.
3.10 데이터 뭉치
- 데이터 항목들은 어린아이 같은 면이 있다. 서로 어울려 노는 걸 좋아한다. 그래서 데이터 항목 서너 개가 여러 곳에서 항상 함께 뭉쳐 다니는 모습을 흔히 목격할 수 있다.
- 이렇게 몰려 다니는 데이터 뭉치는 보금자리를 따로 마련해줘야 마땅하다.
3.12 반복되는 switch문
- 중복된 switch문이 문제가 되는 이유는 조건절을 하나 추가할 때마다 다른 switch문들도 모두 찾아서 함께 수정해야 하기 때문이다. 이럴 때 다형성은 반복된 switch문이 내뿜는 사악한 기운을 제압하여 코드베이스를 최신 스타일로 바꿔주는 세련된 무기인 셈이다.
3.15 추측성 일반화
- 이 냄새는 ‘나중에 필요할 거야'라는 생각으로 당장은 필요 없는 모든 종류의 후킹 포인트와 특이 케이스 처리 로직을 작성해둔 코드에서 풍긴다.
- 그 결과는 물론 이해하거나 관리하기 어려워진 코드다.
- 당장 걸리적거리는 코드는 눈앞에서 치워버리자.
3.17 메시지 체인
- 클라이언트가 한 객체를 통해 다른 객체를 얻은 뒤 방금 얻은 객체에 또 다른 객체를 요청하는 식으로, 다른 객체를 요청하는 작업이 연쇄적으로 이어지는 코드를 말한다. ex) managerName = aPerson.department.manager.man;
3.22 데이터 클래스
- 데이터 클래스란 데이터 필드와 게터/세터 메서드로만 구성된 클래스를 말한다.
- 그저 데이터 저장 용도로만 쓰이다 보니 다른 클래스가 너무 깊이까지 함부로 다룰 때가 많다.
- 이런 클래스에 public 필드가 있다면 누가 보기 전에 얼른 레코드 캡슐화하기 로 숨기자. 변경하면 안되는 필드는 세터 제거하기 로 접근을 원천 봉쇄한다.
3.24 주석
- 주석은 악취가 아닌 향기를 입힌다. 문제는 주석을 탈취제처럼 사용하는데 있다.
- 주석이 장황하게 달린 원인이 코드를 잘못 작성했기 때문인 경우가 의외로 많다.
- 주석을 남겨야겠다는 생각이 들면, 가장 먼저 주석이 필요 없는 코드로 리팩토링해본다.
🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
- 3.4 긴 매개변수 목록에서 매개변수 객체 만들기는 DTO 객체를 만들어서 서비스단으로 전달하는 것과 같다고 생각했습니다.
- 세터를 줄이는 이유가 가변 데이터의 유효범위를 줄이기 위한다는 걸 알게 되었습니다.
- 3.17 메시지 체인은 클린코드에서도 봤던 기차충돌 코드와 똑같았습니다.
- 확실히 메시지 체인 방식의 코드는 가독성을 확 낮춰줍니다.
🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- 주석을 어떻게 하면 잘 달 수 있을까?
- 각자의 스타일이 달라서 제 기준에 주석을 많이 다는 사람도 봤습니다. 어떤게 정답인지 모르겠지만, 저는 이 책에 나오는 얘기처럼 코드에 최대한의 정보를 담고 거기에 담지 못한 정보를 주석으로 남겨야 한다고 생각합니다.
반응형
'독서 > 리팩터링' 카테고리의 다른 글
| [리팩터링] 챕터06. 기본적인 리팩터링(6 - 1 함수 추출하기) (0) | 2022.05.26 |
|---|---|
| [리팩터링] 챕터05. 리팩터링 카탈로그 보는 법 (0) | 2022.05.25 |
| [리팩터링] 챕터04. 테스트 구축하기 (0) | 2022.05.24 |
| [리팩터링] 챕터02. 리팩터링 원칙 (0) | 2022.05.23 |
| [리팩터링] 챕터01. 리팩터링: 첫 번째 예시 (0) | 2022.05.21 |
