Exceptional C++, More Exceptional C++에 이은 세번째 gotw 책이다. gotw (Guru of the Week)란, C++ 프로그래밍에 관한 Herb Sutter의 연재물이다. Herb Sutter의 홈페이지에 잘 정리되어있으면서, CUJ에 가끔 실리기도 하고, 책으로도 출간된다. 현재까지 87번까지 나와있는데, #1~#30은 Exceptional C++에, #31~#62는 More Exceptional C++에, #63~#86은 바로Exceptional C++ Style이다.
주변이나 커뮤너티에서 C++ 관련 질문을 하면, 내가 자주 언급하는 것은 바로 gotw다. 그만큼 C++ 프로그래머가 자주(언젠가는?) 접하게되는 문제들을 gotw가 다루고 있기 때문이다. (Effective 시리즈들도 비슷한 성격을 갖고 있지만, C++ 프로그래머들이 보편적으로 읽는 필수서라서 굳이 언급하게 되는 기회는 없는 것 같다.) 굳이 책을 사서 읽지 않더라도, 시간날 때마다 웹에서 gotw item 하나씩 읽어보는 것도 괜찮을 것이다.
기존 Exceptional 시리즈의 형식이나 내용의 질을 그대로 유지하고 있기 때문에 기존의 글에 덧붙여서 별다른 설명은 필요하지 않을 듯 하다. 아쉽게도, 아직 번역은 되지 않았다.
번역판을 읽었다. 원제는 ‘Writing Solid Code: Microsoft’s Techniques for Developing Bug-Free C Programs’. 대체로 C/C++ Programmer를 대상으로 한 버그를 줄이기 위한 프로그래밍 기술에 관한 유명한 책이다. 하지만, programming language에 한정되지않는 조언들도 있다. Steve Maguire의 Microsoft에서의 실제 경험을 바탕으로 지어진 책이고, 실제로 그의 경험들이 예시로 등장한다.
이 책에는 다음과 같은 조언들이 등장한다.
– Enable compiler warnings and pay attention to them. – Use assertions to validate your assumptions. – Don’t quietly ignore error conditions or invalid input. – For a complicated, critical algorithm, consider using a second algorithm to validate the first. (e.g. validate binary search with a linear search). – Don’t write multi-purpose functions such as realloc (it can grow memory, shrink memory, free memory, or allocate new memory — it does it all). – Check boundary conditions carefully. – Avoid risky language idioms. – Write code for the “average” programmer. Don’t make the “average” programmer reach for a reference manual to understand your code. – Fix bugs now, not later. – There are no free features; don’t allow needless flexibility (like realloc). – Ultimately the developer is responsible for finding bugs; he shouldn’t write sloppy code and hope that QA will find all his bugs.
[from Paul J. Mantyla’s comments in Amazon]
대체로 programming을 1-2년 정도 한 경험이 있는 사람이라면, 이러한 충고들은 대체로 스스로 익힐 수 있다. 시행 착오를 피하기 위한 책 정도가 될까. 오래된 책이라서 (1993년에 출판), 설명을 위한 예들 역시 오래된 감이 있지만, 충고들 자체는 여전히 유효하다. C/C++ programming job을 얻기 전의 학생들은 한번씩 읽어보면 좋을 듯한 책이다. 어느 정도 숙련된 programmer라면 부담없이 읽어볼만한 책이라서, 화장실에 두고 심심풀이로 읽는 것도 나쁘지는 않을 듯하다.
번역은 몇가지 용어의 번역이 모호해서, 원서를 찾아보기도 했지만, 무난한 편이었다. 번역서다 보니, 1-2일 정도만에 다 읽을 수 있었다. 조판 자체가 깔끔하지 못해서, 딱히 소장하고 싶은 마음이 들지 않는다. 번역서는 누군가에게 줘버리고, 원서만 가지고 있을 생각이다.
TDD는 XP와 함께 매우 유명한 프로그래밍 기술 중의 하나다. 어느 정도 TDD나 Agile software development methodology에 관심이 있는 사람이라면, “Test First”가 TDD의 가장 중요한 idiom을 알고 있을 것이다. ‘automated test를 먼서 작성하고, test를 동작하게 만들기 위한 가장 간단한 code를 작성하고, refactoring은 가능한 한 뒤로 미루라’는 것이 TDD의 기본이다.
이 책은 세 개의 파트로 나뉘어있다. Part I은 어떤 story (일종의 requirement)를 구현하는 과정을 TDD를 사용해서 보여주고 있다. Part II는 xUnit이라는 tool을 사용해서 TDD를 좀 더 편리하게 수행하는 것을 보여주고 있다. Part III는 TDD와 연관된 여러가지 pattern들을 정리해두었다.
TDD는 여러가지 이익을 가지고 있지만, 가장 마음에 드는 것은 test 설계부터 하기 때문에, 구현자의 입장보다 사용자의 입장에서 먼저 생각해보게 되고, 결국 interface의 품질이 더 좋아진다는 것이다. interface는 중요하지만, implementation은 그다지 중요하지 않다. implementation은 변경할 수 있고, interface는 그렇지 않을 가능성이 크기 때문이다. 이미 사용자들이 interface를 사용하고 있다는 이유로 대충 설계해놓은 interface를 개선할 수 없게되는 경우를 흔히 볼 수 있다.
번역도 되어있고 하니, 한번쯤은 읽어볼만한 책이다. 아마 집중해서 읽으면 2-3일이면 다 읽을 수 있을 듯 하다.
‘Introduction to Software Engineering’ 과목에서는 Object-Oriented Design을 가르친다. 간단한 정의와 함께, UML design 과정에서 use case로부터 object를 골라내서 class diagram을 그리는 법은 가르친다. 하지만, 아무도 object-oriented programming paradigm 뒤에 들어있는 생각을 가르쳐주지는 않는다. (물론, 다룰 주제가 많은 software engineering 과목에서 OOP를 깊게 설명하기는 어렵다.)
OOP language를 쓰는 것은 일종의 유행이다. 모두들 그 이유를 잘 알지도 못하면서 OOP를 선호한다. 심지어는 그것이 무엇인지도 모르면서 말이다. 사실, 나도 그런 사람들 중의 하나였고, C를 사용한 procedural programming paradigm에 익숙해지고 난 후, 주로 OOP language (C++, Java, Python, Ruby, …)를 사용하기 시작하면서, 계속 던지게 되는 질문은 OOP란 무엇인가, 대체 procedural programming paradigm보다 object-oriented programming paradigm이 무엇이 우월한가라는 것이었다.
‘Object Thinking’은 이러한 질문에 답변해주는 책이다. 즉, SE 과목에서 한두페이지의 페이지에 설명해놓은 것을 이 책에서는 300페이지에 걸쳐서 설명해놓은 책이다. OOP는 technique이 아니라 paradigm이다. 생각하는 방식은 누군가의 간단한 한마디 말로는 바뀌기 힘들다. (물론 그런 경우도 있다.) ‘Object Thinking’은 ‘object philosophy’, ‘object culture’란 말을 도입한다. 당연하게도, 사상(thinking)에는 철학(philosophy)이 전제되고, 문화(culture)가 따르고, 역사(history)를 가지기 마련이다. object thinking의 중심 원리(principle)들과 역사를 설명하고, 다른 philosophy와 culture와 대조를 함으로써 object thinking이 무엇인지가 조금씩 드러난다.
이 책에서는 단지 OOP가 무엇인지에 대해서만 다루고 있는 것은 아니다. OOP 외에도 software development의 여러가지 생각(thought)들을 object culture의 범주안으로 통합시킨다. 특히, XP와 같은 Agile software development가 여기에 해당된다. 따라서, 이 책에서 얘기하는 ‘object thinking’은 단지 OOP가 아닌 것이다.
또, 이 책에서 설명하는 OOP는 Booch를 중심으로 표준화된 전통적인 SE 진영의 OOP와는 조금씩 다르게 보인다. 여러번 책에서 언급되는 Smalltalk community 쪽(이를 공식적으로는 어떻게 지칭하는지 모르겠다.)에서 발전된 생각으로 보인다. 한가지 예로, OOP에 관한 여러 책들에서 object란 data와 algorithm의 결합이라고 지칭하지만, 이 책에서는 그러한 생각을 과감하게 거부한다. object란 behavior로 정의된다고 주장한다. 이러한 생각 한가지만으로도 object design에는 엄청난 영향을 미치게된다고 생각된다. (이 주제에 대해서는 나중에 따로 다뤄보겠다.)
아직 번역서가 없지만, 여력이 된다면, 또는 언젠가 번역이 된다면, 반드시 읽어보라고 추천해주고 싶은 책이다. 시간이 난다면, 이 책에서 인상 깊었던 생각들을 조금씩 블로그에 정리해볼까도 한다.
“More Effective C++”와 “Effective STL”을 번역하신 곽용재님이 번역작업 중이시고, 초고를 탈고하셨다고 한다. The C++ Programming Language는 C++의 창안자인 Bjarne Stroustroup이 쓴 책인 만큼 권위있고, 자세하며, 잘 쓰여진 책이다. (Books for Software Development 참조) C++ 을 배우는 사람들이 C++ 책을 추천해달라고 할 때, The C++ Programming Language를 추천해줄 수 없었던 가장 큰 이유가 번역이 되지 않았다는 사실이었는데, 앞으로는 대답이 달라질 수 있을 듯하다.
“Rapid Development”를 번역하신 박재호님이 번역작업중이시다. 이 책은 원래 개발자들 사이에 매우 유명한 “Joel On Software”라는 Joel Spolsky의 홈페이지 내용을 책으로 엮은 것이다. 나는 송민철 팀장님이 알려주신 “The Joel Test”를 통해서 Joel On Software를 알게되었는데, 이 후로 계속 RSS를 구독중이다. 아쉽게도, 원서를 아마존을 통해서 이미 사버려서, 번역판을 살 일은 없을 것 같지만, 이런 좋은 책이 번역된다는 것은 매우 기쁜 일이다.
C++ In-Depth 시리즈의 번역 quality는 그동안 믿을만 했기 때문에, 별 걱정 없이 번역판을 읽었다. 이로써, 그 시리즈의 번역된 중급서들은 다 읽은 셈이다.
내용은 Scott Meyers의 Effective C++과 비슷한 부류의 것을 기대하면 된다. 즉, C++ 언어를 잘 쓰는 것에 대한 책이다. 여러가지 주제를 다루고 있어서 딱히 한정해서 얘기하기는 힘들 것 같다. 목차를 살펴보라.
형식은 C++ programming 시에 발생하는 문제들을 내놓고 이에 대한 답을 제시하는 식이다. (혹자는 문제집 풀고 있냐고…) 개인적으로 문답법을 상당히 좋아하긴 하지만, 이 책을 읽을 때는 그냥 무시하고 죽죽 읽어나가버렸다.
지금 읽는 소프트웨어 개발 관련 책만도 2권이나 있고 다른 읽을 책도 많지만, C++ 언어 계열로 더 읽는다면, 최근에 C++ In-Depth 시리즈에 추가된 Herb Sutter와 Andrei Alexandrecu의 저작, C++ Coding Standards를 꼽고 싶다. 제목으로부터 오해할 가능성이 높겠지만, tab size를 어떻게 쓰고, bracket 위치를 어디에 두는가에 관한 책이 아니다. 실제로 읽기 전엔 모르겠지만, EC++ 계열의 practice들을 정리해서 “표준적인 coding style”로 집약한 책으로 보인다. 하나를 더 고르라면, C++의 아버지 Bjarne Stroustroup이 C++ 언어의 진화 과정을 설명하고 왜 현재의 문법이 생겼는지를 설명해주는 Design & Evolution of C++을 꼽겠다. 언어의 역사를 이해하는 것은 언어의 철학을 이해하는 데에 도움을 주고, 언어의 철학을 이해한다면 그 언어를 쓰기도 쉬워진다.
덧붙여, 프로그래밍 언어에 대해 왜 그렇게 열심히 공부하냐는 사람도 있는데, 이는 작문법을 왜 그렇게 열심히 공부하냐는 질문과 비슷하다. 작문을 잘하기 위해서는 물론 작문을 많이 해보아야겠지만, 다른 사람들이 이미 고민해둔 좋은 작문방법이 있다면, 시행착오를 통해서 배우는 것보다는 이를 공부하는 것이 훨씬 시간이 절약되기 때문이다. 게다가, 작문법에는 언어간의 벽을 뛰어넘는 무언가가 있어서, 다른 언어에 대해서도 적용되는 경우가 있다. 반대로, 언어간의 벽을 뛰어넘지 못하는 철학적인 요소도 작문을 하는데에 필요하다.
물론, (프로그래밍을 처음 배우는 모든 사람들에게 항상 얘기하듯이) 작문법만 공부해서는 절대로 문장가가 될 수 없다는 점을 유념해야할 것이다. 역사 공부도 중요하고 철학 공부도 중요하지만, 실제로 다작을 해보는 것처럼 중요한 것은 없다. 마찬가지로 어느 정도 프로그래밍에 대한 지식을 익히고 나서는, 실제로 프로그래밍을 해보지 않는 한, 절대로 더 높은 단계로 올라설 수가 없다.
현재 진행 상황은 chapter 5를 마치고 chapter 6를 읽는 중. 11월까지 끝내려고 마음 먹었는데, 그렇게는 안되는 것 같다. 1-2월 정도까지 읽어야하려나… 같이 읽던 ‘리눅스 커널의 이해’는 잠시 쉬고, 이 책에 집중을 해봐야겠다.
그건 그렇고, 상당히 재미있게 보고 있다. 책을 사고나서 내용을 훑고 나서는 그냥 ‘OO introduction 책이잖아?’ 하고 쉽게 보았는데, 지금까지만으로도 몇몇 중요한 meme을 도입하게 만들어, 내 mindset에 상당한 변화를 주고 있다. 번역이 되어서 널리 읽히게 되면 참 좋겠다는 생각이 든다. 그 중에서 가장 인상적인 chapter가 바로 chapter 3이었다.
Chapter 3: From Philosophy to Culture는 object culture를 소개하고 있다. object culture의 특성을 간단히 옮겨보면,
정확하게 정해진 형식성보다는 질서를 가진 비형식성으로의 위임
전체를 바라보기 보다는 지역적인 초점 (local focus)
최소한의 디자인/프로세스 문서의 생산
중앙 집중식 관리 스타일보다는 협동적
제어보다는 조정과 협조에 기반한 디자인
구조화된 개발보다는 빠른 프로토타이핑
체계적인 것보다는 창의적인 것에 가치를 둠
외부의 과정에 따르기보다는 내부적인 능력에 따름
정확하게 이해할 필요는 없고, 대충의 감만 잡으면 될 것 같다. 뒤에서 계속 반복되면서, 저절로 익숙해지는 일종의 “문화”이기 때문이다.
Four Presuppositions
다음으로 얘기하는 것은 object thinking (object culture의 기반이 되는?) 4가지 전제조건이다. 역시 그대로 옮겨보자.
모든 것은 object이다.
문제 영역(problem domain)을 시뮬레이션하면 object를 발견하고 정의할 수 있다.
“모든 것은 object이다”라는 가정은 아무리 복잡한 영역(domain)이라고 하더라도, decomposition을 거치면, 상대적으로 적은 수의 object들만이 남는다는 생각이다. 일종의 원자론이다. (모든 물건들은 100개 남짓한 종류의 원자들로 이루어져있다라는 생각과 비슷하고, 이 책에서도 그러한 비유를 활용한다.) 그렇다면 object란 무엇인가? 이 질문에 대한 정확한 답은 더욱 뒤에 나온다.
위에서 얘기했듯이, object가 발생하는 이유는 decomposition이라는 과정을 거치기 때문이다. decomposition은 abstraction을 적용함으로써 수행된다.이러한 abstraction은 특정한 관점(aspect)을 선택하고 그것에 초점을 맞추는 것을 필요로 한다. 이러한 관점(aspect)의 차이가 decomposition을 수행할 때, 그 결과물들 사이의 차이를 구분하는 기준이 된다.
전통적인 컴퓨터 과학자들과 소프트웨어 엔지니어들은 복잡한 domain을 모듈로 decomposition할 때, data와 function (algorithm)으로 분리하는 방법을 사용했다. (CS101을 열심히 배웠다면, 아마 dijkstra의 ‘프로그램’의 정의도 기억날 것이다) 이 때, data와 function은 가상적인 기준이어서 자연스러운 이음매가 아니고, 이 때문에 소프트웨어 엔지니어링의 거의 모든 문제가 발생한다고 얘기한다. 다시 말하면, 프로그램을 data와 function으로 분리하는 것은 일반적으로 우리가 세계를 이해하는 방식과 너무 틀리다는 것이다.
그래서 제안하는 decomposition abstraction의 기준은 바로 행동(behavior)이다. 인간은 세계를 이해할 때, 분류를 하고, 분류를 하기 위해서는 차이를 인식해야하는데, 차이를 인식할 때의 기준은 행동(behavior라는 주장을 하고 있다. object thinking에서는 이처럼 실세계에서의 decomposition 방식을 소프트웨어 개발에 도입하기 때문에, 당연히 소프트웨어 개발자는, 해당 영역의 전문가(domain expert)의 얘기를 들어야한다. 이는 문제 영역(problem domain)의 시뮬레이션이 곧 object의 decomposition이라는 주장으로 이어진다.
“object를 잘 조합할 수(composable) 있다”면 decomposition 역시 잘 된 것이다. 이러한 조합성(composability)은 재사용성(reusability)과 유연성(flexibility)을 포함한다. 이를 획득하기 위해서는 object의 행동을 발견하고 일반화하는 과정이 필요한데, 이것 역시 나중 chapter로 설명을 미룬다.
실세계에서도 그런 것처럼 object는 자율적이어야 한다. 중앙 집중적인 제어는 쪼개서 분산시킬 수 있다.
OO에 익숙하지 않은 사람이 가장 쉽게하는 실수들이 이러한 4가지 조건들에서 자주 발견된다. 자주 볼 수 있는 것 중의 하나는 객체가, problem domain이 아니라 implementation domain의 동작을 노출하는 것이다. 비슷한 것으로는 클래스나 메서드의 이름 problem domain에 대해서 제대로 파악이 안되어서 implementation domain의 용어와 혼재되어 있는 것이다. 다른 한가지는 중앙 집중적인 제어다. 그 사람이 짓는 클래스의 이름에 “*Manager”라는 이름이 많다면 이를 의심해볼 수 있다. 또 다른 예로는, 한 object는 거의 자신의 동작을 가지지 않고, 다른 object가 해당 object의 상태를 심하게 바꾸는 방식이 있다. 분명 OO 언어를 사용해서 만들었겠지만, data/function의 decomposition에 지나지 않는 예다. (이러한 실수들에 대해서 따로 글을 써 볼 예정이다.)
Object Principles – Software Principles
그 다음으로는 Witt, Baker, Merrritt의 Software quality를 정의하는 axiom들을 소개한다.
Axiom of separation of concerns: 복잡한 문제를 여러 간단한 문제들로 나누어서 해결한다.
Axiom of comprehension: 인간의 인식한계를 고려한다.
Axiom of translation: 정확도는 동등한 문맥들간의 이동에 영향받지 않는다.
Axiom of transformation: 정확성은 동등한 component간의 교체에 영향받지 않는다.
Principle of modular design: axiom of separation of concerns
Principle of portable designs: axiom of translation
Principle of malleable designs: axiom of transformation
Principle of intellectual control: abstraction의 적절한 사용
Principle of conceptual integrity
소프트웨어 엔지니어링의 지극히 일반적인 얘기들이지만, 가만히 살펴보면, object thinking과 object는 위의 목적에 상당히 적합하다는 것을 알 수 있다.
그리고 한가지 더, Fred Brooks의 유명한 paper인 ‘No Silver Bullet: Essence and Accidents of Software Engineering’에서 언급한 소프트웨어 개발에 있어서의 본질적인 어려움을 소개하면서, object thinking이 이러한 문제를 해결하고 있다고 주장한다.
Complexity: 소프트웨어는 인간이 만든 어떤 다른 체계보다도 복잡하다.
Conformity: 소프트웨어는 실제 세계에 부합해야한다
Changeability: 세계가 변화하면 소프트웨어도 변화해야한다; 세계는 자주 변화한다.
Invisibility: 소프트웨어(e.g. 실행하는 프로그램)를 실제로 볼 수 없으므로, 생각하기도 힘들다.
위의 전제조건에서도 보았듯이, object thinking에서 object는 실세계를 반영해야하므로, 당연히 이러한 어려움에 대한 가장 직접적인 대응책일 수 밖에 없다.
Cooperating Cultures
계속 비판해온 전통적인 컴퓨터 과학과 소프트웨어 엔지니어링을 절대적으로 거부하는 것은 아니라고 얘기한다. 그리고, 각각의 culture의 영역을 구분하는 기준을 제시한다.
Natural world – Deterministic world의 축과 Comprehension – Implementation의 축을 교차시키고, Object paradigm은 Natural world/Comprehension의 영역에, Computer science paradigm은 Deterministic world/Implementation의 영역에 둔다. 두 paradigm/culture는 적용하는 영역이 다른 것이다. 흥미로운 것은 deterministic world의 예로, hardware, discrete module, algorithm, small-scale formal system 등을 들고 있다는 것이다. 대체로 data와 function의 구분이 불가피한 영역들이다. 그렇다면 OS를 개발할 때는 대체로 computer science paradigm을 적용하는 것이 좋은가? 약간 더 hardware로부터 멀리 있는 system programming은 어떠한가? 모호하긴 하지만, OS의 상위 layer나 system programming 수준에서는 OO paradigm을 적용하는데에 무리는 없으리라고 생각한다.
3장은 프로세스와 프로세스 전환, 4장은 x86계열에서의 인터럽트 처리 방식과 리눅스에서의 인터럽트 처리 방식, 5장은 커널 동기화에 필요한 여러가지 primitive들, 6장은 역시 x86 계열에서 사용되는 하드웨어 타이머들의 소개와 리눅스에서의 활용 방식, 9장은 시스템 콜이 처리되는 방식, 10장은 시그널의 처리 방식, 11장은 프로세스 전환 시, 스케줄러 정책을 다루고 있다.
나머지 장들은 디스크 액세스로부터 파일 시스템, swapping에 관련된 것이어서 11장을 읽고 난 후엔 거의 다 읽은 거겠지 하고 생각했는데, 아직도 반이나 남아있다. 비슷한 속도로 읽으면 복학하기 전에는 끝낼 수 있을 듯하다.
읽으면서 든 느낌은 kernel 구현은 보통의 프로그램 처럼 하나의 behavior를 위한 logic이 잘 모여있기 보다는 – 각종 하드웨어 이벤트 들에 대해서 multiplexing되어 있어서 – 이곳 저곳에 얇게 퍼져있고, 따라서 직관적으로 이해하기는 좀 힘들다는 것이었다. 물론 이 책이 그러한 복잡함을 이해하는 데, 큰 도움이 되겠지만 말이다.
