20.11.30

2가지 역할

2가지 역할을 하는 변수는 쪼개야한다. 예외는 없다. (SRP와 연결되는 내용인 듯?) 클래스도 마찬가지다. 종종 클래스에서 필드들의 역할이 충돌하거나 이름이 충돌하는 경우가 발생하는데 이 경우는 필드가 잘못 naming 되어있는 경우도 있지만 대개 클래스를 잘못 설계했을 가능성이 높다.

값 객체(Value Object)

값 객체 참조가 흔히 위험하다고들 하는데 그 이유가 무엇일까? 어떤 클래스안에 다른 클래스를 주입하는 코드를 짰다고 가정해보자. 해당 클래스에 다른 클래스의 객체를 집어 넣고 외부에서 이를 사용한다면 의도치 않게 그 객체의 값이 변경되고 그것이 예상치 못한 오류나 결함으로 이어질 수 있다. 따라서 외부에서 해당 객체에 접근을 못하도록 객체를 클래스안에서 새로 생성해 그 클래스안에서만 접근이 가능하도록 바꿔야한다.

참조를 값으로 바꾸기

그런데 위에서 말한 것처럼 항상 참조가 옳은 것은 아니다. 어떤 유저가 주문을 할때 마다 주문 객체에 유저객체가 생성된다고 가정해보자. 그럼 주문 객체마다 다른 유저객체를 가지고 있을텐데, 해당 유저의 정보가 갱신된다면 주문객체에 있는 유저객체 전부의 값을 변경시켜주어야 한다. 이런 경우에는 참조가 더 좋은 설계일 것이다. 명심하자. 리팩토링은 항상 반대가 존재한다.

코드가 보여주는 What?과 Why?

코드는 딱 보았을 때 그 의도(why)를 알 수 있어야한다. 특히 코드 리뷰에서는 why?에 초점이 맞춰져 진행이 되어야한다.

if(!aDate.isBefore(plan.summerStart)&&!aDate.isAfter(plan.summerEnd))
  charge = quantity * plan.summerRate;
else
  charge = quantity * plan.regularRate + plan.regularServiceCharge

if(summer())
  charge = summerCharge();
else
  charge = regularCharge();

위 코드와 아래코드를 비교해보면 아래 코드는 한번에 어떤 코드인지를 알 수 있다. 딱보고 여름에 맞춰서 금액이 달라지는 코드라는 것이 파악가능하다. summerCharge 함수의 세부 비즈니스 로직도 같이 봐야되는 것 아닌가라고 반문할 수 있는데 그건 코드리뷰의 영역이 아니다. 코드리뷰는 해당 코드의 로직의 흐름을 파악할 수 있는지에 초점이 맞춰져 진행이 되어야 한다. summerCharge함수가 무슨일을 하는지(what)는 테스트 코드의 역할이다. 리뷰는 빠르게 읽으면서 코드의 가독성을 확인하고 세부적인 비즈니스 로직은 테스트 코드를 통해 검사한다. (테스트 코드 역시 무엇을 왜로 다시 치환하는 방법이다.)

진입점, 반환점, Coroutine

일반적인 함수는 진입점과 반환점이 하나이다. 함수에 진입하고 나서는 쭉 진행하고 값을 리턴한다. 프로그래밍은 일련의 routine을 짜는 것이라 할 수 있다. 하나의 거대한 routine이 있고 이를 구성하는 subroutine들이 있는데 이 subroutine들이 바로 함수라 할 수 있다. 이런 subroutine을 여러개 모아둔것을 coroutine이라 하는데 흔히 쓰는 async await가 바로 이러한 coroutine이라 할 수 있다. async await는 함수가 진행되다가 시간이 오래걸리는 작업이 있을 때 이를 기다리지 않고 쭉 진행하다 해당 작업이 끝나면 다시 돌아와 작업을 진행하는데 이를 애초에 진입점이 여러 개다라고 얘기하기는 힘들지만 잠시 다른 일을 하다 다시 돌아오므로 진입점 시각에서 Coroutine이라 해석한다.

출처: 리팩토링 책 - 마틴 파울러