Book

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의 분야이다.

Inside C#, 2nd Edition

C# Programming Language에 관한 책이다. 사실 .Net Framework에 대한 내용도 상당히 포함되어있기 때문에, Language를 배우기에 좋은 책은 아니다. 그럼에도 불구하고, C#의 여러 언어적인 요소와 CIL(Common Intermediate Langauge; aka MSIL)을 비교하면서 작동원리를 설명해주기 때문에 C# Programming Language의 구현 방식을 약간이나마 들여다볼 수 있는 점은 이 책의 미덕이다. 번역은 엉망인 편이다. (10점 만점에, 초반은 4점 중반은 0점, 후반은 5점 정도?) 아르바이트 생들에게 시키고 한번도 제대로 읽어보지 않은 정도의 퀄리티. 읽어보면서 내가 직접 수정하면서 읽어간 곳만도 한 스무군데 정도 되는 것 같다. 요즘에 번역서를 몇권 보면서 신뢰를 약간 얻어가는 중이었는데, 이 책을 보고 다시 실망해버렸다. 따라서 이 책을 읽고자 하는 사람은 차라리 원서를 보기를 추천한다.

참고로, C# Programming Language를 공부하고 싶다면 이 책보다는, O’Reilly사의 Programming C#, Third Edition과, C# Programming Language의 아버지인 Anders Hejlsberg가 쓴 The C# Programming Language를 추천한다.

Modern C++ Design

Modern C++ Design은 template의 사용에 관한한 최고의 책이라고 한다. template이 어디에 쓰는 건지 모르겠다면 Modern C++ Design은 template을 사용해서 구현할 수 있는 모든 technique을 보여줄 것이다. (from http://www.lastmind.net/tWiki/bin/view/Main/SoftwareDevelopmentBooks)

현재 읽고 있는 책이다. 현재 Chapter 6를 읽고 있는데, 이번 달 안에 끝낼 생각. 번역은 C++ In-Depth 시리즈를 통틀어서 그렇듯이, 만족스러운 편이다. Template parameter를 Strategy로 사용하는 idiom을 Chapter 1에서 소개하고, Template을 사용하는 자잘한 techniqueue을 Chapter 2에 모아두었다. 이어서 Template을 이용해서 구현하는 굵직굵직한 주제들이 나온다. Typelists, SmallObjAllocator, Generalized functor, Singleton, Smart pointer, Object Factory, Abstract Factory, Visitor, Multi Method가 그것들인데, 잘 알려진 패턴이거나 현재 Library TR에서 adopting 중인 것이기 때문에 어쩌면 이미 잘 알고 있는 사람도 있을 것 같다. (저자인 Andrei Alexandrescu가 CUJ의 고정 칼럼 필자이기 때문에, CUJ에서도 이미 다루어졌던 주제들이 많다.) 어떤 것들은 이것이 쓸모가 있는가 싶을 정도인 것도 있고, 어떤 것들은 당장 내 코드에 반영할만한 것들도 있고, 또 내가 직접 구현해보고 싶은 것들도 있다. 확실히 template을 잘 쓰고 싶은 사람이라면 한번쯤은 거쳐가야할 책인 듯 싶다.

(참고로 이 글은 요즈음 만들고 있는 MovableTypeWriter로 작성한 글.)

[“딥뿔군의 글”:http://myruby.net/archives/002324.html]에 적혀있는 세가지 법칙을 보고 생각난 것을 적어보자면…
**1. ‘공격적인’ 스케쥴에 메인 프로젝트는 좀 더 타당한 스케줄을 따랐을 때보다 프로젝트를 끝내는 데 더 오래 걸린다.**
bq. 흔히 스케줄을 일에 비해 짧게 또는 희망적으로 잡는 경우인데, 스케줄은 프로젝트 관리에 경험이 적을 수록 비관적으로 잡는 것이 좋다고 생각한다. (경험이 많아지면, 스케줄을 재조정하는 것도 프로젝트에 나쁜 효과를 끼치지 않고 유연하게 할 수 있지 않을까 생각) 그런데, 의외로 이렇게 잡아야만 열심히 일한다고 생각하는 사람이 많다. 하지만, 경험적으로 리스크가 끼어들거나 해서 시간이 부족하면 위에서는 압력이 들어오고, 당사자들은 초조해지고, 그래서 프로젝트가 방향을 잃고 좌초하는 경우도 많다.
**2. 작업을 완료하는데 필요한 프로세스에 대한 자신의 직감을 모델링한다.**
bq. ‘직감’ 이런 단어가 들어가면 정말 어려운 것들이다. 책을 읽지는 않아서, 이 말이 무엇을 말하는지 정확히는 모르겠지만, 경험을 통해 직감을 성숙시키고, 이를 ‘모델’화하라는 말인 것 같다. 대부분의 책들은 이를 위한 의식적인 노력이 필요하다고 얘기하고 있다. 특히 ‘측정’을 통해, 원래의 예측이 얼마나 틀렸는지, 무엇이 원인인지 등을 파악해야한다. 난 측정까지가 아니라 원인 분석 정도에 그치고 있는데, 측정을 활용하면 좀 더 빠르게 이러한 직감에 이를 수 있지 않을까 생각해본다.
**3. 하루를 잃는 데는 수없이 많은 방법이 존재하지만, 하루를 만회하는 데는 단 한가지 방법조차도 존재하지 않는다.**
bq. 내 경우, 하루를 잃게 되는 대부분의 경우는, 오늘 할 일을 내일로 미루는 것이다. 프로젝트 원에게 진행상황을 물어볼 것을 오늘 하지 못하는 경우, 무엇을 확인하고 시켜야할 것을 내일로 미루는 경우, 스케줄은 하루씩 미뤄지는 것 (단축할 수 없는 것)과 마찬가지인거다.

원문: http://www.lastmind.net/tWiki/bin/view/Main/SoftwareDevelopmentBooks

C++ Programming Language

프로그래밍 언어에 대한 책에는 세가지가 있다. 프로그래밍 언어를 배우기 위한 책, 프로그래밍 언어를 잘 쓰기 위한 책, 프로그래밍 언어의 레퍼런스.

읽어보지는 않았지만, C++을 배우기 좋은 책으로 ‘Essential C++’을 꼽을 수 있을 것 같다. Bruce Eckel의 ‘Thinking in C++’같은 것도 나쁘지 않은 것 같다. (본인은 좋은 C++ 입문서를 읽어본 적이 없다. 번역서는 커녕 일반 서점에서는 외서를 구하기가 힘들었기 때문에, 한국 사람이 쓴 책을 읽었었다.)

‘The C++ Programming Language’는 C++의 창안자인 Bjarne Stroustroup이 쓴 책인 만큼 권위도 있고 자세하기도 하고 잘 쓰여진 책이기도 하다. (한 때, ISO C++ Standard가 이 책을 기반으로 쓰여지기도 했으니까) 이 책은 위에서 말한 프로그래밍 언어에 대한 책의 세가지 성격을 모두 갖고 있는 책에 가깝다. C++의 문법뿐만 아니라 왜 그런 문법이 생기게 되었는가, 그리고 어떻게 사용해야하는가 까지도 자세하게 적고 있으니 말이다. 이러한 성격 탓에 입문서로는 약간 부담스러울 수는 있으나, 다른 입문서를 읽고 C++ 문법을 모두 익히더라도 한번 쯤 읽어볼만한 책이다.

개인적으로 Effective 서들은 C++의 중급자로 올라서기 위해서는 ‘필수서’라고 생각한다. C++을 사용할 때 거의 항상 부닥치는 문제들에 대한 idiom을 제시하고 있기 때문이다. Exceptional* 서는 *Effective*보다는 덜 범용적이지만, 역시 중요하고 유용한 idiom들을 적고 있다. Modern C++ Design은 template의 사용에 관한한 최고의 책이라고 한다. template이 어디에 쓰는 건지 모르겠다면 Modern C++ Design은 template을 사용해서 구현할 수 있는 모든 technique을 보여줄 것이다.

‘The C++ Standard’는 말그대로 ISO C++ Standard를 책으로 만든 것이다. 더 정확하게는 C++98과 이후에 나온 Technical Corrigandum 1 (일종의 서비스팩)을 합쳐놓은 버전이다.
STL reference로는 STL Tutorial and Reference Guide의 번역판을 가지고 있으나 별로 참조할 일이 없어서 평가는 하기 힘들 듯 하다.
대체로 http://cppreference.com 이나 ‘The C++ Standard’를 참조하는 편이다.

번역에 관해 한마디 하자면, 본인이 읽어본 번역서는 Effective 시리즈와 Exceptional C++이다. (Modern C++ Design 읽는 중) Effective 시리즈도 번역이 나쁘다는 사람이 있으나, 개인적으로는 그런대로 읽을만하다고 생각했고, (개인적으로 기본적인 용어를 번역하는 것을 싫어한다) Exceptional C++은 악역이었다. Herb Sutter의 홈페이지에 쓰여진 내용을 찾아 대조해보면서 읽어야만 했다.

저자에 대해서도 좀 적어보면, Bjarne Stroustroup(http://www.research.att.com/~bs/homepage.html)은 C++의 창안자이자 현재도 ISO C++ standard commitee에서 활발하게 활동하고 있는 사람이다. Herb Sutter(http://www.gotw.ca/)는 ISO C++ standard committee의 의장(convener)이며, 책이나 논문, 잡지(CUJ) 등을 통해, 활발할 저술활동을 하고 있다. comp.lang.c++.moderated newsgroup의 moderator이기도 하다. ‘Modern C++ Design’의 저자인 Andre Alexandrescue도 CUJ에 정기적으로 기고하는 사람 중 하나이다. Scott Meyers는 Effective 시리즈의 저자라는 사실 하나라도 너무나도 유명하기 때문에 굳이 따로 언급할 필요도 없을 듯 하다. (사실, 그 외에는 잘 모르겠음)

입문서

• Essential C++: C++ In Depth 시리즈의 입문서
• Thinking in C++, Volume 1: Introduction to Standard C++ ‘Thinking in Java’로 유명한 Bruce Eckel의 저서
• Thinking in C++, Vol. 2: Practical Programming
• The C++ Programming Language C++의 창안자인 Bjarne Stroustroup의 책. 그만큼 권위있고 잘 쓰여진 책이다.

C++을 잘 쓰기 위한 책

• Effective C++
• More Effective C++
• Effective STL
• Exceptional C++
• More Exceptional C++
• Modern C++ Design: C++ template 사용에 관한한 최고의 책
• Large-scale C++ Software Design
• Design & Evolution of C++: C++의 프로그래밍 언어적인 요소들이 어떤 이유로 현재의 형태로 정해졌는지 설명해주는 책.
• Advanced C++ Programming Styles and Idioms: C++ idiom에 대해 자주 인용되는 책 중의 하나.

레퍼런스

• The C++ Standard: C++ Standard를 옮겨놓은 절대적인 reference
• STL Tutorial and Reference Guide: C++ Programming with the Standard Template Library
• The C++ Standard Library : A Tutorial and Reference

‘Design Patterns’의 패러디. 사보고 싶다. 하지만, 연애에 정통한(?) 친구의 말에 의하면 연애는 항상 case by case라고 한다. +_+
 
http://www.amazon.com/exec/obidos/ASIN/0974312002/qid%3D1080878203/sr%3D11-1/ref%3Dsr%5F11%5F1/103-6893209-5095018