티스토리 뷰

반응형

마틴 파울러 - 리팩터링 (2판)  의 1,2장 내용 중 기억하고 싶은 것 기록 ✏️✏️

 

 

[1] 리팩터링하는 이유 

 

리팩터링의 궁극적인 목적인

개발 속도를 높여서 더 적은 노력으로 더 많은 가치를 창출하는 것이다. 

 

 

아래 그래프처럼 내부 설계가 잘 된 소프트웨어는

새로운 기능을 추가할 지점과 어떻게 고칠지를 쉽게 찾을 수 있다. 

 

 

사람들이 빠지기 쉬운 가장 위험한 오류는 리팩터링을 '클린코드'나 '바람직한 엔지니어링 습관' 처럼 도덕적인 이유로 정당화하는 것이다. 

리팩터링은 오로지 경제적인 이유로 하는 것이다. (개발 기간 단축, 기능 추가 시간 단축, 버그 수정 시간 단축)

스스로 이렇게 인식하고 다른 사람과 대화할 때도 이 점을 명심하라.

리팩터링하도록 이끄는 동력은 어디까지나 경제적인 효과에 있다. 

 

이를 명확히 이해하는 개발자, 관리자, 관리자, 고객이 많아질 수 록 '좋은 설계' 곡선을 더 많이 볼 수 있다. 

 

 

 

[2] 리팩터링 원칙 

 

1. 리팩터링의 첫 단계는 리팩터링할 코드 영역을 꼼꼼히 검사해줄 테스트 코드들을 마련하는 것이다. 

 

디지털 시대의 연약한 자여, 그대 이름은 소프트웨어

 

 

2. 리팩터링하는 절차의 핵심은 조금씩 변경하고 매번 테스트하는 것이다. 

 

 

각 단계를 굉장히 잘게 나누고 매번 컴파일하고 테스트하여 작동하는 상태로 유지한다.

 

리팩터링을 효과적으로 하는 핵심은

단계를 잘게 나눠야 더 빠르게 처리할 수 있고

코드는 절대 깨지지 않으며

이러한 작은 단계들이 모여서 상당히 큰 변화를 이룰 수 있다는 사실을 깨닫는 것이다. 

 

리팩터링 하는 동안에는 코드가 항상 정상 작동하기 때문에 전체 작업이 끝나지 않았더라도 언제든 멈출 수 있다.

 

누군가가 리팩터링하다가 코드가 깨져서 며칠이나 고생했다 라고 한다면, 십중팔구 리팩터링한 것이 아니다. 

 

아무리 간단한 수정이라도 리팩터링 후에는 항상 테스트하는 습관을 들이는 것이 바람직하다.

한가지를 수정할 때마다 테스트하면 오류가 생기더라도 변경 폭이 작기 때문에

살펴볼 범위도 좁아서 문제를 찾고 해결하기 훨씬 쉽다. 

 

 

 

>>

1장에서 저자가 직접 리팩터링하는 예제를 보여주시는데

정말 작은 단계로 나눠서 '컴파일-테스트-커밋' 의 리팩터링 리듬을 계속 유지해가신다.

마틴파울러 같은 거장분도 이렇게 작게 작게 고치고 돌려보고 하시다니..🥸.🥸

 

 

 

반응형
댓글