티스토리 뷰

반응형

개발은 '데이터'를 할당하는 작업이다.

어떤 개발영역이든 '데이터'를 다루고 할당하는 작업을 한다. 여기서 말하는 '데이터'는 DB에 저장되는 값이 될 수도 있고, 사용자에게 적절하게 반환되어서 보여지는 값이 될 수도 있다.

 

우리가 만든 코드들은 결국 데이터를 할당하는 작업을 한다.

 

다시말해 (낯선)코드를 읽고 파악하는 과정은 데이터가 어떤식으로 다루어지고 변경되어지고 할당되어지는지 확인하는 과정이다. 코드를 읽어나가는 사람 입장에서 데이터들이 어떤방식으로 할당되어지는지 예측할 수 없다면 그 코드는 읽기 좋은 코드라고 말할 수 없다.

 

데이터가 예측되는 메서드를 만들자.

  • DB 값을 변경하기 위한 데이터를 할당하는 작업.
  • 사용자에게 보여주기 위한 데이터를 할당하는 작업.

이 정도 수준의 할당은 아주 낮은 추상화 단계에 작업이라고 할 수 있다.

우리가 만든 코드들은 이 낮은 추상화 단계에 작업들을 더 높은 추상화 단계로 잘 포장해서 데이터를 다룬다.

 

예를들어 라면을 한개 꺼내서 먹어버리는 과정을 얘기해보자.

이 과정은 필연적으로 저장되어있던 '라면'이 한개 줄어드는 과정을 수반해야 한다. (가장 낮은 수준의) 코드라면 var 라면갯수 = 라면갯수 - 1; 이 될 것이다.


이 코드를 한단계 높게 추상화 시켜 포장한다면 라면_한개_꺼내기() 메서드 정도가 적절한 것 같다.

// 데이터를 할당하는 코드를 높은 추상화 단계로 포장
func 라면_한개_꺼내기() {
    var 라면갯수 = 라면갯수 - 1; 
    ...
}

라면_한개_꺼내기() 라는 메서드를 보면 '라면'이 한개 줄어들어 라면의 갯수가 변경될 것임을 짐작하게 하는가? 즉, 데이터가 어떤식으로 변경 될 것인지 짐작하게 하는가? 아주 쉽게 짐작된다.

 

좀 더 추상화 수준을 높여보자. 사실 라면_한개_꺼내기() 메서드는 사실 라면_끓여먹기()라는 메서드의 일부분이었고 라면_끓여먹기()라면_한개_꺼내기(), 라면_끓이기(), 라면_먹기() 라는 같은 수준의 과정들을 추상화한 메서드다.

//한단계 더 높은 추상화 단계로 포장
func 라면_끓여먹기() {
    라면_한개_꺼내기(); 
    라면_끓이기();
    라면_먹기();
}

라면_한개_꺼내기() 보다 한단계 더 추상화된 라면_끓여먹기()라는 메서드는 라면의 갯수가 변경 될 것임을 짐작하게 하는가? 즉, 데이터가 어떤식으로 변경될 것인지 짐작하게 하는가? 추상화 수준이 한단계 올라 이전보다 직관적이진 않지만 아주 어렵지도 않다.

 

핵심은 메서드이름을 적절하게 지어야 한다는 점이다. 적절한 메서드의 이름안에서라면 어떤 데이터들이 변경될 것인지 짐작되어야 한다.

 

 

적절한 메서드 위치에 대한 고찰

만약에 라면_끓여먹기()라는 메서드 내부에 강아지_사료주기() 라는 메서드가 존재한다면, 강아지 사료 데이터가 줄어들 것인데 라면_끓여먹기()라는 메서드는 이를 암시해주기 어렵다. 다시말해 강아지_사료주기()라는 메서드의 적절한 위치가 이곳이 아니라는 뜻이다.

 

예제만 보면 누가 저렇게 바보 같은 행위를 할까 싶지만, (한 트랜잭션에서) 여러개의 얽혀있는 데이터를 변경하는 작업을 하다보면 충분히 발생되고 있는 문제들이다.

 

이런실수를 하지 않기 위해서는 명심하자. 메서드를 보면 어떤 데이터가 할당되는 과정인지 짐작가능한가?? 만약 예상하지 못할것 같다면 진지하게 메서드 (혹은 코드)의 위치를 다시 고민해봐야 한다.  이후에 코드를 읽고 유지보수해야하는 개발자는 어디서 데이터가 변경되는지 온 메서드를 다 뒤지고 다녀야 할 것이다.

반응형
댓글