[도서] Programmer in New York

1. 벼랑 끝에선 마이크

1.1. 페어프로그래밍
 - XP프로그래밍에서 페어프로그래밍은 두 사람이 작업을 같이 수행하면, 한사람이 각각 작업을 수행하는 것 보다 효율적이라는 철학이다.
 - 페어프로그래밍은 항상 할 수 있는것은 아니지만 많이 행해질 수록 좋다는 생각을 가지고 있다.
 - 그러나 중요한 것은 공평한 규칙이 지켜지는 것에 한해서이다.
 - 공평한 규칙의 요소는 '실력'이 아니라 '열정'이다.
 - 프로그래밍 실력은 차이가 나도 페어프로그래밍을 수행하는데 아무 상관이 없다.
 - 그러나 열정의 수준은 동등해야 한다.
 - 책에서 마이크가 발생시킨 버그를 영우가 도와주는데 마이크의 관심은 영우가 이 문제를 해결해 주기만을 가만히 기다린다. 이것은 페어프로그래밍도 아니고 아무것도 아니다. 그냥 기생하는 것이다.
 - 진정한 페어프로그래밍을 하기위해서는 서로 주인의식을 가지고 열정적으로 페어프로그래밍에 임해야 한다.
 - 그렇지 않고 마이크처럼 행동한다면 영우의 의욕을 꺽어버릴 뿐더러, 팀원 서로간에 이용하고, 이용당하는 관계가 싹트게 된다. 팀의 분위기를 와해 시키는 잘못된 방향이 아닐 수 없다.

1.2. JIRA
 - 아틀라시안(Atlassian)에서 만든 웹 기반 프로그램
 - 버그나 업무를 기록하고 관리 할 수 있다.
 - 지라에서는 버그 우선순위를 P1 ~ P5까지 설정해두고 있다.
 -- P1, P2 : 소프트웨어가 출시되기 전에 반드시 수정되어야 하는 버그나 업무를 의미한다.
 -- P3     : 주어진 시간내에 할 수 있으면 좋고, 그렇지 않으면 다음 릴리즈에 넘겨도 좋은 평범한 문제
 -- P4, P5 : 실질적으로 수정될 필요가 없는 지극히 사소한 문제

1.3. Command Pattern
 - 명령을 객체화한 패턴
 - 인터페이스에 execute()라는 메소드를 두고
 - 이를 구현한 객체를 '커피 볶기 - execute()', '커피 분쇠하기 - execute()', '커피 끓이기 - execute()'로 명령어를 객채화 하면, 많은 switch, if - else 구문을 피하고, 보다 유연하면서도, 간단한 방식으로 명령을 처리할 수 있다.
 - 예) struts에서 Action객체의 execute메소드가 이와 같다고 할 수 있다.

2. 잔디밭에 피어오르는 잡초
 - 버그가 완전히 없는 프로그램은 없다. 이러한 버그를 미연에 방지하고, 줄여가기 위해서는 풍부한 유닛 테스트를 보유하는 것이 필요하다.
 - 유닛 테스트는 오류 발생을 유닛 단위로 수정하고 테스트 할 있으며,
 - 전체 프로그램은 작은 유닛단위로 개발할 수 있기 때문에 변화에 빠르게 되는 장점이 있다.

3. 무정부 주의자 콜린
 - 프로그래머는 고도의 창의성과 섬세함, 그리고 논리성이 필요한 작업이다.
 - 이러한 작업을 위해서는 리듬을 타는것이 중요하다.
 - 이러한 리듬을 만들기 위해서는 충분한 휴식과, 자기만의 취미와 같은 것들이 필요하게 된다.
 - 하지만 이러한 것들을 빙자하여, 늦게 출근하거나, 일찍 퇴근해 버리는 등의 일을 밥먹듯이 하게 되고, 팀이라는 개념보다는 자신의 작업을 너무 고집하게 되면 좀더 향상된 프로그램이 나올 수없다고 생각된다.
 - 프로그램은 혼자서 하는것이지만 시스템은 그 혼자들이 모여서 이루어지는 것이기 때문이다.
 - 최소한의 기본은 필요하지 않을까? 생각된다.

4. 톰과의 한 판 승부
 - 개발을 하다보면 버그가 발생하고, 이 버그의 치명성 정도에 따라 개발자들 사이에 알게 모르게 발생되는 승부가 일어난다.
 - 먼저 이 버그를 수정하여 자신의 빠른 판단력과 프로그래밍 실력을 보여주고 싶은것은 대부분의 개발자들이 가진 당연한 마음이기 때문이다.
 - 영우는 새벽 4시에 미아로 부터 걸려온 전화를 받고 버그의 원인과 이를 수정하기 위해서 시름한다. 역시 같은 시간에 톰도 영우와 같은 처지에 놓이게 된다. 이들은 자신이 이 버그를 해결하고 말겠다는 생각으로 열심히 모든 논리와 가설로 버그픽스에 임한다.
 - 이 승부에서는 톰이 영우보다 빠르게 해결했다.
 - 이 내용에서 중요한 것을 몇가지 얻게 되었다. 그것은 선의의 경쟁은 긍정적인 효과를 가져 온다는 것이다. 또한 이러한 선의의 경쟁이 발생할 수 있는 원인제공, 동기? 이러한 것들이 무엇일까 고민해본 결과 '동일한 목표'라는 것이 아닐까? 생각해 보았다. 공동의 목표 내가 이기고자 하는 것이 아닌, 하나의 문제를 해결하는 것이 목표이기 때문에 누가먼저 한다고 해도 그렇게 치명적이지 않다는 것이다.
 - 마지막으로 문제를 해결하는 능력역시 중요하지만 그것보다 문제를 바라보는 관점이 더욱 중요하다는 것이다. 우리는 문제가 발생하면 문제가 제시하는 정확한 의미를 파악하기보다, 그 문제를 당장 해결해야 한단느 것에 초점을 맞추게 된다. 그러나 그러한 방식으로 문제해결에만 초점을 맞추다 보면 문제가 가지고 있는 다면적인 부분, 그리고 문제의 근본원인과 전혀새로운 문제를 발견했을때 이를 쉽게 해결하지 못하는 경우가 발생하기 때문인다.

5. 로버트는 왜 회사를 그만두었는가?
 - 로버트는 제품 출시를 얼마앞두지 않고 자신이 만든 치명적인 버그를 고치기 위해 밤을 세며 수정작업을 했다.
 - 단순하게만 보였던 문제를 해결한 다음날 QA팀에서 버그 픽스를 통해 생긴 다른 문제점을 또 발견하게 되고, 제품 출시는 뒤로 미루어지게 되었다.
 - 로버트는 기능적인 부분의 버그를 고치고, 자신의 일이 끝났다고 생각했다. 그러나 성능적인 면에서 치명적인 문제점인 메모리 누수가 발생되었다.
 - 프로그램을 하는데는 개발만큼 중요한 것이 테스트인것 같다. 아니.. 테스트가 더욱 중요한것 같다. 문제를 단순한 국면으로만 바라보지 않고, 전체적으로 바라보는 시선, 그리고 꼼꼼하고 논리적으로 따져보는 것이 중요함을 다시한번 느끼게 해 주었다.
 - 또한 로버트는 그러한 일이 발생하자, 회사에 사표를 쓰고 떠나게 된다.
 - 누구나 실패를 하지만 로버트는 그 실패를 극복하지 못하고 회사를 떠나버린것이다. 실패 그것을 극복하고 일어난 사람은 엄청난 발전을 한다. 그러나 극복하지 못하면, 세월만 낭비하게 되고, 자신감만 약해지게 한다. 실패는 두려워할 것이 아니라, 자신을 더욱 발전 시키는 계기일 뿐이다.

6. 프로그래밍의 절대 미학
 - 프로그래밍에서 중요한 것은 말이 아니라. 코드이다.
 - 말과 행동이 어눌하거나, 혹은 말은 정말 멋드러지게 한다고 해서 그 사람을 어떠한 프로그래머라고 평가하지 말아야한다.
 - 오직 믿을 수 있는것은 얼마나 간결하면서도, 유연하면서도 제대로 동작하는가? 그것이다.

7. 유용한 툴
7.1. 지라(JIRA)
http://www.atlassian.com/software/jira/ 아틀라시안에서 만든 버그 트래킹 시스템 상업용

7.2. 이서리얼(Ethereal)
http://www.ethereal.com/ 네트워크를 오고가는 패킷을 저장해서 내용을 분석할 수 있도록 해주는 도구이다. 오픈소스 프로그램이다.

7.3. 유어킷(Your Kit)
소프트웨어가 CPU나 메모리 같은 하드웨어 자원을 사용하는 량과 패턴을 분석해주는 도구. 자바 언어에서는 유어킷(http://www.yourkit.com)과 함께 볼랜드사에서 나오는 옵티마이즈잇(?OptimizeIt)이 많이 사용된다.

7.4. 퍼포스(perforce)
소프트웨어의 소스코드를 관리하는 프로그램이다.