Tidy First?를 읽고 내 식대로 요약하고 생각 공유하기

⚠️⚠️⚠️ 주의 ⚠️⚠️⚠️

아래 정리 글은 저자가 책에서 말하고자 하는 의미나 사실 그리고 의도와 일치하지 않고 거짓이나 왜곡 등이 포함되어있을 수 있습니다.

적당히 걸러서(?) 이해해주시기 바랍니다.

책도 읽어보시고 제 글도 읽어보시면서 더 이해하기 쉽게 설명해주실 수 있는 부분을 찾으셨다거나, 제가 너무나 명확하게 잘못 이해하고 있는 부분을 교정(?)해주시는 등의 의견 교환은 매우 환영합니다.

TL;DR

• 리팩토링은 기능 개발을 멈추는 것이 아니다.
• 코드 정리에 대한 커밋과 동작 변경에 대한 커밋은 분리해야한다.
• 코드를 만드는 데, 가장 큰 비용이 들어가는 일은 코드 작성이 아니라 읽고 이해하는 데 드는 비용이다.
• 코드 정리는 리팩토링으로 가는 관문이다.
• PR 리뷰가 느리면 더 큰 PR을 만드는 결과를 초래한다.
• 코드는 컴퓨터에 지시할 뿐만아니라 컴퓨터에 지시하려는 개발자의 의도를 사람들에게도 설명해야한다.
• 모두가 스카우트 규칙(=찾았을 때보다 더 나은 상태로 남겨두라)을 지키는 것도 좋은 시도다.
• 비용(=진짜 돈)을 잘 따져서 코드 정리와 동작 변경의 균형을 맞추는게 좋다.

Part 1 - 코드 정리 방법

코드 정리 방법을 소개 하기 앞서 리팩토링을 싫어하는 이유는 뭘까?

→ 새로운 기능을 넣는 것도 아닌데 잠재 위험은 있고 성공적으로 리팩토링하더라도 새로 보여줄 것도 없기 때문

실무적으로나 현실적으로 맞는 말이긴하지만 코드 정리는 리팩토링과 다르다.

코드 정리는 리팩토링으로 가는 관문이고 더 간단한 작업이다.

아래 부터 코드 정리 방법을 다룬다.

1. 보호 구문으로 풀어 정리하기

중첩된 조건문은 헷갈리게 하기 쉬우니 읽기 쉽게 중첩을 풀어서 정리한다.

그러나 보호 구문으로 푸는 행위를 남용해선 안된다.

// as-is
if (조건)
    if (다른 조건)
        ...코드...

// to-be
if (조건 부정) return
if (다른 조건) return
...코드...

보호 구문으로 풀다보면 아래 코드 처럼 한 번에 정리가 안되는 경우가 있는데, 이 때는 한 번에 정리하려고 하지 말고 반드시 작은 단계를 거쳐서 코드를 정리해야한다.

if (조건)
    ...코드...
...다른코드...

2. 안 쓰는 코드 지워 정리하기

안쓰는 코드? 그냥 지운다.

가까운 미래에 사용될 것 같은데? 아니, 그냥 지운다.

Deprecated API이긴 한데 다시 부활할 수 있으니까 주석 처리만 할까? 아니, 그냥 지운다.

단, ‘조금만’ 삭제해야한다.

3. 대칭으로 맞춰 정리하기

같은 기능도 코드로 작성하는 방법은 여러 방법이 있다. 같은 기능이라면 비슷한 모습으로 정리한다.

비슷한 모습이 아닌 경우의 문제점은 '다른 동작의 코드겠지' 하고 예단하게되고 코드 간의 공통성이 있는데도 세부 사항에 묻혀서 드러나지 않기 마련이라 같은 기능 또는 공통점이 있는 코드는 비슷한 형태로 정리하는게 좋다.

구체적으로 대칭이 맞춰지지 않은 코드는 아래 예시와 같다.

ex) 어떤 코드는 for 문 처리 어떤 코드는 stream 으로 처리하여 같은 기능인지 헷갈리게 하기

ex) 어떤 코드는 삼항연산자(?:)로 구현하고 어떤 코드는 if-else 문으로 구현하여 같은 기능인지 헷갈리게 하기

// A 기능 구현 방법 1
for(int i = 0; i < users.size(); i++) {
   if (조건) {
      // ...코드...
   }
}

// A 기능 구현 방법 2
users.stream()
    .filter(조건)
    .forEach(it -> ...코드...);

4. 새로운 인터페이스로 기존 루틴 부르기

기존에 있던 인터페이스 때문에 어렵거나 복잡해지면 새로운 인터페이스를 만들어서 새로운 인터페이스가 기존 인터페이스를 호출하도록 정리한다.

5. 읽는 순서 정리하기

코드를 봤을 때, 읽는 입장에서 전체를 이해하는 데 요긴한 부분이 먼저 올 수 있도록 순서를 바꿔 정리한다.

순서에 정답은 없으나 오늘 내가 코드를 읽을 때, 읽는 순서에 가장 영향을 주는 부분이라고 판단한 것을 앞으로 옮겨준다.

6. 응집도를 높이는 코드 배치 다시하기

코드의 순서를 바꿔서 변경할 요소들을 가까이 두어 정리한다.

두 루틴에 결합도가 있으면 가까이 둔다.

두 파일에 결합도가 있으면 같은 디렉토리에 둔다.

위에서 유사한 코드는 대칭을 맞춰주는 방법처럼 결합도가 있는 코드를 가까이 두면 나중에 정리할 대상으로 눈에 띄기 좋다.

응집도를 높이는 작업을 하다보면 결합도도 좋아질 수 있다.

7. 선언과 초기화를 함께 옮기기

변수가 사용될 때 선언과 초기화를 같이 해주도록 코드를 옮겨 정리한다.

하나씩 옮기고 그래도 불안하고 무섭다면 더 작은 단계로 진행한다.

8. 설명하는 변수로 추출하여 정리하기

// as-is
return new Point(
    ...긴 표현식...,
    ...다른 긴 표현식...
)

// to-be
x = ...긴 표현식....;
y = ...다른 긴 표현식...;
return new Point(x,y);

코드를 읽는데 긴 표현식이 있다면 변수로 추출하여 정리한다.

9. 설명하는 상수 만들어주기

코드에서 상수가 나타나면 상징적인 상수로 바꾸는 정리법을 수행한다.

// as-is
if (response.code == 404) {
    ...코드...
}

// to-be
private static int NOT_FOUND = 404;
if (response.code == NOT_FOUND) {
    ...코드...
}

가끔 우연히 같은 상수(ex 금액 천원 단위 절삭용 1,000과 본문 글자수 제한용 1,000)가 있을 수 있어 다른 의미로 쓰이진 않는지 주의해야한다.

10. 명시적인 매개변수 사용하기

어떤 코드를 보는데 입력(매개변수)이 명확하지 않은 코드를 발견했다면 입력을 명확하게 하는 코드로 바꾼다.

입력이 명확하지 않은 코드의 예시는 아래 처럼 Map을 메서드 매개변수로 받기 것과 같은 것이다.

// as-is
params = {a:1, b:2}
foo(params)

function foo(params)
    ...params.a... ... params.b...

// to-be
function foo(params)
    foo_body(params.a, params.b)

function foo_body(a,b)
    ...a... ...b...

foo 함수의 매개변수를 바로 바꾼게 아니라 foo 함수는 그대로 두고 foo_body 함수를 만들어서 코드 정리로 마친 것을 확인하자.

11. 비슷한 코드끼리 분리해주기

긴 코드 덩어리를 읽다가 구분되는 지점에 빈 줄 넣어 정리한다.

관련있는 코드 끼리 뭉쳐주면 다양한 길로 나아갈 수 있는 여지 마련하기 때문에 빈 줄 하나 넣는 것도 코드 정리가 될 수 있다.

12. 도우미(helper)로 추출하기

코드를 읽는 도중 목적이 분명하고 나머지 코드와 상호작용이 적은 코드 블록을 만났다면 그 블록을 도우미 클래스로 추출하고 적절한 이름을 붙여 준다.

유틸리티 메서드도 마찬가지다.

13. 하나의 더미로 코드 모으기

코드가 너무 작은 단위로 쪼개져있다고 느껴지면 오히려 하나로 모아 정리한다.

작은 코드 조각을 지향하는 목적은 코드를 한 번에 조금씩 이해할 수 있도록 하는 것이다.

그런데 때때로 코드를 작게 쪼개는 그 과정이 잘못될 수 있는데 이 때 명확성을 되찾기 위해서 먼저 코드를 한데 모으고 다시 이해하기 어려운 부분은 추출해서 새롭게 정리하는 과정을 거치도록 한다.

14. 설명하는 주석달기

‘아, 이건 이렇게 돌아가는거구나!’라는 생각이 드는 순간(=코드에서 명확하지 않은 내용)을 주석으로 기록하여 정리한다.

이 행위의 요점은 다른 사람의 관점에서 생각하고 예상되는 질문을 선제적으로 언급하려고 노력하는 것이다.

코드에 결함을 발견했다? 즉시 해당 위치에 주석을 달아 정리한다.

15. 불필요한 주석 지우기

코드만으로 내용을 이해할 수 있으면 주석을 지운다. (주석 반대론자는 아니다.)

Part 2 - 코드 정리와 코드 변경 관리 노하우

팀 또는 개인이 언제, 어떻게 코드를 정리 해야하는가?

코드 정리를 언제 시작하고 언제 멈추나?

구조를 변경하는 코드 정리와 시스템 동작 변경을 어떻게 결합할 수 있을까?

아래부터는 위 질문들에 대한 해답 보다는 판단 기준을 제시해준다.

1. 코드 정리는 별도의 PR로 수행하기

결론부터 말하면 딱 하나의 정리만 있더라도 코드 정리 PR은 분리한다.

• 코드 정리 PR을 하는 방법
  • 1개의 PR에 코드 정리를 다 하는 방법
  • 여러 개의 PR로 분할하고 PR 마다 하나의 코드 정리 방법만 적용하는 방법

1개의 PR에 코드 정리를 다 하는 방법은 다소 위험한 부분이 있다.

변경이 변경을 낳는다는 점을 유의해야한다. 구조 변경(코드 정리)을 적용하다보면 동작 변경하기 쉬워져서 코드 정리만 하려고 한 활동인데 동작 변경을 하려고한다.

이게 섞여서 하나의 PR에서 처리된다면, 전체적인 그림을 볼 수 있는 장점도 있지만 검토하는 입장에서 유용한 피드백을 제공하기에는 너무 큰 덩어리라 유용한 피드백을 제공하기 힘들다는 단점도 있다.

반대로 아주 작은 PR은 소소한(또는 유용한) 피드백을 유도하기 좋고 검토하는 입장에서 비용도 적게 드는 장점이 있지만, PR 자체가 무시될 확률이 높아지는 단점도 있다.

작은 PR에서 최악의 경우는 리뷰가 느린 경우인데 이렇게 관리되면 피드백을 받느라 대기만 할 수 없으니 점점 나중에 더 큰 PR을 만드는 결과를 초래해서 악순환된다.

장단점이 있지만 추천하는 방법은 역시 PR을 더 작게 분리하는 것이다.

코드 정리를 반복해서 조직이 리뷰에도 적응하고 더 강화된 반복을 하다보면, 코드 정리 PR은 그냥 머지하는 시도를 해볼 수 있다.

그렇다면 단점이 어느정도 상쇄되기 때문에 더 나은 방법이 될 수 있다.

2. 연쇄적인 정리 금지하기

정리를 하다보면 계속하고 싶어지는데 정리의 단계 크기를 아주 작게 유지하는 것이 원칙이다.

아까 변경이 변경을 낳는다고 한 것 처럼 하나의 정리법을 적용하면 다른게 보이는데 많이 또는 크게 정리하다보면 무리한 정리가 되어 실패하게될 수 있어서 작은 단위로 관리하는 것이 중요하다.

3. 코드 정리의 일괄 처리량 조율하기

통합과 배포 전 얼마나 코드 정리를 하는게 적절한가?

기본적으로 코드 정리는 먼 미래를 바라보는 것이 아니기 때문에 즉각적으로 다룰 필요가 있는 만큼 정리되어야 한다. (=적절한 타협이 필요함)

출처 : https://books.google.co.kr/books?id=UZgFEQAAQBAJ&newbks=0&printsec=frontcover&pg=RA1-PA48&dq=tidy+first&hl=ko&source=newbks_fb&redir_esc=y#v=onepage&q=tidy%20first&f=false

• 코드 정리의 양이 많을 수록 아래 사유로 비용 증가
  • 우연히 코드 변경을 할 가능성이 높아짐
  • 코드 충돌 가능성이 높아짐
  • 코드 정리가 많다는 것은 이후 코드 변경이 많아지고 그로인해 생기는 추가 비용 가능성 높아짐
• 코드 정리의 양이 적을 수록 아래 사유로 비용 증가
  • 검토를 자주해야하는 비용 증가
  • PR 준비 비용 증가

일반적으로 총 비용이 적게드는 적절한 지점을 찾아 적용하기 마련이다.

그런데 꼭 중간 값이어야할 필요가 있을까?

그냥 코드 정리의 양을 작게하는 대신 강력한 문화가 동작한다면 아주 작은 코드 정리는 리뷰를 하지 않게 하여 비용을 없앨 수 있지 않을까? (물론 성공하는데는 적어도 몇 달 걸린다.)

4. 코드 정리와 코드 변경간의 리듬 정하기

코드 정리하는 즐거움은 계속하고 코드 변경은 아주 조금만 하는게 정상일까?

아니면 코드 정리는 최소한으로하고 코드 변경 강행군을 계속하는게 정상일까?

코드 정리와 코드 변경은 적절히 리듬을 만들어야하는데 제안하는 방법은 코드 정리는 분 단위로 관리하고 최대 1시간이 넘으면 안되게 관리하는 것이다.

한 번의 코드 정리 시간이 1시간이 넘으면 이미 동작 변경에 필요한 최소한의 구조 변경 시기를 놓쳤다는 의미다.

설령 코드 정리를 충분히 한 후에 동작 변경을 하는게 모두가 봐도 유리한 경우가 있을 수 있는데 그럼에도 불구하고 코드 정리를 오래 지속해서는 안 된다.

5. 얽힘 푸는 것으로 되돌아가기

코드 정리를 적당히 하고 동작 변경을 위해 테스트 코드 작성한 후 동작 변경을 이제 하려는데 코드 정리가 더 필요하다는 것을 깨달은 경우에는 어떻게 관리해야할까?

다시 말해 정리와 변경 과정에서 변경 대상의 동작을 모두 알게되었고 그 동작을 쉽게 변경하기 위해 어떤 코드를 정리해야하는지까지 모두 알게 되었으나 정리 코드와 변경 코드가 얽혀 버렸다. 이것은 어떻게 할 것인가?

그 답은 과감하게 이미 작업한 테스트 코드와 동작 변경을 버리고 다시 코드 정리를 하는 선택지를 해보는 것으로 실험해보도록 하고 관리 규칙을 정한다.

6. 코드 정리 시점을 정하는 규칙

• 다음 상황에서는 코드 정리를 하지 마세요.
  • 앞으로 다시는 코드를 변경하지 않을 때
  • 설계를 개선하더라도 배울 것이 없을 때
• 다음 상황에서는 코드 정리를 나중으로 미루세요.
  • 정리할 분량이 많은데, 보상이 바로 보이지 않을 때
  • 코드 정리에 대한 보상이 잠재적일 때
  • 작은 묶음으로 여러 번에 나눠서 코드 정리를 할 수 있을 때
• 다음 상황에서는 동작 변경 후에 코드 정리를 하세요.
  • 다음 코드 정리까지 기다릴수록 비용이 더 불어날 때
  • 코드 정리를 하지 않으면 일을 끝냈다는 느낌이 들지 않을 때
  • 코드 정리하는 데 드는 시간이 동작 변경에 드는 시간과 거의 비슷할 때
• 다음 상황에서는 코드 정리 후 동작 변경을 하세요.
  • 코드 정리를 했을 때 코드 이해가 쉬워지거나 동작 변경이 쉬워지는 즉각적인 효과가 있을 때
  • 어떤 코드를 어떻게 정리해야하는지 알고 있을 때

Part 3 - 코드 정리를 해야하는 이유와 하지 말아야하는 이유 (이론)

코드 정리를 해야하는 이유와 코드 정리를 하지 말아야하는 이유(?)에 대해서 이론적으로 살펴본다.

• 소프트웨어 설계란 무엇인가?
  • 소프트웨어 설계는 인간관계 속에서 벌어지는 활동
  • 소프트웨어 설계의 의미는 요소들을 유익하게 관계 맺는 일
• 소프트웨어 설계의 목표는 무엇인가?
  • 소프트웨어 가치를 극대화 하는 것
  • 소프트웨어의 비용을 최소화 하는 것
• 소프트웨어가 가치를 만드는 방식 2가지
  1. 현재 소프트웨어가 제공하는 가치
     • ex) 1 달러의 비용을 지불하고 10달러를 벌어오는 소프트웨어
  2. 미래에 새로운 일을 시킬 수 있는 가능성
     • ex) 10달러의 비용을 지불하고 100달러를 벌어오는 소프트웨어로 만들 수 있는 가능성
     • ex) 1달러의 비용을 지불하고 20달러를 벌어오는 소프트웨어로 만들 수 있는 가능성

두 번째 방법은 미래의 가능성이기 때문에 얼마나 더 투자를 해야 언제부터 더 가치있는 소프트웨어가 되는지 불확실하다.

맞는 말이긴 하지만, 그렇기 때문에 확실하게 돈을 버는(=가치를 만드는) 방법이 있다.

바로 우리 소프트웨어가 어떤 형태로든 진화할 수 있도록 유연한 구조로 만들어 놓는 것이다.

즉, “10달러의 비용을 지불하고 100달러를 벌어올 수 있도록” 또는 “1달러의 비용을 지불하고 20달러를 벌어올 수 있도록” 준비(정리)를 하는 일을 하는 것은 당장 확실하게 돈을 버는 방법이다.

그럼에도 여전히 돈을 버는게 맞는지? 하는 의문이 남을 수 있다.

왜냐하면 진짜로 우리가 구조 변경에 투자했는지 측정할 수 없고, 구조 변경을 했기 때문에 진짜 더 쉽게 변경할 수 있는 것인지, 이 구조가 최선이었는지 등을 측정할 수 없기 때문이다.

이에 대한 답은 스스로 찾아야 하지만 코드 정리는 보통 적은 비용으로 되돌릴 수 있는 일이기에 리스크를 적게 가져가고 리턴이 분명히 있는 작업이란 것은 알아두어야 한다.

1. 시간 가치(오늘의 1달러가 내일의 1달러보다 크다)

10년동안 1,000만 달러의 비용을 들여 2,000만 달러를 벌어들이는 시스템 vs 10년동안 1,000만 달러의 비용을 들여 1,200만 달러를 벌어들이는 시스템, 무엇을 선택할 것인가?

바보가 아닌 이상 기대값이 더 높은 2,000만 달러를 벌어들이는 시스템을 선택을 하겠지만 질문의 함정은 “시간 가치”에 있다.

똑같은 질문을 시간 가치를 포함해서 질문하면 어떻게 될까?

오늘 1,000만 달러를 지불하고 10년 후에 2,000만 달러를 벌어오는 시스템 vs 오늘 1,200만원을 받고 10년 후에 1,000만 달러를 지불하는 시스템, 무엇을 선택할 것인가?

두 번째 질문에서 전자는 10년 동안 긴장하게 하고 불안하게 한다. 심지어 진짜 2,000만 달러를 벌어올 수 있는지도 불확실하다.

후자는 전혀 불안하지않다. 오히려 기대에 차게된다.

왜냐하면 그 즉시 차액인 200만 달러의 수익이 보장되었고 이후 투자를 통해 얻을 수 있는 수익 또한 기대해볼 수 있기 때문이다.

위 예시로 시간 가치를 이해했다면 코드로 적용했을 때 “지금 당장 돈을 벌 수 있는 일(=동작 변경)을 하라”는 말이다.

단, 그것이 코드 정리와 뒤따르는 동작 변경의 비용 합계가 즉시 동작 변경하는것보다 더 클 때 말이다.

2. 옵션

“다음에 어떤 동작을 구현할 수 있을까?” 라는 질문을 스스로 하면서 개발하는 것은 가치있는 일이다.

이 질문에 후보 목록이 많을수록 더 가치가 있다.

그 중에 어떤 항목이 가장 가치가 있을지 생각하는 것은 구현할 수 있는 옵션을 계속 열어두는 한 신경쓸 필요가 없다.

그런 의미에서 코드 정리는 일종의 콜옵션의 프리미엄(계약금)이다.

콜옵션은 미래에 고정된 가격으로 무언가 살 수 있는 권리이고 의무는 없다. (행사할 수도 있고 행사하지 않을 수도 있음)

코드 정리를 하는 약간의 비용(=프리미엄)을 주고 미래(옵션을 구매할지 여부 결정하는 기간 또는 필요한 시점)에 고정된 가격(당연하게도 프리미엄을 포함하여 그냥 샀을 때보다 싼 가격)을 지불하고 동작 변경을 얻는 개념이다.

다만, 옵션은 나중에 돈을 벌기 위해(심지어 정확하게 어떻게 벌지 모르더라도) 지금 돈을 쓰라고 하기 때문에 옵션을 만드는데 비용을 마구 사용해서는 안된다.

시간의 가치에서 배운 것이 지금 돈을 벌고 비용은 나중에 지불하는게 좋다는 것이다.

옵션을 만드는 것과 동작을 변경하는 것의 균형을 맞추는데 집중을 해야한다.

3. 되돌릴 수 있는 구조 변경

구조 변경은 대체로 되돌릴 수 있고 동작 변경은 대체로 되돌릴 수 없다.

구조 변경, 코드 정리를 했는데 뭔가 적절하지 않다면 어떻게 할까? 되돌리면 된다.

하지만 반대로 금액을 잘못 찍은 세금계산서 10만 건을 발송해버리는 동작 변경을 해버렸다면 되돌릴 수 없고 그것을 해결하기 위한 비용까지 합하면 아주 큰 비용이 들 것이다.

이는 되돌릴 수 있는 결정과 되돌릴 수 없는 결정은 큰 차이가 있다는 것이다.

그렇다면 우리는 되돌릴 수 없는 일에 신중을 가하는 즉, 투자를 많이 해야한다는 것이다.

그런데 또 되돌릴 수 없는 일을 두 세번씩 검토하는 비용을 적게 해주는 것이 되돌릴 수 있는 일이 코드 정리라면 그 두 작업간의 비중은 적절히 균형을 유지해야한다는 것이다.

4. 결합도와 결합도 제거

소프트웨어 가격이 비싼 이유에 대한 연구하면서 비싼 소프트웨어에서 나타난 공통점이 있는데 그것은 한 요소를 변경하려면 다른 요소도 변경해야한다는 것이었다.

반대로 저렴한 소프트웨어는 좁은 범위의 코드 변경만 필요한 경향이 나타났다.

출처 : https://books.google.co.kr/books?id=-WndEAAAQBAJ&pg=PA51&lpg=PA51&dq=tidy+first&source=bl&ots=X6nj6NDqBP&sig=ACfU3U02fY_6_kjBKi0GZoHLrFKuatsBZg&hl=ko&sa=X&ved=2ahUKEwjb99KH3_uFAxW-iq8BHfLPB344FBDoAXoECAIQAw#v=onepage&q=tidy first&f=false

다소 비약적으로 말하면 결합도가 소프트웨어 비용을 좌우한다고 바꿔말할 수 있다.

이번에는 소프트웨어의 생애주기에서 사용된 비용을 분석해봤는데 유지보수에 70% 이상 아니, 그보다 훨씬 더 비중을 차지한다는 것을 알아냈다.

다소 비약적으로 말하면 전체 소프트웨어 비용은 그것을 변경하는 데 드는 비용과 거의 같다. (소프트웨어 비용 ~= 소프트웨어 변경 비용)

모든 변경은 비용이 다 비슷할까? 그렇지 않다.

소프트웨어 생애주기에 따른 누적 비용 그래프 곡선을 보면 급격하게 증가하는 포인트들이 있는데 그 원인은 출시 초기 작은 변경이 아니라 중간에 큰 몇몇 변경이 때문이다.

다소 비약적으로 말하면 소프트웨어 전체 변경 비용은 큰 몇몇 변경에 드는 비용과 거의 같다. (소프트웨어 변경 비용 ~= 큰 변경 비용)

작은 변경 비용보다 큰 변경 비용이 비싼 이유는 뭘까? 정비례하지 않는 이유는 뭘까?

바로 어떤 요소를 변경하려고 했을 때 다른 요소도 같이 변화해야하는 것들이 많아지고 한 번만 일어나는 게 아니라 변경 내내 계속 전파되는 특성 때문이 아닐까?

이 특성이 뭐더라? 결합도. (큰 변경 비용 ~= 결합도)

삼단논법으로 다음의 수식을 얻을 수 있다.

→ 소프트웨어 비용 ~= 소프트웨어 변경 비용 ~= 큰 변경 비용 ~= 결합도

→ 소프트웨어 비용 ~= 결합도

“그래 좋았어, 결합도는 나쁜거야, 모든 결합도를 제거할거야!” 라는 생각은 잘못 되었다.

결합도는 나쁜 것도 아니고 결합도가 있어야 하는 정당한 이유는 방금 전까지만 해도 문제가 되지 않았기 때문이다.

그래서 결합도를 제거하는 비용과 결합도 때문에 발생하는 비용을 절충해서 결합도가 적당히 유지되도록 또는 결합도를 적당히 제거되도록 하는게 좋다는 결론이다.

결론

책 제목처럼 “코드 정리가 먼저인가?” 라는 질문에 답을 하기 위해서는 아래 4가지 힘을 참고하고 결정하세요.

• 비용
  • 코드를 정리하면 비용이 주는가? 줄일 가능성이 있는가? 나중에 하는게 낫나?
• 수익
  • 코드를 정리하면 수익이 생기나? 수익이 더 빨리 생기거나 커지게 할 가능성이 있는가?
• 결합도
  • 코드를 정리하면 변경에 필요한 요소의 수가 줄어드는가?
• 응집도
  • 코드를 정리하면 변경을 더 좁은 범위로 집중시켜 더 적은 요소만 다룰 수 있게되는가?

코드 정리에 영향받는 사람은 바로 나 자신이기 때문에 만족할 가능성이 매우 높다.

그렇기에 코드 정리를 더욱더 하고 싶겠지만 적절하게 멈출줄도 알아야한다.

그게 어렵기 때문에 위의 기준을 근거로 결정 하겠지만, 그 결정을 할 때도 “코드 정리를 해야한다” 쪽으로 생각하게 되는 것을 항상 경계해야한다.

아래는 책 마지막에 나오는 글귀(Q&A)를 살짝 각색했다.

Q. 아니 그래서 코드 정리를 먼저 하실 건가요?

A. 아마도요. 여러분을 위해서 충분히 그만한 가치가 있습니다. 소프트웨어 설계는 인간관계 속에서 벌어지는 활동이고 그 활동이 진솔한 활동이 될 수 있도록 하자는 취지니까요.