아키텍트 이야기를 읽고 있습니다. 처음에는 딱딱하고 어려운 책 아닌가 생각했었는데, 설명 중간에 줄거리가 되는 이야기가 있어서 책을 읽을 때 흥미를 꾸준히 느낄 수 있도록 합니다. 책에서는, 아키텍트란 소프트웨어 개발과 관계되어, 기술적 결정을 하는 최고 책임자라고 정의합니다. 프로그래머의 정년은 다른 직업보다 짧게 이야기되곤 하는데요, 이 책에서는 그에 대한 대안으로 아키텍트라는 역할을 제시합니다. 줄거리가 되는 이야기의 등장인물들은 이니셜을 가지고 등장하는데요. C라는 인물이 아키텍트로서 마주하는 상황들이 재미있으면서도 현실적으로 느껴졌습니다. 이는 저자가 다양한 시스템을 개발한 경험을 가지고 있는 데에서 기인한 듯합니다.

한국에서도 아키텍트라는 직업은 이제 낯선 이름이 아니게 된 듯합니다. 네이버 카페 아키텍트를 꿈꾸는 사람들에서는 스터디와 캠프 등 활발한 활동을 펼치고 있습니다. 문제를 풀기 위해 기술을 판단한다는 점에서 아키텍트란 직업은 매력이 있습니다. 다만, 훌륭한 아키텍트가 되기 위해서는 끊임없이 기술을 학습하고 의사소통을 잘 하는 법을 익히는 등 많은 노력이 필요할 것 같습니다. 아키텍트에 대한 전반적인 정보를 듣고, 아키텍트와 개발자 사이의 차이를 인지하는 데 도움을 주는 책이라고 봅니다.
아키텍트 이야기 상세보기
야마모토 케이지 지음 | 인사이트 펴냄
개발자들을 위한 아키텍트 이야기를 담은『아키텍트 이야기』. 이 책은 아키텍트가 프로젝트의 흐름에 따라 어떠한 역할을 하고 어떻게 프로젝트를 성공시키는 가에 대하여 가상의 아키텍트를 통하여 상세하게 설명한다. 《아키텍트 이야기》에서는 아키텍트의 요구 분석 단계 업무와 설계방법, 아키텍처로 문제를 해결하는 방법, 왜 아키텍트가 돌파구인가에 대한 내용으로 구성했다.
Posted by 세레

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2008.01.21 15:59
    프로그래머의 정년에 관한 이야기는 참 많았죠. 어떻게 해야 오래 살아남는다. 일정 단계 이후엔 무엇이 되어야 하느냐등등.. 아키텍트를 단지 프로그래머가 가질수 있는 대안이 아닌 또 다른 하나의 직업으로 보아야겠죠. 물론 프로그래머 출신이 훨씬 더 유리할 수는 있겠지만 말입니다. 인사이트의 책은 확실히 읽고 싶다는 욕구를 불러일으키는 책들이 많은것 같습니다. 좋은 책 소개 잘 보았습니다.^^
    • 2008.01.21 18:12 신고
      댓글 주소 수정/삭제
      그렇네요, 저의 오독입니다. 아키텍트는 또다른 미래에 할 수 있는 직업이네요. 좋은 지적 감사합니다. 좋은 책을 계속 출판해 주는 곳 중 하나라서(곧바로 수익으로 이어지지 않는 책들도 있기 때문에, 사명적인 느낌이 듭니다), 저도 좋아하는 출판사입니다.

 

Professional 소프트웨어 개발을 읽었습니다. 스티브 맥코넬 씨가 지은 책인데요, 번역서가 2003년에 초판이 발행되었네요. 책의 용어를 사용하자면 이 책은 SWEBOK(Software Engineering Body of Knowledge)에서 변하지 않는 범주에 속하는 책이라고 여겨집니다.

책을 읽고 나서 곰곰이 생각하게 된 것은, 컴퓨터과학과 소프트웨어공학 사이의 격차인데요. 일단 컴퓨터과학은 현업에서 그 가치가 크게 인정받지 못하더라고, 다른 과학자와 주로 관련을 맺는 점에 반해, 소프트웨어공학은 현업에서 실제로 소비자와 부딪치기 때문에 여러가지 제약 조건들을 숙지하고 있어야 한다는 점이 인상적이었습니다.

마지막 파트인 업계의 프로정신에서 다루어진, "혁신의 확산"에 대한 그래프가 있었는데요. 선각수용자와 전기 다수의 캐즘(chasm)을 다루고 있는 부분이 있었습니다. 혁신자보다는 적은 위험을 안는 선각수용자들은 XP나 스크럼 등 애자일 방법론을 적용하는 쪽이고, 전기 다수인 사람들은 역량 성숙도 모델(CMM) 종류를 적용하는 것이라고 생각했습니다. 책에서는 Code&Fixing(일단 코드를 작성하고, 나중에 고치는)을 가장 피해야 한다고 했는데, 이 부분에서 가책을 느꼈습니다.

책의 역자서문에서는 Rapid Development나 Code Complete를 스터디하기 전에, 다소 추상적인 에세이들이 모인 이 책을 먼저 읽을 것이 추천되고 있습니다. 소프트웨어공학 분야를 아우르면서, 동시에 "프로페셔널"하다는 것에 논한다는 점에서 신선한 자극을 주는 책이락 생각합니다.
Posted by 세레

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2007.12.28 09:00
    꽤 재밌게 읽었는데, 내용이 가물가물하네요.^^ 집에가서 다시 한번 훑어봐야겠어요. 서평들 잘 읽다간답니다.^^
    • 2007.12.28 13:34 신고
      댓글 주소 수정/삭제
      네, 저도 재밌게 읽었어요. 들러주셔서 감사합니다. :)
  2. 2007.12.29 13:51 신고
    트랙백보고 놀러왔습니다. ^^

    서평 잘보고 갑니다.~
    • 2007.12.29 16:46 신고
      댓글 주소 수정/삭제
      트랙백에서 오셨군요. 반갑습니다. :)

 

실용주의 프로그래머를 위한 단위테스트 with JUnit를 읽었습니다. 실용주의 서가에서 나온 책인데요, 데이비드 토머스와 앤드류 헌트가 실용주의 프로그래머의 실천편이라고 보시면 될 듯합니다. 테스트는 코드를 다 작성하고 나서 발견하지 못한 오류를 찾기 위해 나중에 작성하는 것이 아닌가라고 생각하시는 분이 꽤 되리라고 생각합니다. 시간과 공간 자원에 제약이 걸린 일반적인 프로젝트의 경우에는, 동작하는 코드를 만들기에 급급해서 테스트라는 부분을 소홀히 하는 경우도 드물지 않을 것입니다. 그리고 그때 테스트를 수행한다고 해도 그건 요구사항에 적합한지 확인하는 인수 테스트(acceptance test)이죠.

이 책은 단위테스트를 왜 도입해야 하는가에 대해 서론에서 매우 설득력 있게 설명하고 있습니다. 원천적으로 오류가 없는 소프트웨어란 매우 어렵습니다. 목적은 매 순간의 코드를 단위테스트를 통해 검증함으로써 나중에 일어날 수 있는, 즉 찾지 못한 오류가 누적됨으로써 발생하는 재앙을 막아보자는 데 있습니다. 이런 패턴적 문제 해결은 애자일 쪽과 통하는 면이 있습니다. 코드를 작성함으로써 부산물로 나오는 단위테스트 코드는, 그 코드를 후에 인수할 사람들에게는 좋은 문서이자, 참고자료, 나침반이 됩니다.

이 책에서는 JUnit으로 테스트를 작성하는 근본적인 부분부터, 테스트의 대상은 무엇인지, 모의 객체는 어떻게 사용하는지, 프로젝트에서는 테스트를 어떤 식으로 할 것인지 등에 대해 차근차근 다루고 있습니다. 재치있는 약자를 통해 쉽게 책의 내용을 숙지할 수 있도록 돕는 것도 책의 장점입니다. 이를 테면 Right-BICEPCORRECT가 있습니다.

사실 이 책을 고른 이유는, 책의 서문에서 비록 이 책이 예제는 Java를 사용하고 JUnit 프레임워크를 사용했지만 다른 60개가 넘는 언어에서 비슷한 테스트 프레임워크가 지원된다고 했기 때문입니다. c2.com에서 Testing Framework라는 문서를 통해 다양한 프레임워크가 있다는 것을 알 수 있습니다. 개인적으로 SmlUnit[각주:1]이라는 테스팅프레임워크를 다루어 보려고 하다가, 막막해서 JUnit에 대한 책이 나와 있으니 이 책을 우선 참고하는게 어떨까 하는 생각이었죠.

프로젝트에 단위테스트를 도입하여 꾸준한 피드백으로 잘 조직화된 코드를 작성한다면, 유지보수성이 높고 안정적인 결과물이 나오지 않을까 생각해 봅니다.
단위 테스트 (실용주의 프로그래머를 위한) 상세보기
데이비드 토머스 외 지음 | 인사이트 펴냄
소프트웨어 개발의 생산성을 증대하기 위한 기본 도구들을 다룬 '시작 도구 시리즈'의 두번째 책으로 JUnit를 이용한 단위테스트 방법을 소개한다. 이 책은 테스트를 통해 요구사항을 좀더 명확히 하고 질 높은 소프트 웨어를 개발하고자 하는 테스트 주도 개발에 중점을 두고, 자동화 테스트 기구인 JUnit을 이용하여 무엇을 어떻게 테스트할 것인지 구체적이고 실용적인 방법을 제안하고 있다.

  1. SML#, SML/NJ, MLton을 지원하는 Standard ML 버전 프레임워크. SML#-SMLUnit에서 JUnit의 이식된 버전임을 밝히고 있다. SML#의 도구로 포함되어 있다. SML#은 SML에서 C와의 한결같은 상호운용성, 레코드 다형성, 랭크1 다형성 등을 확장한 것이다. 도호쿠 대학 전기통신 연구소에서 일본 문부과학성 등의 후원을 받고 있다. [본문으로]
Posted by 세레

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

 

린 소프트웨어 개발을 읽었습니다.[각주:1] 도요타라는 자동차 회사에서 적용하고 있는 작업 방식(혹은 도요타 생산방식이라고 알려진)에 대해서는, 많은 경영서들에서 언급하고 있었고 이런 방식이 소프트웨어 개발에 적용될 수 있다는 점에서 이 책에 관심을 갖게 되었습니다. 책의 부제는 "애자일 실천 도구 22가지"인데, 이 부제대로 책은 각 도구를 기준으로 하여 차분히 설명하고 있습니다.

특히 흥미를 가졌던 주제는
  • 도구 1의 가치를 전달하지 않는 모든 행위를 낭비로 간주했던 점이 신선했던, 낭비 찾아내기
  • 도구 11의 시간 자원의 효율적 사용을 도와주는 대기행렬이론[각주:2]
  • 도구 13의 피상적 접근을 경계하고, 사람에 집중하는 자기 결정권
  • 6장의 통합성
    • 고객과 개발자가 동적으로 의견을 교환하도록 돕는 인식통합성,
    • 신속하고 잦은 소통이 강조되는 개념통합성
입니다. 더불어 책 중간에 예시로 소개되었던 "죽음의 행진"이라는 책에도 호기심이 생겼습니다. 22개의 도구가 여러 장에 걸쳐 소개되고 나서는, 주의사항과 환경별 사용법 등이 소개된 사용설명서와 제품보증서가 나옵니다. 책에 나왔던 여러 지침들을 실행하기 전에 이 부분을 읽어보는 것이 바람직해 보입니다. 아쉬웠던 점은, 사이드바에 제시된 주석의 양이 많고 빈번한 것입니다. 저자의 의도는 본문에 제시된 글에 대해 풍부한 참고자료나, 적절한 출처, 본문에 대한 보강설명 등을 제공하려는 것으로 보입니다. 주석을 꼼꼼하게 챙겨 보는 저같은 경우에는 본문을 읽다가, 사이드바의 주석을 읽고 다시 본문으로 돌아오려면 맥이 끊겨서, 본문에 집중하는데 어려움을 겪었습니다.

그림과 도표로 린 방식의 이해를 돕는 이 책은, 소프트웨어 개발에 관련된 다양한 역할의 분들이 '린'방식의 본질을 알고, 실천하는 데 좋은 길잡이가 될 것으로 보입니다.
린 소프트웨어 개발 상세보기
메리 포펜딕 지음 | 인사이트 펴냄
린(Lean)방식에 의한 소프트웨어 개발 방법론: 조직에 애자일 개발 방법을 적용하라! 이 책은 소프트웨어 개발 분야를 이끌어 가는 사람들을 위한 Thinking Tool에 대해 다룬다. 도요타에서 유래되어 제조뿐만 아니라 유통, 제품 개발까지 혁명적으로 변화시킨 린(Lean) 원칙들을 효과적인 애자일 방법으로 전환하기 위한 도구 모음이다. 린 원칙을 애자일 개발방법에 도입하여 더 좋고, 더 싸고, 더 빠르게 최적화 시키는 방법과

  1. 원서는 "Lean Software Development"입니다. [본문으로]
  2. 제약이론과도 연관이 있는 주제인데, 나중에 "The Goal"과 같은 책을 찾아보고 싶네요. [본문으로]
Posted by 세레

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

 

익스트림 프로그래밍, 애자일 프랙티스에 이어서 (고객 중심의 요구사항 기법) 사용자 스토리를 읽게 되었습니다. 이제 '린 소프트웨어 개발'만 읽는다면, 인사이트에서 나온 애자일 시리즈 도서를 다 읽게 되는군요. 사용자 스토리는 현실을 반영하지 못하는 요구사항 명세에서, 고객과의 지속적인 대화를 강조합니다. 대화로 하여금, 모호한 문장으로 생기는 고객과 개발자 사이의 간극을 좁힐 수 있습니다. 고객으로 하여금 사용자 스토리를 작성하게 함으로써, 개발자와 고객 사이의 공통된 언어를 사용하도록 돕습니다.

고객 또는 대리사용자로부터 수집한 사용자 스토리는 2부의 '추정과 계획'에서 점수를 매깁니다. 이 스토리 점수에 따라서 이터레이션마다 어떤 스토리를 개발할 것인지 계획하고,  각 이터레이션 주기를 모니터링 함으로써 이터레이션 차트를 그리도록 합니다.

3부에서는 스토리로 오해하기 쉬운 것들과, 사용자 스토리를 써야 하는 이유, 그리고 스토리를 사용할 때 주의해야 할 점들을 다룹니다. 또한 Agile 계열의 방법론 중 하나인 Scrum에서 사용자 스토리를 사용하는 예시를 보여줍니다. 4부에서는 항해업에 종사하는 사람들을 위해 온라인 도서 판매 서비스를 제공한다는 예제를 통해, 사용자 스토리를 전체적으로 짚어봅니다. 5부에서는 익스트림 프로그래밍을 접하지 못한 사람들을 위해, 간략한 개요가 들어있고 각 장의 연습문제 해답이 들어 있습니다.

다른 서적에 소개된 요구사항 기법들에 짓눌려 있었다면, 사용자 스토리를 통해 재빠르고 가벼운 기법을 도입한다면 어떨까요?
사용자 스토리 상세보기
마이크 콘 지음 | 인사이트 펴냄
애자일(Agile) 프로그램의 활용법과 사용자가 필요한 소프트웨어 개발에 대한 내용을 담고 있는『사용자 스토리』. 이 책은 사용자 스토리를 수집하는 현실적인 방법과 상황에 따른 대처 방법, 사용자 스토리 수집 후 조직화와 순위를 부여하여 계획하고 테스트 단계에 활용하는 방법에 이르기까지 상세하게 설명하고 있다. 《사용자 스토리》에서는 사용자 스토리가 무엇인지에 대한 개념과 개요, 사용자 스토리 작성과 수집, 테
Posted by 세레

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. daliot
    2009.08.27 20:22
    켄트 벡이 한국에 옵니다. 관심이 있으실 것 같아 링크를 남깁니다.
    http://www.sten.or.kr/bbs/board.php?bo_table=news&wr_id=1807
  2. daliot
    2009.08.30 17:11
    9월 4일 열리는 Kent Beck의 Responsive Design 세미나에 대한 호응이 너무 좋아서 정원이 이미 꽉차고 말았습니다. 9월 2일에도 같은 세미나를 하기 때문에 혹시라도 선착순에 밀리신 분이시라면 한번더 기회가 있다는 것을 알려 드립니다.

    http://sten.or.kr/bbs/board.php?bo_table=news&wr_id=1822
    • 2009.09.07 18:15 신고
      댓글 주소 수정/삭제
      돈도 갈 수 있는 시간도 없네요. 다음에 꼭 기회가 되면 참석하겠습니다. 알려주셔서 감사합니다.

 

(우리가 미처 알지 못한) 소프트웨어 공학의 사실과 오해(원서명: Facts and Allacies of Software Engineering)을 주변에서 추천해 주셔서, 읽게 되었습니다. 소프트웨어 컨플릭트 2.0의 저자이기도 한 로버트 L.글래스가 지은 책입니다. 책은 사실 55가지와 오해 5+5가지를 다루고 있습니다. [각주:1]

제일 감명 깊게 읽은 곳은 오해의 마지막 부분입니다. 교육에 관련된 오해인데요. 저도 처음에 프로그래밍 언어를 배울 때나, 아니면 특정한 프로그래밍 언어를 가르쳐 주는 책을 볼 때면 이런 이런 문법을 설명해 줍니다. 그 다음에 연습문제로 이런 이런 코드를 짜 보라고 하죠. 이렇게 많은 책에서 설명하고 있기 때문에, 그렇게 프로그래밍 언어를 학습하는 일이 당연한 것처럼 느꼈습니다. 우리가 어떤 언어를 학습할 때에 쓰기는 가장 끝 부분에 배웁니다. 읽는 법을 알아야, 쓰고 나서라도 자신이 쓴 문장을 읽는 일이 가능합니다. 그런데 프로그래밍 언어를 가르치는 쪽의 경우에, "코드 읽기"라는 부분에 대해 관심도가 떨어진다는 느낌이 듭니다. "코드 읽기"는 다른 사람이 썼던 코드를 인수받아야 할 경우나, 아니면 자신이 몇 달 전에 작성했던 코드를 분석할 때와 같이 쓸 일이 있음에도 말이죠.

이 책에서는 각각의 사실 또는 오해에 대해 "토의-논쟁-출처-참고문헌"의 구조로 짜임새 있게 이루어져서 자신이 관심있는 사실 또는 오해를 더 탐구할 수 있도록 열어두고 있습니다. 특히 오해 부분에서는 이 오해들을 읽더라도 화를 내지 말 것을 주문하는 문장이 기억에 남았습니다. 소프트웨어 부문의 문제를 지적하고, 설명하며, 문제를 보는 새로운 관점을 건넨다는 점에서 유용한 책이라고 생각합니다.
  1. 10을 굳이 5+5로 풀어 쓴 이유는 Fifty Five, Five + Five 처럼 F의 반복을 통해 저자가 책을 멋지게 보이려고 한 노력입니다. 자세한 내용은 책의 서론을 참고하시기 바랍니다. [본문으로]
Posted by 세레

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2007.10.06 11:51 신고
    안녕하세요? 트랙백 타고 왔습니다~
    저도 말씀하신 교육 부분에서 많은 걸 느꼈습니다. 우리가 언어를 배울 때는 읽기 먼저 배우면서 프로그래밍은 대개 '쓰기'부터 가르치니 참 아이러니하죠.
    잘 읽고 갑니다~ ^^
    • 2007.10.07 01:18 신고
      댓글 주소 수정/삭제
      이런 주제에 대해 그냥 그렇다고 여기고 넘어갈 수도 있는데, 이렇게 질문을 던져 볼 기회를 얻어서, 새로운 시각을 얻어서 좋았어요. 댓글 감사합니다. ^^

 

익스트림 프로그래밍(Extreme Programing Explained 2/E)를 읽었습니다. Extreme Programming, 줄여서 XP는 "애자일 소프트웨어 개발"에서 논의되는 방법론 중의 하나입니다. 한국 eXtreme Programming 사용자 모임도 있고요.
첫 부분에 XP에 대한 설명과 1부 XP 탐험하기에 대해서는 차근차근 XP가 추구하는 가치, XP의 실천방법 등에 대해 나와 있습니다.

제일 관심있게 읽었던 부분은 "제약이론"입니다. 세탁하는 과정을 비유로 들어서 제약 이론을 설명하고 있었는데, 제약 지점을 찾는 것에 대한 이야기를 하고 있었습니다. 제약 이론은 전체적인 처리 역량을 좋게하는데 초점을 두고 있다는 점에서 좋은 방법으로 보입니다. 다만 XP를 적용함으로써 새로운 제약지점 부서는 주목받는 일을 원하지 않기 때문에, XP가 도입되기 여렵다고 하는 점에서 아쉬웠습니다.

도요타 생산 시스템이 언급되는 장도 있었습니다. 이 장에서 언급되었던 Lean Software Development가 2007년 9월 중순에 번역본으로 나왔던 소식을 들었던 터라, 반가웠습니다. 테일러주의가 보편적으로 사회에 자리잡기는 했지만, 특정 분야(이를테면 소프트웨어 개발)에서는 그에 적합한 방법을 사용하는 것이 맞다고 봅니다.

책 끝부분에 많은 참고문헌이 소개되어 있어서,
어떤 주제에 대해 관심이 있다면 찾아서 학습할 수 있도록 돕고 있습니다.

블로그에 읽었던 책을 틈틈이 정리하고는 하는데, 이번주는 정말 책을 열심히 읽었네요.
익스트림 프로그래밍(Extreme Programming) 상세보기
켄트 벡 지음 | 인사이트 펴냄
익스트림 프로그래밍 입문서 개정2판. 이 책은 XP의 소개와 운전하는 법 배우기, 가치와 원칙, 실천 방법, 제약 이론, XP확장, XP의 철학 등의 내용을 담았다. 저자는 이 책에서 소프트웨어를 개발하는 데 필요한 핵심과 실천 방법들을 소개하고, 프로젝트를 어떻게 더 잘 운영할 것인지, 사실에 기반을 둔 계획성들에 관하여 이야기한다. 《익스트림 프로그래밍》에서는 XP를 적용하여 얻게 되는 가치와 조화되는 삶에 관한 실천

Posted by 세레

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

 

애자일 프랙티스를 읽었습니다. Practices of an Agile Developer의 제목 공모 이벤트에 참여만 했을 뿐인데 책을 받게 되어 기쁩니다. 책을 처음 펼치자 마자 맞닥뜨린 인용구가 인상적이었습니다. 책에서는 한 장이 시작할 때마다 그와 관련된 속담, 격언, 인용구 등으로 주제를 도입하고 있습니다. The Pragmatic Programmer(실용주의 프로그래머로 국내에서 번역되었죠.)의 공동저자 중 한 사람인 앤디 헌트와 Agile Developer의 설립자 벤캣 수브라마니암이 쓴 이 책은 말 그대로 적용 가능한 실천 지침들을 제공하고 있습니다.

1장에서는 우선 애자일 소프트웨어 개발에 대한 배경적 지식을 논합니다. 2장부터 8장까지 각 장의 서두에는 어떤 지침들이 나올 예정인지 간략히 소개되어 있습니다. 각 지침의 첫 부분에는 악마가 사람들이 피해야 할 나쁜 습관을 일러줍니다. 지침에 관련된 에피소드나 실례를 제시하여 이 지침이 왜 유용한지 거부감없이 느낄 수 있게 하며, 천사가 사람들이 가져야 할 좋은 습관을 일러 줍니다. 책 표지에 악마와 천사가 등장하는 것은, 독특한 캐릭터들이 지침의 설명 부분에 등장하기 때문으로 생각합니다. 그 후에는 "어떻게 느껴야 하는가?"라는 부분이 있습니다. 말 그대로 이런 느낌을 갖고 있다면, 바르게 가고 있다는 안내를 해 주기 위해 도입된 것으로 보입니다.

하지만 어떤 지침이든 지나치게 적용하거나, 느슨하게 적용하면 그 효과를 제대로 발휘하지 못할 수 있습니다. 이런 부분을 바로잡기 위해 "균형 유지하기"에서는 어떤 부분에 중점을 두어야 하고, 어느 정도가 적당한지 지적합니다.

에필로그를 읽다보니 전에 보았던 Ship It!을 개발 기반의 마련을 위한 Starter Kit으로 추천하더군요. 뒤에는 여러 참조 링크와 관련 문헌들이 소개되어 있고, 실용주의 프로그래머처럼 가이드라인 요약본이 뒷표지 앞에 붙어 있습니다.

최근에 IT 회사에 다니시는 분에게 이야기를 들을 기회가 있었습니다. 그 분이 의아해하셨던 것은, "왜 대학에서는 테스트를 가르치는 과목이 없느냐?"였습니다. 애자일의 인프라스트럭처에는 "유닛테스트"가 중요한 위치를 차지하고 있습니다. "테스트 주도 개발"이라는 움직임이 보이고, 국제 테스팅 컨퍼런스(2007년 10월 초에 서울 코엑스에서 열린다고 합니다.) 도 열리고 있으며, 수습 불가능한 스파게티 코드가 되는 일을 피하고 유지보수를 쉽게 하기 위해서라도 테스트의 중요성은 날로 커지고 있습니다. 그래서, 테스트에 대한 과목도 교과과정에 들어있으면 하는 바람이 생겼습니다.

애자일이라는 걸 머리로는 알고 있지만, 어떻게 실천해야 하는가에 대해 막막함을 느낀 분들도 있을거라 생각합니다. 이 책에서 시도하기 쉬운 지침을 선택하여 점진적으로 적용한다면, 개인과 팀에 긍정적인 변화가 생기지 않을까 생각해 봅니다.
애자일 프랙티스 상세보기
벤캣 수브라마니암 지음 | 인사이트 펴냄
애자일 소프트웨어 개발 전문서. 이 책은 45개의 애자일 프랙티스 사례를 통해 어떤 문제에프랙티스를 적용하고 맞추는 방법을 통해 애자일 소프트웨어를 익힐 수 있도록 구성했다. 프랙티스를 올바르게 적용했을 때 어떻게 느껴지는지, 과하게 적용하는 것과 성기게 적용하는 것 사이에서 균형을 맞추는 방법을 설명하고 코딩과 디버깅에 관한 내용도 함께 설명한다. 책 뒤편에는 애자일 프랙티스 자료에 관한 내용도 포함했다.
Posted by 세레

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

 

노란 표지에 큼지막한 글씨의 "Are your lights on?"의 번역서가 2006년에 나왔더군요. 번역서 제목은 "대체 뭐가 문제야?"입니다. 이 책의 저자는 컨설팅의 비밀를 쓰신 제랄드 와인버그 씨가 공동 저자로 참여한 책인데요. 간단히 말하면 "문제"에 대한 책입니다. 책은 가벼워서, 들고 다니며 읽기에 좋습니다.

우리는 일상에서 늘 문제와 접하고 있습니다. 그러나 우리가 문제 자체에 대해 깊게 생각하는 일은 쉽지 않습니다. 왜냐하면 우리는 문제를 풀기에도 바쁘기(또는 바쁜 것처럼) 느껴지기 때문입니다. 이 책은 우리에게 "무엇이 문제인가?"라는 질문을 던짐으로써, "문제"에 대해 넓은 시각을 획득하게 합니다.

책의 각 장이 모두 주옥같은 교훈을 담고 있지만, 가장 마음에 들었던 장은 폴란드에 있는 할머니를 만나려 하는 여자 분의 이야기가 담긴 장이었습니다. (몇 장인지는 정확히 기억이 나지 않네요.) 제일 감동적이었고, 도움이 많이 되는 장이었죠.

이 책 또한 컨설팅의 비밀처럼, 이야기를 통해 글의 전개를 풀어 나가는 방식을 취하고 있습니다. 그래서 책 내부에는 이야기와 관련된 익살스런 삽화들이 수록되어 있죠. 그래서 책을 읽는 내내 즐거운 이야기를 듣는다는 마음으로 읽을 수 있었죠. 문제와 마주치는 사람 누구든 한 번 읽어 보실 것을 권하고 싶은 책입니다.
대체 뭐가 문제야 상세보기
도널드 고즈 , 제랄드 와인버그 지음 | 인사이트 펴냄
문제 해결에 관한 창의적 사고를 길러주는 6가지 질문. 이 책은 복잡한 문제 해결과정일수록 해결보다 문제 정의가 중요함을 일깨워준다. 저자는무엇이 문제인지를 먼저 인식하고 그것을 분명하게 정의하는 것이 진정한 문제 해결능력이며 창의적 문제 해결의 기본임을 설명한다. 그리고 주인공들의 일화를 통해 이 책이 제시하는 6가지 질문에서 해결해야 할 문제가 무엇인지 알려주고, 문제해결 상황에서 맞닥뜨리는 수많은 난관

Posted by 세레

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

컨설팅의 비밀

2007.08.07 10:47

 

컨설팅의 비밀이란 책을 읽었습니다. 제랄드 와인버그 씨가 쓰신 책이에요. The Psycology of Computer Programming이라는 책을 쓰기도 하신 분이죠(아직 번역되고 있다고 하네요, 제목은 아마 프로그래밍 심리학일 듯).

예전에는 도서관에서 빌릴 책 고르는 데 시간이 오래 걸렸는데, 요즘은 출판사를 보고 고르고 있어요. 출판사마다 각자의 전문 분야가 있고, 과거에 나왔던 책의 질을 보면 나중에 나왔던 책도 좋을 거라는 기대를 갖게 하거든요. 인사이트도 좋아하는 출판사에요. :)

지하철에서 틈틈이 읽기 좋은 크기라서 읽었는데, 글을 잘 쓰시는 분들은 자신이 전달하고자 하는 뜻이 있을 때 그 주제를 이야기와 섞어 표현하는 일에 능숙하세요. "조엘 온 소프트웨어"에도 비슷한 이야기가 있었지만요. 그런 책은 지루하지 않고, 책이 전달하고자 하는 바를 생각하는 여유를 독자에게 준다고 생각해요. 이 책도 여러 이야기들이 제랄드 와인버그씨가 제안하는 규칙들과 섞여 소개되고 있습니다. 루디의 루타베이거 원리, 오렌지 주스 법칙 등 흥미로운 이야기가 많았어요.

이제는 "Are Your Lights On?"의 번역서인 "대체 뭐가 문제야?"를 읽고 있습니다. 이 책도 제랄드 씨가 공동 저자로 참여했는데 삽화가 곁들여져 있어 흥미롭게 읽고 있어요.
컨설팅의 비밀 상세보기
제랄드 M. 와인버그 지음 | 인사이트 펴냄
컨설팅의 원리, 법칙, 원칙을 담은 컨설팅전문서적. 전문적인 컨설턴트부터 현대 사회를 살아가는 기업인, 직장인, 학생, 일반인에 이르기까지 모두 이용할 수 있게 래즈베리 잼 법칙, 와인버그의 쌍둥이 법칙, Why 저주 등 컨설팅의 핵심과 기본적인 원칙을 재치있는 언어로 풀어냈다.
Posted by 세레

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


카테고리

분류 전체보기 (447)
Science (283)
ars boni et aequi (55)
Routine (83)
Language (23)
Q&A (1)
me2day (1)

달력

«   2019/11   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30