쉽고 간단한 리팩토링!

회사에 입사해 한 달 동안 테스트코드 작성, 그리고 리팩토링을 하며 주요 로직들을 검증하는 기간을 가졌었다.

한달동안 리팩토링하며 이것 하나만 알고 있어도 도움이 많이 되겠구나 싶은 것이 있었다.

 

P.S. 금방 쓰고싶었는데.. 또 오래걸렸다 ㅜ.ㅜ

한달에 글 하나씩!

 

---

리팩토링!

이거 하나만 알고있어도 꽤 괜찮은 코드를 작성할 수 있다.

 

지갑이라는 클래스가 있다.

현금 지갑이거나, 주식 지갑일수도 있다.

앞으로 나올 코드들은 이해 할 필요 없다. 그냥 보기 편해졌네? 라는 것만 느끼면 된다.

class Wallet {
  constructor(owner) {
    this.owner = owner;
    this.stagingMoney = 0;
    this.availableMoney = 0;
  }
}

 

우리가 돈을 쓰면, 지갑에서는 돈이 빠져나간다! ㅠㅠ

주식을 산다면.. 낙찰이 되기 전까지 우리의 돈은 대기금 상태가 된다.

function orderStock(owner, price, count) {
  const wallet = new Wallet(owner);
  wallet.stagingMoney += price * count;
  wallet.availableMoney -= price * count;
}

 

우리는 주식을 살 뿐 아니라, 음식을 주문 하고, 편의점에서 츄파츕스를 사먹기도 한다.

// 여기저기 입출금 로직 반복됨

function 음식주문하기(price, count) {
  const wallet = new Wallet(owner);
  wallet.stagingMoney += price * count;
  wallet.availableMoney -= price * count;
}

function 직접결제하기() {
...
}

 

 

자, 우리는 돈을 쓸 곳이 너무나 많다!

여기서도 쓰고 저기서도 쓰고 없으면 신용카드..

 

이 말은 즉슨, 우리는 '출금'이라는 기능의 코드를 자주 반복하게 된다.

이 행위를 지갑 클래스안에 메소드로 만들어보자.

class Wallet {
  constructor(owner) {
    this.owner = owner;
    this.stagingMoney = 0;
    this.availableMoney = 0;
  }

  hold(price) {
    this.stagingMoney += price;
    this.availableMoney -= price;
  }
}

 

입찰을 해보자!

function orderStock(owner, price, count) {
  const wallet = new Wallet(owner);
  wallet.hold(price * count);
}

 

 

지갑의 상태를 변경하는 부분을 메소드로 만들었다.

 

메소드로 만들면 뭐가 좋을까?

서비스 코드에서 핵심 내용 이외의 불필요한 디테일들은 숨김으로써

서비스 코드를 이해하기 쉬워진다.

 

자, 우리는 지갑에서 대기금으로 전환하는 로직만을 구현했었다.

출금이 완벽하게 이루어지려면, 대기금을 빼야한다.

츄파츕스() {
  this.stagingMoney -= price; // 대기금을 취소한다.
  this.availableMoney += price;
    
  this.availableMoney -= price; // 출금한다.
}

메소드로 만들면, 무한정 길어질 수 있는 내부 로직을 하나의 동사로 표현할 수 있다.

츄파츕스() {
  const wallet = new Wallet(owner);
  
  wallet.release(orderPrice)
  .withdraw(resultPrice);
}

 

츄파츕스를 사기 위해서는 점원, POS, 지갑, 등, 여러가지 것들이 상호작용을 하게된다.

이 여러가지 것들을 '객체' 라고 해보자. (클래스도 좋다.)

 

우리가 츄파츕스 함수에서 알고 싶은 것은

점원이 계산을하고, 포스기에 돈이 들어가고, 지갑에서 돈이 빠져나가고

이런 전체적인 구성이지.. 각 객체의 디테일이 아니다.

점원은 계산을 할 때 츄파츕스가 2개면 암산, 개수가 많으면 계산기를 사용한다.

포스기에는 만원짜리는 첫번째칸, 동전은 마지막칸에 넣는다.

손님은 동전과 지폐가 있으면 동전을 먼저 쓴다.

이런 내부 구현 사항이 하나의 동사로 요약되면 당연히.. 보기 좋아지겠지?!

 

 

 

 

자, 이제 우리는 돈을 펑펑 쓰고 카드 빚이 200만원이 되었을때 이런 생각을 하게된다.

하루에 만원 이상은 쓰지 말아야겠다...

 

class Wallet {
  constructor(owner) {
    ...
    this.오늘쓴돈 = 0;
  }
}

이런식으로 하루 지출액을 계산하여 만원을 초과하면 결제되지 못하도록 할 수 있다.

 

우리가 만약 메소드를 사용하지 않았다면...

입찰하기, 음식주문하기, 츄파츕스사기, 기부하기, 롤스킨구매, 등의 함수들에 가서

하루 지출액을 계산하는 코드를 추가해야한다!

 

예외처리, 추가 기능이 생겨날수록 수정에 대한 부담은 커진다.

(수정할 부분이 많아진다, 중복이 많아진다, 중복된 코드를 작성/수정할 때 실수 할 가능성이 높아진다.)

 

메소드로 관리하면.. 클래스가 있는 하나의 파일만 수정하면 된다.

 

요약

1. 세부사항을 메소드로 요약하여 서비스의 핵심 로직을 파악하기 쉬워진다.

2. 기능 추가, 수정이 쉬워진다. (수정할 부분이 적어진다.)