8장 기능 이동

[choisohyun]

인상깊었던 책의 내용과 인상깊었던 이유
현업 등 코드에 반영할 수 있는 방법과 생각
관련 아티클이나 이해를 돕는 자료를 첨부
새롭게 알게된 점이나 이해가 어려웠던 점

[RAINBOWJYP]

리팩터링할 때 반복문 안에 2가지 이상의 일을 하고 있는 경우 반복문을 쪼개는 것이 좋겠다. 반복문이 2번 실행되어 병목현상이 발생되는 일은 드물다고 한다. 만약 병목현상이 일어나는 경우 하나로 합치는 것은 쉬울 것이다.
죽은 코드가 자리를 잡고 있는 경우가 많은데 언젠가 쓰일지도 몰라 라는 생각으로 방치하지말고 과감하게 지워보자!
리팩터링 기법중 함수옮기기, 필드 옮기기는 클래스에 익숙하지 않아 이론적으로 쉽게 이해되진 않았다. 실습이 필요하다!!

[choisohyun]

좋은 소프트웨어 설계의 핵심은 모듈화가 얼마나 잘 되어 있느냐를 뜻하는 모듈성이다.
모듈성이란 프로그램의 어딘가를 수정하려 할 때 해당 기능과 깊이 관련된 작은 일부만 이해해도 가능하게 해주는 능력이다.

이번 챕터의 핵심은 첫 부분에 나와 있는 것 같습니다. 모듈성이라는 말이 인상깊고 작은 일부만 이해해도 기능을 이해하게 해주는 코드를 만들기 위해 리팩터링을 진행한다는 점을 되새겼습니다.

[hamo-o]

8.7 반복문 쪼개기 - 반복문을 두 번 실행해야 하므로 이 리팩터링을 불편해하는 프로그래머도 많다. 하지만 최적화는 리팩터링 이후에 수행하자. 반복문을 두 번 실행하는 게 병목이라 밝혀지면 그때 다시 합칠 수 있다.

실제로 O(N)으로 해결될 문제를 O(2N)으로 시간복잡도를 늘린다는 것이 찝찝해서 최대한 하나의 순회에서 작업을 하려고 노력했습니다. 하지만 가독성과 다른 데이터 구조를 사용해야 한다는 점에서 불리한 점들이 많다는 것을 배웠습니다. 최적화와 리팩터링을 구분해서 생각해야 한다는 점을 명심해야겠습니다.

---

8.3 문장을 함수로 옮기기 - 어떤 함수를 호출하는데 항상 같은 로직이 따라붙는다면? 반복되는 부분을 피호출 함수로 합칠 수 있다.

반복되는 부분을 피호출 함수로 합치기에는 부적절하지만, 일부 코드에서 함수 호출 앞뒤로 특정 로직이 반복되는 경우가 있었습니다. 반복 부분을 옮기기에는 애매해서 그냥 두었는데, 반복되는 부분과 함수 호출 부분을 통째로 새로운 함수로 추출하는 방법이 있다는 것을 배웠습니다.

[blan19]

단순히 코드 블록, 문장의 순서를 바꾸는 것만으로도 전체 맥락을 이해하기가 훨씬 쉬워지는게 체감이 되었습니다.

p310. 관련 코드끼리 모으는 작업은 다른 리팩터링(주로 함수 추출하기; 6.1절)의 준비 단계로 자주 행해진다. 관련 있는 코드들을 명확히 구분되는 함수로 추출하는 게 그저 문장들을 한데로 모으는 것보다 나은 분리법이다. 하지만 코드들이 모여 있지 않다면 함수 추출은 애초에 수행할 수조차 없다.

// before
const condition = 0;
let foo = "foo";
let bar = "bar";

while(condition + 3 > 0) {
 ...
}

// after
let foo = "foo";
let bar = "bar";
const condition = 0;

while(condition + 3 > 0) {
 ...
}

단순하게 condition 변수의 위치만 바꿨는데도 읽기가 편해지고 흐름을 이해하기가 편해졌습니다.
코드를 작성할 때, 코드 맥락의 관계를 생각하고 유지하는 선에서 작성하면 좋을 것 같습니다

위와 같이 문장 한 장을 옮기는 것이 문장 교환하기라고 하네요 .

[wook-hyung]

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

함수를 추상화의 경계를 결정 짓는 하나의 단위라고 볼 수 있을 것 같습니다.
책의 예제처럼 일부 호출자에게 다르게 동작해야 하는 함수가 있을 경우, 그 동작을 함수의 시작 혹은 끝으로 옮긴 다음, 호출한 곳으로 코드를 단계적으로 옮기면서 리팩토링 하게 되면 더 적합한 경계로 재설정 되면서도 안전하게 리팩토링이 가능할 것 같습니다.

[LastCow9000]

관련된 기능들을 잘게 쪼개고, 묶고, 이동하여 응집도 높게 모듈화를 하는 것이 결국엔 가독성을 높일 수 있다는 것을 배웠습니다. 특히 변수 선언을 함수 첫머리에 모아두는 편이었는데 처음 사용할 때 선언하는 것이 여러 방면에서 좋다는 것을 알 수 있었습니다.

[suojae]

1. 결국 프로그래밍은 무언가 문제를 해결한다는 것인데 문제를 해결함에 있어 주제별로 작게 문제를 쪼개서 인풋-아웃풋으로 하나씩 해결해나가는 것이라 응집도와 모듈성이 중요하다.
2. 이때 큰 문제를 풀기위해 쪼개고 쪼갠 가장 작은 단위는 함수이며 각 함수는 저마다의 문맥을 지니고 있다. (oop에서는 보통 class)
3. 파이프라이닝하라는 부분이 인상적이었다. 어떻게 하는지 스텝바이스텝으로 너무 친절해서 바로 파이프라이닝 리팩토링해보고 싶다는 생각이 들었다.