실무 코드에 디자인 패턴 적용 시의 '기준'에 대해... - Inflearn

강의를 들으며 정리한 내용을 바탕으로, 실무적인 관점에서 더 깊이 이해하고 싶은 부분이 생겨 질문드립니다.

추석 연휴 동안 강의를 수강하고, 출근을 하여 실무에서 다루고 있는 코드를 보다보니

"이것도 OO 패턴으로 리팩토링 할 수 있을까?" 하는 유혹(?)을 이곳 저곳에서 느끼게 되었습니다.

(특히, 상태 패턴과 전략 패턴을 도입 할 수 있어 보이는 코드가 상당히 많았습니다.)

책임 연쇄 패턴이나 커맨드 패턴처럼 유연성을 위해 클래스가 많이 늘어나는 경우, 얻는 이점보다 구조의 복잡함이 더 커지는 순간이 있을 것 같은데요.

결국은 본인 혹은 현실적인 실무 환경 등, 각자의 실무 환경에 따라 달라질 수 있는 내용이지만

실무에서 "이 정도면 과하다. 그냥 if문으로 가자"라고 판단하시는 기준이나 경험적인 '신호'가 있다면 어떤 것일지 조언을 구하고 싶습니다.

안녕하세요, 인프런 AI 인턴입니다.
모니터크리너님께서 실무 코드에 디자인 패턴을 적용할 때의 기준에 대해 질문해 주셨네요.

디자인 패턴을 적용하는 것이 코드의 유연성과 확장성을 높일 수 있지만, 때로는 과도한 적용으로 인해 코드가 복잡해질 수 있습니다. 실무 환경에서 판단할 수 있는 기준이나 신호로는 다음과 같은 것들이 있습니다:

프로젝트의 복잡도와 규모: 작은 규모나 단순한 프로젝트에서는 복잡한 패턴을 도입하는 것보다 간단한 코드 구조가 유지보수나 이해에 더 도움이 될 수 있습니다.
현재와 미래의 요구사항: 현재 요구사항을 충족하는 것뿐만 아니라, 미래의 변경이나 확장 가능성을 고려해야 합니다. 만약 변경 가능성이 거의 없다면, 간단하고 명료한 방법을 선택하는 것이 효과적일 수 있습니다.
팀의 역량과 경험: 팀 내에서 디자인 패턴에 대한 이해도가 높고 이를 관리할 역량이 충분한 경우라면, 패턴 적용이 유리할 수 있습니다. 그렇지 않다면 간단한 구조가 더 나은 경우가 많습니다.
기능적 요구사항: 패턴 적용이 기능적 요구사항을 충족시킬 수 있는 경우에 적합하며, 그렇지 않으면 과도한 디자인일 수 있습니다.
추적 가능한 복잡성 증가: 패턴 적용으로 인해 복잡도가 커지되, 그 증가분이 쉽게 추적 가능한 경우라면 유의미할 수 있습니다.

이런 기준들을 참고하여 모니터크리너님의 실무 환경에 적합한 판단을 하시길 바랍니다. 실무에서의 경험과 팀의 피드백을 통해 더욱 적절한 결정을 내릴 수 있을 것입니다.

추가적인 도움이 필요하다면 stackoverflow.com에서도 관련 토론을 찾아보실 수 있습니다.
성공적인 개발이 되시길 바랍니다!

Inflearn Community Q&A