01_리팩터링-첫 번째 예시

리팩터링 2판을 보며 정리한 내용입니다.

1.2 예시 프로그램을 본 소감

• 나는 수백줄짜리 코드를 수정할 때면 먼저 프로그램의 작동 방식을 더 쉽게 파악할 수 있도록 코드를 여러함수와 프로그램 요소로 재구성한다.
• 구조가 빈약하다면 구조부터 바로잡은 뒤에 기능을 수정하는 편이 작업하기가 훨씬 수월하다.(선: 리팩토링, 후: 기능추가)
• 잘 작동하고 나중에 변경할 일이 절대 없다면 코드를 현재 상태로 놔둬도 아무런 문제가 없다.

1.3 리팩터링이 첫 단계

• 먼저 테스트 코드부터 마련해야한다.
• 테스트를 작성하는 데 시간이 좀 걸리지만, 신경 써서 만들어두면 디버깅 시간이 줄어서 전체 작업 시간은 오히려 단축된다. (→ 4장)(아무리 간단한 수정이라도 리팩터링 후에는 항상 테스트하는 습관!)

1.4 statement()함수 쪼개기

• 반복문 쪼개기 → 변수값을 누적시키는 부분을 분리합니다.
• 문장 슬라이드 → 변수 초기화 문장을 변수값 누적 코드 바로앞으로 옮긴다.
• 함수 추출하기 → 적립 포인트 계산 부분을 별도 함수로 추출한다.
• 변수 인라인 하기 → 로컬 변수(임시변수) 제가하기
• 전체 동작을 각각의 부분으로 나눌 수 있는 지점을 찾는다. → switch
• (함수 반환값 - result라는 이름 사용)
• 컴퓨터가 이해하는 코드는 바보도 작성할 수 있다.
• 사람이 이해하도록 작성하는 프로그래머가 진정한 실력자다.
• 좋은 코드라면 하는 일이 명확히 드러나야 함 → 변수 이름 중요!
• 로컬변수 제거 → 추출 작업이 훨씬 쉬워진다는 장점
• 반복문이 쪼개서 성능 느려진다? 미미함
• 만약 성능이 느려진다면, 리팩토링 후 성능개선하는 것이 효과적따라서 특별한 경우가 아니면 무시하라

1.7 중간 점검: 두 파일(과 두 단계)로 분리됨

• 리팩토링후 44줄 짜리 코드 → 70줄 (함수로 추출하면서 함수 본문 열고 닫는 괄호가 덭붙여져서 그렇다)
• 추가된 코드 덕분에 전체 로직을 구성하는 요소 각각이 뚜렷이 부각되고, 계산하는 부분과 출력형식을 다루는 부분이 분리됐다.
• 이렇게 모듈화하면 각 부분이 하는 일과 그 부분이 맞물려 돌아가는 과정을 파악하기 쉬워진다.
• 간결함이 지혜의 정수일지 몰라도, 프로그래밍에서만큼은 명료함이 진화할 수 있는 소프트웨어 정수다.
• 항시 코드베이스를 작업 시작 전보다 건강하게(healthy) 만들어놓고 떠나야 한다.

1.8 다형성을 활용해 계산 코드 재구성하기

• 조건부로직을 다형성으로 바꾸기
  💡 다형성(polymorphism)이란 하나의 객체가 여러 가지 타입을 가질 수 있는 것을 의미합
• → 코드 수정시에 조건부로직을 각각 수정하도록 코드를 작성하는 것보다는 서브 클래스를 추가하는 것이 확장성, 가독성 면에서 좋다.
• 생성자를 팩터리 함수로 바꾸기!
• → 조건문은 오직 팩터리 함수에서만 사용하도록 한다!

 

 

기억에 남는 부분

경험 많은 프로그래머조차 코드의 실제 성능을 정확히 예측하지 못한다.

소프트웨어 성능은 대체로 코드의 몇몇 작은 부분에 의해 결정되므로 그 외의 부분은 수정한다고 해도 성능 차이를 체감할 수 없다.

잘 다듬어진 코드라야 성능 개선 작업도 훨씬 수월하기 때문이다.

"좋은 코드를 가늠하는 확실한 방법은 '얼마나 수정하기 쉬운가'이다"

 

 

 

정리

사실 42seoul을 진행하며 간단하게 shell script로 test코드를 작성해 본 적은 있지만 최근에야 회사 업무를 하며 pytest와 같은 테스트 프레임워크를 사용해보고 테스트가 왜 중요한지 느끼는 와중에 1.3의 내용을 보니 확 와닿았다.

모든 코드를 최적의 코드로 짜는게 제일 좋겠지만 사실 프로그램의 성능에는 작은 부분(핵심 로직)에 의해 결정되고 이를 파악하려먼 구조가 잘 잡혀있어야한다.

팩토리 함수라는 개념을 몰랐었는데 정리를 한번 해보기로!

 

 

 

관련 코드는 github저장소에서 확인가능합니다.

GitHub - Metacognition-Polymath/refactoring-2nd-edition: 코드 구조를 체계적으로 개선하여 효율적인 리팩터링