야곰야곰's S/W 공부

단계적 통합 단계적 통합 과정은 다음과 같다. 각 루틴에 대해 설계, 코딩, 테스트, 디버그를 한다. 이 단계는 "단위 개발"이라 부른다. 루틴들을 하나의 거대한 시스템으로 묶는다. 이것은 "시스템 통합"이라 부른다. 전체 시스템을 테스트하고 디버그 한다. 이것은 "시스템 분해"라고 부른다. 단계적 통합의 한 가지 문제는, 시스템의 루틴들이 처음에 합쳐질 때, 새로운 문제가 필연적으로 드러나고, 그 문제의 원인은 어디에나 있을 수 있다는 것이다. 특정 문제의 위치에 대한 불확실성은 모든 문제들이 갑자기 정체를 드러낸다는 사실에 의해 복잡해진다. 단계적 통합은 모든 루틴들이 단위 검사된 후, 프로젝트의 후반부까지는 시작될 수 없다. 루틴들이 최종적으로 결합되고 오류가 행운에 의해 드러날 때, 프로그래머들은..

소프트웨어 설계란 컴퓨터 프로그램에 대한 요구를 조작 가능한 프로그램으로 변환시키는 계획의 개념, 발명, 책략을 의미한다. 설계는 요구 사항을 코드 작성과 오류 수정에 연결시키는 행위를 말한다. 설계의 단계 1단계 : 서브 시스템으로 분할 이 단계에서 설계의 주요 작업은 모든 주요 서브 시스템의 구분이다. 이 단계의 주요 설계 행위는 어떻게 프로그램을 주요 구성 요소로 분리하느냐를 결정하는 것과 구성 요소 사이의 인터페이스를 정의하는 것이다. 서브 시스템은 일반적으로 모듈과 루틴을 포함한 전체 프로그램보다 작은 프로그램의 부분을 가리킨다. 2단계 : 모듈로 분할 이 단계에서의 설계는 시스템의 모든 모듈의 정의를 포함한다. 대형 시스템의 프로그램 분할 단계에서 지정된 서브 시스템은 너무 커서 직접 모듈로 ..

루틴이란 하나의 단일 목적에 도달하기 위한 개별적인 함수나 프로시저를 말한다. 루틴 작성의 이유 복잡성의 감소 루틴 작성의 가장 중요한 이유는 프로그램의 복잡성을 줄이는 데 있다. 정보를 숨기는 루틴을 만들면 그것에 관해 생각할 필요도 없다. 자세한 세부 사항은 잊고 내부적 작업을 알지 못해도 루틴을 사용할 수 있다. 루틴의 추상화 기능 없이 복잡한 프로그램을 머리만으로 관리하는 것은 불가능하다. 코드의 중복을 피함 의심할 것도 없이 가장 널리 알려진 이유는 코드 중복을 피하는 것이다. 2개의 루틴 안에 유사한 코드를 만들면 그것들이 분리되어 있어 에러를 내포할 가능성이 크다. 양쪽 루틴에서 중복되는 코드가 있다면 공동 코드화 시킨다. 그러고 나서 양쪽의 코드 부분에 새 루틴을 사용한다. 공간 절약은 물..

한 번 설정하고, 여러 곳에서 활용하자. 컨스트럭터 내에서 멤버 변수의 설정을 위한 할당 대신 초기화를 사용하면 불필요한 런터임 작업과 타이핑을 줄일 수 있다. 컨스트럭터는 내부적으로 초기화 코드를 만들어낸다. 다음 코드를 보자. class A { string s1_, s2_; public: A() { s1_ = "Hello,"; s2_ = "World"; } }; 실제로는 여러분이 다음과 같이 작성한 것처럼 컨스트럭터의 코드가 만들어진다. A() : s1_(), s2_() { s1_ = "Hello,"; s2_ = "World"; } 즉 직접 초기화하지 않은 개체는 표준 컨스트럭터를 통해 자동으로 초기화되고, 할당 연산자를 통해 할당된다는 것이다. 주요한 개체의 할당 연산자는 이미 만들어진 개체를 다룬..

나누고 정복하라. 작은 클래스가 만들기도 쉽고, 얻기도 쉬울 뿐만 아니라 테스트하고 사용하기도 쉬우며, 다양한 상황에서 활용하기에도 편리하다. 다양한 기능을 가진 클래스 대신 간단한 개념을 담은 작은 클래스를 만들어 활용하자. 하나의 클래스에서 복잡하고 완전한 기능을 제공하는 방식은 분명 매력적인 것이 사실이지만, 작은 클래스를 사용하는 것이 대부분의 시스템에 있어 보다 효율적인 이유가 여러 가지 있다. 최소화된 클래스는 각각 하나의 명확한 개념만을 포함하므로, 여러 개의 분리된 개념을 포함하는 클래스와는 달리 서로 간의 구분이 쉽다는 장점이 있다. 작은 클래스는 보다 이해하기 쉽고, 사용하기 쉬우며 재활용하기도 쉽다. 작은 클래스는 분산과 배치에도 유리하다. 많은 기능이 집적된 클래스의 경우 별도의 덩..

클래스가 관리하는 내부 테이터에 대한 핸들을 리턴하여 클라이언트가 개체의 상태를 좌우하게끔 만드는 것은 좋지 않다. 다음 코드를 보자. class Socket { public: ................. int GetHandle() const { return handle_; } // 이렇게 해서는 안된다. private: int handle_; }; 데이터를 숨기는 것은 강력한 추상화와 모듈화의 도구이다. 하지만 데이터를 숨겨놓고 그 제어권을 내주는 것은 스스로를 파괴하는 행동이며, 마치 대문을 잠가놓고 열쇠를 꽂아두는 것과 같다. 그 이유는 다음과 같다. 클라이언트가 기능을 제어할 두 가지 방법을 가지게 된다 클래스의 추상체(Socket)를 이용하거나, 클래스가 의존하고 있는 임플리먼테이션을 제어..

클래스는 종류에 따라 그 쓰임이 다르며, 적용되는 규칙 또한 다르다. 먼저 값 클래스(std::pair, std::vector)는 다음과 같은 특징이 있다. 값을 중심으로 한 공용 디스트럭터, 복사 컨스트럭터, 할당이 존재한다. 가상 함수가 없다. 기반 클래스가 아닌 구체적인 클래스로 사용된다. 다른 클래스의 직접적인 멤머로서 또는 스택 내에서 인스턴스가 만들어진다. 기반 클래스(base calss)는 클래스 계층을 이루는 단위로, 다음과 같은 특징이 있다. 공용(public)이면서 가상(virtual)이거나 보호된(protected)이면서 가상이 아닌 디스트럭터, 비 공용 복사 컨스트럭터, 할당 연사자 등이 있다. 가상 함수를 통해 인터페이스를 구성한다. 인스턴스는 힙에서 동적으로 만들어지거나 스마트 ..

간접적인 타입 변환은 코딩의 편리함에는 도움을 줄는지 몰라도 임시 개체가 만들어진다는 점에서 그다지 효율적이지는 못하다. 이러한 추가적인 개체의 생성을 피하고 최적화를 이루기 위해서는 변환이 일어나지 않는 범위 내에서 일반적인 인자 타입을 사용한 오버로딩 함수를 사용하면 된다. 사무실에서 일하던 중 종이가 다 떨어졌다면 어떻게 할 것인가? 복사를 담당하는 동료에게 가서 몇 장을 얻어오면 잠시나마 문제는 해결될 것이지만 그렇게 오래 가지는 못할 것이다. 간접 변환이 하는 일이 바로 이것이다. 임시적인 개체를 만들어 잠지 문제를 해결하는 것을 말한다. class string { string(const char* text); // 간접 변환을 가능하도록 함 }; bool operator==(const stri..

a+b가 있다면 a+=b도 같은 의미인 것이 좋다. 즉 두 대상 사이에 이루어지는 산술 연산자의 경우 같은 효과를 가지는 할당 연산자도 제공해야만 중복을 피하고 효율을 극대화할 수 있다. 일반적으로 바이너리 연산자 @가 있다면 a@=b나 a=a@b와 같은 할당 연산 버전도 준비하고, 같은 의미를 가지게끔 해주는 것이 좋다. 이를 위해서는 다음과 같이 @ 연산을 @= 방식으로 만들면 된다. T& T::operator@=(const T&) { // .... 구현 내용 ... return *this; } T operator@(const T& lhs, const T& rhs) { T temp(lhs); return temp @=rhs; } 두 함수의 기능은 같다고 볼 수 있다. 할당 형식은 실제 작업을 수행하고..

인자가 입력, 출력, 입력/출력 중 어떤 것인지, 그리고 값, 참조 인자 중 어떤 것인지 적절히 선택하라. 인자에 대한 값, 참조, 포인터를 적절히 선택하는 것은 안전과 효율성을 높이는 좋은 습관이다. 비록 효율성이 가장 중요한 부분은 아니지만 다른 부분에 악영향을 미치지 않는 한 효율적인 코드를 작성하는 것이 좋을 것이다. 입력의 용도로만 사용되는 인자의 경우는 포인트와 참조에 대해 const 속성을 부여하는 것이 좋다. 값에 의한 복사(point, complex)가 용이한 기본 타입(char, float)과 값 개체를 사용하는 것이 좋다. 다른 사용자가 정의한 타입을 받아들일 때에는 const로의 참조 방식을 사용하자. 함수에서 인자의 복사가 이루어지는 경우에는 참조보다는 값에 의한 전달을 사용하자...

각 헤더 파일이 자체적으로 완성도가 있게끔 작성하라. 헤더의 내용과 관련이 있는 다른 헤더는 첨가시켜 주어야 한다. 만약 어떤 헤더 파일이 다른 헤더 파일을 포함시켜야만 작동할 수 있도록 만들어진다면 그만큼 그 헤더 파일의 완성도는 떨어지게 되고, 그 헤더 파일의 사용자는 활용에 어려움을 겪게 될 것이다. 헤더는 스스로 충분히 자급자족할 수 있는 형태로 완성도 있게 만들어야 한다는 것이다. 즉, 빌드 내에서 각 헤더는 분리시켜 컴파일하고, 각각 오류나 경고가 없게 만들어야 한다. 템플릿과 연결되었을 때의 미묘한 이슈들을 짚고 넘어가자. 예 1 : 의존 이름. 템플릿은 정의되는 시점에 컴파일되는 것이 일반적이지만, 의존 이름이나 타입이 아직 그 시점까지 컴파일되지 않았을 경우는 예외이다. template ..

지나치게 의존적인 것은 좋지 않다. 정의 내용을 #include 하여 의존하게 되는 상황을 줄여야 한다. 상호 의존적인 것도 피해야 한다. 순환 의존성은 두 모듈이 직/간접적으로 서로에게 의존하고 있을 때 발명하는데, 모듈은 기능이 응집된 단위이기 때문에 서로 의존하는 모듈은 진정한 개별 모듈이라 볼 수 없으며, 오히려 하나의 커다란 모듈로 보는 것이 옳다. 즉, 순환 의존성은 모듈의 장점에 위배되는 것으로, 큰 프로젝트에서 피해야 할 부분이다. 타입의 정의가 절실히 필요한 경우가 아니라면 일방적으로 방향으로의 선언을 사용하는 것이 좋다. 클래스 C의 완전한 정의가 필요한 두 가지 경우를 보자. C 개체의 크기를 알아야 할 경우 e.g. 스택에 C를 할당할 때나 다른 타입과 직접적으로 연결된 멤버로 사용..

짧은 것이 긴 것보다 낫고, 평면적이 것이 깊은 것보다 낫다. 모든 함수는 그 이름에 맞는 적절한 하나의 역할을 가져야 한다. 여러 개의 작은 요소들이 합쳐서 하나의 긴 함수로 만드는 것은 결코 좋은 방법이 아니다. 너무 긴 라인으로 구성된 함수와 블록(if, for, while, try 등)이 중첩된 구조는 함수의 이해를 힘들게 하고, 관리를 힘들게 하는 주범이다. 블록을 중첩해서 사용하면 그만큼 코드를 읽는 사람의 입장에서 이해가 힘든 것이 당연하다. 블록을 읽어 내려가다가 내부에 다른 블록이 등장하면 지금까지 읽었던 내용을 기억해 둔 상태에서 새로운 블록의 내용을 모두 파악하고, 다시 기억해둔 내용을 꺼내어 조합해야 하기 때문이다. 가능하면 함수의 최대 길이를 제한하는 습관을 가지고, 다음과 같은 ..

깔끔한 상태에서 시작하라. 초기화되지 않은 변수는 C와 C++에서 있어 버그의 온상이므로, 상상 변수 사용 전에 깨끗한 메모리 상태를 만들어야 한다. 순차적 언어인 파스칼, C, 포트란, 코볼 등을 사용할 때는 변수를 사용하는 코드와 정의하는 코드가 분리되고, 사용되기 직전에 값을 할당하지만, 이러한 방식은 절대 권장되지 않는 형태이다. 초기화 되지 않은 변수에 대한 일반적인 오해 중 하나는 그로 인해 프로그램의 실행이 방해받을 것이라는 점이다. 하지만 이러한 프로그램들은 몇 년간 별다른 문제없이 실행될 수 잇다. 다만 이후에 다른 문맥에서의 호출, 재 컴파일 등 프로그램의 다른 부분에 생긴 변화로 인해 간헐적인 프로그램 중단이 발생할 수 있다. 표준 초기값이나 ? 를 사용하는 경우.. // 권장되지 않..

사용 범위가 넓은 함수는 가능하면 최소화하라. 변수는 하나의 상태이고, 가능하면 최소의 상태를 다루는 것이 편하다. 변수의 수명은 최소한 짧게 유지하도록 하자. 필요 이상으로 수명이 길게 정해진 변수는 다음과 같은 단점을 가지고 있다. 프로그램의 이해와 관리가 힘들다 예를 들어 현재 드라이브만이 바뀌었을 때 모듈 경로 문자열도 업데이트되어야 하는가? 문맥상의 의미를 파악하기 힘들다 대부분의 영역에서 유효한 범위인 네임스페이스 수준의 변수가 최악의 경우이다. 값이 초기화되기 쉽다 적절한 초기화 없이 변수를 선언해서는 안 된다. 초기화되지 않은 변수는 C와 C++ 프로그램에서 버그를 발생키는 큰 원인이며, 컴파일러에 의해 언제나 감지될 수 있으므로 주의를 기울여야 한다. 변수를 가능하면 로컬 범위로 정의하고..

프로그램은 마법이 아니다. 주문을 쓸 필요가 없다. 42나 3.14159와 같은 리터럴은 사용하지 말자. 이런 값들은 자체적으로 자신을 설명하지 못할뿐더러, 여러 곳에서 사용할 경우 관리도 어렵다. 대신에 width * aspectRatio와 같은 심볼 이름과 표현식을 사용하는 것이 좋다. 프로그램에 원시적인 숫자를 반복해서 사용하는 것은 프로그램의 이해도를 떨어뜨리고 관리를 힘들게 하므로, 상수보다는 열거형이나 const 값, 범위가 주어지고 이름이 정해진 값을 사용하는 것이 바람직하다. 42라는 값을 두 번 썼다고 두 값이 같은 의미를 가지라는 법은 없다. 프로그래머의 머리속에서만 이루어지는 계산은 나쁜 버릇이고, 만약 84라는 값이 있다면 두 개의 42를 더한 것인지, 아니면 어떤 하나의 42를 두..

변하지 않는 값은 그만큼 이해하기도 쉽고, 추적하기도 쉽기 때문이다. 따라서 값을 정의할 때 그 이유가 적당하다면 const를 사용하여 상수를 만드는 것이 좋다. 상수는 안전하고, 컴파일 시에 검사 되며, C++타입 시스템과 부합된다는 것을 기억하라. 상수가 많으면 상수가 정의된 부분과 값만을 신경 쓰면 되기 때문에 그만큼 코드가 간결해진다. void Fun(vector&v) { //... const size_t len = v.size(); //... } const는 일종의 바이러스이다. 한 곳에 일단 위치를 잡으면 코드의 다른 부분으로 전파되기 쉬우며, 아직 const로 지정되지 않은 부분과의 함수 호출 교류가 있을 때에는 그 부분을 const로 만들어버리는 상황을 발생시킨다. 하지만 이는 버그가 아닌..

빌드 시에 해야 할 일을 런타임까지 미루지 말라. 컴파일러가 컴파일을 진행하면서 잘못된 부분을 찾을 수 있게 하는 것이 런타임에 검사하도록 하는 것보다 좋은 방법이다. 런타임 검사는 컨트롤과 데이터에 의존적이기 때문에, 완벽하게 대비하기 힘들다. 반대로 컴파일 시의 검사는 컨트롤과 데이터에 의존하지 않기 때문에 비교적 완벽한 신뢰를 줄 수 있다. C++ 언어는 오류 검사를 컴파일 타임에 진행되도록 하여 보다 가속화할 수 있는 다양한 기회를 제공한다. 정적인 검사는 데이터와 프로그램 흐름에 독립적이다. 정적인 검사는 프로그램의 입력과 흐름에 관계가 없으므로, 그만큼 검사가 수월하다. 반대로 런타임 검사의 경우는 적절한 신뢰를 위해 다양한 입력 샘플과 환경에서 테스트해 볼 필요가 있다. 정적으로 표현된 모델..