스티브 잡스의 일생에 대한 이야기입니다. 잡스의 학창시절부터 현재에 이르기까지 그가 이루어낸 성공, 실패, 에피소드들이 400페이지에 걸쳐 쓰여져 있습니다. 이야기가 너무나 흥미로워서 잠을 자는 시간을 기꺼이 줄이게 됩니다. 마치 행복한 결말을 알고 있는 헐리우드의 블록버스터 영화를 보는 기분이었습니다.

애플을 창업하고 결국 대단한 성공을 이루었지만, 그는 좋지 않은 습성을 많이 가지고 있습니다. 보통 성공하는 사람이라면 가지지 말아야 한다고 알고 있는 그런 단점들. ‘혼자 결정하기’, ‘잘 삐치기’, ‘고집 부리기’, ‘변덕’, ‘주변 사람들과 잘 싸우기’. 이런 엄청난 약점에도 불구하고 그는 장점을 더욱 부각시켜서 커다란 성공을 이루어 냅니다. ‘열정적으로 일하기’, ‘비전을 제시하고 믿게 만들기’, ‘포기하지 않기’, ‘뛰어난 실행능력’. 놀라운 일입니다. 그의 삶은 마치 이렇게 이야기하는 듯 합니다.

열정. 대단한 것을 만들 수 있다는 믿음. 성공을 위해 그 외 다른 것들은 별로 중요하지 않다.

매킨토시, 픽사 애니메이션, 성공하는 프로젝트 속에는 한결같이 열심히 일하는 참여자들이 있었습니다. 모든 것을 쏟아 붓는 열정. 그 열정이 성공의 보증 수표는 물론 아닐 것입니다. 그럼에도 그 열정을 느낄 때면 내 가슴도 콩닥콩닥 뛰고 있음을 알게 됩니다. 나도 그 격정의 시간과 공간에 머물러 있었으면…

책 중반에 나온 픽사의 인사원칙이 인상적입니다.

"우리보다 나은 사람을 뽑는다"

강제적이지 않은 방법으로 어떤 행동을 이끌어내는 힘.

예를 들면 변기 사진 속의 파리그림. 넛지를 가장 잘 설명하는 사진인 듯.

이 파리그림 하나가 변기 밖으로 튀는 소변의 양을 80% 줄였다고 합니다.

평균적으로 하루에 한 시간 정도 책을 읽습니다. 그 시간은 주로 퇴근하는 지하철 안에서와 잠자리에 들면서입니다. 주말에는 시간을 조금 더 낼 수 있습니다. 이렇게 찔끔찔끔 책을 읽다 보니, 책을 읽고 감상문을 쓰려고 하면 무슨 내용인지 정리가 잘 안됩니다. 읽으면서 마음에 들었던 문장, 가졌던 생각이 다 읽고 난 후에는 날아가 버립니다. 책을 오랜 기간 동안 읽은 경우에는 무슨 내용인지 완전 잊어 버립니다.

alankang 님은 좋은 독서 방법을 사용하고 있습니다.. 그 방법은 책을 읽으면서 마음에 드는 곳을 줄을 그어서 표시합니다. 그리고 그 내용을 위키에 옮겨 적습니다. 그리고 관련 글과 링크를 겁니다. 줄 긋기 대신 포스트잇을 사용하시는 분도 계시군요.  북다트라는 것도 있네요.

책을 두 번씩 읽는다는 분도 있습니다. 두 번 읽음으로써 기억을 더 오래가게 만들 수 있습니다.

읽은 기간을 책 앞에 표시해 두시는 분도 있습니다. 책 읽는 재미를 좀 더 높여주는 효과, 책을 질질 끌지 않게 되는 효과를 기대할 수 있습니다.

중요한 부분을 표시해 놓았다가 다시 한번 음미하는 단계가 필요한 듯이 보입니다. 따라 해 봐야겠습니다.

1. 책을 읽으면서 마음에 드는 부분을 포스트잇으로 표시하면서 생각을 적는다.
2. 표시한 부분을 틈틈히(매일) 노트에 옮겨 적는다.
3. 책을 다 읽은 후에는 감상문을 쓴다.

moq를 사용하기 위해서는 메소드가 추상 메소드이어야 한다. 즉 virtual로 선언되어 있거나 interface 안에 선언되어 있어야 한다. moq를 이용해서 TcpClient와 같은 System class를 직접 mocking할 수는 없다. TcpClient를 mocking하는 한 가지 방법은 Adapter 패턴 을 사용하는 것이다.

1. public interface ITcpClient
2. {
3.   void Connect(string host, int port);
4.   Stream GetStream();
5. }
6. public class TcpClientAdapter : ITcpClient
7. {
8.   private readonly TcpClient _client;
9.   public TcpClientAdapter(TcpClient tcpClient)
10.   {
11.     _client = tcpClient;
12.   }
13.   public void Connect(string host, int port)
14.   {
15.     _client.Connect(host, port);
16.   }
17.   public Stream GetStream()
18.   {
19.     return _client.GetStream();
20.   }
21. }

이제 TcpClient 클래스 대신 ITcpClient 인터페이스를 moq에서 사용할 수 있다.

1. var tcpClientMock = new Mock<ITcpClient>();
2. var streamMock = new Mock<Stream>();
3. streamMock.Setup(stream => stream.ReadByte()).Returns(0x03);
4. tcpClientMock.Setup(tcp => tcp.GetStream()).Returns(streamMock.Object);

더 좋은 방법은 없을까?

스티브 잡스의 신의 교섭력. 자극적인 제목입니다. 부제는 “신인가 악마인가. 위기에서 빛나는 잡스의 마력!” 입니다. 책 표지에는 “이 남자, 상당히 위험하다. … 기술 대공개!” 라고 쓰여 있습니다. 요란한 제목과 설명입니다. 불안한 출발입니다.

책을 읽고 나서의 느낌을 한 마디로 표현하자면 “이건 뭥미?" 입니다. 잡스가 대단하다는 것을 알겠는데, 뭐가 신의 교섭력이고 무슨 기술을 대공개했는지 모르겠습니다.

책에서 소개한 일화, 이야기들의 깊이를 봤을 때, 저자가 과연 잡스에 대해 얼마나 알고 있을까? 하는 의심이 듭니다. 언론에 의해 보이는 것만 보고 생각을 만든 듯해서 믿음이 가지 않습니다. 게다가 그 생각이 편향되어 있습니다. 성공한 사람을 분석하는 것은 필요하지만, 이렇게 보여지는 것, 보고 싶은 것만 보고 판단하는 것은 곤란합니다.

책을 읽는 중간에 슬쩍 짜증이 나서, 스티브 잡스에 대한 다른 책을 읽어 봐야겠다고 생각했습니다. 그래서 서에게 아이콘 이란 책을 빌렸습니다.

책의 분위기가 왠지 모략의 즐거움 과 닮았습니다. 모략의 즐거움처럼 이 책도 중고 장터로 향해야겠습니다. 알라딘에서 명화 텀블러를 준다는 행사에 혹해서 사게 된 책입니다. 다행인 것은 텀블러는 아주 마음에 듭니다.

오랜만에 읽어본 소설입니다. 재미있게 읽었습니다.

위의 빨간 애가 브란웰. 데미안이 생각나는 캐릭터입니다. 아래의 파란 애가 브란웰의 친구이자 이야기를 이끌어나가는 코너입니다. 어떤 사건으로 인해 브란웰이 누명을 쓴 상태에서 말을 못하게 되었는데, 그 원인을 친구인 코너가 파헤쳐 나간다는 이야기입니다. 브란웰이 말은 잃은 날 무슨 일이 있었는지 조금씩 추리해 나갑니다. 식스센스만큼 엄청난 반전은 아니지만 지루하지도 않습니다. 그 과정에서 2차 성장이 막 일어나고 있는 아이들의 이성에 대한 호기심, 부모의 이혼과 재혼이 아이들에게 미치는 영향, 친구 사이의 우정 같은 이야기들에 공감하게 됩니다.

마음에 드는 구절들이 몇 개 있었는데, 찾기가 힘드네요. 책 읽는 방법을 좀 개선해야겠습니다.

오랜만에 소설을 읽으면서 소설이 실용서적보다 좋은 점 두 가지를 생각해 봅니다. 하나는 감수성을 자극합니다. 정신적으로 힘든 상태에서 소설은 회복에 도움을 줍니다. 최근의 우울함을 벗어나는데 좋은 역할을 했습니다. 다른 하나는 읽기 편합니다.  이기적 유전자를 읽을 때는 하루에 몇 장 못 읽었습니다. 난독증에 걸린 것은 아닐까 하는 생각까지 했으니까요. 금방 읽을 수 있어서 자신감이 회복되었습니다.

캐스팅을 하는 일반적인 방법은 다음과 같이 ()를 사용하는 것이다.

1. var num = 3.0;
2. var bnum = (byte)3.0; // bnum = 3

위 방법은 편하지만 안전하지는 않다. 엉뚱한 타입으로 캐스팅하면 문제 - InvalidCastException 발생 – 가 발생한다. 보다 안전한 방법으로 캐스팅하는 방법은 as를 사용하는 것이다.

1. var ms = stream as MemoryStream;

만약 stream이 MemoyStream이 아니라면 ms에는 null이 할당된다. 가능하다면 as를 사용하는 것이 읽기 편하고 안전하다. as를 사용하는 것이 ()보다 성능도 좋다고 한다. 단 int와 같은 built-in 데이타 타입은 as를 사용할 수 없다.

객체가 어떤 클래스에 속하는지 확인하기 위해서는 어떻게 할까? 그때는 is를 사용할 수 있다.

1. if ( stream is MemoryStream )
2. {
3.   var pos = stream.Position;
4. }

읽기 편하다. 아주 마음에 든다.

동생이 DSLR 카메라를 샀습니다. 가끔 진이 사진을 찍어주는데, 제 똑딱이로는 볼 수 없었던 진이의 모습을 보게 되네요.

세수하는 진이

사색하는 진이

우리는 과거의 경험, 특히 실패한 경험으로부터 많은 것들을 배울 수 있습니다. 드리밍 인 코드는 챈들러라는 프로젝트가 진행되는 과정을 보여줌으로써 소프트웨어 개발에 대한 귀중한 간접 경험을 제공합니다.

이 책을 통해서 얻을 수 있는 교훈을 단 한 문장으로 표현해야 한다면 다음 문장이 제격일 듯 싶습니다.

은총알은 없다.

새로운 기능을 가진 혁신적인 소프트웨어를 개발하는 것은 어려운 일입니다. 어려움을 덜기 위해 여러 가지 방법론이 제시되고 있지만, 언제나 성공을 보장해 주는 확실한 방법론은 없습니다. 모든 프로젝트는 나름대로의 특성으로 인해 특별합니다. 한 프로젝트에서 성공한 방법도 다른 프로젝트에서는 동작하지 않을 수 있습니다.

챈들러 프로젝트는 오픈 소스, 매력적인 비전, 안정적인 개발 환경, 뛰어난 개발자들과 같은 특성으로 인해 뭔가 다를 것으로 기대되었지만, 결국은 여느 프로젝트처럼 무리한 계획과 일정 지연에 시달립니다. 그 결과물인 챈들러 1.0을 실행시켜 보면 ‘이것이 과연 좋은 개발자 10명 이상이 5년 이상 개발한 것이란 말인가?’ 라는 생각이 들 정도 입니다. 무엇이 챈들러 프로젝트를 실패하도록 했을까요?

책 중반 즈음을 보면 챈들러의 PM인 미치 케이퍼가 다음과 같은 말로 진행의 더딤을 표현하는 말이 나옵니다.

어떻게 하면 유용한 작업을 시작하기 전에 우리가 준비하는 데만 무한한 시간과 노력을 들이는 일을 피할 수 있을까요?

준비하는 데만 무한한 노력과 시간을 들이고 있습니다. 원해서 혹은 모르기 때문에 그렇게 된 것이 아닙니다. 잘 하려다 보니 그렇게 된 것입니다. 확장가능하고 혁신적인 챈들러를 위해서 몇 가지 중요한 의사결정을 신중히 해야 했습니다. 데이터 저장방식을 결정하는 일. 문서 모델을 결정하는 일. 기본 컴포넌트를 결정하는 일. 공유 방법을 결정하는 일. 이 어렵고도 중요한 의사결정을 하는 데 모두 오랜 시간을 필요로 했습니다. 어떤 것들은 결정을 번복해야 했습니다. 처음부터 다시 시작한 것도 있었습니다. 일정 지연은 필연적으로 발생하게 되었고, 그 과정에서 처음에 중요하게 생각했던 기능들을 포기하게 만들었습니다. 프로젝트 자체의 비전이 흔들리게 된 것입니다.

그 원인은 다양할 것입니다. 구체적인 목표가 없는 것, 기술에 대한 전문성이 부족한 것, 새로운 것을 과감하게 시도한 것, 외부의 압박이 없는 것. 모든 것을 만들려고 한 것. 무리한 계획을 세운 것. 이 원인들은 또한 우리의 프로젝트가 실패하게 되는 일반적인 요인들이기도 합니다.

왜 우리는 뻔히 알고 있는 문제들에 의해 프로젝트가 지연되는 것을 막을 수 없는 것일까요? 여기 한가지 흥미로운 설명이 있습니다.

브룩스의 법척. 이미 지연된 프로젝트에 추가 인력을 투입하는 것은 일정을 더 늦출 뿐입니다. 새로 투입된 인원을 교육하는 시간이 필요하기 때문에 단기적으로는 인원이 증가된 효과를 누리지 못합니다.

한편 개발자는 매우 열심히 일합니다. 그러나 개발자는 프로젝트에서 중요한 것이 아닌 자기가 좋아하는 것을 개발하려고 합니다.  문제는 본인은 물론 주위에서도 그것이 중요한 것인지 그렇지 않은지를 알기 어렵다는 것입니다. 열심히 일하고 무엇인가를 만들어 내는데, 일정 지연이 생깁니다. 개발 인원이 부족하다고 생각하고 인원을 투입하면 브룩스의 법칙의 지배를 받게 됩니다. 악순환입니다.

마음에 들었던 부분

이 책은 소프트웨어 개발의 발전과정, 역사에 대한 지식을 늘려 줍니다. 개발 방법론의 변천 및 긱의 어원같은 재미있는 사실을 많이 알게 되었습니다.

다음과 같은 멋진 구절이 있었습니다.

세상을 바꾸고 싶다면 비관적인 지성, 낙천적인 의지를 가져야 한다.

프로그래밍을 공부하는 방법에 대한 특이하고도 인상 깊은 접근법도 있었습니다.

저는 프로그래머들도 시인, 예술가처럼 창의적인 활동을 하는 사람들을 양성하는 방식으로 양성해야 한다고 생각합니다. 사람들은 이게 엉뚱한 소리라고 말할지도 모릅니다. 하지만 시문학 석사학위를 받으려고 교육받을 때 사람들은 무엇을 하나요? 그들은 위대한 시들을 공부합니다. 소프트웨어 공학에서 그렇게 하나요? 아니요. 우리는 위대한 소프트웨어의 소스코드를 읽지 않습니다. 위대한 소프트웨어의 설계를 공부하지도 않죠. 그 디자인을 보지도 않고요. 위대한 소프트웨어 디자이너들의 인생을 공부하지도 않습니다. 즉 우리는 우리가 만들려는 것의 기존 문헌들을 공부하지 않습니다.  - 리처드 가브리엘

생각

저는 방법론에 대해 강박관념 같은 것이 있습니다. 제 머리 속에서는 TDD를 해야만 멋진 것이고, 안 하거나, 잘 진행이 안되면 실망합니다. 애자일 방법론을 따라야 하는 것이고, 무엇이라도 벗어나는 것이 있으면 문제가 있다고 생각합니다. 간결한 코드를 추구해야만 합니다. 책을 읽고 나서는 이 생각이 바뀌었습니다. 이런 생각들은 불행히도 내 진정한 경험에서 나온 것이 아니고, 책 혹은 다른 사람의 이야기로부터 나온 것들입니다. 그들의 경험을 존중해야 하지만, 맹신해서는 안되겠습니다. 모든 방법론은 권장사항 혹은 내가 해 봤더니 좋더라 정도로 받아들이는 것이 좋을 듯합니다. “꼭 해봐야겠는걸. 그런데 잘 안되네.. 내게 무슨 문제가 있는걸까?” 가 아니라, “정말 그렇게 좋아? 네가 좋았다니 나도 해 보겠어. 하지만 나에게 맞는 것만 받아들일 거야.” 정도로만 생각해야겠습니다.

언제나 통하는 은총알은 없습니다. 하지만 반대로 어쩌면 지금 우리가 만들고 있는 총알이 우리를 가로 막고 있는 드라큐라의 숨통을 끊을 수 있을지도 모릅니다. 조금 더 흥미진진해졌습니다.

Resharper 를 다운로드 받아 설치한다.

비쥬얼 스튜디오를 열고 프로젝트를 하나 생성한다.

Test 프로젝트를 추가한다. 테스트 프로젝트를 꼭 생성할 필요는 없지만, 보통 생성하는 듯이 보이며, 생성하는 것이 더 깔끔해 보인다.
Test 프로젝트 밑에 lib 디렉토리를 만들어서 xunit.net 과 moq 를 넣어 준다. 필요한 파일은 moq.dll, xunit.dll, xunit.extensions.dll 이다. 그리고 이 dll 파일들에 대해 참조 추가를 한다. lib 디렉토리 역시 꼭 만들 필요는 없지만 관리하기 편해 보인다.
Test 프로젝트에서 참조 추가를 해서 테스트하려는 프로젝트를 추가한다. 준비를 마치면 솔루션 탐색기는 다음과 같이 된다.

Test 프로젝트에 클래스를 하나 추가해서 테스트를 작성한다.

테스트 오른쪽 옆의 동그라미를 누르면 테스트 메뉴가 보인다. 테스트를 실행하면 에러가 발생한다.  FirstClass가 없기 때문이다. FirstClass를 만들고 TrueTest()메소드를 추가한다.

이제 Test 가 성공한다.

보기 좋고 편리한 UI와 빠른 테스트 속도가 마음에 든다.