제어권을 유지하기

비슷한 걸 어떻게 구현을 잘 하는 게 좋을까요. 어려운 문제가 상황에 따라 답은 다를 거에요. 여기서는 코드의 중복을 관리하기 위한 하나의 관점에 대해 이야기하려고 합니다. 코드의 제어권에 대한 이야기에요.

저는 백엔드 엔지니어이기 때문에 백엔드 웹 서버 기준으로 설명할게요. 하나의 API는 각각의 진입점이 있습니다. 두 API가 비슷한 일을 한다고 했을 때 이를 어떻게 구현하면 좋을까요? 두가지 방법을 소개하고 비교할게요. 하나는 제어권을 넘기는 방법이고 다른 하나는 제어권을 API들이 각각 유지하는 방법입니다.

아래는 제어권을 넘기는 방법입니다. 서로 조금 다른 두가지 일을 다 잘 처리하는 doCommonThing 이라는 함수를 정의해요. doA 와 doB 는 이 함수를 호출하기만 하면 됩니다. 코드가 하는 일의 제어권을 doCommonThing 에 넘기는 방법이에요.

function doA() {
  doCommonThing(true);
}

function doB() {
  doCommonThing(false);
}

function doCommonThing(boolean someDifferent) {
  doX();
  if (someDifferent) {
    doY();
  }
  doZ();
}

아래는 제어권을 유지하는 방법입니다. doA 와 doB 가 하는 일이 유사합니다. 하지만 각 함수에서 무엇을 해야하는지는 진입 포인트에서 각각 작업했어요. doA 와 doB 가 코드의 제어권을 유지하고 있습니다.

function doA() {
  doX();
  doY();
  doZ();
}

function doB() {
  doX();
  doZ();
}

저는 여기에서 두번째 방법인 제어권을 유지하는 방법을 선호합니다. 왜냐하면 doA 를 수정할 때 doB 의 기능이 깨지지 않기 때문입니다.

세월의 흔적이 쌓인 소프트웨어를 관리하기는 어렵습니다. 오래된 소프트웨어일수록 개발자가 모르는 영역이 많이 쌓여있어요. 개발자는 동작을 다 이해하지 못한 상태로도 기능을 추가하거나 수정을 하게 됩니다. 이 때 각 진입점에서 제어권을 유지하고 있으면 원하는 것만 수정하기 쉬워집니다. 코드의 수정이 의도치 않은 결과를 덜 내도록 관리할 수 있어요. 코드를 수정한 뒤 무엇을 테스트해야하는지도 명확해지구요. 제품을 망가뜨릴지도 모른다는 불안감에서 벗어나 자신감 있게 코드를 작성할 수 있습니다.