[TDD/방법론] 코드 리팩토링

nana·2024년 9월 7일

방법론

목록 보기
4/9
post-thumbnail

효과적인 리팩토링을 위해 반대로 좋고 커다란 설계가 어떤 모습인지 이해해야한다.
중복의 양을 최소화 하고(낮은 중복성), 높은 명확성을 목표로 코드를 리팩토링 해야한다.

1. 복잡한 코드는 메서드로 추출한다.

  • 변경 전
  • 변경 후

👉🏻 할당 부분을 별도의 메서드로 추출하여 복잡성을 고립시킨다.
반복문에는 단순한 선언문만 남으므로 match 변수는 조건이 답변에 맞는지 여부만 나타낸다.

메서드를 올바른 클래스에 두기.

  • 변경 전

  • 변경 후

    Profile.java

    Criterion.java

👉🏻 matches 메서드가 Profile 클래스와는 상관없으므로 Criterion이라는 클래스로 이동해준다.

자동 및 수동 리팩토링


1 : answerMatching이라는 메서드로 로직 분리해줌.
2 : 해당 반복문에서 answer은 한번만 쓰이므로 matches에 인라인함.

수동으로 넣어도 되고 Refactor > Inline메뉴를 통해 inline 할 수도 있다. (Intellij 단축키 : ctrl + Alt + N)

깔끔한 설계


👉🏻 앞의 소스가 세개의 새로운 메서드, 반복문으로 변경되었다.

  • 명확한 테스트가 가능한 단위들로 쪼개졌다.
  • 새로운 세개의 반복문으로 matches() 메서드는 잠재적으로 실행 시간이 네 배가 된 것 같지만 성능이 즉시 문제되지 않는다면 어설픈 최적화 노력으로 시간을 낭비하기 보다 코드를 깔끔하게 유지하는 것이 좋다
  • 깔끔한 설계는 성능을 위해 최적화할 때 즉시 대응할 수 있다. - 깔끔한 설계는 코드를 이동시킬 수 있는 유연성을 제공하고 다른 알고리즘을 적용하는 데도 수월하다.
profile
BackEnd Developer, 기록의 힘을 믿습니다.

0개의 댓글