창발성
- 창발성이란 단순한 결합이 복잡한 결과를 나타내는 것을 의미한다.
- 하위 계층에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 나타는 현상
창발적 설계란 어떤 규칙과 원칙에 따라 설계를 하게 되면, 그것들이 모여 아주 좋은 거시적 설계가 된다고 보면 될 것같다.
창발적 설계로 깔끔한 코드를 구현하자
- 착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙 네 가지가 있다면?
- 네 가지 규칙을 따르면 코드 구조와 설계를 파악하기 쉬워진다면?
- 그래서 SRP 나 DIP 와 같은 원칙을 적용하기 쉬워진다면?
- 네 가지 규칙이 우수한 설계의 창발성을 촉진한다면?
- 켄트 벡은 다음 규칙을 따르면 설계는 '단순하다' 고 말한다.
- 모든 테스트를 실행한다.
- 중복을 없앤다.
- 프로그래머 의도를 표현한다.
- 클래스와 메서드 수를 최소로 줄인다.
단순한 설계 규칙 1: 모든 테스트를 실행하라
- 테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템은 '테스트가 가능한 시스템' 이다.
- 당연하지만 중요한 말이다. 테스트가 불가능한 시스템은 검증도 불가능하다.
- 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다.
- 크기가 작고 목적 하나만 수행하는 클래스가 나온다.
- 철저한 테스트가 가능한 시스템을 만들면 더 나은 설계가 얻어진다.
- 결합도가 높으면 테스트 케이스를 작성하기 어렵다.
- 아래와 같은 방법을 따르면 결합도를 낮추며 설계 품질은 높아진다.
- DIP와 같은 원칙을 적용
- 의존성 주입(Dependency Injection)
- 인터페이스
- 추상화
단순한 설계 규칙 2~4: 리팩터링
- 테스트 케이스를 모두 작성했다면 점진적으로 리팩토링 해나간다.
- 코드를 정리하면서 시스템이 깨질까 걱정할 필요가 없다. 테스트 케이스가 있으니까!
- 리팩토링 단계에서는 응집도를 높이고, 결합도를 낮추고, 관심사를 분리하고, 시스템 관심사를 모듈로 나누고,
- 함수와 클래스 크기를 줄이고, 더 나은 이름을 선택하는 다양한 기법들이 동원된다.
- 또한 단순한 설계 규칙 중 나머지 3개를 적용하는 단계이기도 하다.
- 중복 제거
- 프로그래머 의도 표현
- 클래스 메서드 수 줄이기
중복을 없애라
- 우수한 설계에서 중복은 커다란 적이다. 중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻하기 때문이다.
- 같은 코드는 당연히 중복이다. 비슷한 코드는 더 비슷하게 고쳐주면 리팩터링이 쉬워진다.
- 깔끔한 시스템을 만들려면 단 몇 줄이라도 중복을 제거하겠다는 의지가 필요하다.
// 각 메서드를 따로 구현하는 방법도 있다. 하지만 size()가 개수를 반환하는 로직이다.
int size() {}
boolean isEmpty{}
// 따라서 isEmpty는 이를 이용하면 코드를 중복해서 구현할 필요가 없어진다.
boolean isEmpty() {
return 0 == size();
}// Code 1-1, 중복 제거 전
public void scaleToOneDimension(float desiredDimension, float imageDimension) {
if (Math.abs(desiredDimension - imageDimension) < errorThreshold)
return;
float scalingFactor = desiredDimension / imageDimension;
scalingFactor = (float)(Math.floor(scalingFactor * 100) * 0.01f);
RenderedOpnewImage = ImageUtilities.getScaledImage(image, scalingFactor, scalingFactor);
image.dispose();
System.gc();
image = newImage;
}
public synchronized void rotate(int degrees) {
RenderedOpnewImage = ImageUtilities.getRotatedImage(image, degrees);
image.dispose();
System.gc();
image = newImage;
}- scaleToOneDimension 메서드와 rotate 메서드를 살펴보면 일부 코드가 동일하다. 다음과 같이 코드를 정리해 중복을 제거한다.
// Code 1-2, 중복 제거 후
public void scaleToOneDimension(float desiredDimension, float imageDimension) {
if (Math.abs(desiredDimension - imageDimension) < errorThreshold)
return;
float scalingFactor = desiredDimension / imageDimension;
scalingFactor = (float) Math.floor(scalingFactor * 10) * 0.01f);
replaceImage(ImageUtilities.getScaledImage(image, scalingFactor, scalingFactor));
}
public synchronized void rotate(int degrees) {
replaceImage(ImageUtilities.getRotatedImage(image, degrees));
}
private void replaceImage(RenderedOpnewImage) {
image.dispose();
System.gc();
image = newImage;
}- 이런 ‘소규모 재사용’은 시스템 복잡도를 극적으로 줄여준다.
- 소규모 재사용을 제대로 익혀야 대규모 재사용이 가능하다.
- TEMPLATE METHOD 패턴은 고차원 중복을 제거할 목적으로 자주 사용하는 기법이다. 예를 살펴보자.
// Code 2-1, 최소 법정 일수를 계산하는 코드만 제외하면 두 메서드는 거의 동일하다.
public class VacationPolicy {
public void accrueUSDDivisionVacation() {
// 지금까지 근무한 시간을 바탕으로 휴가 일수를 계산하는 코드
// ...
// 휴가 일수가 미국 최소 법정 일수를 만족하는지 확인하는 코드
// ...
// 휴가 일수를 급여 대장에 적용하는 코드
// ...
}
public void accrueEUDivisionVacation() {
// 지금까지 근무한 시간을 바탕으로 휴가 일수를 계산하는 코드
// ...
// 휴가 일수가 유럽연합 최소 법정 일수를 만족하는지 확인하는 코드
// ...
// 휴가 일수를 급여 대장에 적용하는 코드
// ...
}
}// Code 2-2, 템플릿 메서드 적용
abstract public class VacationPolicy {
public void accrueVacation() {
caculateBseVacationHours();
alterForLegalMinimums();
applyToPayroll();
}
private void calculateBaseVacationHours() { /* ... */ };
abstract protected void alterForLegalMinimums();
private void applyToPayroll() { /* ... */ };
}
public class USVacationPolicy extends VacationPolicy {
@Override protected void alterForLegalMinimums() {
// 미국 최소 법정 일수를 사용한다.
}
}
public class EUVacationPolicy extends VacationPolicy {
@Override protected void alterForLegalMinimums() {
// 유럽연합 최소 법정 일수를 사용한다.
}
}표현하라
- 소프트웨어 프로젝트 비용 중 대다수는 장기적인 유지보수에 들어간다.
- 시스템이 점차 복잡해지면서 유지보수 개발자가 시스템을 이해하느라 보내는 시간은 점점 늘어나고 동시에 코드를 오해할 가능성도 점점 커진다.
- 그러므로 코드는 개발자의 의도를 분명히 표현해야 한다.
- 개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워진다.
- 그래야 결함이 줄어들고 유지보수 비용이 적게 든다.
- 좋은 이름을 선택한다. 이름과 기능이 완전히 딴판인 클래스나 함수로 개발자를 놀라게 해서는 안 된다.
- 함수와 클래스 크기를 가능한 한 줄인다. 작은 클래스와 작은 함수는 이름 짓기도 쉽고, 구현하기도 쉽고, 이해하기도 쉽다.
- 표준 명칭을 사용한다. 예를 들어, 디자인 패턴은 의사소통과 표현력 강화가 주요 목적이다.
- 단위 테스트 케이스를 꼼꼼히 작성한다.
- 표현력을 높이는 가장 중요한 방법은 노력이다.
- 나중에 읽을 사람을 고려해 조금이라도 읽기 쉽게 만드려는 충분한 고민은 거의 찾기 어렵다.
- 하지만 나중에 코드를 읽을 사람은 바로 자신일 가능성이 높다는 사실을 명심하자.
그러므로 자신의 작품을 조금 더 자랑하자. 함수와 클래스에 조금 더 시간을 투자하자.
더 나은 이름을 선택하고, 큰 함수를 작은 함수 여럿으로 나누고, 자신의 작품에 조금만 더 주의를 기울이자. 주의는 대단한 재능이다.
클래스와 메서드 수를 최소로 줄여라
- 중복을 제거하고, 의도를 표현하고, SRP를 준수한다는 기본적인 개념도 극단으로 치달으면 득보다 실이 많아진다.
- 클래스와 메서드 크기를 줄이면서, 그 수는 가능한 줄여야한다.
추가) 정말 명확하고 필요한 클래스, 메서드만 만들어아 한다는 의미로 보임
- 때로는 무의미하고 독단적인 정책 탓에 클래스 수와 메서드 수가 늘어나기도 한다.
- 클래스마다 무조건 인터페이스를 생성하라고 요구하는 구현 표준
- 자료 클래스(자료구조)와 동작 클래스(객체)는 무조건 분리해야 한다고 주장하는 개발자
- 가능한 독단적인 견해는 멀리하고 실용적인 방식을 택해야 한다.
- 목표는 함수와 클래스 크기를 작게 유지하면서 동시에 시스템 크기도 작게 유지하는 데 있다.
- 하지만 이 규칙은 간단한 설계 규칙 네 개 중 우선순위가 가장 낮다.
- 다시 말해, 클래스와 함수 수를 줄이는 작업도 중요하지만
- 그보다 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다는 뜻이다.
결론
- 경험을 대신할 단순한 개발 기법이 있을까? 당연히 없다.
- 하지만 이 장, 아니 이 책에서 소개하는 기법은 저자들이 수십 년 동안 쌓은 경험의 정수다.
- 단순한 설계 규칙을 따른다면 (오랜 경험 후에야 익힐) 우수한 기법과 원칙을 단번에 활용할 수 있다.
Backend Developer