리팩터링 2판 1장 - 첫 번째 예시 2탄

1탄을 작성하기 위해 2시간 가량 집중해서 정독했는데 느낀점은 지금까지 나는 어떻게 코드를 짰던걸까? 하는 의문점이 들었다..기능을 돌아가게 하는것도 중요하지만 리팩터링을 하며 수정이 용이하고 확장 가능한 설계를 하는것이 얼마나 중요한가를 깨닫게 되었다. 정확하게는 리팩터링은 어떻게 하는것인가의 기준이 생기기 시작했다.

 

2탄의 시작은 책 내용 기준 1.5 중간 점검: 난무하는 중첩 함수부터이다.

 

지금까지는 프로그림의 논리적인인 요소를 파악하기 쉽도록 코드의 구조를 보강하는데 주안점을 두고 리팩터링을 했다면 이제 HTML 버전을 만드는 작업을 살펴보자

=> 해당 부분은 텍스트로만 봤을 때는 이해가 잘안되었다. 

 

• 계산 코드가 분리됐다:
  데이터 처리나 비즈니스 로직 같은 복잡한 계산 작업은 별도의 파일이나 함수로 정리되어 있다는 의미입니다.
  즉, HTML을 작성할 때는 **"화면에 표시할 데이터만 신경 쓰면 된다"**는 뜻입니다.
• HTML 코드만 작성하면 된다:
  계산된 결과를 기반으로 UI를 출력하는 역할만 수행한다는 의미입니다. UI 코드에 로직이 섞이지 않으므로 간단한 구조로 유지할 수 있습니다.

즉 나는 react를 사용해왔기 때문에 선언형프로그램에 익숙해져있어서 당연하게 사용해왔던 것이다. 그럼 이참에 한번 집고 넘어가면 좋겠다.

 

1. 명령형 프로그래밍(JavaScript의 기본 방식)

명령형 프로그래밍에서는 개발자가 UI를 업데이트하기 위한 모든 단계를 명시적으로 작성해야 합니다.

예: 클릭 카운트를 증가시키는 기능

javascript
코드 복사
let count = 0; // 요소 가져오기
const button = document.querySelector("#button");
const display = document.querySelector("#display");
// 클릭 이벤트 핸들러 추가
button.addEventListener("click", () => {
count += 1;
// 상태를 업데이트
display.textContent = `Count: ${count}`;
// UI를 업데이트 });

• 여기서 중요한 점:
  • count라는 상태를 수동으로 관리해야 합니다.
  • DOM 요소(display)를 직접 가져와야 하며, 상태가 변경될 때마다 명령을 내려 UI를 갱신해야 합니다.
  • 모든 동작이 명시적으로 작성되어야 하므로 코드가 장황해지고, 복잡한 애플리케이션에서는 관리가 어려워질 수 있습니다.

---

2. 선언형 프로그래밍(React의 접근 방식)

React는 선언형 방식을 사용하여 상태와 UI를 자연스럽게 연결합니다.
개발자는 **"무엇을 렌더링할지"**에만 집중하면 되고, UI 갱신은 React가 알아서 처리합니다.

동일한 예를 React로 작성하면:

jsx

코드 복사
import React, { useState } from "react"; 
const App = () => {
const [count, setCount] = useState(0); 

return ( <div> <p>Count: {count}</p>
<button onClick={() => setCount(count + 1)}>Click Me</button> 
</div> ); };

여기서 중요한 점:

• count 상태를 관리하면 React가 DOM을 자동으로 갱신합니다.
• UI 갱신 로직을 명시적으로 작성하지 않아도 됩니다.
• 코드는 간결하고 직관적입니다.

 

---

3. 명령형 vs 선언형 비교

특징 명령형 (JavaScript) vs 선언형 (React)

초점	"어떻게 할지(How)"를 명시적으로 작성	"무엇을 할지(What)"를 선언적으로 정의
UI 갱신 방식	DOM을 직접 조작	상태를 기반으로 UI 자동 갱신
코드 가독성	복잡하고 장황해질 수 있음	간결하고 직관적
유지보수성	상태와 UI 갱신 로직이 분리되지 않아 관리 어려움	상태와 UI를 독립적으로 관리 가능
적용 예	순수 JavaScript, jQuery 등	React, Vue.js, Angular (선언형 프레임워크)

---

4. 결론

일반 JavaScript는 명령형 프로그래밍 스타일에 기반을 두고 있습니다. 이는 단순한 작업에는 적합하지만, 복잡한 애플리케이션에서는 관리와 유지보수가 어려울 수 있습니다. React는 선언형 스타일을 통해 UI 갱신과 상태 관리를 자동화하여, 코드를 더 간결하고 직관적으로 작성할 수 있게 도와줍니다. 따라서 React와 같은 선언형 프레임워크는 명령형 JavaScript의 단점을 극복하기 위해 등장했다고 볼 수 있어요. 😊 생각해보면 버츄얼돔의 사용이 엄청난 변화가 맞는거같다.

 

하지만 지금은 공부를 하는 단계임으로 전부다 파헤쳐보겠다.

 

책에서 얘기하는건 텍스트 버전과 (api, db 저장, 텍스트 출력 등), HTML 버전을 똑가은 계산 함수로 사용하게 만들고 싶다고 나와있다. 선호하는 방식은 단계쪼개기!

 

1. 두 단계로 나누는 것이다. 첫 단계에서는 statement() 즉 최상단 함수의 데이터를 처리하고 다음 단계는 앞서 처리한 결과를 텍스트느 HTML로 표현하자 단계를 쪼개려면 중첩 함수들을 함수 추출하기로 뽑아내야된다.

2. 본문 전체를 별도 함수로 추출하고 두 단계 사이의 중간 데이터 구조 역할을 할 객체를 만들어서 인수로 전달한다. 즉  2개의 매개변수를 전달할 필요가 없음으로 statementData = invoice.customer 이런식으로 하나로 통합시킨다.

react에서 useState 사용 data 객체를 통일시키는것과 비슷한거같다. ( 불필요한 매개변수를 줄이면 함수의 사용이 단순해지고, 읽기와 이해가 쉬워진다.)

3. 함수 옮기기! 

중첩함수였던 playfor을 최상단으로 옮김 

statementData.performances = invice.performance.map(enrichPerformance)


function enrichPerformance (aPerformance) {
	const result = Object.assign({}, aPerformance) // 얕은 복사 수행 (불변성) 원시값만 변경
	....
    result.play = playfor(result) 
    return result
}

4. 위처럼 변수의 인라인을 객체를 생성하여 저장시킴으로써  statementData {} 안에 play, amount, volumeCredits 등등을 객체로 추가할 수 있다. 그럼 statement 최상위 함수에서 statementData set이 형성되고 매개변수로 전달했을 때 데이터만 가져와서 사용 가능

5. 그러면 아래와 같이 첫 단계인 statement에 필요한 데이터 처리에 해당하는 코드를 모두 별도 함수로 빼낸다.