'javadoc'에 해당하는 글 1건

336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
어떤 부분을 수정했는데 잘못된 부분이 있습니다. 이때 잘못되었다는 피드백을 즉시 받을 수 있다면 가장 이상적인 환경일 것입니다. 지금 까지 얘기했던 테스트 환경과 CI서버를 잘 구축해놓으면 이런 이상적인 환경을 구축할 수 있고 현실화 시킬 수도 있습니다.

하지만 실전에서는 또 다른 어려운 점이 많이 생깁니다. 개인적인 경험을 되돌아보면 어떤 부분을 리팩토링 하려고 했더니 그 부분이 핵심 기능 중 하나라서 리팩토링에 따른 영향이 무척 컸던 경우가 있습니다. 영향 받는 부분을 검토하고 검증 방법이 있나 살펴보았습니다. 그런데 테스트도 없고 그 외 검증할 방법이 마땅치 않았습니다. 리팩토링에 투자할 수 있는 시간은 한정되어 있고 고민에 빠져들었습니다. 이런 때는 어떻게 해야 할까요?

이럴 때 바로 영향력 제어가 필요합니다. 영향력 제어는 리팩토링 즉 변경에 따라 발생하는 영향력을 현재 상황에서 다룰 수 있을 정도로 축소시키려는 노력입니다. 이를 위한 여러 가지 방법이 있겠지만 이어지는 글에서 본인이 실무에서 사용하여 그 효과를 느낀 방법 두 가지를 소개하려고 합니다.

1. 위임을 이용한 영향력 제거

지난 단위 테스트에 대한 글에서 인터페이스가 변경되지 않는 경우 영향력을  제거하는 방법을 소개했습니다. 하지만 인터페이스가 변경되는 경우에는 이 방법을 사용할 수 없습니다. 결국 영향 받는 부분 모두를 검증해야 하는데 현실적인 여건상 쉽지 않을 때가 많습니다. 이럴 때는 다소의 레거시(Legacy)를 인정하며 영향력 제거를 꾀하는 '위임'을 이용하여 리팩토링을 진행할 수 있습니다.

예전 리팩토링 프로젝트를 할 당시 프로젝트 전역에 걸쳐 사용되는 핵심 도메인 모델의 한 메서드를 리팩토링 해야 하는 경우가 있었습니다. 코드 내부뿐 아니라 메서드의 인터페이스도 변경해야 했습니다. 그런데 인터페이스를 수정하려고 보니 수많은 JSP에서 해당 인터페이스를 사용하고 있었습니다. 안타깝게도 당시 JSP에 대한 자동화 된 검증방법을 준비하지 못한 상황이었습니다. 그래서 수정을 하더라도 어마어마한 범위의 확인을 어떻게 할지에 대한 대책이 필요했습니다. 어떻게 하면 시간을 아끼면서 리팩토링도 할 수 있을까? 저는 많은 고민을 했고 결국 위임을 사용했습니다. 세부적인 방법은 아래와 같습니다.
 
1) 리팩토링 했을 때 최종적으로 만들고 싶은 형태의 새로운 메서드를 개발하고 그에 따른 단위 테스트를 작성한다. 이때 주의할 점은 예전 메서드의 기능을 100% 지원할 수 있는 형태로 만들어야 한다는 점이다. 즉 하위 호환성을 완벽하게 제공해야 한다. 또한 메서드 인터페이스가 기존과는 달라야 한다는 점에 유의해야 한다. 만약 인터페이스가 같다면 단위 테스트를 이용하여 수정 전/후의 동일성을 보장하여 영향력을 제어할 수 있기 때문에 굳이 위임을 사용할 필요가 없다.

2) 예전 메서드에 대한 단위 테스트를 작성한다. 이후 수정을 할 때 해당 테스트를 통해 수정 전후의 동일성이 보장될 수 있게 한다.

3) 예전 메서드의 내부 코드를 모두 지운다. 그리고 예전에 하던 것처럼 동작을 직접 구현하는 것이 아니라 1번에서 만든 새로운 메서드에게 구현을 위임하는 방법으로 코드를 작성한다. 이것이 가능한 이유는 1번에서 하위 호환성을 제공했기 때문이다.

4) 2번에서 작성한 테스트 코드를 이용하여 동일성을 보장한다. 만약 테스트가 잘 동작한다면 예전과 같게 동작하는 것이 보장된 것이다.

5) 추천하지 않는다는 의미의 @deprecated 주석을 예전 메서드에 달아 사용자들이 예전 메서드를 더는 사용하지 않도록 안내한다. 예전 메서드는 참조가 많아 부득불 하게 유지하는 것이며 가능한 한 빨리 제거하는 것이 좋다.

6) 예전 메서드에 @see 주석을 달아 대신 사용 가능한 새로운 메서드를 알려준다. 추가로 주석 부분에 새롭게 리팩토링 한 메서드가 필요한 배경을 설명하고 하위 호환성을 제공한다는 점을 밝혀두면 이후 개발자들이 더욱 신뢰성을 가지고 새롭게 리팩토링 한 메서드를 사용할 수 있기 때문에 좋다.


그림#1. 위임의 예

저는 위와 같이 작업하여 제가 리팩토링 프로젝트에서 만났던 비슷한 유형의 문제를 모두 해결할 수 있었습니다. JSP에서 해당 인터페이스를 호출하던 부분은 예전 메서드가 그대로 존재하며 '예전과 동일한 일'을 해주기 때문에 아무런 영향을 받지 않게 되었습니다. 새로운 메서드가 추가된 것 빼고는 예전과 모든 것이 동일했기 때문에 더 이상 검증에 대해 신경 쓰지 않아도 됐고 따라서 특별히 QA를 받지 않아도 됐습니다. 또한 @deprecated와 @see를 이용한 안내로 말미암아 새롭게 코드를 작성할 때는 리팩토링 된 메서드에 대한 안내를 좀 더 편하게 받을 수 있었습니다.

위임은 현실과 이상의 괴리를 채워주는 훌륭한 방법이라고 생각합니다. 즉 리팩토링을 하고 싶지만 완벽하게 할 수는 없을 때 한편으로 이상적인 코드를 추구하면서 잠시 예전의 코드도 인정하는 방법입니다. 이렇게 되면 인터페이스 변경에 따른 전반적인 코드수정을 하지 않아도 되며 리팩토링에 따른 영향력을 거의 무의미하게 만들어 검증 또한 쉬워집니다.

2. 인터페이스 변경에 따른 영향력 확산 고립

때로 인터페이스를 변경했을 때 그에 따른 영향의 파급이 계속해서 커지는 경우가 있습니다. 예를 들어 아래 그림은 DAO의 반환 타입을 기존 Map에서 모델로 바꾸었는데 BO(Business Object)에서는 DAO에서 받은 Map을 그대로 반환하는 예입니다. 그림에서 볼 수 있듯이 문제는 해당 BO가 가지고 있는 영향력이 넓다는 점입니다. 따라서 BO의 인터페이스를 수정하게 되면 많은 부분에 영향이 미치고 검증의 부담으로 다가옵니다.


그림#2. 영향력 고립의 예

이럴 때는 영향력의 확산을 막기 위해 위 그림의 빨간 선 부분에서 영향력을 고립시킬 수 있습니다. 즉 DAO는 리팩토링을 해서 Map대신 Model을 반환하게 하지만 BO에서는 예전과는 달리 DAO에서 Model을 받더라도 예전처럼 Map으로 바꿔 반환함으로써 외부에서는 변화를 모르게 하는 방법입니다.

여기서 중요한 점은 BO에 대해서 단위 테스트에 얘기했던 단위 테스트를 이용한 동일성 보장을 해주어야 한다는 점입니다. 기존에 쓴 글에서 필요한 부분을 일부 발췌했습니다.

이어 단위 테스트는 인터페이스 변경 없이 내부코드만 변경이 있을 경우 ... 내부코드 변경의 경우는 영향 받는 곳의 코드변경은 없다는 점 ... 이 점을 통해 알 수 있는 사실은 만약 우리가 변경되는 내부코드의 변경 전/후의 동일성을 확실히 보장한다면 내부코드 수정으로 말미암아 영향 받는 부분에 대해서는 더는 신경 쓰지 않아도 된다는 것 (생략)

이 방법을 적용했을 때 BO의 내부코드는 변경 되었지만 동작은 예전과 동일하다라는 것이 보장되기 때문에 해당 BO의 변화에 영향 받는 넓은 범위의 동작을 보장할 수 있게 됩니다. 영향력 고립시키기는 부분적으로 리팩토링을 할 때 원치 않게 영향력이 확산되는 것을 막아줍니다.

WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

,