A Philosophy of Software Design, 2nd Edition

1. 소프트웨어 설계 문제의 근원은 복잡성이다

복잡성은 의존성과 불명확성의 축적으로부터 온다.

복잡성은 점진적으로 축적된다. 소프트웨어 시스템이 성장함에 따라, 구성 요소 간의 의존성과 불명확한 코드 섹션의 점진적인 축적으로 인해 더 복잡해지는 경향이 있다. 이러한 복잡성은 세 가지 주요 방식으로 나타난다:

• 변화 증폭: 작은 변화가 많은 곳에서 수정이 필요함
• 인지 부하: 개발자가 변경을 위해 많은 정보를 이해해야 함
• 알 수 없는 미지수: 어떤 코드를 수정해야 하는지 또는 어떤 정보가 관련 있는지 불명확함

단순함이 해답이다. 복잡성을 극복하기 위해, 소프트웨어 설계자는 의존성과 불명확성을 최소화하는 단순하고 명확한 설계에 집중해야 한다. 이는 다음을 포함한다:

• 모듈화 설계: 시스템을 독립적인 모듈로 나누기
• 정보 은닉: 구현 세부 사항을 모듈 내에 캡슐화하기
• 명확한 추상화: 기본 복잡성을 숨기는 단순한 인터페이스 제공

2. 전략적 프로그래밍이 전술적 접근을 능가한다

최선의 접근법은 지속적으로 작은 투자를 많이 하는 것이다.

장기적인 사고가 더 나은 결과를 낳는다. 전략적 프로그래밍은 단순히 코드를 작동시키는 것보다 훌륭한 설계를 만드는 데 중점을 둔다. 이 접근법은 다음을 포함한다:

• 초기 설계에 시간 투자
• 지속적으로 작은 개선 사항 만들기
• 깨끗한 설계를 유지하기 위해 코드 리팩토링

전술적 프로그래밍은 기술 부채를 초래한다. 전술적 접근법은 단기적으로는 더 빠르게 보일 수 있지만, 종종 다음과 같은 결과를 초래한다:

• 빠른 수정과 해킹의 축적
• 시간이 지남에 따라 변경이 어려워짐
• 장기적인 개발 비용 증가

전략적 사고를 채택함으로써, 개발자는 유지보수와 진화가 더 쉬운 시스템을 만들 수 있으며, 궁극적으로 장기적으로 시간과 노력을 절약할 수 있다.

3. 모듈은 얕지 않고 깊어야 한다

최고의 모듈은 강력한 기능을 제공하면서도 단순한 인터페이스를 가진다.

깊이는 추상화를 만든다. 깊은 모듈은 단순한 인터페이스 뒤에 상당한 구현 복잡성을 숨긴다. 이 접근법은 다음을 포함한다:

• 모듈 사용자에 대한 인지 부하 감소
• 구현 수정의 용이성
• 정보 은닉과 캡슐화 촉진

얕은 모듈은 복잡성을 더한다. 기능에 비해 복잡한 인터페이스를 가진 모듈은 얕다고 간주된다. 이러한 모듈은 다음을 초래한다:

• 전체 시스템 복잡성 증가
• 불필요한 구현 세부 사항 노출
• 시스템 이해와 수정의 어려움

깊은 모듈을 만들기 위해, 기본 복잡성을 추상화하는 단순하고 직관적인 인터페이스 설계에 집중하라. 기능과 인터페이스 복잡성의 비율을 최대화하도록 노력하라.

4. 좋은 인터페이스는 복잡성 관리의 열쇠이다

모듈의 인터페이스는 형식적 정보와 비형식적 정보를 포함한다.

잘 설계된 인터페이스는 시스템을 단순화한다. 좋은 인터페이스는 불필요한 세부 사항을 노출하지 않고 모듈의 기능을 명확하게 추상화한다. 인터페이스는 다음과 같아야 한다:

• 사용하기 쉽고 직관적이어야 함
• 구현 복잡성을 숨겨야 함
• 형식적 정보(예: 메서드 시그니처)와 비형식적 정보(예: 고수준 동작 설명)를 제공해야 함

인터페이스는 신중하게 진화해야 한다. 기존 코드를 수정할 때:

• 모듈의 인터페이스에 미치는 영향을 고려하라
• 구현 세부 사항을 노출하지 않도록 하라
• 인터페이스가 제공하는 추상화를 유지하거나 개선하도록 노력하라

좋은 인터페이스를 만들고 유지하는 데 집중함으로써, 개발자는 복잡성을 관리하고 시스템을 더 모듈화하고 이해하기 쉽게 만들 수 있다.

5. 주석은 추상화를 만드는 데 필수적이다

주석은 추상화를 완전히 포착하는 유일한 방법이며, 좋은 추상화는 좋은 시스템 설계의 기본이다.

주석은 추상화를 완성한다. 코드는 구현 세부 사항을 표현할 수 있지만, 주석은 다음을 포착하는 데 필수적이다:

• 고수준 설계 결정
• 선택의 이유
• 기대와 제약
• 코드만으로는 명확하지 않은 추상화

먼저 주석을 작성하라. 코드를 구현하기 전에 주석을 작성함으로써:

• 설계에 대한 생각을 명확히 할 수 있음
• 초기 추상화를 평가하고 개선할 수 있음
• 문서가 항상 최신 상태로 유지됨

무엇과 왜에 집중하라, 어떻게가 아니라. 좋은 주석은 다음을 설명해야 한다:

• 코드에서 명확하지 않은 것들
• 코드의 목적과 고수준 동작
• 단순히 코드가 하는 일을 반복하지 않음

명확하고 유익한 주석을 우선시함으로써, 개발자는 더 나은 추상화를 만들고 시스템의 전체 설계를 개선할 수 있다.

6. 일관된 명명과 형식은 가독성을 향상시킨다

좋은 이름은 일종의 문서화이다: 코드를 이해하기 쉽게 만든다.

일관성은 인지 부하를 줄인다. 명명과 형식에 대한 규칙을 설정하고 따름으로써, 개발자는 다음을 할 수 있다:

• 코드를 더 예측 가능하고 읽기 쉽게 만듦
• 코드를 이해하는 데 필요한 정신적 노력을 줄임
• 버그나 설계 문제를 나타낼 수 있는 불일치를 강조함

이름을 신중하게 선택하라. 좋은 이름은 다음과 같아야 한다:

• 정확하고 모호하지 않음
• 명명된 엔티티의 명확한 이미지를 만듦
• 코드베이스 전체에서 일관되게 사용됨

형식이 중요하다. 일관된 형식은 다음을 통해 도움이 된다:

• 코드의 구조를 더 명확하게 만듦
• 관련 요소를 시각적으로 그룹화함
• 중요한 정보를 강조함

명명과 형식에 주의를 기울임으로써, 개발자는 코드의 가독성과 유지보수성을 크게 향상시킬 수 있다.

7. 지속적인 개선은 깨끗한 설계를 유지하는 데 필수적이다

장기적으로 효율적으로 작업할 수 있는 깨끗한 소프트웨어 구조를 원한다면, 초기 구조를 만드는 데 추가 시간을 투자해야 한다.

설계는 지속적인 과정이다. 깨끗한 소프트웨어 설계는 다음을 요구한다:

• 기존 코드를 개선하기 위한 정기적인 리팩토링
• 설계 결정의 지속적인 평가
• 시스템이 진화함에 따라 변경할 의지

개선에 투자하라. 깨끗한 설계를 유지하기 위해:

• 정리와 리팩토링을 위한 시간을 할당하라
• 설계 문제를 복합되기 전에 신속히 해결하라
• 각 코드 변경을 전체 설계를 개선할 기회로 보라

완벽과 진행의 균형을 맞추라. 깨끗한 설계를 추구하면서:

• 일부 타협이 필요할 수 있음을 인식하라
• 점진적인 개선에 집중하라
• 가장 큰 이익을 제공하는 변경 사항을 우선시하라

설계를 지속적인 개선 과정으로 취급함으로써, 개발자는 시스템이 성장하고 진화함에 따라 깨끗하고 관리 가능한 상태를 유지할 수 있다.

8. 오류 처리는 확산되지 않고 단순화되어야 한다

예외 처리를 단순화하는 가장 좋은 방법은 처리할 예외가 없도록 API를 정의하는 것이다: 오류를 존재하지 않도록 정의하라.

예외 사례를 줄여라. 오류 처리를 단순화하기 위해:

• 예외 조건을 최소화하도록 API를 설계하라
• 일반적인 경계 사례를 처리하기 위해 기본 동작을 사용하라
• 예외가 정말로 필요한지 고려하라

오류 처리를 집계하라. 예외가 불가피할 때:

• 가능한 한 여러 예외를 한 곳에서 처리하라
• 관련 오류 처리를 단순화하기 위해 예외 계층을 사용하라
• 의미 있게 처리할 수 없는 예외를 잡지 말라

정상적인 경우를 쉽게 만들어라. 오류 없는 경로를 가능한 한 단순하고 명확하게 만드는 데 집중하라. 이 접근법은 다음을 포함한다:

• 개발자의 인지 부하를 줄임
• 버그 도입 가능성을 최소화함
• 코드를 이해하고 유지보수하기 쉽게 만듦

오류 처리를 단순화함으로써, 개발자는 더 견고하고 이해하기 쉬운 시스템을 만들 수 있다.

9. 범용 코드는 특수 목적 솔루션보다 일반적으로 더 낫다

클래스가 특수 목적 방식으로 사용되더라도, 범용 방식으로 구축하는 것이 더 적은 작업이다.

범용성은 재사용성을 촉진한다. 범용 코드는:

• 더 넓은 범위의 문제에 적용될 수 있음
• 종종 더 단순하고 추상적임
• 더 깨끗한 인터페이스를 가지는 경향이 있음

조기 특수화를 피하라. 새로운 기능을 설계할 때:

• 다소 범용적인 접근법으로 시작하라
• 너무 일찍 특정 사용 사례에 최적화하려는 충동을 억제하라
• 실제 사용 패턴에 따라 설계가 진화하도록 하라

범용성과 단순성의 균형을 맞추라. 범용 솔루션을 추구하면서:

• 과도한 엔지니어링이나 불필요한 복잡성을 피하라
• 범용 설계가 여전히 일반적인 경우에 사용하기 쉬운지 확인하라
• 정말로 필요할 때 특수 목적 솔루션을 만들 준비가 되어 있어야 함

범용 설계를 선호함으로써, 개발자는 미래의 요구 사항을 더 잘 처리할 수 있는 더 유연하고 유지보수 가능한 시스템을 만들 수 있다.

10. 읽기 쉬운 코드를 작성하라, 작성하기 쉬운 코드가 아니라

소프트웨어는 작성하기 쉬운 것이 아니라 읽기 쉬운 것으로 설계되어야 한다.

장기적인 유지보수를 우선시하라. 코드를 작성할 때:

• 미래의 독자가 이해하기 쉽게 만드는 데 집중하라
• 코드의 목적을 모호하게 만드는 지름길이나 기발한 트릭을 피하라
• 명확한 추상화와 문서화를 만드는 데 시간 투자

코드를 명확하게 만들어라. 다음을 목표로 코드를 작성하라:

• 최소한의 정신적 노력으로 빠르게 이해할 수 있음
• 명확하고 일관된 명명 규칙 사용
• 논리적이고 따라가기 쉬운 구조 가짐

명확성을 위해 리팩토링하라. 기존 코드를 정기적으로 검토하고 개선하라:

• 복잡한 섹션을 단순화할 기회를 찾아라
• 긴 메서드를 더 작고 집중된 조각으로 나누라
• 중복과 불일치를 제거하라

작성하기 쉬운 것보다 읽기 쉬운 코드를 우선시함으로써, 개발자는 시간이 지남에 따라 유지보수, 디버그 및 확장이 더 쉬운 시스템을 만들 수 있다. 이 접근법은 초기에는 더 많은 노력이 필요할 수 있지만, 장기적인 복잡성 감소와 팀 생산성 향상으로 보상받는다.

Last updated: July 21, 2024