Clean Code 12장 창발성
- 창발성
하위 체계로부터 생겨나지만, 그 하위 체계로 환원되지 않는 속성
창발적 설계로 깔끔한 코드를 구현하자✅
켄트 벡은 다음 규칙을 따르면 설계는 '단순하다'고 말한다
우선 순위 순
- 모든 테스트를 실행한다.
- 중복을 없앤다.
- 프로그래머 의도를 표현한다.
- 클래스와 메서드 수를 최소로 줄인다.
단순한 설계 규칙 1:모든 테스트를 실행하라
설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다.
- 테스트가 가능한 시스템
테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템
테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 높아진다. 테스트 케이스가 많을수록 개발자는 테스트가 쉽게 코드를 작성한다.
단순한 설계 규칙 2~4 : 리팩터링✨
테스트 케이스를 모두 작성했다면 코드와 클래스를 정리해도 괜찮다. 코드를 점진적으로 리팩터링 해나간다.
테스트 케이스가 있기 때문에 코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다.
리팩터링 단계에서는 소프트웨어 설계 품질을 높이는 기법이라면 무엇이든 적용해도 괜찮다.
중복을 없애라❌
중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻한다. 깔끔한 시스템을 만들려면 단 몇 줄이라도 중복을 제거하겠다는 의지가 필요하다.
중복의 형태
- 똑같은 코드
- 더 비슷하게 고쳐주면 리팩터링이 쉬워짐
- 구현의 중복
- 소규모 재사용 활용, 템플릿 메서드 패턴 활용 등등
소규모 재사용
아주 적은 양의 공통적인 코드를 새 메서드로 뽑아 이 메서드를 좀더 추상화해 다른 맥락에서 재사용하는 것
템플릿 메서드 패턴
메서드에서 공통적인 부분은 두고 다르게 구현되는 하나의 부분만 상속으로 다르게 구현하는 방법
표현하라🎨
자신이 이해하는 코드를 짜기는 쉽다. 나중에 코드를 유지보수 하는 사람이 코드를 짜는 사람만큼이나 문제를 깊이 이해할 가능성은 희박하다.
코드는 개발자의 의도를 분명히 표현해야 한다. 개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워진다.
나중에 코드를 읽을 사람이 바로 자신일 가능성이 높다는 사실을 명심하고 코드만 돌린 후에 다음 문제로 직행하는 것이 아니라 노력과 주의를 들여야 한다.
HOW
- 좋은 이름을 선택한다.
- 이름과 기능이 완전히 딴판이게 클래스나 함수를 짜서는 안된다.
- 함수와 클래스 크기를 가능한 줄인다.
- 작은 클래스와 함수는 이름 짓기도 쉽고, 구현하기도 쉽고, 이해하기도 쉽다.
- 표준 명칭을 사용한다.
- 클래스가 COMMAND나 VISITOR 같은 표준 패턴을 사용해 구현된다면 클래스 이름에 패턴 이름을 넣어줘 다른 개발자가 클래스 설계 의도를 이해하기 쉽게 한다.
- 단위 테스트 케이스를 꼼꼼히 작성한다.
- 테스트 케이스는 '예제로 보여주는 문서'이기 때문에 잘 만든 테스트 케이스를 읽어보면 클래스 기능이 한눈에 들어온다.
클래스와 메서드 수를 최소로 줄여라🔗
함수와 클래스 수를 가능한 줄여야 한다. 목표는 함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하는 데 있다.
이 규칙은 간단한 설계 규칙 네 개 중 우선순위가 가장 낮다. 테스트 케이스를 만들고, 중복을 제거하고 의도를 표현하는 다른 작업이 더 중요하다.
느낀점🙊
진짜 간단한데 어려운 것 같다. 이 책을 지금까지 읽으면서 이번 장에서 소개한 단순한 설계 규칙 4가지는 다 들어봤던 것들이다. 그렇지만 참... 적용하기 어려운 것 같다.
특히 나는 코드를 짜고 보면 중복이 되는 부분이 정말 많다는 것을 느낀다. 그래서 항상 이 중복을 어떻게 처리를 할까?를 생각하게 되고 그러다가 코드를 뒤엎게 되고... 하는 경우도 있게 되는 것 같다.
중복을 잘 처리할 수 있는 방법과 최대한 중복이 없게 코드를 처음부터 짜는 것을 고민하면서 연습해 나가야겠다.
