바람직한 설계의 특징: Code Complete 2

Code Complete 2에서 5장 구현 설계를 읽으면서, 소프트웨어 설계란 무엇이고, 더 좋은 설계를 하기위해서는 어떤 점을 고려해야하는지에 대해 정리해보았다.

설계의 필요성

구현(코드 작성)단계에서 문제를 발견하고 수정하는 것보다 설계 단계에서 문제를 발견하고 수정하는 것이 훨씬 더 비용이 적게든다.

따라서 설계 단계에서 더 많은 문제를 발견하고 수정해야 하지만 완벽한 설계란 존재할 수 없다는 점을 말해준다. 설계 단계에서 더 많이 생각하고, 더 많이 수정할 수록 구현(코드 작성)단계에서 문제를 발견하여 수정하는 일을 최소화할 수 있기에 왜 완벽한 설계란 없는 것인지, 완벽한 설계는 아니지만 바람직한 설계를 하는 방법이 무엇인지에 대해서 정리해보려고 한다.

소프트웨어 설계란?

“소프트웨어 설계”는 컴퓨터 소프트웨어에 대한 명세를 동작 가능한 소프트웨어로 변환하기 위한 계획에 대한 구상이나 창작, 도구를 뜻한다.

설계는 요구사항을 코드 작성과 디버깅에 연결하는 작업이다.

설계의 어려움

1. 설계는 불명확한 문제다.

“불명확한 문제”란 전체 혹은 일부를 해결해야만 정의할 수 있는 문제이다.

따라서 문제를 명확하게 정의하려면 문제를 한번 “해결”해야 하며, 작동하는 솔루션을 만들기 위해서 다시 문제를 해결해야 한다는 의미를 담는다.

2. 설계는 엉성한 프로세스다

완성된 소프트웨어의 설계는 정돈되어 있고 깔끔해 보여야 하지만, 설계 과정은 최종 결과물만큼 깔끔하지 않다.

설계 단계에서 실수하고 고치는 것이 똑같은 실수를 코드 작성 후에 발견하여 코드를 수정하는 것보다 비용이 적게든다.

설계는 “충분”한 상태를 알기 어렵기 때문에 엉성해 보이기도 한다.

3. 설계는 절충과 우선순위의 문제이다.

현실 세계에서는 설계자의 주요 업무 중 하나가 서로 상충하는 설계 특징을 비교하여 그 특성들 사이의 균형을 맞추는 일이다.

빠른 응답 속도가 개발 시간을 최소화하는 것보다 중요하다면 설계자는 그에 맞는 설계를 선택할 것이다. 개발 시간을 최소화하는 것이 가장 중요하다면 좋은 디자이너는 그 목적에 맞게 다른 설계를 작성할 것이다.

4. 설계에는 제약이 따른다.

설계의 핵심은 어느 정도는 가능성을 만들고, 어느 정도는 가능성을 제한한다는 데 있다.

5. 설계는 비결정적이다.

세 사람에게 같은 문제를 설계하도록 하면 완전히 다른 설계를 내놓겠지만, 모두 충분히 쓸만할 것이다. 컴퓨터 프로그램을 설계하는 방법은 보통 수십 가지에 이른다.

6. 설계는 발견적 학습 과정이다.

설계는 비결정정이기 때문에 설계 기법은 예상된 결과를 만들어내는 반복적인 처리 과정이라기보다 발견적 학습(”경험 법칙” 또는 “작동하는지 시도해 보는 것”)이라고 할 수 있다.

7. 설계는 창발적이다.

설계의 이런 특성들은 설계가 “창발적”이라는 말로 깔끔하게 요약할 수 있다. 설계는 설계 검토와 격식없는 토론, 코드 작성 경험 자체, 코드 수정 경험을 통해 진화하고 발전한다.

바람직한 설계의 특징

1. 복잡성을 최소화한다.

설계는 “재치있는” 설계 보다 간단하고 이해하기 쉽게 설계해야 한다.

재치있는 설계는 일반적으로 이해하기 어렵고, 특정 부분을 살펴보고 있을 때, 다른 부분에 대해서도 함께 살펴야 한다면 잘못된 설계라고 말할 수 있다.

2. 유지보수의 편리함

유지보수가 편리하다는 것은 유지보수 개발자(다른 개발자)를 위한 설계이다.

유지보수 개발자가 작성한 코드에 대해서 물어볼 만한 질문은 계속 떠올려 보고, 유지보수 개발자를 청중이라고 생각하고 시스템을 쉽게 이해할 수 있도록 설계해야 한다.

3. 느슨한 결합

프로그램의 각 부분 사이의 연결을 최소화하도록 설계해야 한다.

클래스 사이의 연결을 최소화하기 위해서 클래스 인터페이스에서의 추상화, 캡슐화, 정보은닉과 같은 방법을 사용한다. 연결을 최소화한다면 통합이나, 테스트, 유지보수할 때 작업을 최소화 할 수 있다.

4. 확장성

내부구조를 해치지 않고 시스템의 기능을 개선할 수 있도록 설계해야 한다.

예측 가능한 변경 사항을 미리 고민하면 시스템에 입히는 충격을 최소화할 수 있다.

5. 재사용성

현재 시스템의 일부를 다른 시스템에서 사용할 수 있도록 설계해야 한다.

6. 높은 팬인(fan-in)

높은 팬인은 특정 클래스를 사용하는 클래스의 수가 많다는 것을 의미한다.

높은 팬인은 시스템이 유틸리티 클래스를 잘 활용하도록 설계되었다는 것을 의미한다.

7. 낮은 팬아웃(fan-out)

낮은 팬아웃은 특정 클래스가 다른 클래스를 적게 사용한다는 것을 의미한다.

높은 팬아웃(7 이상)은 한 클래스가 다른 클래스를 여러 개 사용한다는 것을 가리키며 이로인해 지나치게 복잡할 것이다.

8. 이식성

시스템을 다른 환경으로 쉽게 이동시킬 수 있도록 설계해야 한다.

9. 간결성

불필요한 부분이 없게 시스템을 설계해야 한다.

볼테르는 한 권의 책이 완성되는 시점은 더 이상 추가할 내용이 없을 때가 아니라 더 이상 뺄 내용이 없을 때를 의미한다. 이 말은 소프트웨어에도 적용된다.

어떤 코드를 수정하면 나머지 코드를 다시 개발하고 검토하고 테스트하고 확인해야 한다. 불필요한 부분을 없앰으로써 “기능을 추가하기는 쉬운데 어떤 문제가 발생하게 될까?”에 대해서 답할 수 있어야 한다.

10. 계층화

계층화는 시스템에 대해 특정한 계층에서 바라보고 일관되게 이해할 수 있도록 분산 계층을 유지하는 것을 의미한다.

시스템을 다른 계층을 보지 않고도 특정 계층에서 볼 수 있도록 설계해야 한다.

11. 표준 기법들

표준화 되고 일반적인 접근 방법을 사용해 전체 시스템이 친숙하다고 느껴지게 만들려고 노력해야 한다.

참고 자료

스티브 맥코넬, Code Complete 코드 컴플리트 2/E 더 나은 소프트웨어 구현을 위한 실무 지침서, 위키북스 - https://product.kyobobook.co.kr/detail/S000001766290