Five Lines of Code 13장. 나쁜 코드를 식별 가능하게 만들기

안티-리팩터링(나쁜 코드를 딱 봐도 안 좋아 보이게 만들어서 품질의 수준을 명확히 표시하는 방법) 을 활용하여 식별 가능한 나쁜 코드를 만들 수 있다.

우리는 코드의 복잡성이나, 시간의 촉박함으로 인해 원하는 수준으로 리팩토링을 못할 때가 많다.

이럴때 '끔찍하지만 않게' 하는 어줍잖은 리팩토링보다는 차라리 엉망진창인 상황 그대로 두는 편이 낫다.

 

나쁜 코드를 남겨두었을 때 장점

1. 다시 찾기가 쉽다 

2.통제가 지속 가능하지 않다는 신호를 줄 수 있다.

 

=> 나쁜 코드를 남겨두어도 괜찮다는 심리적 안정감을 제공하는 분위기어야 한다.

 

코드를 나쁘게 놔두는 활동은 코드를 깨끗한 코드와 레거시 코드로 분리하는 역할도 한다.

깨끗한 코드와 레거시 코드가 한눈에 알아보기 쉽다면 그 비율도 쉽게 측정이 가능하고, 리팩터링 노력을 쏟을 곳을 결정하는데 도움을 준다.

 

리팩터링은 깨끗한 코드에서 가까운 파일부터 시작하는 것이 좋다.

why?

- 코드를 좋게 만들려면 주변 코드도 좋게 만들어야 하기 때문. -> 주변 코드가 양호하다면 그런 선작업이 필요 없음

- 깨진 유리창 이론(유리창이 하나 깨지고 나면 곧 더 많은 유리창이 깨진다.) -> 나쁜 코드가 있다면 그 주변에 나쁜 코드가 훨씬 더 많다.

 

나쁜 코드를 찾는 방법

다음과 같은 특징을 갖는 코드는 나쁜 코드라고 할 수 있다.

- 단순하고 구체적인 코드: 다섯줄 제한, if문음 함수 시작에만 배치 규칙을 어긋나는 코드

- 완전하고 추상적인 코드: 매직상수, 코드 중복등

- 순환 복잡도(객관적 알고리즘): for, while문이나 ||, && 와 같이 각각 경로를 둘로 나누는 코드

- 인지 복잡도(주관적 알고리즘): 메서드를 읽는 동안 많은 정보를 유지해야 하는 코드

 

코드를 안전하게 나쁜 코드로 보이기 위한 규칙

다음 세가지 규칙을 따른다.

1. 올바른 정보를 절대 훼손하지 말 것

정보가 정확하다는 전제 하에 기존 정보를 모두 보존해야 한다.

부정확하거나 불필요한 정보는 제거 할 수 있다.

 

2. 향후 리팩터링을 어렵게 만들지 말 것

자신이 리팩터링 하는 사람이 될 수 있다는 것을 염두하고 메서드 추출 위치에 빈칸 넣기 등 향후 리팩터링을 더 쉽게 만들어야 한다.

 

3. 결과를 한눈에 알 수 있을 것

깨끗한 코드와 구분할 수 있는 눈에 띄는 차이가 있음을 보장해야 한다.

 

나쁜 코드를 나쁘게 보이기 위한 방법

1. 열거형 사용

✓ 부울과 같은 명명된 상수를 열거형 값의 이름으로 유지하는 방법으로 정보를 파괴하지 않을 수 있다.

✓ 클래스로 타입코드 대체, 클래스로의 코드 이관, 삭제 후 컴파일 하기 등의 패턴 적용이 가능하므로 리팩터링을 어렵게 만들지 않는다.

✓ 열거형은 찾기 쉬워 눈에 띈다.

 

2. 정수형 및 문자열을 타입코드로 사용

간혹 열거형을 추가할 능력이 없거나 무엇을 빨리 동작시켜야 할 때가 있다. 이럴 때 int 나 string을 타입 코드로 사용할 때가 많다.

function area(width: number, shape: string) 
{
	if (shape === "circle")  // if (shape === CIRCLE) 등과 같은 열거형으로 변환 가능
    	return (width/2) * (width/2) * Math.PI;
    else if (shape === "square") 
    	return width * width;
}

 

문자열을 사용하면 텍스트가 상수 이름과 동일한 목적을 수행한다는 장점이 있다.

문자열 타입은 미리 선언할 필요가 없어 유연하다

if else if 조건절의 string 값을 열거형으로 자연스럽게 이전 시킬 수 있다.

 

3. 코드에 매직 넘버 넣기

실험적 코드나 리팩터링이 필요함을 강조하고 싶을 때 (저자는) 상수를 사용하거나 상수를 인라인으로 사용한다.

상수의 이름이 부정확하면 문제의식 없이 사용하여 정보가 파괴될 위험이 있으니 조심할 것 

 

4. 코드에 주석 넣기

✓주석 삭제 패턴을 잘 따랐다면 추가된 주석은 굉장히 눈에 띌 것이다.

✓주석에 적는 것은 무엇이든 정확하고 안전해야 한다.

✓메서드 이름에 사용할 수 있는 주석을 달면 리팩토링이 쉬워진다.

 

5. 코드에 공백 넣기

구조는 볼 수 있지만 이름을 지을 만큼 충분히 이해하지 못했을 때 주석 넣기 방법 대신 사용한다.

오해를 살만한 명시적인 공백은 조심해야 한다.

 

6. 이름을 기준으로 항목을 그룹화하기

캡슐화 후보로 표시하는 방법으로 그룹화 할 항목에 공통 접사를 붙일 수 있다.

공통점사는 데이터 캡슐화를 적용해야 한다는 신호이다.

 

7. 이름에 컨텍스트 추가하기

접사를 추가하는 것은 그 자체로 명확한 신호일 수 있지만 더 강조 표시해야 하는 경우 카멜케이스(camelCased)나 파스칼케이스(PascalCased) 형식의 이름에 밑줄을 추가할 수 있다. 

보통 접사와 함께 많이 사용하며 컨텐스트가 정확해야 한다.

 

8. 긴 메서드 만들기

일부 메서드들이 만족스럽지 못한 방식으로 추출된 것을 발견하면 하나로 합쳐서 하나의 긴 메서드로 만든다.

원래 메서드 이름에 오해의 소지가 없다면 메서드 명을 유지한다. 

주석을 활용하여 정보를 제공할 수도 있다.

 

9. 메서드에 많은 매개변수 넘기기

매개변수가 많은 메서드는 정의하는 쪽 호출 하는 쪽 모두 눈에 띈다.

데이터 객체나 구조체를 긴 매개변수 목록으로 만들면 유형과 이름을 모두 유지 할 수 있다.

 

10. getter 와 setter 사용하기

getter와 setter는 get,set 접두사가 붙는다. 이 메소드들은 데이터를 캡슐화할 부분을 명확하게 알게 해준다.