ch08

⬅️ 7장 | 9장 ➡️

8장 기능 이동

• 8.1 함수 옮기기
• 8.2 필드 옮기기
• 8.3 문장을 함수로 옮기기
• 8.4 문장을 호출한 곳으로 옮기기
• 8.5 인라인 코드를 함수 호출로 바꾸기
• 8.6 문장 슬라이드하기
• 8.7 반복문 쪼개기
• 8.8 반복문을 파이프라인으로 바꾸기
• 8.9 죽은 코드 제거하기

Note

'기능 이동' 챕터는 다음 질문을 중심으로 읽어나가시면 좋습니다.

1. 무엇을 기준으로 요소를 옮겨야 하는가
2. 어떻게 모듈성 또는 응집도를 높일 수 있는가
3. 어떤 데이터 구조가 자연스러운 코드를 이끌어내는가

8.1 함수 옮기기

p.278

1. 좋은 소프트웨어 설계의 핵심은 모듈화가 얼마나 잘 되어 있느냐를 뜻하는 모듈성이다. 모듈성이란 프로그램의 어딘가를 수정하려 할 때 해당 기능과 깊이 관련된 작은 일부만 이해해도 가능하게 해주는 능력이다. 모듈성을 높이려면 서로 연관된 요소들을 함께 묶고, 요소 사이의 연결관계를 쉽게 찾고 이해할 수 있도록 해야 한다.
2. 모든 함수는 어떤 컨텍스트 안에 존재한다. 객체지향 프로그래밍의 핵심 모듈화 컨텍스트는 클래스다.

p.279

1. 함수를 옮길지 말지를 정하기란 쉽지 않다. 그럴 땐 대상 함수의 현재 컨텍스트와 후보 컨텍스트를 둘러보면 도움이 된다. 대상함수를 호출하는 함수들은 무엇인지, 대상 함수가 호출하는 함수들은 또 무엇이 있는지, 대상 함수가 사용하는 데이터는 무엇인지를 살펴봐야 한다.

8.2 필드 옮기기

p.289

1. 프로그램의 상당 부분이 동작을 구현하는 코드로 이뤄지지만 프로그램의 진짜 힘은 데이터 구조에서 나온다. 주어진 문제에 적합한 데이터 구조를 활용하면 동작 코드는 자연스럽게 단순하고 직관적으로 짜여진다. 반면 데이터 구조를 잘못 선택하면 아귀가 맞지 않는 데이터를 다루기 위한 코드로 범벅이 된다.
2. 가장 적합한 데이터 구조를 알아내고자 프로젝트 초기에 분석을 해본 결과, 경험과 도메인 주도 설계 같은 기술이 내 능력을 개선해줌을 알아냈다. 프로젝트를 진행할수록 우리는 문제 도메인과 데이터 구조에 대해 더 많은 것을 배우게 된다.

p.290

1. 한 레코드를 변경하려 할 때 다른 레코드의 필드까지 변경해야만 한다면 필드의 위치가 잘못되었다는 신호다.
2. 클래스의 데이터들은 접근자 메서드들 뒤에 감춰져(캡슐화되어) 있으므로, 클래스에 곁들여진 함수(메서드)들은 데이터를 이리저리 옮기는 작업을 쉽게 해준다.

p.293

1. 날레코드 변경하기 : 이 리팩터링은 대체로 객체를 활용할 때가 더 수월하다. 캡슐화 덕에 데이터 접근을 메서드로 자연스럽게 감싸주기 때문이다.
2. 이럴 때는 접근자 함수들을 만들고, 날 레코드를 읽고 쓰는 모든 함수가 접근자를 거치도록 고치면 된다.

💡의견

1. DDD(Domain-Driven Design)
   • MSA처럼 기능별로 나누는 것이 백엔드에서의 DDD, 아키텍쳐 별로 나누는 게 (프로덕션을 특정 도메인 단위로 스토어나 컴포넌트를 묶는것) 프론트사이드의 DDD

8.3 문장을 함수로 옮기기

p.296

1. 중복제거는 코드를 건강하게 관리하는 가장 효과적인 방법 중 하나다. 이렇게 해두면 추후 반복되는 부분에서 무언가 수정할 일이 생겼을 때 단 한 곳만 수정하면 된다.

8.4 문장을 호출한 곳으로 옮기기

p.301

1. 함수는 프로그래머가 쌓아 올리는 추상화의 기본 빌딩 블록이다. 코드베이스의 기능범위가 달라지면 추상화의 경계도 움직이게 된다. 함수 관점에서 생각해보면, 초기에는 응집도 높고 한가지 일만 수행하던 함수가 어느새 둘 이상의 다른 일을 수행하게 바뀔 수 있다는 뜻이다.

8.5 인라인 코드를 함수 호출로 바꾸기

p. 308

1. 함수의 이름이 코드의 동작 방식보다는 목적을 말해주기 때문에 함수를 활용하면 코드를 이해하기가 쉬워진다.
2. 말이 되지 않는다면 함수 이름이 적절하지 않거나(함수 이름을 바꿔주자), 그 함수의 목적이 인라인 코드의 목적과 다르기 때문일 것이다(따라서 함수 호출로 대체하면 안 된다.)

p.309

1. 사용 중인 프로그래밍 언어의 표준 라이브러리나 플랫폼(혹은 프레임워크나 안정화된 서드파티 라이브러리 등)이 제공하는 API를 잘 파악하고 있을수록 이번 리팩터링의 활용 빈도가 높아질 것이다.

💡의견

1. UI 컴포넌트 라이브러리(framework) 사용
   • MUI, Vuetify, Element, Ant Design,
   • 라이브러리를 사용하기도 하고 직접 만들어서 쓰기도 함.
   • back office를 제외하고는 컴포넌트 엘리먼트를 거의 만들어서 씀.
   • 가져다가 쓸 때도 커스텀이 가능한지 기술 조사를 통해 엄격하게 판단, 심사함.
   • 직접 만드는 경우 사내 디자인 시스템 또는 스토리북을 통해 공유함.
   • Ant Design은 커스터마이징이 너무 어려워 특히 외부에 공개하는 서비스에는 사용을 추천하지 않음.
   • Vuetify라는 라이브러리에 종속되어 Vue 2에서 Vue 3로 마이그레이션하지 못하기도 하므로 라이브러리 도입 시 신중해야 함.
2. vue2 vs vue3
   • Vue 3 변경점 정리: 무엇이 바뀌나요?

8.6 문장 슬라이드하기

p.310

1. 예컨대 하나의 데이터 구조를 이용하는 문장들은(다른 데이터를 이용하는 코드 사이에 흩어져 있기보다는) 한데 모여 있어야 좋다. 실제로 나는 문장 슬라이드하기 리팩터링으로 이런 코드들을 한데 모아둔다. 가장 흔한 사례는 변수를 선언하고 사용할 때다.

p.311

1. 요소를 선언하는 곳과 사용하는 곳을 가까이 두기를 좋아하는 나는 선언 코드를 슬라이드하여 처음 사용하는 곳까지 끌어내리는 일을 자주 한다.

💡의견

1. 변수를 사용하는 곳과 가깝게 선언해야 하는지?
   • 클린코드에서는 그렇게 말했으나, 정답이 없는 것 같음.
   • 코드가 너무 길어져 변수 선언부가 너무 멀어진다 싶으면 해당 컴포넌트에서 훅으로 빼거나 컴포넌트를 분리시켜서 해결할 수 있음.
   • 클린코드라는 것은 팀원들간의 정의라고 생각함.

8.7 반복문 쪼개기

p.316

1. 종종 반복문 하나에서 두 가지 일을 수행하는 모습을 보게 된다. 그저 두 일을 한꺼번에 처리할 수 있다는 이유에서 말이다. 하지만 이렇게 하면 반복문을 수정해야 할 때마다 두 가지 일 모두를 잘 이해하고 진행해야 한다. 반대로 각각의 반복문으로 분리해두면 수정할 동작 하나만 이해하면 된다.

💡의견

1. 깃 사용시 command vs gui
   • 취향 차이.
2. 반복문을 쪼개기보다 오히려 나뉘어 있으면 합치려고 할 것 같다.
   • 반복문을 함수로 분리하는 리팩터링까지 진행한다면 함수 하나당 하나의 역할만 하므로 적절해 보인다.
   • 데이터 개수가 작은 경우는 쪼개는 것이 좋고 많은 경우는 합치는 것이 좋을 것 같다.

8.8 반복문을 파이프라인으로 바꾸기

p.320

1. 컬렉션 파이프라인을 이용하면 처리 과정을 일련의 연산으로 표현할 수 있다.

8.9 죽은 코드 제거하기

p.327

1. 사용되지 않는 코드가 있다면 그 소프트웨어의 동작을 이해하는 데는 커다란 걸림돌이 될 수 있다.
2. 코드가 더 이상 사용되지 않게 됐다면 지워야한다.

⬅️ 7장 | ⬆️ 위로 | 9장 ➡️