[3부 코드의 모습] Chapter13 웅대한 설계

바람직한 소프트웨어 설계를 하는 방법

코드 설계의 품질은 원숙한 프로그래머임을 나타내는 지표다.

 

설계로서의 프로그래밍

프로그래밍이라는 행위는 초기에 설계하면서 결정했던 것을 검증하고, 나머지 설계 작업을 수행하는 것이다

 

설계는 당연히 먼저 해야 하는 일이다

 

우리는 무엇을 설계하는가?

설계는 개발 프로세스의 각 단계에서 주어진 일을 구성요소들로 나누고, 각 구성요소가 작동하는 방법을 생각해내는 과정이다

소프트웨어의 설계 수준

시스템아키텍처

아키텍처 설계는 전체 시스템의 성능과 특성에 미치는 영향력이 가장 크고, 특정한 코드 행에 미치는 영향력은 가장 적다.

모듈/컴포넌트

각각의 서브시스템을 알기 쉬운 더 작은 모듈들로 나누는 것이다

나중에 쉽게 바꿀 수 없다

클래스와 데이터 타입

모듈을 한입 크기의 덩어리들로 나눈다

함수

정확히 어떤 함수가 필요한지 결정한 다음에, 그 함수들이 내부적으로 어떻게 작동해야 할지, 제어 흐름은 어떤 경로를 따라가야 할지, 어떤 알고리즘을 사용해야 할지 설계해야 한다

 

무엇을 위한 소동이지?

설계는 코드의 밑바탕. 설계가 잘못되면 코드는 불안정해지고, 쉽게 번복되고, 목적과 다른 것이 되어버릴 것이다

건실한 설계??

더 작성하기 쉽고

더 이해하기 쉽고

더 고치고 더 쉽고

버그의 잠복 가능성은 더 적고

변경에 대한 더 탄력적인 코드

 

좋은 설계

반복적이고

점증적인 구축

신중하고

현실적이고

지식에 근거한

 

좋은 설계에는 몇 가지 매력적인 특성이 있다

단순성

잘 설계된 코드의 가장 중요한 특성

적을수록 많이 얻는다. 적은 것을 가지고 많은 일을 하는 심플한 코드를 만들기 위해 노력하자

세련미

균형 그리고 아름다움과 많은 관련이 있다

모듈화

강한 응집력

낮은 커플링 : 아주 단순한 설계에서는 모듈 간의 커플링이 거의 없고, 그래서 모듈 간의 의존성도 거의 없다

커플링을 최소화하고 내부적으로 응집력이 있게끔 모듈을 설계하자

바람직한 인터페이스

인터페이스는 성격과 특성에 대해 생각해 보는 것을 돕는 열쇠가 되는 몇 가지 원칙이 있다

구획 나누기

잘 설계된 코드는 역할과 책임을 명확히 정의한다

추상화

사용자에게 중요한 것이 정확히 무엇인지, 감추는 게 유용한 것이 무엇인지 신중하게 선택함으로써 추상회된 개념을 생성한다

압축

큰 오퍼레이션을 단순하게 표현하는 인터페이스의 능력을 말한다

대체 가능성

확장성

확장이 가능하도록 설계하자, but 너무 심하게 일반화 하지는 말자

중복 피하기

중복은 세련미와 단순성의 적이다

이식성

코드의 이식성을 설계 수준에서 관리하고 뒤늦게 생각해서 해킹하듯이 집어넣으면 안 된다

#ifdef NEW_PLATFORM

=> 엔진팀 코드에 너무 많다 과연 설계가 잘못된 것일까? 이걸 줄일 방법은 없는 것일까? 시간이 문제인건가?

관용구 사용

C++에서 RALL(Resource Acquisition Is Initialization) 패턴을 공부해야 된다!!

훌륭한 문서화

 

코드를 설계하는 방법

설계를 할 때는 언제든지 설계를 하는 부분보다 바로 다음으로 큰 콘텍스트 안에서 생각하고 설계하라

 

설계 방법과 프로세스

구조적인 설계

기능의 분해에 관한 것이다

톱다운방식 보텀업방식

주로 도움되는 이야기가 많은 부분이었다

객체지향 설계

객체의 동작과 상호 작용이 모두 정해지면 설계가 완료된다

설계 툴

표시법

잘 규격화된 표시법은 UML : 팀에서 사용하고 있는 방식

디자인 패턴

설계 테크닉들의 vocabulary를 제공, 그것을 실무에 적용하는 방법을 보여주는 강력한 설계 툴

플로차트

알고리즘의 시각화에 사용되는 특별한 그래픽 표시법

슈도코드

기능을 구현할 때 초안을 잡는 일을 도와 준다

코드 안에서 하는 설계

CASE툴

설계 과정의 일부 또는 전부를 보조하는 역할을 한다

 

좋은 프로그래머는…

자기가 건드린 모든 것이 좋은 상태로 남게 되기를 희망한다

프로그래밍을 창의적인 과정으로 생각하고, 자기가 하는 일에 예술적인 요소를 끼워 넣는다

코드 작업을 시작하기 전에 코드의 구조에 대해 생각한다

지저분한 코드를 보면 추가 작업을 하기 전에 깔끔하게 정리하고 리팩토링해야겠다는 생각을 한다

다른 소프트웨어의 설계에 대해 끊임없이 공부하고 성공과 실패에 대한 지식을 쌓아 올린다

나쁜 프로그래머는…

뜨개질하듯이 코드를 작성해서 점점 더 큰 딱딱한 공처럼 만든다. 자기가 만족할 때까지 그 일을 계속하고, 결과에 대해 불평을 한다

나쁜 설계를 알아볼 줄 모르고, 밀집된 코드를 가지고 작업할 때도 아무 혐오감을 느끼지 않는다

즐겁게 해킹하듯 코딩하고 나서 자기가 어질러놓은 것을 다른 사람들이 치우라고 남겨둔 채 도망간다

코드의 내부 설계를 음미하거나 존중하지 않는다; 쌀쌀맞게 무사한다