Clean Code - 3

📓 독서후기

「클린코드」 9 ~ 12장 독서 후기

• 9장. 단위 테스트
• 10장. 클래스
• 11장. 시스템
• 12장. 창발성

1주일에 4장씩 읽기가 목표이며 읽은 후기를 블로그에 후기로 정리까지 해보려한다.

이번주는 9장 「단위 테스트」 ~ 12장 「창발성」 까지 읽은 후기를 간략히 남겨보았다.

9. 단위 테스트

---

사실 나는 테스트 코드를 짜본 경험이 별로 없다.
제대로 배우고 싶지만 TDD는 아직까진 나에게 판타지로 느껴지는 개발론 중 하나이다.

이번 장에서는 테스트 코드의 중요 성을 강조하며 TDD 법칙을 설명한다. 그리고 TDD의 가장 중요한 세가지 법칙은 다음과 같다 강조한다.

• “실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.”

• “컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.”

• “현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.”

이번장은 읽어보니 “테스트” 라는 걸 막연히 어렵게 느껴왔던 점에 대해 벽이 조금 허물어진 느낌을 받았다.

• “실제 코드가 확장되거나 변경되면 당연히 테스트 코드도 바뀌어야하니 일이 두배가 되는 것 아닌가..?”

위 생각이 내가 막연히 생각했던 “TDD는 판타지다.” 라는 결론이었다.

그래서 충분한 테스트 없이 코드를 출시하고, 그 책임을 “팀원들 혹은 사용자들에게 전가하고 있었던게 아닐까?” 란 생각을 다시하게 되었다.

이 장을 읽고 기억에 남는 문구를 꼽자면 아래의 문장을 꼽을 것 같다.

"테스트 케이스가 없다면 모든 변경이 잠정적인 버그다."

10. 클래스

---

함수뿐만 아니라 클래스에도 해당 원칙은 적용된다.

"단일 책임 원칙"

클래스 혹은 함수나 모듈을 변경해야한다면 그 이유는 단 하나여야 한다는 원칙이다.

항상 클래스나 함수는 작게 쪼개어져야 한다. 등등 “모듈화”에 대한 이야기는 많이 들었다.

그 작게라는 기준이 되는 요소는 코드의 길이가 아닌, “책임” 이라는 걸 이번 장에서는 강조한다.

도구 상자를 떠올려보자, 한가지의 도구는 한가지의 책임을 갖고 한가지의 일을 잘 해낸다.

3장 함수에서 다룬 내용과 크게 다르지 않다 생각한다. 클래스도 마찬가지로 체계적인 정리 없이 쓰인다면 버그가 숨어들기 좋을 수 밖에 없다.

큰 클래스만으로 이뤄진 시스템보다는 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.

11. 시스템

---

도시를 계획하면 행정별로 각 부서를 나누고 부서마다 비슷한 수준의 일을 담당한다.

소프트웨어도 마찬가지다. 적절한 추상화와 모듈화로 기능을 책임 별로 나누고 관리한다.

"복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다."

이 장에서는 제작과 사용을 분리해야한다라며 강조를 한다.

건물을 예로 들면, 건축과정 중 기중기와 승강기가 필요하지만 완공 시점 이후에는 필요가 없어지듯이 응용 프로그램 개발에도 이와 같은 설계 기법인 “관심사” 분리에 대해 강조한다.

건축 설계 기법처럼 시스템 또한 시작 단계부터 관심사를 분리하여 설계하는 것에 대한 중요성을 언급하는 장이었다.

이번 11장은 어려운 개념 (횡단 관심사, 영속성, 관점 지향 프로그래밍(AOP) 등등..) 이 너무 많이 나와서.. 객체지향 개념에 대해 조금 더 공부한 뒤 다시 읽어봐야겠다.

이 장의 결론은 책의 방향성과 일치한다.

"시스템 역시 깨끗해야 한다."

깨끗하지 못한 아키텍쳐는 논리를 흐리며 이는 제품 품질의 하락으로 이어진다.

품질이 떨어지는 코드에는 역시 버그가 숨어들기 쉬워지고 스토리를 구현하기 어려워진다를 강조한다.

12. 창발성

---

사실 이 단어를 책을 읽으며 처음 접했다. (창발?..)

위키백과에는 이 단어를 다음과 같이 정의한다.

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

이 장에서는 창발적 설계의 중요성을 강조한다.

“창발적 설계” 라는 문장을 단어의 뜻을 접목해서 해석하면 다음과 같다.

"착실하게 규칙(하위 계층)을 따르기만 하면 우수한 설계(상위 계층)가 나오는 설계 방식."

즉, 이 장에서는 잘 따르기만하면 우수한 설계를 보장하는 규칙 혹은 원칙이란 무엇인지 설명하는 장이다.

이번 장에서 꼽은 규칙은 다음과 같다. (중요도 순이다.)

• “모든 테스트를 실행한다.”

• “중복을 없앤다.”

• “프로그래머 의도를 표현한다.”

• “클래스와 메서드 수를 최소로 줄인다.”

이미 이전 챕터들에서 너무 강조했던 내용들이다.

이 책은 읽으면서 느끼지만 한결같은 방향을 제시하고 같은 내용을 지속적으로 강조한다. (그만큼 중요하단것이지!)

부록을 제외하면 17장까지 존재하는 이책에서 말하고자하는 방향을 이제야 어렴풋이 보이는듯하다.

다시한번 복기하는 마음으로 읽었던 챕터였다.