리팩토링(Refactoring)?

• 우리가 리팩토링 하고자 하는 코드가 웹으로 노출하고 있는 기능을 변경, 추가하지 않은 채로 구조만 개선하는 작업
  • 구조를 개선하는 이유? 더 이해하기 쉬운 코드로, 변경하기 좋은 코드로 만들기 위함
• 리팩토링 작업은 끊임 없이 진행되는 것이 좋음
• 리팩토링 전/후에 기능이 변경되지 않았다는 것을 알기 위해서 테스트를 만들어 줘야됨
  • 자동화된 테스트를 이용하면 수동 테스트를 하지않아도 리팩토링 후에도 코드에 새로운 버그가 들어갔다거나 기존 기능이 동작하지 않는지 문제를 확인할 수 있음

WebApiExRateProvider 리팩토링

WebApiExRateProvider : WebApi를 이용해 환율 정보를 가져옴

• 시간이 지난 뒤에 서버가 이상한 에러를 내면서 중단되거나

• 알 수 없는 예외를 던지는 상황을 만날 수 있음

  ⇒ 디버깅을 통해 리팩토링 진행

Clinet의 main 메서드를 통해 수동 테스트

main 메서드 실행을 통해 코드에 문제가 없는 것을 확인

버그 발생 상황을 포함한 코드 리팩토링 진행

1. URL 경고

   • Deprecated : 앞으로 더 이상 사용하지 않을 것이기 때문에 경고를 주는 것
   • URL을 직접 사용하지 않고 URI를 만들어서 사용

2. throws IOException

   • throws IOException를 던지면 PaymentService에서 받음

     • IOException은 보통 우리가 컨트롤할 수 없는 쪽에서 발생함
       • 인터넷 끊김, 서비스 제공하는 업체 서버 장애 발생으로 중단 등 여러가지 종류의 관여 할 수 없는 외부 네트워크와 관련된 작업에서 발생하거나 그 뒷단에서 발생하기 때문 ⇒ 말그대로 진짜 예외적인 상황인 것
     • 인터페이스 차원에서 보는 경우 throws IOException을 꼭 던져야 되는 것처럼 메소드를 정의해 놓는 것은 매우 이상한 것
     • 예를 들어 고정적인 환율을 리턴하는 SimpleExRateProvider에서는 IOException이 발생할리가 없음
     • WebApi를 호출해서 사용하지 않는 한 throws IOException이 필요한 것이 아님

   • IOException을 무조건 던지도록 메서드를 선언하는 것은 잘못된 설계

   • throws IOException을 검색해보면 정말 필요도 없는 곳에서 예외를 던지고 있기 때문에 전부 삭제 진행

     

     

3. WebApiExRateProvider의 getExRate

   • WebApiExRateProvider의 getExRate는 분명하게 API를 사용하는 네트워크를 이용하는 것이므로 Exception 대응이 필요함
   • Checked Exception이 아닌 Runtime Exception으로 Unchecked Exception을 던질 것(throws를 정의할 필요가 없음)
   • Exception을 catch하는 이유
     • 상황을 복구하기 위함
     • 복구하기 위한 설계가 없다면 무시하도록 하면 됨
     • RuntimeException은 throws를 선언하지 않아도 제일 앞단까지 던져짐
       • 서버라면 톰캣이나 웹서버에서 받아서 적절한 응답으로 클라이언트에게 전달
       • 로그를 남기고 개발팀에 전달하는 notification을 탈 수도 있음