Clean Code를 읽고 내용을 정리한 것입니다.
시스템
복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다.
By Ray Ozzie (Microsoft CTO)
도시
현대의 도시는 온갖 세세한 사항들을 나누어서 맡는 식으로 관리되고 있다.
- 수도 관리 (수도공사)
- 치안 관리 (경찰)
- 재난 (소방서)
- 전기 관리 (한전)
- ... etc
도시를 소스코드로 작성한다고 하면 도시를 구성하는 세부 사항들이 추상화/모듈화된 것으로 볼 수 있다.
큰 그림을 이해하지 못해도 작은 단위의 기능들은 잘 동작하기 때문에 효율적인 것이다.
관심사 분리
살펴보고자 하는 관심사는 시작 단계이다.
public class Singleton {
public static Singleton instance = new Singleton();
private Singleton() {}
}
위 코드는 가장 간단하게 작성할 수 있는 싱글턴 패턴의 코드이다.
어플리케이션이 시작할 때 인스턴스가 생성될 것이다.
위와 비슷한 유형의 코드가 많아지면 시작 단계에서 불필요한 부하가 생긴다.
심지어 Singleton
클래스가 실제로 사용되지 않을 수도 있다.
이는 불필요한 자원 낭비로 이어진다.
Refactoring
필요할 때 생성하는 방식으로 바꿔본다.
public class Singleton {
private static Singleton instance;
private Singleton Singleton() {}
public getInstance() {
if (instance == null) instance = new Singleton();
return instance;
}
}
위의 코드는 실제로 Singleton이 필요해지기 전까지 인스턴스를 생성하지 않는다.
이런 기법을 초기화 지연(Lazy Initialization)이라고 부른다.
이 코드에도 다중 스레드 시스템에서 안정성을 보장하지 못하는 문제가 있지만, 싱글톤에 대해 논의하는 글이 아니기 때문에 넘어가도록 한다.
의존성 문제
이번엔 다른 예시를 살펴보겠다.
public Service getService() {
if (service == null) service = new ServiceImpl(...); // 매개변수 생략
return servce;
}
lazy 기법을 사용해서 실제로 필요한 순간 인스턴스를 생성하고 반환하는 코드이다.
이 코드는 ServiceImpl
에 명시적으로 의존하고 있다.
또 ServiceImpl
을 생성할 때 사용하는 매개변수가 정해져 있다.
ServiceImpl
이라는 구현체는 어느 상황에서나 필요하다고 확신할 수 있을까?
클래스의 생성과 사용에 대한 관심사 분리가 되어 있지 않기 때문에 발생하는 상황이다.
Main 분리
실제로 생성하는 부분과 가져다 사용하는 부분을 모듈화하여 분리한다고 하자.
사용하는 곳에서 보면 인스턴스가 생성되는 과정을 전혀 알 수 없고 적절한 방법으로 생성되었겠거니 하는 짐작만 가능한 시스템을 제작한다.
그렇게 되면 조금 더 효율적으로 인스턴스를 관리할 수 있다.
실제로 이러한 기능을 제공하는 프레임워크가 다수 존재한다.
자바 진영에선 Spring Framework가 대표적이다.
의존성 주입
Spring Framework의 핵심 요소 중 하나는 의존성 주입 (Dependency Injection)이다.
의존성 주입은 제어의 역전 (Inversion Of Control) 기법으로 의존성을 관리하는 방법을 말한다.
제어의 역전은 본래 개발자가 가질 책임인 제어의 권한을 Spring framework에 넘겨 코드에만 집중할 수 있는 환경을 마련한다.
도시 확장하기
작은 도시가 큰 도시로 확장되어 가는 과정은 큰 고난이 따르기 마련이다.
조그마한 마을이 갑자기 성장하여 큰 도시가 되어 버렸을 때, 어느 골목의 교통량 또한 크게 늘어 기존의 2차선으로 부족한 상황이 생겼다고 하자.
왜 처음부터 6 ~ 8차선 이상의 도로로 만들지 않았을까 하는 고민은 의미가 없다.
작은 마을엔 4차선 이상의 도로도 낭비이기 때문이라는 것을 잘 알고 있기 때문이다.
SW도 마찬가지로 처음부터 깨끗하고 올바른 아키텍처를 만드는 것은 쉽지 않다.
오늘 할 일에 집중하고 내일의 일을 예상하여 시스템을 적절하게 확장시킬 여지를 만들어가는 것이 중요하다.
AOP
관심사를 분리하는 기법 중 하나이다.
AOP는 횡단 관심사를 찾는다.
서로 다른 클래스에 선언된 메소드에서 특정 기능(로깅, 트랜잭션 처리 등)을 반복적으로 사용한다면,
로깅이나 트랜잭션 처리는 횡단 관심사로 처리하는 것이다.
Spring framework에서는 프록시 패턴으로 AOP를 처리하고 있다.
'IT 도서 > Clean Code' 카테고리의 다른 글
[Clean Code] 동시성 (0) | 2020.02.20 |
---|---|
[Clean Code] 창발성 (0) | 2020.02.18 |
[Clean Code] 클래스 (0) | 2020.02.16 |
[Clean Code] 단위 테스트 (0) | 2020.02.15 |
[Clean Code] 주석 (0) | 2020.02.14 |