<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Refactoring on Gukin Han</title>
    <link>https://gukin.dev/tags/refactoring/</link>
    <description>Recent content in Refactoring on Gukin Han</description>
    <generator>Hugo</generator>
    <language>ko-kr</language>
    <lastBuildDate>Fri, 25 Apr 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://gukin.dev/tags/refactoring/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Java enum을 활용한 전략 패턴(Strategy Pattern) 실무 적용기</title>
      <link>https://gukin.dev/posts/java-enum-strategy-pattern/</link>
      <pubDate>Fri, 25 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://gukin.dev/posts/java-enum-strategy-pattern/</guid>
      <description>&lt;p&gt;B2B 서비스에서 새로운 고객사가 들어오거나 기존 기능을 수정 및 이슈 픽스 해야하는 상황일 때 복잡한 if-else 레거시가 유지보수 효율성 문제를 자주 발생시켰다. enum 방식의 전략 패턴을 도입했고, 각 로직에는 단위테스트를 쉽게 도입할 수 있었다. 결과적으로 회귀테스트 비용이 제로로 떨어졌고, 나중에 팀원이 동일한 작업을 진행하면서 추가 작업이 쉬워졌음을 느꼈다고 공유해주었다.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;이 글에 사용된 코드는 실제 프로덕션 코드가 아닌, &lt;strong&gt;핵심 구조만 재구성한 예시&lt;/strong&gt;입니다.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2 id=&#34;유지보수-관점에서-if-else의-문제점&#34;&gt;유지보수 관점에서 if-else의 문제점&lt;/h2&gt;
&lt;p&gt;모든 if-else 구조가 나쁜 것은 아니다. 때론 간결하고 단순한 코드 방식이 더욱 유지보수에 유리한 경우가 있다.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
