3.3 코드 분할
코드 분할(decomposition)은 큰 덩어리의 코드를 작은 덩어리로 쪼개는 것이다.
함수 하나하나가수백라인씩 되고, 블록이 몇 중으로 겹쳐진 코드는 코드를 봐야하는 사람을 낭패스럽게 한다.
이상적으로는 함수 하나가 한가지 작업만 해야 한다. 복잡도를 심각하게 높이는 다른 부가 작업은 별도의 함수로 분리되어야 한다.
예를들어, 누군가 이 함수가 하는일이 물었을 때, 먼저 A를 하고, B를 한 후 C면 D를 하고, 아니면 D를 한다 라고 답했다면,
A, B, C, D를 별도의 메서드로 분리해야하는 것이 바람직 하낟.
코드 분할은 이론적으로 잘 정립된 개념은 아니다.
어떤 프로그래머는 종이로 출력했을 때 함수 크기가 한쪽 이내여야 한다고 주장할 수도 있다.
또 다른 경험 법칙은 코드의 길이가 길든 짧든 눈을 가늘게 뜨고 코드의 윤곽을 흘려보았을 때 특정 블록이 너무 밀집해 있지 않은지 보는 것이다.
3.3.1 리팩토링을 통한 코드 분할
컨디션이 좋을 때 굉장한 집중력으로 단기간에 많은 코드를 버그 없이 작성해낸 경험이 있을 것이다. 그러나, 이때 작성한 코드는 보기 좋은 코드와는 거리가 먼 경우가 많다. 모든 프로그래머가 때때로 이런 코드를 만들어 낸다.
이렇게 짧은 시간에 왕성하게 코드를 만들어내는 시기는 프로젝트 과정 중에서 가장 생산성 높을 때인 경우가 많다.
코드를 수정하는 와중에 밀집된 코드가 만들어지기도 한다.
버그 수정이나 새로운 요구 사항의 구현이 급하게 닥치면 기존 코드에 최소한의 수정으로 대응하게 된다.
이러한 수정이 쌓이다 보면, 애초에 우아헀던 코드는 온데간데없고 땜질과 임기응변으로 가득한 누더기 코드만 남는다.
(이런 현상을 code cruft, code smell 이라고 한다.)
리팩토링은 코드를 재구성 하는 것이다. 다음은 리팩토링할 때 사용할 수 있는 몇 가지 테크닉이다.
- 추상화를 더욱 강화하는 방법
- 필드( 멤버 변수) 를 캡슐화 한다 : 필드를 private 블록에 두고 필드에 대한 접근은 게터와 세터를 이용
- 타입을 일반화 한다 : 좀더 일반적, 범용 탕비을 이용해서 많은 코드에 활용할 수 있게 한다.
- 코드를 좀 더 논리적인 부분으로 분할하는 방법
- 메서드를 추출한다. : 덩치가 큰 메서드의 일부를 새로운 메서드로 분리해서 더 이해하기 쉽게 한다.
- 클래스를 추출한다. : 기존 클래스에서 일부분을 추려내어 새로운 클래스로 만든다.
- 네이밍과 코드 위치를 개선하는 방법
- 메서드나 필드를 이동시킨다. : 좀더 적합하 클래스나 소스 파일로 이동시킨다.
- 메서드나 필드의 이름을 변경한다. : 목적을 더 잘 드러낼 수 있는 이름으로 바꾼다.
- 풀업 : OOP 코드에서, 상위 클래스로 이동시킨다.
- 풀다운 : OOP 코드에서, 하위 클래스로 이동시킨다.
시간이 가면서 누더기가 되었거나, 읽기 어려운 밀집코드로 되어있었다면, 주기적인 리팩토링을 통해 누적된 때를 벗겨내야 한다.
기존 코드를 다시 검토하면서 좀 더 이해하기 쉽고 유지보수가 편리하도록 재작성하게 된다.
'전문가를 위한 C++정리' 카테고리의 다른 글
3. 코딩 스타일 3.4 네이밍 3.4.2 네이밍 컨벤션 (0) | 2024.01.17 |
---|---|
3. 코딩 스타일 3.4 네이밍 3.4.1 좋은 이름의 선택 (0) | 2024.01.17 |
3. 코딩 스타일 3.2 코드의 문서화 3.2.2 주석 작성 스타일 (0) | 2024.01.16 |
3. 코딩 스타일 3.2 코드의 문서화 3.2.1 주석을 작성해야 하는 이유 (0) | 2024.01.16 |
3. 코딩 스타일 3.1 보기 좋은 코드의 중요성 3.1.1 ~ 3.1.2 (0) | 2024.01.13 |