[Clean code] chapter 12. 창발성

창발성의 정의

창발(創發)또는 떠오름 현상은 하위 계층(구성 요소)에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상이다. 또한 불시에 솟아나는 특성을 창발성(영어: emergent property) 또는 이머전스 (영어: emergence)라고도 부른다. 자기조직화 현상, 복잡계 과학과 관련이 깊다.

창발은 새로운 것이 일시적인 과정, 창조가 성장이나 진화로서 일시적이 아닌 것으로 고찰되는 것을 말하고, 사물이 아닌 성질이 그 어느 구성부분에 의해서도 가지고 있지 못한 것을 말한다. 예를 들어 암모니아 냄새는 수소나 질소에서는 존재하지 않고, 화학의 법칙으로서는 예견할 수 없다. 창발에 대한 설이 보다 일반적으로 말하는 것은 조직의 일정 수준에서 실체에 속한 성질은 그보다 낮은 차원에서 발견된 성질로부터는 예견할 수 없다는 것이다. 그것의 역(전환명제)처럼, 환원주의는 다양한 해석을 인정하고 있다.[1]

참조: https://ko.wikipedia.org/wiki/%EC%B0%BD%EB%B0%9C

일시적인 좋은 구조, 좋은 코드를 만들기 위해서 배운 것들에 대해서 지속적으로 적용시키기 위한 것을 말한다고 생각하면 될 것 같다.

창발적 설계로 깔끔한 코드를 구현하자.

착실하게 따르기만 하면 우수한 설계가 되는 규칙 4가지가 존재한다.

• 모든 테스트를 실행한다.
• 중복을 없앤다.
• 프로그래머 의도를 표현한다.
• 클래스와 메서드 수를 최소로 줄인다.

위 목록의 순서는 중요도 순서이다.

1. 모든 테스트를 실행하라

무엇보다 먼저, 설계는 의도한 대로 돌아가는 시세틈을 내놓아야 한다.

테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템은 ‘테스트가 가능한 시스템’이다. 당연하지만 중요한 말이다.

테스타가 많을 수록 많은 장점을 얻을 수 있다. 설계 품질은 올라가고 SRP을 준수하는 클래스는 만들기 쉽고 또한 개발자는 테스트를 만들기 더욱 쉽게 만들 수 있다.

결합도가 높으면 테스트 케이스를 작성하기 어렵다.

놀랍게도 테스트 케이스를 만들고 계속 돌려라라는 간단한 규칙을 지키면 시스템 결합도는 낮아지고 높은 응집도 있는 프로그램이 만들어진다.

2~4. 리팩토링

테스트 케이스를 작성했다면 이제 코드와 클래스를 정리해도 괜찮다. 코드를 리팩토링하면서 설계에 계속 생각하면서 개선해 나간다. 테스트 케이스를 돌려 기존 긴으을 깨뜨리지 않았다는 사실을 확인한다. 코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다. 테스트 케이스가 있다.

중복을 제거하라

우수한 설계에서 중복은 커다란 적이다. 중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻하기 때문이다. 중복은 여러 가지 형태로 존재한다. 코드 중복, 비슷한 코드, 구현 중복도 모두 중복에 해당한다.

int size() {}
boolean isEmpty() {}

---
boolean isEmpty() {
    return 0 == size();
}

깔끔한 시스템을 만들려면 단 몇 줄이라도 중복을 제거하겠다는 의지가 필요하다.

Template method 패턴은 고차원 중복을 제거할 목적으로 자주 사용하는 기법이다.

표현하라

우리 대다수는 엉망인 코드를 접한 경험이 있으리라. 직접 만들기도 해봤을 것이다. 우리는 자세하게 표현하지 않아도 그때 당시에 우리는 코드를 이해하고 있었기 때문에 이해하기 쉽다. 하지만 나중에 나, 혹은 다른 사람들이 해당 코드를 봤을 때 쉽게 이해하지 못하고 그것을 하는데 많은 시간을 투자해야 될 수도 있다.

실제 소프트웨어 프로젝트 비용에서 유지보수가 매우 큰 비용이 드는 이유가 그렇다.

그러기 때문에 개발자의 의도를 분명히표현해야 한다. 코드를 명확하게 짤수록 다른 사람이 이 코드를 이해하기 쉬워진다.

• 우선 좋은 이름을 선택한다. 이름과 기능이 딱 떨어지게 계속 생각해보자.
• 둘째, 함수와 클래스 크기를 가능한 줄인다. 작은 클래스와 메소드는 코드를 읽고 이해하기 쉽고 구현도 쉽다.
• 셋째, 표준 명칭을 사용한다. 디자인 패턴을 활용한 클래스를 설계했다면 command, visitor과 같은 키워드를 붙여주자.
• 네째, 단위 테스트 케이스를 꼼꼼히 작성한다. tc는 예제로 보여주는 문서이다.

가장 중요한 것은 노력이다. 나중에 코드를 볼 사람이 내가 될 가능성이 크다. 그러니 그것을 기억하고 더 좋은 메소드 이름, 중복 제거와 같이 노력해서 다른 사람에게 자랑해보자.

클래스와 메서드 수를 최소로 줄여라.

중복을 제거하고 의도를 표현하고 SRP를 준수한다는 기본적인 개념도 극단으로 치달으면 득보다 실이 많아진다.

목표는 함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하는데 있다.

이 규칙은 하지만 앞에 언급한 4가지 규칙보다는 우선순위가 떨이진다. tc를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다.

결론

경험을 대신할 단순한 개발 기법이 있을까? 당연히 없다.

방금까지 말한 단순한 설계 규칙을 따른다면 우수한 기법과 원칙을 단번에 활용할 수 있다.

key point

• 테스크 케이스 작성
• 중복 제거
• 나의 의도를 명확하게 해서 코드 작성

마무리

이전에 나왔던 내용을 전체적으로 정리했다는 생각이 든다.

단순한 4가지 방법이라고 하지만 절대 단순하지 않다.

테스트는 정말 많은 도움이 될 수 있다. 하지만 처음 개발을 진행하고 자주 구조가 바뀌는데 있어서 오히려 걸림돌이 될 수 있다고 생각한다.

하지만 존재에 대한 반대는 하지 않는다. 지속적으로 관리된다고 과정했을 때 말이다.

좋은 규칙이지만 정말로 많은 노력. 이라는 생각이 든다.