리팩토링을 하고 난 뒤 다시보면 오히려 더 복잡해 보이는것 같은 ... - 인프런

Readable Code: 읽기 좋은 코드를 작성하는 사고법

OCP: Open-Closed Principle

리팩토링을 하고 난 뒤 다시보면 오히려 더 복잡해 보이는것 같은 느낌입니다..

해결된 질문

작성

192

학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요!
먼저 유사한 질문이 있었는지 검색해 보세요.
서로 예의를 지키며 존중하는 문화를 만들어가요.

강의에서는 사실 처음에 만들어졌던 로직을 하나하나씩 변경해가면서 그 히스토리를 알고 있는 상태니까.. 리팩토링을 하는 과정이나, 하고 난 뒤에도 어느정도 이해가 가지만 만약 처음 들어온 신입 개발자가 리팩토링이 완료된 코드를 보면 오히려 더 복잡해 보이는 경우도 있지 않을까 하는 생각이 들어서 질문드립니다..

가독성을 위해 추상화를하고 메소드를 분리하고 했지만, 상세 구현 로직을 확인하려면 다시 내부로 들어가는 과정을 거치면서 오히려 집중력이 분산되는 느낌인데.. 리팩토링이 추구하는 가치와 약간 모순된다는 느낌을 받았습니다..

혹시 이렇게 느끼는 이유가 아직 코드 작성 경험이 적어서 그러는걸까요? 굳이 추상화해놓은 메소드 내부까지 들어가서 확인할 필요는 없는건가요?

제가 느끼기로는 맨 처음 아무런 정리가 안되었던 코드가 제일 이해가 잘갔던 것 같아서 계속 리팩토링을 하면서도 고민이 되어서 질문드립니다..

객체지향 리팩토링 클린코드-기획전

답변 2

박우빈

지식공유자

안녕하세요, ewgregerg c 님!

네, 충분히 공감가는 상황이네요. 몇 가지 말씀드리자면,

리팩토링

저는 그래서 리팩토링을 하고 난 뒤에, 하루이틀 정도 시간이 지나고 (혹은 그 이상) 다시 한번 코드를 살펴봅니다. 내가 작성한 코드고, 아무리 도메인을 이해하고 있는 저여도 다시 읽어보면 어색한 부분이 보이기 마련인데요. 그 때 그 부분을 추가로 수정하기도 합니다.
- 또한 새로운 팀원이 합류했을 때 해당 코드를 같이 보면서 어떤 부분이 이해가 잘 가지 않았는지, 혹은 잘 읽혔는지를 이야기해보고, 추가로 리팩토링을 진행해볼 수도 있겠죠.
리팩토링을 하는 이유는 단순히 가독성에만 있지는 않습니다. 유지보수성도 중요하게 다뤄야 하는데요. 객체를 정의한 책임에 따라 나누고, 결합도를 낮추어 변경되는 요구사항에 맞게 유기적으로 발전하는 소프트웨어가 될 수 있도록 만드는 일입니다. 만약 처음의 구조 그대로였다면, 변화된 요구사항에 빠르고 유연하게 대처할 수 없었을 거예요.

과도한 추상화

반대로 말씀해주신 관점에서 보았을 때도, 그렇기에 과도한 추상화를 지양해야 합니다. 너무 객체의 책임을 분리하는 데에만 집중하고, 미래를 과도하게 예측하여 추상화 레벨을 현재 요구되는 수준보다 높여놓으면, 모두가 읽기 어려운 코드가 만들어질 수 있습니다. 이럴 땐 오히려 유지보수성도 떨어질 수 있겠죠.
- 추상화를 거치면 복잡도가 높아질 수 있기 때문에, 필요가 발생하는 시점에, 적절한 수준에서 이루어지는 것이 가장 좋습니다.

코드 읽기

처음 보는 코드를 읽을 때에는, 상세한 나무 보다는 전체적인 숲을 염두에 두고 읽는 것이 좋습니다. 도메인을 파악하는 단계에서는 상세 구현부를 자주 탐색하다가는 길을 잃기 마련인데요. 도메인의 큰 흐름이 파악될 때까지는, 적절한 추상화 레벨 구간에 내 읽기 시야를 맞추고, 낮은 레벨의 구현부는 적당히 넘기는 방법이 효율적입니다.
- 해당 부분이 정 궁금하면 그 때 함수나 메서드를 타고 들어가서 읽어보면 되겠죠.

도움이 되셨기를 바랍니다.
감사합니다. 🙂

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다.

ewgregerg c님이 느끼시는 리팩토링에 대한 혼란은 많은 개발자들이 공감할 수 있는 부분입니다. 리팩토링의 주요 목표는 코드의 가독성을 높이고 유지보수를 쉽게 만들기위한 것이지만, 때로는 처음 보는 입장에서 오히려 복잡해 보일 수 있습니다. 이는 몇 가지 이유에서 비롯될 수 있습니다.

리팩토링을 통한 코드의 복잡성 증가에 대한 이해

추상화의 특성:
- 추상화된 코드는 전체적인 설계나 흐름을 쉽게 파악하게 해 주지만, 각 메소드나 클래스 내부의 실제 구현을 이해하려면 각각의 상세 부분까지 들어가야 합니다. 이는 리팩토링을 통해 ‘큰 그림’을 명확히 하려는 반면, 구체적인 구현을 이해하기 어렵게 하는 딜레마를 야기할 수 있습니다.
코드 작성과 이해의 숙련도:
- 코드 작성 경험이 적을 때는 추상화된 코드를 이해하는데 시간이 더 걸릴 수 있습니다. 이는 특정 패턴이나 설계 원칙에 익숙하지 않기 때문일 수 있습니다. 다양한 코드 패턴을 학습하고 적용하면서 이러한 이해의 어려움은 점차 해결될 수 있습니다.
리팩토링의 방향성:
- 모든 리팩토링이 항상 긍정적인 변화를 가져오는 것은 아닙니다. 코드의 책임을 모호하게 하는 리팩토링이나 과도한 분리는 오히려 복잡성을 증가시킬 수 있습니다. 따라서 리팩토링은 신중하게 진행되어야 하며, 코드가 실제로 읽기 쉬워졌는지 평가하는 과정이 중요합니다.

리팩토링을 이해하고 극복하는 방법

리팩토링의 이유를 되새기기: 리팩토링의 목적은 더 이해하기 쉽고 유지보수하기 쉬운 코드를 만들기 위함임을 기억하세요. 따라서 리팩토링을 통해 이러한 목표를 달성하고 있는지 지속적으로 평가해야 합니다.
참고 자료 활용: 아래 링크된 자료들은 객체지향 프로그래밍 및 코드 리팩토링에 대한 심도 있는 설명을 제공하며, 이러한 개념을 더 잘 이해하는 데 도움이 될 것입니다.
- 읽기 좋은 코드 작성을 위한 팁
- 객체지향 프로그래밍에서 리팩토링 전략
피드백 활용: 팀 내 다른 개발자들과 코드 리뷰나 피드백을 통해 리팩토링 된 코드의 가독성과 구조를 객관적으로 평가받는 것도 큰 도움이 됩니다.
실제 경험의 중요성: 코드를 많이 작성하고, 리팩토링의 여러 사례를 접하면서 자신의 리팩토링 감각을 기르는 것이 장기적으로 큰 도움이 됩니다.

리팩토링의 과정에서 개인적인 느낌과 반응은 매우 중요하며, 이러한 부분들을 고민하고 발전시키는 과정 자체가 개발자로서의 성장을 이끄는 중요한 부분입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변