12. 창발성(Emergence)

emergence [ ih-mur-juhns ]

noun.

3. Evolution. the appearance of new properties or species in the course of development or evolution.

---

그렇다면, 코드를 어떻게 꽃피울지에 대한 접근방법을 알아봅시다. 어떻게 첫 발을 내딛어야 할까요?

창발적 설계로 깔끔한 코드를 구현합시다

밥 아저씨와 켄트 백 등의 고수들은 아래 설계 규칙 4가지가 소프트웨어 설계 품질을 높여준다고 합니다.

특히 켄트 백은 아래 규칙을 따르면 설계는 ‘단순하다’ 라고 말합니다. 이 순서는 중요도 순입니다.

1. 제 1규칙
   1. 단순한 설계 규칙 1: 모든 테스트 코드를 실행하십시오
   2. 단순한 설계 규칙 2~4: 리팩토링
2. 중복 제거
3. 프로그래머의 의도를 표현
4. 클래스 및 메소드의 수를 최소화

테스트 코드

최우선으로, 설계의도 대로 돌아가는 시스템을 내놓아야 합니다. 아무리 좋은 시스템을 문서로 설계한다 하더라도 돌아가는 최소한의 결과물이 없다면 노력에 대한 가치를 인정받기 힘듭니다.

테스트를 거쳐 모든 테스트 케이스를 항상 통과하는 시스템은 ‘테스트가 가능한 시스템’ 입니다. 테스트가 불가능하다면 검증도 불가능합니다.

테스트가 가능한 시스템을 만들려하면 설계품질 또한 높아집니다. 크기가 작고 단독 목적만을 수행하는 클래스가 나옵니다. SRP를 준수하는 클래스는 테스트하기 더욱 쉽습니다. 테스트 케이스가 많을 수록 더욱 쉽게 코드를 작성합니다. 이런 이유로 철저한 테스트가 가능한 시스템은 더 나은 설계의 초석이 됩니다.

결합도가 높으면 테스트 케이스를 작성하기 어렵습니다. 테스트 케이스를 많이 작성할 수록 DIP같은 원칙을 적용하고 DI, 인터페이스, 추상화 등의 도구를 통해 결합도를 낮춥니다. 이 것이 설계 품질을 올리는 길입니다.

테스트 케이스를 만들고 계속 돌리면, 낮은 결합도와 높은 응집도를 달성합니다. 따라서 테스트 케이스 작성은 설계 품질을 올리는 길 입니다.

리팩토링

테스트코드가 있다면 코드와 클래스를 정리해도 됩니다. 점진적으로 코드를 좋게 만들어보고 다시 정리합니다. 테스트를 계속 돌리면서 기존 기능이 깨지지 않았는지 점검합니다. 시스템이 깨질까 걱정하지 마십시오. 테스트코드가 있습니다.

리팩토링에서는 설게 품질을 높이는 기법을 적용합니다. SOLID 원칙을 적용하고, 1장부터 11장까지 논의했던 사항을 모조리 적용합니다. 이 단계에서 중복을 제거하고, 프로그래머의 의도를 표현하고, 클래스나 메소드의 수를 최소한으로 줄이면 됩니다.

중복 제거

중복은 추가작업, 추가위험, 불필요한 복잡도의 원인입니다. 공통 코드를 새로운 메소드로 뽑아서 다른 클래스로 빼는 방법이나, TEMPLATE METHOD 패턴을 사용하는 것이 방법입니다.

표현하기

일필휘지(一筆揮之)는 어렵습니다. 코드 작성 또한 하나의 글쓰기입니다. 그렇기 때문에 몇번이고 탈고를 거쳐야 좋은 코드가 완성됩니다.

좋은 코드를 작성하는 것은 나의 의도를 상대방이 읽을 수 있게 고치는 것을 의미합니다. 이런 코드는 결함을 일으킬 확률이 낮고 유지보수 비용이 적게 듭니다. 그렇다면 어떤 방안이 있는지 살펴봅시다.

1. 좋은 이름을 선택합시다. 이름과 기능이 딴판인 클래스나 메소드를 작성하지 맙시다.
2. 함수와 클래스의 크기를 가능한 줄입시다. 작은 코드는 읽기 쉽습니다¹.
3. 표준 명칭을 사용합시다. 디자인 패턴을 사용했다면 클래스 이름에 패턴명을 넣어줍시다(E.g., VISITOR, COMMAND, etc.). 그러면 상대방이 훨씬 빠르게 이해할 수 있습니다.
4. 테스트 케이스를 꼼꼼하게 작성합시다. 남들이 나의 코드를 읽을 때 사용하는 ‘예시’입니다. 잘 만든 테스트 케이스로 클래스의 기능을 표현할 수 있습니다.

위의 4가지 방안을 지키기 위해 노력하는 것이 필요합니다. 동료와 나를 위한 길이니까요.

클래스 및 메소드의 수를 최소화

상기 개념을 극단으로 사용하면 득보다 실이 많아집니다. 분명 좋은 개념이지만 도그마로 인식하면 안 됩니다. 실용적인 방식을 택하는 것이 유연하기 때문입니다.

무의미하고 독단적인 정책을 서로에게 강요하지 말고 논리로 설득합시다. 또한 우선순위가 더 높은 사항을 먼저 준수합시다.

결론

선대 프로그래머들이 남긴 경험의 정수를 꼭 흡수하여 이런 원칙을 단번에 활용할 수 있기를 바랍니다. 저 또한 그러고 싶습니다…