인프런 커뮤니티 질문&답변
작성한 질문수
3-2 언제 추출을 멈출까
해결된 질문
작성
·
52
1
메서드가 한가지 이유로 변경될 때까지라는 기준이 모호하기도 하고 약간 실무상으로 반대하는 입장이기도 합니다.
우선 한가지 이유라면 이미
run도 한가지 이유(실행하기 위해)
welcome도 인사말하기 위해
이기 때문에 매우 모호합니다. 반대로 showRoom조차도 일종의 템플릿 메소드 파트와 Room이 처리하는 부분으로 나뉜 것으로 되어있죠.
그런 면에서 저는 실무에서 메소드 추출을 멈추는 실제적인 기준을 변화율로 두고 있어요. 그 동네가 한꺼번에 변하냐 아니냐로 보는 방식입니다.
만약 welcome수준이 한꺼번에 팀장 회의에서 갈려나가는게 일반적이라면 거기서 멈추고 showRoom에서도 room자체의 설명을 보여주는 부분만 자주 바뀌면 다시 추출하는 방식인거 같아요.
답변 2
2
말씀하신 변화율과 한가지 이유가 동일한 것으로 보이는데요.
한꺼번에 변하는 로직을 메서드로 추출하고 서로 다른 이유로 변하는 로직을 다른 메서드로 추출하면 각각의 메서드는 동일한 한 가지 이유로 변하는 메소드가 될것 같습니다.
Hika Maeng님의 질문은 메서드를 추출할 이유에 초점을 맞춰서 말씀하신 거고, 메서드 추출의 결과로 한가지 이유로 변하는 메서드로 분리되면 거기서 메서드 추출을 멈추면 될테니까요.
답변이 되었는지 모르겠네요. 🙂
0
안녕하세요, 인프런 AI 인턴입니다.
Hika Maeng님께서 제기해주신 질문은 메서드 추출의 실무적 기준에 대한 깊이 있는 고민을 담고 있습니다. 메서드 추출의 일반적인 지침은 “변경의 이유가 하나인 시점까지” 이지만, 이 기준이 모호하게 여겨지실 수 있고, 실무에서는 다른 시각으로 접근해야 할 때도 많은 것이 사실입니다.
한가지 이유로 추출한다는 기준의 모호성
- 한가지 이유라는 기준은 SRP(Single Responsibility Principle)에서 강조되는 원칙입니다. 이는 코드의 변경 가능성을 최소화하고 유지보수성을 높이기 위한 방안이지만, 너무 엄격하게 적용할 경우 오히려 코드가 지나치게 분리되어 버릴 수 있습니다.
- 실무에서는 메서드를 무조건 작게 분리하는 것이 아니라, 관련된 기능이나 변경이 함께 이루어질 가능성이 높은 부분들을 하나의 메서드로 묶어둠으로써 이해도를 높이는 것이 중요합니다.
변화율을 기준으로 한 메서드 추출
- 실제적인 코드 변경은 프로젝트의 도메인과 업무 흐름에 크게 의존합니다. 변경이 자주 발생하는 부분을 기준으로 하는 접근 방식이 더 현실적일 수 있음을 지적하셨습니다.
- 예를 들어,
showRoom메서드의 일부가 자주 변경되고 다른 부분이 변화가 적다면, 자주 변경되는 부분만 별도로 추출하여 변경에 유연하게 대응할 수 있게 하는 것이 한 가지 전략이 될 수 있습니다.
기존 답변 및 관련 링크
- 변경에 따른 코드를 유지보수하기 위한 설계 접근 방법에서는 설계의 변경 대응 방안을 주요 응집도 기준으로 설명하고 있습니다. 이는 님의 관점과 유사하므로, 참고하시면 도움이 될 것입니다.
위의 설명을 통해 “언제 메서드 추출을 멈출 것인가”에 대해 현실적인 감각을 갖출 수 있기를 바랍니다. 이 과정에서 프로젝트의 특성이나 팀 내 코드 변경 스타일을 고려하여 접근하시는 것이 좋습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 계속해서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.