개발 일상, 소소한 리팩토링 정리

 

업무 배치와 푸시 배치 구분하는 작업 진행

reason

• 두 기능의 변경 빈도, 실행주기가 다름
• 조만간 푸시 기능 개선이 있었음

 

 

 

기존 배치 프로젝트에서 푸시 관련 코드를 별도 프로젝트 발라냄

기존 코드를 복붙해서 새 프로젝트 이관

이 과정에서 기존 코드를 일부 리팩토링하는 작업도 병행

 

 

분리

• 통지 코드를 별도 클래스로 분리

 

정적 메서드 -> 객체

• JobResultNotifier에 대한 단위 테스트 용이해짐

 

역할 분리

• 통지 여부 판단 로직 분리
• 파일 백업 기능 별도 클래스로 분리

 

 

 

리팩토링과 테스트!

 

 

상속보단 조립

• com.google.android.gcm.server.Sender 클래스를 상속
• 불필요하게 Sender의 모든 메서드 노출
• 조립을 하기 위한 구조로 변경

 

Sender 클래스를 상속한 클래스 분리

Sender의 모든 메서드를 노출하지 않고 필요한 기능만 제공

 

이름을 FcmSender -> Fcm으로 변경

Public static class Fcm{

private SenderImpl sender;

 

public SendResult send(Message message, final String to) throws IOException { 

SenderImpl 기능 사용

}

 

private static class SenderImpl extends Sender { //재정의한 버전은 내부 클래스로 

SenderImple(String Key){

super(key);

}

@Override

protected HttpURLConnection getConnection(String url) throws IOException { 

return super.getConnection(API_SERVER_URL);

}

}

}

 

 

Switch -> 클래스

• 타입에 따른 메시지 포맷팅 처리
• Public interface MessageFormatter{

String formatMessage(Data data);

String formatLink(Data data);

 

static MessageFormatter getFormatter(Datat data){

data의 구분에 따라 알맞은 Formatter 리턴

}

static String message(Data data){

return getFormatter(data).formatMessage(data);

}

}

class PFormatter implements MessageFormatter {

..알맞게 구현, 싱글톤

}

class IFormatter implements MessageFormatter {

..알맞게 구현, 싱글톤

}

class EmptyFormatter implements MessageFormatter{

..알맞게 구현, 싱글톤

}

}

 

String message = MessageFormatter.message(data);

String link = MessageFormatter.link(data);

 

 

 

자기 참조 제거

@Lazy

@Async

 

->

Private AsyncPushSendService asyncSendService

 

Public static class AsyncPushSendService{

@Async

public  void sendAsync(PushData pushData){

…

}

}

 

멀쩡하게 동작하는지 확인할 수 있어야 함

테스트 코드로 기대한 대로 동작하는지 확인

배치다 보니 쿼리에 기반한 코드가 많았음

그래서 단위 테스트로 뭔가를 검증하기는 힘들었기 때문에

통합 테스트를 최대한 많이 만들었음, 다양한 상황에 대해

 

가능하면 정상 상황에 대해 검증하는 테스트 코드는 최대한 많이 만듬(마음의 안정을 위해)

 

단위 테스트 가능한 구조로 변경하면서 예외 상황에 대한 테스트 추가

• 커버리지 높임

 

 

정리

• 주로 테스트 가능성을 높이기 위해 역할 분리
• 통합 테스트로 정상상황에 대한 테스트 진행
• 구조도 일부 변경

 

 

https://www.youtube.com/watch?v=fQ-WTdol6xg&t=1s