'IT서적서평'에 해당되는 글 41건

  1. 2007.12.01 구체적인 행동강력이 담겨있는 빨간책!! [XP도입을 위한 실전 입문]
  2. 2007.11.30 포토샵! 전문가 까진 아니더라도 조금 알고싶은데 [포토샵 CS]
  3. 2007.11.28 ERP 매직카펫을 나르게하려면 메뉴얼봐야죠 [ERP 프로젝트]
  4. 2007.11.27 클래스 구조를알면 openSouce도 잘 보입니다. [클래스 구조의 이해와 설계]
  5. 2007.11.25 '프로젝트 자동화'에는 ant와 log4j는 얼마 안들어 있다. [ANT Log4J]
  6. 2007.11.24 중급 개발자가 고급 개발자로 가기 위한 서적!! [refactoring java] 2
  7. 2007.11.22 프로젝트 과정/결과는 유토피아를 향한다!! [소프트웨어 생존전략]
  8. 2007.11.21 리스크는 이익이 되어 돌아옵니다. [리스크 관리] 1
  9. 2007.11.20 professional소프트웨어개발 [소프트웨어 개발]
  10. 2007.11.16 'Pragmatic' 를 위한 실행방법 [Junit]


Extreme Programming Installed XP도입을 위한 실전 입문
빨간책!
불온(火溫^^ [열정적])서적이면서 선동을 유도하며 구체적인 행동강력이 담겨있는 빨간책!!
Extreme Programming Installed (XPI) 는 구체적인 실행을 위한 가이드 라인이라 볼 수 있는
빨간책으로 처음 나에게 다가왔다.
 
세상에는 XP라는 이니셜을 달고있는 많은 이론들이 있지만 그중에 XPI는 XP의 무엇을 위해
태어나게 되었고 누구를 위해 이야기 하고 있으며 최종 종착지는 어디일까?
 
론 제프리즈는 XPI의 탄생을 떠벌이 기획자혹은 엔지니어들로 인해  왜곡된 XP를 바로 펴려고
자신이 경험한 프로젝트를 중심으로 본 서적의 이야기를 풀어나가고 있다.
XP는 보다 지능화되고 향상된 프로젝트를 만들어내고 개발자에게는 "배웠구나! 얻었구나!" 하는 보람을 주려고 탄생되었다고 생각한다.

하지만 몇몇 떠벌이들이 XP의 취지를 무시한체 XP를종이 몇장에 서술해 가며 되려 고객과 관리자, 개발자들을 고생시키고 있다.
바로 이 책은 C3 (크라이슬러 급여관리) Project를 배경으로 XP가 어떻게 전계되었는지를 이야기한다.
책에 등장하는 3명의 인물은 개발을 경험한 컨설턴트이다.
그들은 고객이 일의 진행사항을 보고 싶어하고 이런 저런 기능들이 추가되길 바라지만
돈주도 말못하는 애로사항을 이해 해주었고,  관리자가 관리는 하지만 별 성과없이 스트레스만 받는말못할 사정도 풀어주려고 하였고 , 개발자의 피패함을 방지하고 보람찬 일상이 되도록 배려해주고 있다.

이말을 다시 풀이하자면!!
진정 XP는 개발자에 국한된것도 아니고 관리자, 고객에게 국한되지 않는 IT전반에 걸쳐
Project라는 미명아래 움직이는 모든 사람을 위한 방법론 인것이다.
 
● 구독방법
본 서적은 다음과 같은 구독방법을 권고한다.
만일 이와같은 방법으로 구독한다면 당신의 회사는 변화하게 될것이다.
 
1. 최초 개발자가 먼저 읽는다.
   - 개발자가 먼저 읽고 각각의 중요한 부분에 연필로 믿줄을 긋고 자신의 의견을 달아놓는다.
   - 개발자는 이때 적당한 tool이 뭐가 있는지 함께 기술하는게 좋을것 같다.
 
2. 두번째로 관리자가 읽는다.
   - 개발자가 다 읽은 책을 관리자가 받아 개발자의 사상을 이해하며 자신이 보기에 중요한 부분을 믿줄 긋는다.
   - 관리자는 개발자의 생각을 읽으려고 노력을 한다면 이보다 더 좋은 효과는 없을것 같다.
 
3. 세번째로 고객(갑)이 읽는다.
   - 개발자와 관리자가 다본 책을 봄으로써 고객은 권한과 권리의 범위를 정확하게 이해한다.
   - 책임의 입장으로써 고객의 투정 한마디가 생각보다 얼마나 크게 작용하는지를 간접적으로 보게 되는것이고 이러함으로써 정말 프로젝트를 바라보는 시선을 갖춘다.

훌륭한 프로젝트는 개발자 한사람으로 만들어 지지 않는다.
고객, 관리, 개발자 모두 훌륭해 져아한다.

하지만 이런 방법론을 함께 공유하기란 쉽지 만은 않다.
그러기에 지각있는 분이 읽어 본 책이 무술교본에 나와있는 행동하나 하나임을 알고 따라하길 바랬
으면 좋겠다.
 
 
"XP실천사항들을 그 쓰인데로 완전히 마스터 했을때에 단순한 법칙을 넘어서 형을 깨트리고 자신만의 형을 창조하시게 될겁니다."
(책속에서...)


디/자/인/??
요즘 디자인 작업을 간간히 할일이 생겨 포토샵 CS를 보게 된다.
포토샵을 아주 모르는바는 아니다. 조금 안다. 그래서 책을 골라도 초급용 고르기에는 너무 아깝고
중급용 고르기에는 이럴 필요까지는 없는데 하는 망설임이 느껴지는게 사실이다.
그러던중 "포토샵 CS - 모든걸알켜주마!"을 보게 되었다.
 
책은 저자와 독자가 이루어가는 강의와 같다.
강의는 일방적이지 않고 독자의 성향에 따라 천천히 이뤄질 수 있고 하루밤 사이에 모든 강의가 끝날 수 도있다.
이런 강의의 결과는 독자를 저자와 동일레벨 혹은 비슷한 레벨까지 끌어올릴 수 있다는 장점을 가지고 있다.
"포토샵 CS - 모든걸알켜주마!" 는 이런 부분에 있어
초급이지만 아주 초급이 아닌 사용자들을 다양한 팁! 의 세계로 인도하고 있다고 볼 수 있다.
 
책은 포토샵이 주로 사용되는 사용처에 맞게 몇가지를 이야기 한다.
그 몇몇가지는 web디자인용, 디지탈카메라 편집용, 이모티콘및 아이콘 제작용 이다.
포토샵이 많은 분야에 활용되기에 서평자 같이 초보이면서 스스로 초보아닌척 하는 사람에게는 이런
다방면에 포토샵 활용방법이나 팁들이 중요할 수 도 있다. (즉! 본책은 전문가분들이 보시기에는 아닙니다.^^)

사용처 1 : web디자인용
 > web디자인용으로 이뤄진 부분중 좀 부실한 책의 경우 아이콘 만들기만 언급하는데
      본 책은 아이콘 만들기 (이모티콘)과 홈페이지 전체 구성에 대한 접근 방법을 같이 이야기 하고 있다.
     사실 홈페이지에서 아이콘하나 못만들 사람 없겠지만 구성을 잡는것은 정말 어려운 일이다.    
     책 저자는 이런 구성의 문제를 자신이 개발한 사이트를 이용한 web구성을 보여주고 있다.    
     (배경화면 만들기도 참 깜찍하게 소개시켜 놓았음)

사용처 2 : 디지탈 카메라 편집용
 > 서평자가 가장 필요로 했던부분이다.
     내가 찍은 2%로 부족한 사진의 맹점을 충분히 극복시키게 해주고 있다.
    사진이 번졌을때,  사진을 우아하게 만들때, 사진을 적당히 오려붙이고 편집할 때..  
    전문 디지탈 카메라 사진 편집이 아니고 일반적이지만 좋은 결과를 보고 싶다면 권장한다.
      (책은 디지탈카메라 아름답게 찍는 방법도 "책속에 책" 이라고 편집시켜 놓고 있다)

사용처 3 : 이모티콘 및 아이콘 제작용
 > web사용자를 위한 이모티콘 및 아이콘 제작인데 가만히 보고 있노라면 노력의 흔적들이 보인다.
    디자인에 중초보 ^^ 인 서평자가 조금 그 퀄리티가 높아졌다고 본다면 디자인 이제 하시는분들에게는
    많은 도움이 될꺼라 생각한다.


서평자는 엉뚱한 디자인 주문에 포토샵 다루는 일이 본 책을 통해 조금 늘었났다. ^^
패턴을 뜰 수 도 있게 되었고, 조금 나아진 배경화면을 만들어 낼 수 있게 되었다.
그냥 지금 약간 다룰줄 아는 포토샵을 조금더 잘 다루고 싶었다는 생각에 사본 책인터라 가격대비 만족이였다.
책은 여느 포토샵 책과 다를바  없다.
하지만 포토샵을 이용할 수 있는 분야를 보고 싶다면 그리고 그 분야에 어떻게 이용되는지 약간의 중, 고급 팁을 보고 싶다면
본 책을 추천한다.


1999년에 들어 많은 재조업들이 IT시장의 활성화에 힘입어 ERP를 도입하게 된다.
그당시 기업환경은 단위항목에 전산화가 적용되이있는터라 진정한 통합을 위한 과정을 비롯
부서간 상호관계의 필요성이 대두된것이다.
이때즈음 ERP는 "매직카펫"과 같아서 ERP로 올라타기만 하면 어디든 자유로이 갈 수 있을것만 같았다.
 
2005년 그로부터 벌써 6년여가 흘렀다.
ERP초창기에 도입한 부서들은 정착화가 되어있지만 중반에서 말부에 ERP를 도입한 기업들은 많은 문제를 겪게 된다.
자사가 도입한 EPR는 "매직카펫"이 아니라 나르지 않는 엉성한 양탄자에 불과하다는 사실을 알게된다.
"ERP 제품은 경쟁사와 동일한데 카펫이 나르지 않는다니..."
"무엇이 문제인가? 무엇이 문제였을까?"
 
아마 이런이슈가 너무 많이 부각되어 이런책의 탄생이 필요하게 되었을지 모른다.
 
책은 ERP도입, 적용, 활용 등에 있어 각 부서마다의 역할과 CIO와 CEO 등과 같이
경영조직에 적극적인 대응을 요구하고 있다.
각부서는 통합을 위한 도메인 설정과 정확한 자기업무 진단의 과정을 거쳐야 한다.
하지만 이 과정에서 업무진단의 미숙과 Process로 뽑아낼 구분에 대한 모호성때문에 ERP도입이 어려워지게 된것이다.
이는 ERP실패의 원인이 되는것이다.
책은 실패 point를 짚어내고  성공적인 ERP로 가기위한 helper역할을 해주고있다.
하지만 안타깝게도 책의 저자가 일본인이라는 사실을 알아 두었으면 한다. (기업조직이 일본임)
(아무래도 기업의 특성이 일본이기에 우리나라같이 일본+미국의 혼용 기업구조에서는 무비판 도입 보다는 필~! 을 느껴야 할것입니다.)
 
책은 크게 2부분으로 나누고 있다.
ERP성공을 위한 필수조건 / ERP성공을 위한 부서마다 해야할일 (구매, 생산, 판매, 인사, 회개, 업무, 기술 ..)
 
제 1부
1부는 ERP 전반에 걸친 성공의 조건들과 공식에 대해 이야기 한다.
- 빅뱅도입과 점진적 도입
 전사적으로 한꺼번에 고생해서 빠르게 도입해서 비용감소를 최소화 시키는것을 "빅뱅도입"이라고 한다.
 하지만 "점진적도입"을 하게 되었을 경우 기존의 시스템과 병행운영을 통한 비용발생도 역시 위험이라고 말하고 있다.
 물론 경영조직의 선택이지만 이리가든 저리가든 수고는 반드시 따라야 한다는 점이다.
- ERP는 CEO, CIO가 직접 챙겨야 한다. (130p의 ERP 성공기업의 특징)
 CEO가 직접챙겼을때와 그렇지 않았을때의 차이가 너무 확연하게 나타난다.

제 2부
에 대항하는 부분은 부서마다 할일을 이야기 한다.
정말 지극히 업무적인 부분이기 때문에 업무에 대한 도메인 이해없는 서평자의 경우 몇번이고 되돌아 봤던것 같다.
 
책은 길을 보여주지는 못한다 하지만 길을 느끼게 해주고 내 가는 길이 맞는지 틀린지 판단하게 해준다.
이미 ERP를 활용하고 있는 기업이든 부서든 본 책을 통해서 자사의 ERP도입에 자사평가를 해보는것도 좋을것 같다.
개념으로만 존재하는 ERP를 의지만으로 도입해 어려움을 겪고 있다면
나르지 못하는 ERP 매직카펫을 수선해서 많은 기업들이 가고싶은 그곳을 향해 잘 날라다녔으면 좋겠다.


다시 기술서적으로 눈을 돌려본다.
이미 충분히 알고 있다고 생각하는 부분부터 다시 짚어보는 의미에서 찬찬히 서적을 고르던중
"클래스 구조의 이해와 설계"에 손을 데게 된다.
 
책 겉표지를 찬찬히 살펴보니 책이 나에게 물어본다.
"프로그래머가 가장 많이 만지작거리는 클레스 제대로 만들고 있습니까?"
"음.. 글쎄 ^^"
 
개인적으로 개발에 임하였을때
얼마나 많은 소스코드를 만들어 내며 얼마나 많은 소스코드를 지워댔는지..
또 얼마나 많은 중복된 역할을 하는 클래스들을 아무런 꺼리낌 없이 만들었던지..
프로젝트가 늘어날때마다,  개발의 경험이 늘어날때마다 기교와 효과는 조금씩 자라지만
결코 완벽한 프로그램개발을 했다고는 말 할 수는 없다.
 
그래서 서평자는 가끔 선진 구조기법들을 보려고 openSource코드의 package의 구조를 tray 해본다.
그때마다 느끼는 좌절감은 상속의 관계와 오버로딩이나 오버라이딩, super, this 같이 충분히
고민하고 만들어낸 부분에서 쉽사리 끈을 잃어버리기 때문이다.
물론 하는 역할이나 구조를 모르는 건 아니지만 전체 프로그램에서 이런것들을 맞딱드리면
주춤해지는건 사실이다.
 
2%.. 뭔가 2%로 부족함이 느껴진다... (결코 여러분도 예외가 아닐꺼라 생각합니다.^^)
 
책은 클래스의 구조를 차근차근 설명해 주고 있다.
처음에는 명사분석법을 통한 객체 정의 지만 나중에 가면 그 객체들간에 연관관계와 포함관계를
이야기해 주고있다.
이야기 흐름에 이용되는 주된 도구는 UML이고 필자는 UML을 단순 표기법! 으로 간주하며
초급 개발자들에게도 쉬운 UML로 접근하는 배려도 잊지 않았다.
하지만 페이지 한장 한장 뒤로 넘길때마다 깊이가 깊어져가기에 UML을 잘 아는 분이 보더라도 좋을것 같다.
 
책은 클래스 구조뿐만 아니라 추가적인 정보들을 제공해 주고 있다.
1. class Diagram을 생성하는 방법
2. class Diagram에 엮여 있는 각종 화살표(?)들의 특징과 사용관계 (집합관계, 포함관계, 연관관계 , 의존관계 ..)
3. Sequence Diagram을 생성하는 방법
4. 하나의 UML을 가지고 java와 C++간의 표현방법
5. java와 C++ 에서 발생하는 언어적 차이도 발견하게 해준다.
 
책의 내용은 모두 열거할 수는 없지만 정말 개발자에게는 계륵조차 없는 통통하게 살오른 치킨이 아닐 수 없다.
java개발자라면 C++개발자라면 한번즘 봤으면 하는 권장한다.
 
서평의 끝에 왔다.
본 책에서 내가 갈등했었던것을 시원스래 정의한것이 있어 한구절 이야기 한다.
 
-- 유/도/속/성/ --
>> 책 98p : 유도속성은 값이 항상 다른 속성으로 부터 계산은 될 수 있지만 매번 유도속성의 값을 필요할때마다 계삭하는것은 비 효율적일 수 있다.
>> 유도속성을 정의하고 안하고는 개발자 몫이다.  이것을 한다고 서비스에 크게 티나지 않을 수 도 있다.
     하지만 개발이 가져다주는 갈등이기에 책을 느끼는 한 구절로 삼아본다.


정말 오래간만에 서평을 쓰게 된다.
한동안 개발에만 열을 올렸더니 책을 볼 기회조차 허락되지 않았다.
지난 실용주의 서적에 대한 Junit에 관한 서평을 쓴 이후로 '실용주의'에 관한 관심이 쏠려
3번째 서적인  "프로젝트 자동화"에 대하여 이야기를 해보려고 한다.
제1편 CVS와 제2편 junit까지 정말 구독자의 기분은 상쾌하게 만들어줬던 실용주의 마지막 3번째는
과연 얼마나 기분좋게 할것인가 기대하는 맘으로 읽기 시작 했다.
결과부터 이야기 하자면 서평자는 주소를 잘못 잡고 있었다.
 
'프로젝트 자동화'가 말하는 것은 표지에 디자인 'ANT&log4j'에 대해서 크게 말하고 있지 않다.
만일 'ANT&log4j' 를 위해서 본 책을 기대에 부풀어 사보게 된다면 약간의 실망을 감내 해야 할 것 이다.
ANT는 깊이가 있어질려다 말았고 log4j는 후반부에 5페이지 정도 분량으로 밖에 소개되고 있지 않다.
정말 'ANT&log4j'에 관해서 알고 싶다면 본 책의 역자가 추천하는 서적
'Java Development With Ant (자바의 또 다른 멋진 도구 Ant 앤트 )'를 보았으면 한다.
 
서평자는 헛된 기대에 책을 보고 예상했던 내용이 크게 부각되지 않아 조금 당황스러 웠다.
이유는 책을 모두 다 보고 책 표지를 다시 보니 불연듯 책 타이틀을 보니 책은 정말 제목데로 만들어 졌다.
'프/로젝/트/자/동/화'
그렇다. '프로젝트 자동화'가 추구하는것은 프로젝트를 자동화하하기 위하여 필요한 ANT, CVS, log4j, ... 등등과 같은
프로젝트 자동화를 위해 사용될 수 있는 도구들을 적절하게 활용된 사례를 기술해 놓았다.
 
실질적인 프로젝트(DocumentManagement System)를 바탕으로 ANT와 CVS, 그리고 5페이지로 언급된
log4j를 사용하고 있는것이다.
 
책 제목은 책 내용을 완벽하게 커버하고 있다.
서평자처럼 "디자인된 표지에 속아 ant는 이정도 깊이인가? log4j는 겨우 5페이지라니.. " 하는 실망감을
가지지 않았으면 좋겠다.
 
자 이제 책 내용을 살펴보도록 한다.
 
● 빌드 (Build) & 릴리즈
책은 미국문화에 이해가 가장 쉽도록 ant를  설명하고 있다. '크루즈컨트롤러' 가 그 예인데 크루즈컨트롤어의 의미는
책 85p에 언급되어있지만 우리나라 문화라면... 아마 리니지 AutoMouse가 아닐까 하는 생각도 해본다. ^^
여하튼 ant의 주된 역할은 프로젝트 진행에 있어 그 어떤 작업환경에서든 동일한 결과를 도출해 낼 수 있도록 하는
"빌드(Build)"에 관점이 기울어져 있는것있다.
 
책이 DMS 기반으로 있기 때문에 ANT의 깊고도 복잡 다단한 부분까지는 접근하지 않고 있다.
아마 불필요하기 때문일것 같고 정말 실전에서 쓸수 있는 것만 '프로젝트 자동화'에 다룬것 이라고 볼 수 있다.
 
 
● 디플로이
디플로이 부분은 여태 내가 디플로이하는 방법보다 보다 효과적이고 강력한 디플로이 방법을 이야기 하고 있다.
단순 ANT로 소스코드를 운영에 반영하고 시스템을 한번 내렸다 올리는 손이 많이 가는 (하지만 내가 지금 그렇게 하고 있는..)
방법보다 더 아름다운 디플로이 방법을 이야기 하고 있다.
 
● 모니터링
서평자는 WEB개발자이기 떄문에 모니터링은 콘솔상에서 쌓여가는 로그파일을 보는게 모니터링 기법이라 생각했다.
하지만 '프로젝트 자동화'에서 말하는 모니터링은 이보다 보다 시각적이고 보다 직관적이다.
여기에 log4j는 모니터링의 한 부분으로써 소개가 되어지고 있다. (그러니 5페이지 될 수 밖에...)
 
 
ant나 log4j는 '프로젝트 자동화'의 한 부분이다.
오히려 본 책은 실용주의 서적 제1편이 말한 CVS의 재 언급이 "오호 이렇게 연결이 될 수 있겠구나" 하는 발상을 가져다 준다.
 
표지만 보고 헛된 기대는 하지 말자!
ANT와 log4j는 함량 미달이다. 하지만 '프로젝트 자동화'는 정말 프로젝트에서 필요한것만 담았다.
ant도 log4j도 cvs가 프로젝트에 어떻게 적용되고 어떻게 사용되는지  다양한 기법들을 담았기에
학문으로써가 아니라 /사/용/할/목/적/으/로  본 책을 접한다면
실용주의의 결정판! 그 '프로젝트 자동화' 가 실망스러움이 아닌 다양한 아이디어를 줄 것이다.
 
서평이 끝났다.
서평자가 보기에 이책이 프로젝트에 필요한 이유는 아래인것 같다..
 
----------------------------------------------------------------------------------------
코드가 길면 길수록 코드를 제대로된 상태로 유지하기 위하여 계속되는 통합의 작업이 더 절실하게 필요하다.
              '프로젝트 자동화 98p'
----------------------------------------------------------------------------------------


중급 개발자가 고급 개발자로 가기 위한 서적!!
 
refactoring java는 프로그램을 짜는 방법이 들어가 있다.
메소드를 선언하는 방법 sub메소드를 만들어 내는 방법, 그리고 그 sub메소드를 호출하고 관리하는 방법..
너무나 고맙게도 고급개발자 (마틴파울러)는 본 서적을 통해 고급! 바로 그들만의 리그에
중급 개발자들을 참여시키고자하는 다분한 의도를 가지고 있다.
 
refactoring java는 이미 많은 서평자들이 엇갈린 의견을 내 놓은것처럼
"해도 그만 안해도 그만" 에서 부터 "꼭 해야하는것!" 하는 다양한 의견을 나타내고 있다.
그도그럴것이 잘 구동되는 소스코드는 건드리지 않는다! 라는 전재 하에서 본 서적은 이야기를 시작 하고 있다.
 
그럼? 잘 구동되는 소스코드를 뭐할려고 건드리는가?
이문제에 답은 refactoring은 누구를 위한 것인가? 라는 질문이 더 잘 어울린다.
refactoring 은 관리자도 스폰서도 위한 작업이 아니다.
refactoring 은 순수 프로그래머들을 위한 작업이다.
 
프로그래머들은 많은 위험에 노출되어있다.
납기일 준수나,  촉박한 일정에 떨어지는 폭탄과도 같은 요구사항들 그리고 가장 기본으로 요구되는 안정된 운영!!
많은 사람들은 프로그래머를 마치 고장난 자판기마냥 동전 몇개만 넣으면 어러가지 음료수를
한꺼번에 쏟아내는줄만 아는데 안타깝게도 프로그래머들은 자판기가 아니라 사람이다.
 
자.. 훌륭한 사람이기에 쏟아질것 같은 요구사항에 미리 미리 대응해 보자.
잘 구동되는 소스코드도 정리해보도록 하고 확장에 용이하도록 분석과 분해를 해봤으면 좋겠다.
납기일이나 촉박한 일정이 다가올것을 염두하고 선수학습하는 맘으로 구조를 짜 맞춰 보자!!
바로 이런 일들을 진행할때 곁에두고 싶은 참고서가 있다면 서평자는 refactoring java를 추천하는 바 이다.
 
● 구독방법
1. 서문과 도입의 글을 필독한다!
    > 모든 refactoring 의 사상이 담겨져 있다.
    > refactoring을 운운하시는 분들은 모두 서문과 도입을 인용 하는것이니 개발자는 꼭! 봤으면 한다.
2. 첫장 부터 타이핑 해가며 한장 한장 따라 시도해본다.
3. 아주간혹 이해가 안간다 하더라도 그냥 .. 그냥 물흐르듯 보자.
 
자세는 키보드옆에 활짝 펴 두고 글도 보면서 차근차근 본다.
 > 정말 이때는 바둑의 기보를 보는 자세가 요구된다. 내가 앞에서 뭐 했는가를 잊어먹으면 곤란해진다.
 
● 책은 이것보다 훨씬 많은것을 동기유발 시킨다.
refactoring java는 UML기반으로 설명을 하고 있다.
서평자 역시 refactoring java를 보고 자주 등장하는 classDiagram 이나 화살표들이 너무 궁금해 RUP책을 보게 되었다.
궁금증이 해결된것은 아니지만 하나의 학습은 다른 학습을 유도하는 시너지 효과를 발휘하고 있다.
 
refactoring java는 코드네이밍 규칙을 이야기 하고 있다.
프로그램 만드는데 작명과 워드랩을 하는 수준은 깔끔과 명확성을 가지고 있다.
refactoring이 전부 내것이 되지 못하더라도 깔끔한 소스코드를 만드는 보너스 팩은 받아누릴 수 있을것이다.
 

사실 서평자는 2003년도 같은 회사 직원 한사람이 이 책을 틈나는 데로 탐독하는것을 봤다.
당시 그는 중급개발자였지만 지금은 고급개발자가 되어있고 지금도 멋진 개발자로써 훌륭히 자기일을 하고 있다.
초입에 들어설때도 그는 면티에 훌렁한 반바지를 입고 빡빡머리에 자유분방함을 가졌지만 소스코드는 그런 외모와는 상관없는
향기를 담고 있었고 알수없는 고수(?)의 흔적들을 볼 수 있었다.
그당시 그가 이 책을 그토록 보고 또보고 하는 이유를 몰랐다.
하지만 그 결과는 나타나고 있고 그 향기는 시간이 지남에 따라 더욱 진하게 퍼지고 있다.
꼭! 본 서적이 원인이였다고 볼 수는 없지만 그래도 그런 그의 향기가 가장 배어나오는게 본 서적이라 위의 예를 들어본다.


서평자는 전에 스티브맥코넬리의 서적을 모두 탐독코자 하였다.
이번에 평하고자 하는 서적은 "소프트웨어 생존전략!"
이름도 그럴듯한 Servival Guide 책이다.
 
2005년3월10일에 구입해서 보기 시작해서 오늘까지 봤으니 거의 2주정도 시간이 걸렸다.
소설책류의 2시간에 비하면 어마어마한 시간이 들어갔다.
서평자는 스티브맥코넬리의 깊은 사상을 이해하려하였고 그가 생존전략! 이라는 거창한 이름을
붇인 까닭을 알고 싶었다.
결과를 미리 말하자면 진정 맥코넬리는 프로젝트의 모든 구성원들이 만족하고 행복해하는
유토피아를 본 서적에서 기술해 놓았다.
 
- 스폰서에게는 프로그램이 완성되어져가는 과정을 보면서 자신의 의견을 적용 될 수 있도록 하였고
- 관리자에게는 잘짜여진 틀 안에서 스폰서와 개발자들사이의 훌륭한 PM 이 되도록 하였고
- 개발자에게는 프로젝트 완료후 기술의 스킬UP과 회사에 강한 소속감을 가질 수 있도록 하였다.
 
정말 놀라운 서적이 아닐 수 없다.
스티브맥코넬리는 3인칭 전지적 관찰자 시점에서 프로젝트에 관여된 3계층(스폰서, 관리자, 개발자) 모두 만족시켜주는 가이드를 제시한것이다.
 
하지만 본 서적이 그토록 유명하게된 까닭은 단지 3계층을 커버하는 수준이였다면 그만큼 유명해지지는 않았을 것이다.
서평자가 보기에 SPSG에 투입되고 연관되어있는 방법론과 서적은 실로 방대하다.

스폰서 / 관리자
 > ROI (투자수익률)
 > 피플웨어 (톰디마르고,  티모시 리스터)             
 > 리스크관리 (톰디마르고,  티모시 리스터)
 > Professional 소프트웨어개발 (스티브맥코넬리)

 
개발자
 > Extreme Programming Installed  (론 재프리즈)
 > Junit (데이브 토머스)
 > TDD (캔트백)
 > RUP (개발방법론: 로즈)

기타 등등..
이런류의 서적들을 모두 총 종합시킨 전과목 참고서 수준이다.
한장 한장 넘기면서 "이 주제는 어디서 본것 같은데..." 하는 느낌과 냄새(?)가 난다는 것이다.
피플웨어나 마일스톤의 경우는 (피플웨어,리스크관리)책 냄새가 나고
스모크테스트나 일별 test계획을 세워서 프로토타이핑을 만들어내는것은 (XPI, TDD, JUNIT..)책 냄새가 난다.
 
만일 위에 언급한 사항들을 모두 보신 분들 이라면 썩 이 책이 신선하게 다가오지는 않을것이다.
하지만 구술도 꽤어야 보배라고 모든 단위 항목 학문을 하나로 꾀어내는 능력은 정말 탁월하다고 칭찬할만 하다.
 
스티브 맥코넬리는 프로젝트 진행단계 단계마다 가장 적당한 방법론의 소개, 행동 방법 등을 기술하였고 프로젝트의 규모에 따라 예외사항까지 기술해 놓았다.
제목 그데로 Guide인 샘이다.
얼마나 가능할련지는 모르지만 가능하다면 내가 참여하는 모든 프로젝트에 본 가이드데로 시행하고 싶은 욕심이 생긴다.^^
 
자 책의 서평을 정리하는 뜻에서 중요한 한가지 힌트를 주고 가름하려고 한다.
스티브맥코넬리는 개발자나 관리자가 움직이는 작은 움직임도 돈으로 계산하도록 하고 있다.
Planning Checkpoint Review를 가장 주의깊게 봤으면 한다.
PCR은 책의 논제가 어디로 흩어지든 항상 중심으로 인도하는 몇개의 끈들중에 하나이다.
PCR은 프로젝트 비용의 10~20%를 확보할 수 있고 PCR은 아키텍쳐를 만들어 내는 중요한 레퍼런스이다.
PCR은 요구사항을 개발!! 하는 도구중에 하나이며    PCR은 완료보고서의 멋진 시작이다^^


리스크 관리를 사보게 되었다.
code Complete책을 보다가 그 방대한 두꺼움에 압박을 당해 가벼운책으로
진정된 마음을 달래보려 빈맘에 리스크 관리를 보게된것이다.
 
책을 접하게된계기는 "리스크관리"의 저자가 전 피플웨어 저자와 동일했기 때문이다.
본 서평자는 책을 마구잡이식 읽기보다는 저자가 생각과 사상을 이해하려고 하기때문에
주로 저자중심의 그룹별 책읽기를 선호한다.
 
"피플웨어"에서 보였던 톰 디마르고와 티모시 리스터는 전화기가 없는 사무실에 훌륭한 사무 환경을
제공함으로써 진정한 개발자와 관리자와의 순수작업공간을 제시함으로써 개발자들로 부터
큰 호응을 얻었다
실제로 복잡한 사무환경과 너저분한 책상에서 깔끔하고 아름다운 제품을 기대하긴 힘들것 같다
   (그래서 필자도 책상을 정리하고 일을 수행하려는 습관을 들이기 시작함^^)
 
다시 본 서적의 원론으로 다가가보자!!
"리스크관리"는 리스크란! 절대 사라질 수 없으며
우리가 원한다고 피할 수 있는 존재가 아니라는것을 인지시키며 시작한다.
직원이 회사를 그만둘 수 도 있고 , 계획이 변경될 수 도 있고, 자금이 딸려 조기 종료될 수 도 있는 다양한 리스크가 있다.
이런 리스크들은 피하는 존재가 아니라 관리의 대상 인것이다.
 
서적 초기에 DIA (Denver International Airport)의  ABHS 구연에 대한 예를 들어주고 있다.
소송관련 컨설턴트인 톰 디마르고와 티모시 리스터는 DIA의 ABHS 프로젝트에 대한 정확히 어디어디가
리스크였고 이 리스크에 대한 책임을 누가 져야하는지를 본서적에서 집어내고 있다.
 
● 사건의 내용
ABHS Project는 납기일을 준수하지 못하여 소송에 휘말리게 된다.
매일 리스크 비용이 발생하기에 Denver시는 해당 문제에 대한 비용청구를 하게 된다.
과연 누가 이 리스크 비용을 감당하게 될것인가??
 
2명의 저자는 ABHS Project 리스크해결을 위해 다양한 접글을 시도한다.
다른 공항의 개발사례도 분석했는지 유무도 파악하며
충분한 자금이 투입되었는지 여부도 확인 하고
일정에 대한 관리는 잘 이뤄졌는지
개발을 위한 요구사항 명세서 도 살펴보고
개발자가 과연 이것을 개발 할 수 있는 정도의 스킬을 가졌는지도 확인하게 된다.
 
자..
소송관련 컨설턴트의 입장에서 실패한 project에 과실 여부를 분석할때 과연 누가 가장 큰 잘못을 했고
누가 그 비용을 담당해야 옳을 것인가??  (이 답은 책에 나와있습니다. ^^ )
 
아직까지 필자가 경험한 project의 이런 리스크 비용은 고스라니 엔지니어 몫이 된다.
영업하시는 분들이 촉박하게 잡은 일정덕에 개발자들을 날을 새고 일을 하지만 납기일 준수는 하지 못하고
그 덕에 온갖 무시와 홀대를 받으며 겨우겨우 1~2달 말미를 받아 드라마같이 프로젝트를 종료한다.
 
2명의 필자는 이런 우리를 위해 리스크를 관리하는 산출근거와 방법들을 설명해 주고 있다.
리스크 산출은 domain에 밀접한 관련이 있긴 하지만 "리스톨로지"를 통하여 리스크를 관리하고자 하는
그들의 높은 의지를 옅볼 수 있다. (실제 적용유무는 글쎄... ^^)
 
이제 서평의 결말이다.
리스크관리가 이뤄지지 않는 조직에서 리스크를 이야기하는것은 선량한 한명의 가슴에 주홍글씨를 세겨넣는것과 같다.
그곳에선 그를 죄인 취급하고 프로젝트 방해꾼으로 총징한다.  (이런곳에서는 리스크를 말하지 말자!!)
 
하지만 정말 건설적인 프로젝트 완료와 성장지향을 원한다면 위험요소를 꼽아내는 그에말에 귀 기울여볼 필요가 있다.
그사람이 "리스크를 이익" 으로 환원시켜줄 연금술사가 될지도 모르니까 말이다.



본 서적을 읽게된 경유는 스티브맥코넬리의 서적 4개를 독파하기 위해 잡게 되었다.
모두가 아시다시피 스티브맥코넬리는 단 4개의 서적만으로 모든 기술을 논할만큼 그에 생각의 깊이는 깊다.
사실 이것에 대한 정보는 인사이트 출판사나 너무도 쉽게 이해시켜놓은 도식이 있다.
 
professional소프트웨어개발 (동기부여)
Rapid Development, Code Complete (스터디)
소프트웨어 프로젝트 생존전략 (적용)
----------- 기회가 되면 이 4권에 책을 서평해봤으면 하는 바램이다.
 
오늘 이야기하고싶은 서적은 "professional 소프트웨어개발" 이다.
 
S/W는 부드러웠기 때문에 두리뭉실 평가된 경향이 있다.
S/W가 만일 부드럽지 않고 단단하고 딱딱했으면 지금처럼 한국 사회에 S/W개발자들이 저평가 되지 않았을 것이다.
물론 이공계 기피라는 단어조차 나오지 않았을 것이다.
스티브맥코넬리는 바로 이런 S/W의 부드러운 부분을 보다 구체화 시키고 체계화 시키기 위해 본서를 저술 하지 안았나 싶다.
 
스티브는 엔지니어 들에게 무 비판적 실행맨, 작업맨 으로써의 역할이 아니라
관리자들혹은 의뢰인들과 엔지니어가 직접 이야기 하며 문제를 풀어가고
다양한 분석과 상황판단을 통해 보다 많은 사람이 행복해하는 합의점을 찾아갈 수 있도록 "스티브 우화"를 적어놓았다.
> 피라미드를 움직이는 이집트인
> 화물숭배공학
> Silver Bullets
> 노붐 오르가눔
> 고아출신의 우대
이것 외에도 스티브는 많은 이야기 꺼리를 바탕으로하는 자신만의 사상을 전달하려고 하고 있다.
 
허면 이런 사상의 결론은 무엇인가?
놀랍게도 엔지니어를 보다 레벨화 시키고 정확하게 평가함으로써 성능좋은 엔지니어는 보다 높은 가치를
그렇지 못한 앤지니어는 교육과 훈련을 통해 높은 가치에 다다르게 함에 있다.
 
여기서 잠시 "professional소프트웨어개발" 의 역자를 살펴보자!!
역자는 윤준호씨로 SW-CMM의 ISO 인증을 위해 노력하는 사람이다.
만나보지는 못했지만 그도 역시 스티브의 엔지니어의 레벨화를 꾀하여 S/W를 짜임세 있게 만드는 분 일것 같다^^
 
자.. 다시 책속의 이야기로 들어가보도록 하자!!
책 서두에서는 "고아출신의 우대" 등과 같은 예를 통해 현실상의 엔지니어의 자각을 유도하고 있다.
책 중반부에서는 이런 엔지니어들에게 professional해 짐을 권면하면서 어떠한 방법으로를 이야기 한다.
책 종반부에서는 SW-CMM등과 같은 것을 통하여 레벨화와 모든 엔지니어의 성숙을 권면하고 있다.
 
우리는 본 서적을 통해 SW-CMM의 다음 세대를 준비할 필요가 있다고 본다.
그냥 단순 코더로써 오늘도 저렴한 몸값에 돌을 힘으로만 옮길 것인지
아니면 보다 향상된 엔지니어가 되어 고가의 몸값에 돌을 효과적을 옮길 궁리를 하게 되야하는지
우리는 본 서적을 통해 다가올 미래를 준비할 필요가 있다고 본다.
스티브의 머리속이 아니더라도 그의 눈으로 세상을 바라보고 나역시 다가올 미래를 준비 해야할것 같다




본 서적에서 언급하는 실용주의는 무엇인가?

'Pragmatic' 이란 단어는 "업무에 능한" 이라는 뜻의 라틴어 'pramaticus' 에서 나왔고 또
라틴어는 '(무엇인가를) 하기' 를 의미하는 그리스어에서 파생된 말이다.
바로 이책은!!! ~하기에 관한 실행을 동반한 개발자 개몽 서적이다.

junit 책을 처음 접했을 당시 상황이 그려진다.
서점 수많은 책꼿이에 반드하게 꼿혀진 하얀색 책~~
그냥 그 하얀 다자인이 맘에 들었는데 내용 역시 junt를 간략하게 소개하는것이 참 맘에 들었다.
CVS, Junit, ANT(?) (기대하는 3번째책) 을 가름해봄 으로써 pramaticus의 추구하는 바를
짐작 할 수 있게 한다.

실행을 동반한 서적!!
바로 이책이 추구하는 목표인듯 하다.

본서적을 읽는데 있어서 TDD와 마찬가지로
"역자 주"를 간과하지 말기바란다.  바로 이 역자주는 번역자 이용원님의 기술이 녹아있는 부분 이기도 하기 떄문이다.
대부분의 개발자들이 역자를 담당하게 되는데 본 Junit의 역자 이용원님께서도 다양한 필드에서 연구를 하셨을 것이 분명하다.
(이러한 이유는 책의 뒷부분에 나오는 Eclipse에서 junit를 사용하는 매뉴얼이 착실히 수록되어 있음을 볼 수 있다.)
원서와는 사뭇 다른 번역서가 한국개발자를 배려한 역자의 노력이 옅보이는 부분이다.
                
책의 내용을 보도록 해보자..
본 책은 어떻게 읽어야 하는가??

● 구독 방법
1. 편안한 책상에 등받이가 쿠션기능이 있는 의자에 앉는다.
2. 모니터와 키보드 그리고 본 서적을 놓고 작업자가 앉는다 (책은 배위에나 다리위에 있다)
3. 컴퓨터는 Eclipse를 띄워놓고 Junit의 처음시작을 타이핑 하며 읽도록 한다.

처음단계가 넘어가면 다음 단계부터는 "오른쪽 알통" 에 대해 깊이 깊이 생각해보도록 한다.

본 책은 순수 실행을 위한 가장 컴팩트한 교과라 봐도 무방할 정도이다.
군더더기는 없으며 그냥 ~하기를 위한 실행을 도모하기 위한 설명이다.
jUNIT에 대해 잔뜩 기대한 사람이라면 다소 실망 할 지 모르나 서평자와 같이 짧고 굵에 읽어 사용하기를
중심으로하는 개발자라면 추구하고 읽어볼 필요가 있다고 본다.

● 서평자 생각..
 project에 있어 가장 큰 복병은 개발자가 자신이 짠 코드의 오류에서 혹은 다른 팀원이 만들어 놓은 소스코드 속에 빠져
 도무지 문제가 어디서 발생되었는지 찾아가는 문제일 것이다.
 junit은 이런 복병을 숨을 수 없도록 요소 요소에 터랫을 박아 놓은 것 이라 볼 수 있다.
 
junit은 잘 구동되던 소스코드를 항상 잘 구동될 수 있도록 신선한 상태를 유지하고 있으며
 junit은 곳곳에 숨어져 있는 메소드단위 최척화  test in/out값을 가지고 있기에 개발자는 과거를 잊어도 된다. (좀심했나??)
 
 단 5개의 명령어 (assertEquals(), setup(), testEnd() , assertTrue(), assertFalse()) 만으로 이토록 훌륭한
 프로젝트 맨토를 구할 수 있다고 알려준다면 본 서적의 임무는 다한것이다.
 
모두가 행복해졌으면 한다.
 이책을 읽음으로써 개발자 모두가 여유있는 시간속에서 개발이 이뤄졌으면 한다.
1 2 3 4 5 

글 보관함

카운터

Total : / Today : / Yesterday :
get rsstistory!