Software Development

More Exceptional C++

Herb sutter의 “Exceptioanl C++”의 후속작이다. Exceptioanl C++ 처럼 Guru of the Week item을 책으로 엮어서 펴낸 책이다. 때문에 책에 있는 내용들은 거의 전부 웹에서 볼 수 있고 내용도 거의 비슷하다.

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++을 꼽겠다. 언어의 역사를 이해하는 것은 언어의 철학을 이해하는 데에 도움을 주고, 언어의 철학을 이해한다면 그 언어를 쓰기도 쉬워진다.

덧붙여, 프로그래밍 언어에 대해 왜 그렇게 열심히 공부하냐는 사람도 있는데, 이는 작문법을 왜 그렇게 열심히 공부하냐는 질문과 비슷하다. 작문을 잘하기 위해서는 물론 작문을 많이 해보아야겠지만, 다른 사람들이 이미 고민해둔 좋은 작문방법이 있다면, 시행착오를 통해서 배우는 것보다는 이를 공부하는 것이 훨씬 시간이 절약되기 때문이다. 게다가, 작문법에는 언어간의 벽을 뛰어넘는 무언가가 있어서, 다른 언어에 대해서도 적용되는 경우가 있다. 반대로, 언어간의 벽을 뛰어넘지 못하는 철학적인 요소도 작문을 하는데에 필요하다.

물론, (프로그래밍을 처음 배우는 모든 사람들에게 항상 얘기하듯이) 작문법만 공부해서는 절대로 문장가가 될 수 없다는 점을 유념해야할 것이다. 역사 공부도 중요하고 철학 공부도 중요하지만, 실제로 다작을 해보는 것처럼 중요한 것은 없다. 마찬가지로 어느 정도 프로그래밍에 대한 지식을 익히고 나서는, 실제로 프로그래밍을 해보지 않는 한, 절대로 더 높은 단계로 올라설 수가 없다.

Object Thinking

현재 진행 상황은 chapter 5를 마치고 chapter 6를 읽는 중. 11월까지 끝내려고 마음 먹었는데, 그렇게는 안되는 것 같다. 1-2월 정도까지 읽어야하려나… 같이 읽던 ‘리눅스 커널의 이해’는 잠시 쉬고, 이 책에 집중을 해봐야겠다.

그건 그렇고, 상당히 재미있게 보고 있다. 책을 사고나서 내용을 훑고 나서는 그냥 ‘OO introduction 책이잖아?’ 하고 쉽게 보았는데, 지금까지만으로도 몇몇 중요한 meme을 도입하게 만들어, 내 mindset에 상당한 변화를 주고 있다. 번역이 되어서 널리 읽히게 되면 참 좋겠다는 생각이 든다. 그 중에서 가장 인상적인 chapter가 바로 chapter 3이었다.

Chapter 3: From Philosophy to Culture는 object culture를 소개하고 있다. object culture의 특성을 간단히 옮겨보면,

정확하게 이해할 필요는 없고, 대충의 감만 잡으면 될 것 같다. 뒤에서 계속 반복되면서, 저절로 익숙해지는 일종의 “문화”이기 때문이다.

Four Presuppositions

다음으로 얘기하는 것은 object thinking (object culture의 기반이 되는?) 4가지 전제조건이다. 역시 그대로 옮겨보자.

각각을 간단하게 설명해보면,

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들을 소개한다.

소프트웨어 엔지니어링의 지극히 일반적인 얘기들이지만, 가만히 살펴보면, object thinking과 object는 위의 목적에 상당히 적합하다는 것을 알 수 있다.

그리고 한가지 더, Fred Brooks의 유명한 paper인 ‘No Silver Bullet: Essence and Accidents of Software Engineering’에서 언급한 소프트웨어 개발에 있어서의 본질적인 어려움을 소개하면서, object thinking이 이러한 문제를 해결하고 있다고 주장한다.

위의 전제조건에서도 보았듯이, 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을 적용하는데에 무리는 없으리라고 생각한다.

Understanding the Linux Kernel (2nd Edition) (continued)

8장을 마친 후에, 이어서 3-6, 9-11장을 읽었다.

3장은 프로세스와 프로세스 전환, 4장은 x86계열에서의 인터럽트 처리 방식과 리눅스에서의 인터럽트 처리 방식, 5장은 커널 동기화에 필요한 여러가지 primitive들, 6장은 역시 x86 계열에서 사용되는 하드웨어 타이머들의 소개와 리눅스에서의 활용 방식, 9장은 시스템 콜이 처리되는 방식, 10장은 시그널의 처리 방식, 11장은 프로세스 전환 시, 스케줄러 정책을 다루고 있다.

나머지 장들은 디스크 액세스로부터 파일 시스템, swapping에 관련된 것이어서 11장을 읽고 난 후엔 거의 다 읽은 거겠지 하고 생각했는데, 아직도 반이나 남아있다. 비슷한 속도로 읽으면 복학하기 전에는 끝낼 수 있을 듯하다.

읽으면서 든 느낌은 kernel 구현은 보통의 프로그램 처럼 하나의 behavior를 위한 logic이 잘 모여있기 보다는 – 각종 하드웨어 이벤트 들에 대해서 multiplexing되어 있어서 – 이곳 저곳에 얇게 퍼져있고, 따라서 직관적으로 이해하기는 좀 힘들다는 것이었다. 물론 이 책이 그러한 복잡함을 이해하는 데, 큰 도움이 되겠지만 말이다.

Extreme Programming Explained: Embrace Change

XP의 창시자인 Kent Beck이 쓴 XP에 관한 책이다. XP를 공부할 때 처음으로 읽어야할 책이 바로 이 책이다. 200 페이지도 채 안되는 분량의 책은 매우 잘 쓰여진 책이다. 맨 먼저 해결하려는 문제를 정의한 후, 문제에 관련된 변수들을 파악한 후, 추구하는 가치와 기본 원리를 설정한 후 (문제의 해결방법에 있어서, 서로 충돌하는 가치가 있을 때 중요한 단계이다), 이 가치를 달성하기 위한 방법을 제시하고, 이 방법을 실제로 적용할 때의 이슈를 논의한다. 책에서만이 아니라 실제 문제에 있어서도 이러한 접근을 하면, 쓸데없는 혼란을 야기하지 않고 문제를 해결할 수 있다. 또, 자신만의 문제를 해결하기 위해서 뿐만이 아니라 다른사람과 문제와 해결책에 관해 커뮤니케이션할 때도 유용한 패턴이라고 볼 수 있다. (가끔씩 주변을 보면, 문제를 정의하지 않고도 해결법을 찾으려고 하거나, 문제를 알려주지도 않고 해결법을 제시하는 사람들을 볼 수 있다. 선문답이 되면 행복한 케이스지만, 동문서답이 되면 곤란하다.)

다시 XP 얘기로 돌아가서, Kent Beck이 제시하는 소프트웨어 개발 프로젝트의 문제는 바로 Risk이다. 즉, 스케줄의 변경, 프로젝트의 취소, 소프트웨어 결함, 요구사항 변경, 리소스 변경 등이 소프트웨어 실패의 가장 큰 원인이란 것이다. (경험적으로, 이에 전적으로 동의한다) 그렇다면, 우리가 이걸 해결하기 위해서 무엇을 할 수 있는 가를 봐야할 것이다. Kent Beck은 소프트웨어 개발 프로젝트의 ‘Four Variables’로 Cost, Time, Quality, Scope를 제시한다. 일반적으로 Cost와 Time은 우리가 control 하지 않고, (이른바, ‘기획’하는 사람들이 control한다) Quality는 control하기에 너무 어려운 변수이기 때문에, Kent Beck은 Scope에 집중하겠다고 얘기한다.

XP의 네가지 가치(Four Values)는 바로 Communication, Simplicity, Feedback, Courage이다. 기본 원리에는 좀 더 여러가지가 있다. Rapid feedback, Assume simplicity, Incremental change, Embraching change, Quality work.

XP의 해결책이 되는 practice들은 비교적 잘 알려져있다. The Planning Game, Small releases, Metaphor, Simple design, Testing, Refactoring, Pair programming, Collective ownership, Continuous integration, 40-hour week, On-site customer, Coding standards. 이러한 practice는 XP에서 새로 발명한 practice들이 아니라 기존의 Software engineering에서 강조하는 것을 radical하게 강조한 것이다. 다시 말해, code review가 좋은 practice라면 항상 하자는 것이 바로 pair programming이고, simplicity가 좋다면 가장 simple한 design을 하자는 것이 Simple design이라는 식이다. 우리나라말로 하면 좋은 게 좋은 것 정도가 될까? 바로 이러한 아이디어가 ‘Extreme Programming’의 어원이라고 한다.

개인적으로는 Simplicity와 Simple design이 가장 인상적이었다. 물론 현업(-_-;)에 가장 적용하기 쉬운 것이고, 스스로가 ‘design for tomorrow’에 의한 폐해를 많이 겪었기 때문이었다. XP 책을 읽기 전에 이미 약간은 이 practice를 적용해보았고, 결과는 매우 좋았던 것 같다. 개인적인 습관 때문인지 자꾸 복잡한 디자인을 하려는 경향이 있긴 하지만… 계속 remind하고 마인드 트레이닝을 할 필요가 있을 것 같다. 아, 그리고 개인적으로는 기획과 개발이 분리된 job을 그다지 많이 하지 않았기 때문에, 직접 경험한 적은 별로 없지만, 주변 사람들이 자주 불평하는, 기획이 계속 requirement를 변경하거나 기획과 개발의 경계가 불명확한 경우의 괴로움을 XP는, 깔끔하게 해결하고 있는 것 같다. Planning Game을 통한 role의 명확한 분리와 Small release로 인한 risk의 감소가 바로 그것이다. Shared code ownership도 매우 좋은 practice이긴 하지만, 실제 우리 팀에서는 중간 정도의 형태를 취하고 있는 것 같다. product의 경우에는 따로 ownership을 가지고 공유하는 라이브러리의 경우에는 shared ownership 정도가 되는 것 같다. 이렇게 되면 갑자기 다른 사람이 고쳐서 동작하지 않는다는 등의 약간의 리스크는 있지만, Testing으로 극복을 할 수 있도, 이 때에 얻는 개발 속도의 장점은 매우 큰 것 같다. 그리고 On-site customer도 회사에서 자주 보는 communication overhead를 상당히 줄여줄 것 같은데, 우리나라에서 자주 보이는, 팀 간의 알력이 강하게 존재하는 조직 구조에서는 실현하기가 상당히 힘들 것 같다. 더구나 manager들이 깨어있고, 같은 이익을 향해 달려간다는 마인드를 가질 수 있으려면 조직의 크기가 클 수록 불리한 반면, 충분한 인력을 확보할 수 없는 작은 조직의 회사라면 다시 불리한 면도 있는 것 같다.

Agile software development methodology가 상당히 유행하고 있는데, XP가 아닌 다른 방법론 – FDD 등의 방법론들도 한번 살펴보고 싶다.

Understanding the Linux Kernel (2nd Edition)

영문판이 아니라 한글판을 읽고 있다. 2.2 버전을 다룬 1판을 사둔 채 버려두고 있다가 2.4 버전을 다룬 2판도 역시 묵혀오고 있다가, 추석 때 집에 내려가서 읽기 시작했다. 내용은 말그대로 리눅스 커널의 구현에 대한 내용으로, 특히 x86 계열에서의 구현에 집중하고 있다. (때문에 x86에 관한 내용도 꽤 나온다.)

현재, 1장의 introduction을 읽은 후, VM 파트를 따라서 2장, 7장을 읽고 8장을 읽고 있는 중이다. 2장 ‘메모리 주소 지정’은 IA-32 매뉴얼에도 나오는 x86 시스템에서의 segmentation, hardware paging, cache, TLB 등을 다루고 있다. 모호하게 이해하고 있던 부분을 (특히 OS 레벨인지 하드웨어 레벨인지의 구분, ‘logical address’와 ‘linear address’의 용어 구분) 말끔하게 해소한 것 같다. 7장은 커널 상의 메모리 관리를 다루고 있다. physical memory와 linear address space의 관리를 다루고 있다. 8장은 커널이 아니라 사용자 프로세스에게 할당되는 메모리를 다루고 있다. 아마도 프로세스에게 할당되는 linear address space의 관리와 page fault handling을 통해 page frame (physical memory)을 할당하는 방법을 다루고 있다. 여기까지 읽은 후에는 3장으로 돌아가서 프로세스에 대한 내용을 읽을 생각이다.

약간의 번역 inconsistency가 눈에 띄지만 (용어의 번역 여부 e.g. TLB/변환참조버퍼) 번역 퀄리티는 만족스러운 편이며, 내용도 어느 정도 OS에 관심을 갖고 있던 사람이라면 그리 어렵지는 않은 정도. 침대 머리 맡에 놓고, 자기 전에 살짝 조금씩 봐주고 있다. 시스템 프로그래머의 길을 간다면 커널의 이해는 거의 필수적이므로 이를 위해 볼만한 책 중의 하나 일 것 같다.

참고를 위해 언급하자면, 물론 다른 고전적으로 유명한 책들도 있다. Bach의 The UNIX Operationg System (너무 오래된 감이 있음)이나 UNIX Internal (괜찮은 듯), The Design and Implementation of the 4.4 BSD Operating System (안봐서 모름), Solaris Internal (안봐서 모름).

Object Thinking

물론 자기네 회사에서 나온 책이니 그렇겠지만, MSDN blog들에서 워낙 칭찬하던 책이라, 이 책을 처음 접하게 되었다. OOT에서 얘기하는 Object design의 기본적인 기법이나 pattern 같은 것들을 어느 정도 알고 있고, 또 사용하고 있지만, 내가 디자인한 OO 코드를 반대하는 사람에게 나의 디자인을 설득할 자신까지는 없었다고 할까. 기껏해야 OO에서 널리 쓰이는 기법이다 정도?의 argument로는 스스로가 납득할 수가 없었다. 따라서, 이 책을 산 목적은 Object-Oriented Technology의 역사/철학적인 백그라운드를 갖기 위해서였다. 실제로 이 책은 OOT의 역사와 철학, 용어들을 설명하는 non-formal한 OOT의 introduction book 정도로 생각하면 될 것 같다.

Preface, Introduction을 막 마친 상태인데, 11월까지는 끝낼 생각이다. 여기서 빠뜨릴 수 없는 얘기가 Preface/Introduction에서 이 사람은 범상치 않은 얘기를 하고 있다는 것이다. Preface에서는 Booch의 말을 언급하면서 OO란 decomposition에 대해 다르게 생각하는 방식/다른 가치/다른 문화라고 얘기한다. 이어서, formalism/Software engineering과 hermeneutics-postmodernism/XP/agile methodologies/behaviroal objects의 철학을 서로 대조하고 있다. Introduction에서는 Software crisis에 대해서 언급하면서 이를 해결하기 위해서 학계가 선택한 현재의 Software engineering은 process와 methodology에 주안점을 두었지만, 이는 현재 실패했다고 한다. 따라서, tool이나 process나 methodology를 만드는 것이 아니라, 원래 ‘Software Crisis’의 해결책으로 제시되었던 ‘Better people’을 만들어내야한다고 주장하고 있으며, 자신의 책이 ‘Better people’을 만드는 데 도움을 주는 책(중의 하나)이라고 주장하고 있다.

참고로, 얼마전에 slashdot에 review가 올라왔던 Organizational Patterns of Agile Software Development에서는 이렇게 얘기하고 있다.

What makes a software development project succeed? It’s not language or tools or process. It’s not a simple as people; even great programmers sometimes find themselves associated with disasters. In some sense, a successful project is the same thing as a successful organization; but what makes those? We need an anti-Dilbert. In Organizational Patterns of Agile Software Development, James O. Coplien and Neil B. Harrison lay out the results of their research on the subject; what they found, helps.

즉, 소프트웨어 개발 프로젝트를 성공하게 하는 건, 툴이나 프로세스도, 사람도 아니라 바로 조직이라고 얘기하고 있다. “Object Thinking”에서 주장하는 “사람”과는 또 다른 주장인 것이다. 누구 말이 맞는 것일까? 서로 다른 철학과 서로 다른 주장이 난무하는 이 분야는 아직 pseudo-engineering의 분야이다.