12장 창발성

 

Clean Code(클린 코드) | 로버트 C. 마틴 | 인사이트- 교보ebook

코드

https://github.com/rkwhr0010/clean_code/tree/main/src

변경 사항은 git history 참고

 

켄트 벡이 제시한 단순한 설계 규칙 네가지를 따르면, 소프트웨어 설계 품질을 크게 높일 수 있다.

 

중요도 순

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

 

단순한 설계 규칙 1: 모든 테스트를 실행하라

어떠한 가치보다 먼저, 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다.

시스템이 의도한 대로 돌아가는지 검증할 방법이 필요하다.

 

검증이 불가능한 시스템은 출시하면 안된다.

 

테스트가 가능한 시스템을 만들려고 애쓰면, 설계 품질이 올라간다.

이유

• 크기가 작고 목적 하나만 수행하는 클래스가 나오기 때문이다. 즉, SRP를 준수하게 된다
• 결합도가 높다면 테스트 작성이 어렵다. 따라서 DIP를 준수하기 위해 DI, 추상화 등을 이용해 결합도를 낮추도록 하게 된다.

 

테스트 케이스를 만들고 계속 돌리라는 규칙을 따르면, 결합도는 낮고, 응집도는 높은 객체 지향 방법론의 목표가 달성된다.

 

단순한 설계 규칙 2~4: 리팩터링

테스트 케이스 작성 후 점진적으로 코드를 리팩터링한다.

리팩터링 과정에서 반복적으로 테스트를 구동해 정상적으로 동작함을 확인한다.

 

리팩터링 단계는 SW설계 품질을 높이기 위한 모든 기법을 적용해도 좋다.

이 단계는 다른 규칙인 중복제거, 의도표현, 클래스/메서드 수 최소화를 적용하는 단계이기도 하다.

 

중복을 없애라

중복은 여러 형태로 표출된다. 유사한 코드들은 더 유사하게 고쳐주면 리팩터링이 쉬워진다.

 

구현 중복

class List {   private int size;   public int size() {     return size;   }   public boolean isEmpty() {     return size == 0;   } }

class List {   private int size;   public int size() {     return size;   }   public boolean isEmpty() {     return size() == 0;   } }

isEmpty()에서 size()를 사용했다.

지금은 단순한 예시라 와닿지 않을 수 있지만,

size()메서드가 꽤나 정교하다고 가정하면,

isEmpty()메서 size()를 재사용한 것은 아주 효과적인 것이다.

void scaleToOneDimension(float desiredDimension, float imageDimension) {     if (Math.abs(desiredDimension - imageDimension) < errorThreshold) {       return;     }     float scalingFactor = desiredDimension / imageDimension;     scalingFactor = (float)(Math.floor(scalingFactor *100) * 0.00f);         RenderedOp newImage = ImageUtilities.getScaledImaged(image, scalingFactor, scalingFactor);     image.dispose();     System.gc();     image = newImage;   }   synchronized void rotate(int degrees) {     RenderedOp newImage = ImageUtilities.getRotatedImage(image, degrees);     image.dispose();     System.gc();     image = newImage;   }

void scaleToOneDimension(float desiredDimension, float imageDimension) {     if (Math.abs(desiredDimension - imageDimension) < errorThreshold) {       return;     }     float scalingFactor = desiredDimension / imageDimension;     scalingFactor = (float)(Math.floor(scalingFactor *100) * 0.00f);         replaceImage(ImageUtilities.getScaledImaged(image, scalingFactor, scalingFactor));   }   synchronized void rotate(int degrees) {     replaceImage(ImageUtilities.getRotatedImage(image, degrees));   }   private void replaceImage(RenderedOp newImage) {     image.dispose();     System.gc();     image = newImage;   }

공통적인 코드를 새 메서드로 뽑았다.

새 메서드로 인해 클래스가 SRP를 위반한다. 별도 클래스로 뽑아도 좋다.

별도 클래스로 뽑으면, 다른 팀원이 새 메서드를 다른 곳에서 재사용할 기회를 얻는다.

이런 소규모 재사용은 시스템 복잡도를 극적으로 줄여준다.

 

템플릿 메서드 패턴은 고차원 중복을 제거할 목적으로 자주 사용된다.

 

표현하라

자신이 이해하는 코드를 짜기는 쉽다. 자신이 짜는 동안 코드를 구석구석 이해하기 때문이다.

중요한 것은 나중에 유지보수할 사람이 이 코드를 보는 관점이다. 이는 먼 미래의 다 까먹은 내가 될 수도 있다.

 

소프트웨어 생애 주기에서 대부분은 유지보수다.

버그의 싹을 심지 않으려면 유지보수 개발자가 시스템을 잘 이해해야 한다.

깨끗한 시스템은 복잡도고, 무엇을 하는지 명확해 이해하기 쉬워 유지보수 비용이 낮아진다.

 

규칙

• 좋은 이름 사용
• 함수와 클래스 크기 가능한 최소화
  작은 모듈은 이해하기 쉬워질 수 밖에 없다.
• 표준 명칭 사용
  예시_디자인 패턴을 사용하면 접미로 붙여 준다
• 단위 테스트 케이스 작성
• 개선하고자하는 의지와 노력

 

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

중복 제거, 의도 표현, SRP 준수라는 기본 개념을 극단적으로 지키면, 득보다 실이 많다.

그래서 "가능한"줄이는 것을 목표로 한다

 

예시

• 클래스마다 무조건 인터페이스를 생성하라고 요구하는 표준
• 자료 클래스와 동작 클래스 무조건 분리

 

가능한 독단적인 견해를 멀리하고 실용적인 방식을 택한다.

이 규칙은 다른 4 규칙 중 가장 우선순위가 낮다. 다른 중요한 우선순위를 먼저 챙겨야 한다.