클린 코드(Clean Code) - 14장, 15장, 16장, 17장

14장. 점진적인 개선 📌

  나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다. 나쁜 일정은 다시 짜면 된다. 나쁜 요구사항은 다시 정의하면 된다. 나쁜 팀 역학은 복구하면 된다. 하지만 나쁜 코드는 썩어 문드러진다. 점점 무게가 늘어나 팀의 발목을 잡는다. 속도가 점점 느려지다 못해 기어가기도 한다. 너무 서두르다가 이후로 영원히 자신들의 운명을 지배할 악성 코드라는 굴레를 짊어진다.

  물론 나쁜 코드도 깨끗한 코드로 개선할 수 있다. 하지만 비용이 엄청나게 많이 든다. 코드가 썩어가며 모듈은 서로서로 얽히고설켜 뒤엉키고 숨겨진 의존성이 수도 없이 생긴다. 오래된 의존성을 찾아내 깨려면 상당한 시간과 인내심이 필요하다. 반면 처음부터 코드를 깨끗하게 유지하기란 상대적으로 쉽다. 아침에 엉망으로 만든 코드를 오후에 정리하기는 어렵지 않다. 더욱이 5분 전에 엉망으로 만든 코드는 지금 당장 처리하기 아주 쉽다.

  그러므로 코드는 언제나 최대한 깔끔하고 단순하게 정리하자. 절대로 썩어가게 방치하면 안 된다. 

(해당 장에서는 Args.java라는 코드를 점진적으로 개선하는 방법을 소개한다. 책을 통해 어떻게 점차적으로 개선하는지 살펴보길 바란다.)

 

15장. JUnit 들여다보기 👑

  해당 장에서는 ComparisonCompactorTest.java로 ComparisonCompactor 모듈에 대해서 100% 코드 커버리지 분석을 수행한 것을 보여준다. 그리고 디팩터링(= 리팩터링의 반대 과정)된 ComparisonCompactor 코드에서 출발하여 어떻게  어느 정도 수준에 이르는 ComparisonCompactor를 만들었는지 보여준다. (책에 나온 코드를 참고하길 바란다.)

 

16장. SerialDate 리팩터링 👓

  16장에서는 http://www.jfree.org/jcommon/index.php에서 제공받은 JCommon 라이브러리에 있는 org.jfree.date 패키지의 SerialDate라는 클래스를 리팩터링을 진행한다. 

 

17장. 냄새와 휴리스틱 🤿

  Refactoring의 저자인 마틴 파울러가 맡은 코드 냄새에 이 책의 저자가 맡은 냄새를 추가하여 냄새들을 소개한다. 그리고 저자가 코드를 짜면서 사용하는 기교와 휴리스틱도 포함한다.

• 주석으로 처리된 코드를 발견하면 즉각 지워버려라!
    걱정할 필요 없다. 소스 코드 관리 시스템이 기억하기 때문이다. 누군가 정말로 필요하다면 이전 버전을 가져오면 된다. 주석으로 처리된 코드를 내버려 두지 마라.
• 빌드는 간단히 한 단계로 끝나야 한다.
    소스 코드 관리 시스템에서 이것저것 따로따로 체크아웃할 필요가 없어야 한다. 불가해한 명령이나 스크립트를 잇달아 실행해 각 요소를 따로 빌드할 필요가 없어야 한다. 온갖 JAR 파일, XML 파일, 기타 시스템에 필요한 파일을 찾느라 여기저기 뒤적일 필요가 없어야 한다. 한 명령으로 전체를 체크아웃해서 한 명령으로 빌드할 수 있어야 한다.
• 출력 인수는 직관을 정명으로 위배한다. 
    일반적으로 독자는 인수를 (출력이 아니라) 입력으로 간주한다. 함수에서 무언가의 상태를 변경해야 한다면 (출력 인수를 쓰지 말고) 함수가 속한 객체의 상태를 변경한다. 객체 지향 프로그래밍이 나오기 전에는 출력 인수가 불가피한 경우도 있었다. 하지만 객체 지향 언어에서는 출력 인수를 사용할 필요가 거의 없다. 출력 인수로 사용하라고 설계한 변수가 바로 this이기 때문이다. 다시 말해, append Footer는 다음과 같이 호출하는 방식이 좋다.
  (출력 인수와 관련해서 다음 글을 읽어보기를 바란다. https://lordofkangs.tistory.com/m/194)
• 당연하게 여길 만한 동작과 기능을 제공해야 한다.
    최소 놀람의 원칙(The Principle of Least Surprise)에 의거해 함수나 클래스는 다른 프로그래머가 당연하게 여길 만한 동작과 기능을 제공해야 한다. 당연하다고 생각되는 동작과 기능의 예시는 다음과 같다. 아래와 같이 요일 문자열에서 요일을 나타내는 enum으로 변환하는 함수가 있다고 하자. 다른 프로그래머는 함수가 'Monday'를 Day.MONDAY로 변환하리라 기대하고, 일반적으로 쓰는 요일 약어도 올바로 변환하리라 기대하고, 대소문자는 당여힌 구분하지 않으리라 기대한다.

Day day = DayDate.StringToDay(String dayName);

• DRY (Don't Repeat Yourself)
    코드에서 중복을 발견할 때마다 추상화할 기회로 간주하라. 중복된 코드를 하위 루틴이나 다른 클래스로 분리하라.
    가장 뻔한 유형은 똑같은 코드가 여러 차례 나오는 중복이다. 이런 중복은 간단한 함수로 교체한다.
    좀 더 미묘한 유형은 여러 모듈에서 일련의 switch/case나 if/else 문으로 똑같은 조건을 거듭 확인하는 중복이다. 이런 중복은 다형성(polymorphism)으로 대체해야 한다.
    더더욱 미묘한 유형은 알고리즘이 유사하나 코드가 서로 다른 중복이다. 중복은 중복이므로 TEMPLATE METHOD 패턴이나 STRATEGY 패턴으로 중복을 제거한다.
• 선택자 인수를 사용하지 마라
    선택자(selector) 인수는 목적을 기억하기 어려울 뿐 아니라 각 선택자 인수가 여러 함수를 하나로 조합한다. 선택자 인수는 큰 함수를 작은 함수 여럿으로 쪼개지 않으려는 게으름의 소산이다. 물론 부울 인수만이 문제라는 말은 아니다. enum, int 등 함수 동작을 제어하려는 인수는 하나 같이 바람직하지 않다. 일반적으로, 인수를 넘겨 동작을 선택하는 대신 새로운 함수를 만드는 편이 좋다. 
• 부적절한 static 함수를 사용하지 마라

Math.max(double a, double b) // 좋은 static 함수
HourlyPayCalculator.calculatePay(employee, overtimeRate); // 적절하지 않은 static 함수

  두 번째 줄의 함수는 적절하지 않은 static 함수이다. 함수를 재정의할 가능성이 존재하고 수당을 계산하는 알고리즘이 여러 개일지도 모르기 때문이다.

  일반적으로 static 함수보다 인스턴스 함수가 더 좋다. 조금이라도 의심스럽다면 인스턴스 함수로 정의한다. 반드시 static 함수로 정의해야겠다면 재정의할 가능성은 없는지 꼼꼼히 따져보자.

• If/Else 혹은 Switch/Case 문보다 다형성을 사용하라
    이유는 다음과 같다. 첫째, 대다수 개발자가 switch 문을 사용하는 이유는 그 상황에서 가장 올바른 선택이기보다는 당장 손쉬운 선택이기 때문이다. 그러므로 switch를 선택하기 전에 다형성을 먼저 고려하라.
    둘째, 유형보다 함수가 더 쉽게 변하는 경우는 극히 드물다. 그러므로 모든 switch 문을 의심해야 한다. 
• 조건을 캡슐화하라

if (shouldBeDeleted(timer)) // 좋다.
if (timer.hasExpired() && !timer.isRecurrent()) // 나쁘다.

• 부정 조건은 피하라

if (buffer.shouldCompact()) // 좋다.
if (!buffer.shouldNotCompact()) // 나쁘다.

• 숨겨진 시간적인 결합
    때로는 시간적인 결합이 필요하다. 하지만 시간적인 결합을 숨겨서는 안 된다. 함수를 짤 때는 함수 인수를 적절히 배치해 함수가 호출되는 순서가 명백히 드러낸다. 아래는 시간적인 결합을 강제하지 않은 코드와 일종의 연결 소자를 생성해 시간적인 결합을 노출한 코드이다.

// 시간적인 결합을 강제하지 않은 코드
public class MoogDiver {
    Gradient gradient;
    List<Spline> splines;
    
    public void dive(String reason) {
        saturateGradient();
        reticulateSplines();
        diveForMoog(reason);
    }
    ...
}

// 일종의 연결 소자를 생성해 시간적인 결합을 노출한 코드
public class MoogDiver {
    Gradient gradient;
    List<Spline> splines;
    
    public void dive(String reason) {
        Gradient gradient = saturateGradient();
        List<Spline> splines = reticulateSplines(gradient);
        diveForMoog(splines, reason);
    }
    ...
}

• 추이적 탐색을 피하라
    일반적으로 한 모듈은 주변 모듈을 모를수록 좋다. 좀 더 구체적으로, A가 B를 사용하고 B가 C를 사용한다 하더라도 A가 C를 알아야 할 필요는 없다는 뜻이다. 예를 들어 a.getB(),getC().doSomething();은 바람직하지 않다.
    이를 디미터의 법칙(Law of Demeter)이라 부른다. 이것은 자신이 직접 사용하는 모듈만 알아야 한다는 뜻이다. 내가 아는 모듈이 연이어 자신이 아는 모듈을 따라가며 시스템 전체를 휘저을 필요가 없다는 의미다.
    여러 모듈에서 a.getB().getC()라는 형태를 사용한다면 설계와 아키텍처를 바꿔 B와 C 사이에 Q를 넣기가 쉽지 않다. a.getB().getC()를 모두 찾아 a.getB().getQ().getC()로 바꿔야 하기 때문이다. 너무 많은 모듈이 아키텍처를 너무 많이 안다. 그래서 아키텍처가 굳어진다.
    내가 사용하는 모듈이 내게 필요한 서비스를 모두 제공해야 한다. 원하는 메서드를 찾느라 객체 그래프를 따라 시스템을 탐색할 필요가 없어야 한다. 다시 말해, myCollaborate.doSomething();과 같은 간단한 코드로 충분해야 한다.
• 긴 import 목록을 피하고 와일드카드를 사용해라
    패키지에서 클래스를 둘 이상 사용한다면 와일드카드를 사용해 패키지 전체를 가져오라. 긴 import 목록은 읽기에 부담스럽다. 사용하는 패키지를 간단히 명시하면 충분하다.
    명시적인 import 문은 강한 의존성을 생성하지만 와일드카드는 그렇지 않다. 명시적으로 클래스를 import 하면 그 클래스가 반드시 존재해야 한다. 하지만 와일드카드로 패키지를 지정하면 특정 클래스가 존재할 필요가 없다. import 문은 패키지를 단순히 검색 경로에 추가하므로 진정한 의존성이 생기지 않는다. 그러므로 모듈 간에 결합성이 낮아진다.
    명시적으로 import 문을 길게 나열해야 하는 경우도 있다. 예를 들어, 레거시 코드를 사용하면서 테스트용 모듈이나 스텁을 빌드할 클래스를 찾으려 한다면, 기다란 import 문을 하나씩 짚어가며 클래스 전체 이름을 찾은 후 적절한 스텁을 배치해야 하리라. 하지만 이렇게 명시적으로 import 문을 사용하는 경우는 극히 드물다. 게다가 요즘 IDE 대다수는 간단한 명령 하나로 와일드카드 import 문을 명시적인 import 문 목록으로 바꿔준다. 그러므로 레거지 코드라도 와일드카드 import 문을 사용하는 편이 좋다.
    와일드카드 import 문은 때로 이름 충돌이나 모호성을 초래한다. 이름이 같으나 패키지가 다른 클래스는 명시적인 import 문을 사용하거나 아니면 코드에서 클래스를 사용할 때 전체 경로를 명시한다. 다소 번거롭지만 자주 발생하지 않으므로 여전히 와일드카드 import 문이 명시적인 import 문보다 좋다.
• Enum을 마음껏 활용하라!
    public static final int라는 옛날 기교를 더 이상 사용할 필요가 없다. int 코드에서 의미를 잃어버리기도 한다. 반면 enum은 그렇지 않다. enum은 이름이 부여된 열거체(enumeration)에 속하기 때문이다.
    한 가지 덧붙이자면, enum 문법을 자세히 살펴보기 바란다. 메서드와 필드도 사용할 수 있다. int보다 훨씬 더 유연하고 서술적인 강력한 도구다.
• 이름으로 부수 효과를 설명하라
    함수, 변수, 클래스가 하는 일을 모두 기술하는 이름을 사용한다. 이름에 부수 효과를 숨기지 않는다.

public ObjectOutputStream getOos() throws IOException {
    if (m_oos == null) {
        m_oos = new ObjectOutputStream(m_socket.getOutputStream());
    }
    return m_oos;
}

  위 함수는 단순히 "oos"만 가져오지 않는다. 만약 기존에 "oos"가 없으면 생성한다. 그러므로 createOrReturnOos라는 이름이 더 좋다.

• 커버리지 도구를 사용하라!
    커버리지 도구는 테스트가 빠뜨리는 공백을 알려준다. 커버리지 도구를 사용하면 테스트가 불충분한 모듈, 클래스, 함수를 찾기가 쉬워진다.

17장 결론

  이 장에서 소개한 휴리스틱과 냄새 목록이 완전하다 말하기는 어렵다. 아니, 완전한 목록이 가능하다고도 생각하지 않는다. 하지만 완전한 목록이 목표가 아니다. 여기서 소개한 목록은 가치 체계를 피력할 뿐이다.

  일군의 규칙만 따른다고 깨끗한 코드가 얻어지지 않는다. 휴리스틱 목록을 익힌다고 소프트웨어 장인이 되지는 못한다. 전문가 정신과 장인 정신은 가치에서 나온다. 그 가치에 기반한 규율과 절제가 필요하다.