해커에 대한 진부한 이야기가 아닌 사회, 교육학 측면에서 바라보는 시각입니다. 역자가 서문에서  "신선한 시각에서 바라본 책"이라고 평을 하면서 시작되는 책입니다. 역자는 그 유명하신(?) 임백준씨입니다.

역자가 서문에서 상기와 같이 "신선한 시각에서 바라본 책"이라고 쓴 이유는 치열한 해커의 열정, 왕따의 공부벌레의 열정은 반드시 성공하리라 생각하는 마인드일꺼라 생각이 듭니다.

틀에 박힌 사람은 그 이상의 틀을 벗어날 수 없습니다. 해커의 기본 법칙인 "해커는 법칙을 깨뜨렸을 때 승리한다"라는 사실을 강조하고 있습니다. 상식을 깨는 사람이 성공한다~ 이 말은 자주 듣죠?

IT에 들어서는 순간, 돈을 벌지 못하는 앵벌이다. 그런 말을 자주 듣지 않습니까? 요즘 KLDP에 보니, 부정적인 시각이 많이 있네요. 또한 후배 고등학생들은 이과를 선택안하는 세상이라, 공대생이 되는 순간, 성공하지 못하는 인생길로 생각합니다.

이 책은 부자가 되는 길은 바로 부를 축적하는 것을 말합니다. 상당히 철학이 있는 말이죠. 부 != 돈 이라는 등식인 겁니다. 부는 돈이 많음을 뜻하는 것이 아니라, 돈은 부를 움직이기 위한 수단이라는 것을 강조하고 있습니다. 부를 창출할 수 있는 사람은 즉 파이를 만들어 키우는 사람은 장인이라는 것을 포커스를 두고 있습니다. 창출할 수 있는 무언가나 위치를 움직임으로서 부를 얻는 것을 말하고 있습니다.

역사적으로 부를 창출한 사람은 시대의 흐름에 있어서 필요한 것을 만드는 사람, 즉 생산자임을 말하고 있습니다. 바로 스타트업을 하고, 그 스타트업이 비록 힘들더라도 몇 배의 노력(저자의 말에 의하면 10년 할 일을 2-3년만에 한다)을 해서 부를 창출할 수 있다라고 강조합니다.

테크놀리지, 이 새로운 흐름에 맞는 무언가를 만들어 소비하게 한다면 부를 얻을 것이라는 것외에 디자인이라는 또 다른 요소를 알려줍니다. "위대한 작품을 만드는 방법은 바로 자기 자신만의 미적 취향과 그것을 만족시킬 수 있는 능력에 달려 있는 것이다."라고요. 자신만의 설계 디자인 감각, 그리고 완벽을 추구하려 하며, 전보다 더 나은 작품을 만들고자 하는 열정(?)을 가르키는 것은 아닐까요?

프로그래밍 언어론에 대해서 나름대로 비교를 해 봅니다. 여러 언어중 리스프를 극찬합니다. 프로그램이 데이터처럼 취급되어 인공지능 언어로 분류되며, 함수 언어라고 알려져 있지요. 부끄럽지만, 저는 인공지능 수업을 듣다가 리스프 언어를 만나고 난 뒤 바로 드롭을 해버렸습니다. 너무나도 이해할 수 없는 언어라 참기 견디기 어려웠죠. 그 언어를 저자는 침이 마르게 칭찬합니다. 맥카시의 뜻을 잘 이은 사람인 듯 싶더라구요. 야후 쇼핑의 전신인 비아웹에서 언어의 일부분의 성능을 위해서 리스프를 사용했다고 합니다. 그러면서 장점을 부각을 합니다.

얼마전의 파이썬의 창시자(이름 못외웁니다...ㅡ.ㅡ)가 구글에 들어가 구글 검색엔진의 일부를 구현했다고 합니다. 이 일과 무관하지 않은 것입니다. 기존 언어가 할 수 없는 일을 해주는 언어, 오히려 복잡할 수 있는 부분이 풀릴 수 있는 일을 특정 언어로서 할 수 있는 것이겠지요. 예를 들어 자바위에 Pyton을 올리며 Jython이라 불리는 스크립트를 쓰는 것이라 생각할 수 있겠지요.

부끄럽지만, 저는 전에 언어 개발에 참여한 적이 있습니다. 새로운 언어입니다. 더이상 말하기는 어렵지만, 저는 얼마나 저의 무지를 배웠는 지 모릅니다. 그냥 이미 있는 기존의 언어를 사용하지, 왜 새로운 언어를 해야 하는 지 이해를 할 수 없었습니다. 하지만, 되돌아 생각해 보면 볼 때마다 귀한 경험이라고 생각합니다.

기존의 할 수 없던 일을 쉽게 할 수 있으며, 강력한 기능을 제공한다면, 새로운 언어 한 번 만들어 볼 수 있는 겁니다. 그래서, 여러 언어들이 계속 나오고 쓰이는 이유도 그런 해커의 정신이 아닐까 합니다.

프로그래밍 언어는 계속 진화합니다. 그리고, 계속 바뀌지만, 언어에 얽매이는 틀이 아닌 자유의 틀을 가진 사고는 가져야 할 듯 싶습니다. 어떤 프로그래밍 언어는 완벽하고, 어떤 프로그래밍 언어는 천박하다 라는 이분법적 사고나 교조주의는 지양해야 할 것입니다. 나름대로의 특징이 있으며, 할 수 없는 일을 하는 특징이 있게 마련이고, 그 쓰임때문에 지금까지도 남아 있는 것이겠죠.

꿈을 가져봅니다... 좋은 언어..

http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200509230033

솔루션을 개발하고 나서 가장 먼저 하는 일을 개발한 솔루션에 대해서 홍보를 하는 것이다. 그 중의 하나가 '전시'혹은 '데모스트레이션'(이하 데모)을 하게 된다.

데모 준비는 가장 데모 환경과 똑같은 환경에서 준비를 해야함에도 불구하고 제대로 준비되지 않는다.
불안 요소로 인해서 데모가 진행되지 못하는 경우가 많다.

데모의 법칙을 한 번 얘기해 보려고 한다.

1. 막상 데모를 준비하려고 하는 순간 문제가 꼭 생긴다.

2. 1번의 문제 때문에 상황이 악화된다. 이 때 관리자는 폭발하게 되어 집중을 하지 못하게 한다. IBM에서 개발중인 과학자에게 관리자가 머라고 했다가 과학자가 이 한마디를 했다고 한다. "당신이 없는게 일이 더욱 빨리 할 수 있는 것이다"라고..

3. 1번의 문제를 피하려다 다른 문제로 꼬인다.

데모는 완전한 제품을 시연하는 것이 아니라, 현재 이런 솔루션을 통해서 무엇가를 할 수 있다라는 혹은 비즈니스를 창출하여 수익을 얻을 수 있다는, 혹은 생산성을 높여 최대한의 수익을 얻을 수 있는 것을 그 목적으로 한다. 그러기에 실수는 없도록 해야 하는데, 이 부분을 잘 모르는 경우가 많다.

데모 준비자가 실수하는 부분이 바로 여기에 있다. 단순히 자기가 맡은 역할만 다하는 것이 아니라, 자신과 엮인 부분이 (INTERFACE) 다른 모듈과 잘 동작되는지, 문제가 없는지를 파악하는 것이 필요하다.
그러기 위해서는 데모 준비자가 갖추어야 할 요소를 다음과 같이 정리해본다.

1. 데모 시나리오를 확정해야 한다.
글쓴 이는 방송 미들웨어 데모를 준비중이었는데, 데모 시나리오가 갖추어지지 않아 단순하게 내 입맛에 맡는 부분만을 생각하고, 그 부분만 완료가 되면, 다 되는 줄 알았다.
데모하는 날, 방송망으로 DVD 소스를 비디오 인코더를 통해서 송출할 때, 수신기에서 디코딩하는 부분이 문제가 생기는 것을 발견하고, 그제서야 관리자에게 보고를 하게 되었고 혼이 났다. 글쓴 이는 황당해서 데모 시나리오가 제대로 정해지는 지 몰랐다고 항변했으나, 관리자는 몰랐으면 확실히 물어보아야 하는 것이 아니냐고 하였다.

1차적으로는 글쓴 이에게 있었다고 본다. 불확실한 부분에 대해서 확실하게 책임을 지고, 데모의 경계선(BOUNDARY)을 일찍 파악하는 것이 중요했는데, 그 부분을 생각하지 못한 것이 큰 문제였다. 어플리케이션을 올려 테스트하는 것만을 생각했지, 동영상 디코딩을 할 줄을 몰랐던 것이다.
실제 방송에서 동영상을 방송 스트림으로 전송하는 것이 방송 데모에서 큰 부분인데, 미처 이 부분까지 생각하지 못했다.

2차적으로는 데모 시나리오가 확실히 잡히지 않은 문제가 가장 컸고, 의사소통이 제대로 이루어지지 않았으며, 책임자가 올바르게 선정되지 않았기에 문제가 생기는 소지가 발생하였다. 관리자는 반드시 자기의 소재를 확실히 하여, 데모 책임자가 어느 선까지 준비되었는지를 체크하는 것이 중요하다.

2. 데모 준비에 앞서 데모 준비 환경과 완벽하게 준비한다.
데모 준비 환경이 계속 바뀌게 되면, 데모를 준비하는 사람은 많이 힘들게 된다. 즉, 미리 준비할 때, 계획성있게 해야 하는데, 늦게 준비가 되면, 일을 또 하게 되어서 셋팅에 문제가 될 소지가 많다.
글쓴 이가 데모 환경을 3번이나 변경을 하면서, 갑작스런 문제가 생겼다. 3번째 데모 환경을 변경중에 수신기에서 방송스트림을 제대로 받지 못하는 일이 갑자기 발생하였다. 1시간 넘게 그 이유를 발견하지 못했다. 결국은 중형 스피커로 발견되었고, 스피커를 치우니, 동작이 되었다.
그리고, 3번째 데모 환경 변경시, 파워 스위치를 모르고 끄는 바램에 이유를 알수 없는 미들웨어 버그가 생기는 일이 벌어졌다. 정확하게 파워 리셋이 되었다고 문제가 생기는 것은 아니었지만, 다른 이류를 촉발시킨 듯 하다.
항상 데모 환경은 4시전에 끝을 내야 되고, 그 이후에 바뀌어서는 안된다.


3. 데모는 기록해 둔다.
데모에 대해서 무엇이 문제인지, 무엇때문에 데모준비, 데모를 하면서 변경 희망 사항이 생기면 제품에 반영할 수 있어야 한다. 또한 데모를 받는 고객에게서 좋은 힌트나 요구사항에 대한 정리를 통해서 제품에 반영할 수 있어야 한다.

또한, 데모 환경을 잘 기록하여 추후 잘 활용할 수 있어야 한다. 하드웨어, 물리적 네트웍의 변경을 한 부분을 잘 정리하여 추후에 데모를 할 경우 다시 할 때도 잘 할 수 있도록 해야 한다.

참고할 만한 웹페이지

How to write unmaintainable code
http://www.web-hits.org/txt/codingunmaintainable.html

Gnu Coding Standards

Ada 95 Quality and Style Guide : Guidelines for Professional Programmers

GNAT Coding Style

Recommended C Style and Coding Standards

Kernel Korner:Proper LinuxKernel Coding Style

C++ Coding Standard

Coding Convention for C++ and Java application

C++ Coding Style : My code Style

Coding Guidelines for Integral Constant Expression

CStupidClassName

General c++ Coding standard at the NFRA

Hight-Integrity C++ Coding Standard Manual-version 2.1

Programming in c++, rules and Recommendations

UWYN c++ coding standard

Wildfire c++programming style with rationale

mozilla coding style guide

c# coding style guide

writing robust java code

ChiMu OO and Java Development : guidlines and Resources v 1.8

Desing by contract for java using JMSAssert

Java Programming style guidelines version 3.1

how to write doc comments for the javadoc Tool

java glossary: gotchas

Netscape's software coding standards guide for java

tips for maintainable java code

draft java coding standard

Java Language coding guidelines

Best practices : PHP coding Style

PHP coding standard

Delphi 4 Developer's guide coding standards document

the wdvl style guide

spelling errers in you're sights

style guide for online hypertext

css coding style




keyword : coding style, coding standard, code convention, coding guideline, programming style
언어 style, guideline, convention, standards

근 4-5개월 정도, 저는 출, 퇴근 시간을 이용하여 전철에서 틈틈이 컴퓨터 과학 분야의 기고문 또는 논문 등을 읽었습니다. 주로 역사적으로 중요한 위치에서 쓴 부분을 중심으로 자세히 보았습니다. 초심의 마음으로 컴퓨터 과학 분야의 알고리즘 혁명가 ‘다이즈크스트라’가 ACM에 기고한 논문부터 웹을 창시한 ‘팀버너스 리’가 쓴 최근 글들을 보았습니다.

 

방 한구석에 처박혀 아직도 읽지 못한 논문들과 기고문들이 지저분하게 쌓여 있습니다. 그렇게 논문을 읽고, 그에 해당하는 참조를 찾아가며 프린트하며 찾아보는 이유는 제가 공부하고 있는 내용이 진실이 아닐지도 모른 생각을 하면서부터였습니다. 그냥 이론에 갇히어 더 이상 창조적인 생각이 아니라 박제처럼 박혀 있는 죽어 있는 컴퓨터 과학이라는 느낌이 너무나 실감나게 느꼈었는지도 모릅니다.

 

학교에서 공부하던 일반적인 전공 내용보다도 컴퓨터 과학 분야의 대가들이 어떠한 삶을 살았는지, 어떤 생각을 최초에 가졌는지 궁금해 했습니다. 그들의 창조적인 생각들을 조금이나마 알아보고 제 자신이 변화하고 싶었습니다.

 

역시 한 토막 한 토막 읽을 때는 연결되지 못하는 점이라는 생각에 통합을 할 수 없었습니다. 나름대로 정리를 한다고 했지만, 머리는 더욱 더 혼란스러워 져 갔습니다. 점들이 점점 많아 지면서 명확하게 점들을 연결하는 선을 그으려고 했었습니다.

 

바로 그 와중에 ‘임백준의 소프트웨어 산책’이라는 책을 읽게 되었습니다. 희미 해진 정열, 그리고 보이지 않는 공대생의 미래라는 현실과 앞으로 내가 하고 있는 일이 과연 계속 할 수 있을지에 대한 불안한 미래가 그리 달갑지는 않습니다.

 

하지만, 코딩 하는 즐거움, 내가 창조할 수 있는 가상의 공간이 있다는 사실에 내가 세상에 태어나 누구보다도 생산적인 일을 하고 있는 즐거움이 고민과 번뇌를 날려 버립니다.

 

이렇게 복잡하고 명확하지 않는 상황에 ‘임백준의 소프트웨어 산책’을 도서관을 통해서 읽게 되었습니다. ‘임백준의 소프트웨어 산책’은 초보자가 읽기에 쉽지 않은 책입니다. 책 이름 그대로 산책 대신 깊은 사색이 오히려 이 책을 표현하는 말이 어울립니다. 보통 저는 산책을 할 때는 더 이상 머리 안의 책상이 복잡해 져서 더 이상 손댈 수 없는 상황에 닥쳐 있을 때입니다.  산책을 통해서 편안하게 내 머리를 쉬게 해주고 나 자신을 되돌아 봄으로서 잠시나마 머리 안의 책상을 치우고 다시 되돌아가 힘을 얻게 됩니다.

 

그리고, 산책은 혼자보다는 맘에 드는 들어 하는 회사 동료나 선배, 후배 등과 같이 걷습니다. 이런 저런 잡다한 얘기와 함께 선배는 지쳐 있는 저에게 힘이 되어 주는 말과 앞으로의 비전을 서로 얘기합니다.

 

특히 그 산책을 임백준씨와 함께 할 수 있는 기회를 책을 통해서 얻게 되었습니다. 임백준씨에 대해서 잘 모릅니다. 블로그 한 번 가지 않았고, 그저 IT잡지나 책에서 보는 대선배이지만, 산책을 통해서 선배로서 하는 말을 책을 통해서 친해 지게 되었습니다.

 

‘도대체 너를 괴롭히는 코딩이 머니? 객체에 대해서 다시 한번 생각해 볼까? 객체가 왜 만들어 질까? 그리고 디자인 패턴은 좀 알아? 리팩토링은 어떻게 생각하는데? 결국 보면 단순한 게 제일 좋은 거야. 개발 방법론은 어떤 게 좋은 걸까? 그리고, XML은 항상 좋은 건 아냐 그리고 내 예전 얘기 한번 들어 볼래?’

 

이런 저런 얘기를 듣고 결국은 이렇게 말합니다.

 

‘그냥 단순한 지식 전달뿐 아니라 알고 보면 참 별거 없어. 인생이 다 머~ 즐거운 거야~새옹지마 아냐? 힘내라~ 어깨에 힘 좀 넣고~ 파이팅!’

 

책 속의 선배가 제가 궁금했던 점을 확실하게 알려 주고 앞으로 어떻게 공부하면 되겠는지 좀 더 확실히 해주고, 초심의 마음을 건네 줍니다. 원리를 알려 주고, 더 이상 헤매지 않도록 힘을 더해 줍니다.

 

저자의 마음을 제 마음속까지 느껴 집니다. 책을 보는 제 느낌은 참 기분이 좋습니다. 회사나 학교에서 얻을 수 없는 기쁨, 바로 책 읽는 즐거움 덕택에 인생의 단 맛을 느껴 봅니다.

중요한 것은 주어진 상황이 맞닥뜨린 문제를 구체적으로 이해하려는 노력이지 카탈로그를 외우는지 여부가 아니기 때문이다.


철학은 남의 것을 외워서 하는 것이 아니라 자기 스스로 하는 것이다.

패턴을 학습한 프로그래머는 유지보수를 고민하게 된다. 그 것이 좋은 프로그래머이다.

리팩토링은 새로운 코드를 만들면서 미래를 향해 나아가는 프로그래밍이 아니라, 이미 존재하는 코드를 부수면서 과거로 뛰어드는 프로그래밍이다.

80:20 원칙이란 프로그램 소스코드의 80%는 소프트웨어의 전체 성능에 20%정도의 영향을 미치고, 나머지 20%가 성능의 80%를 좌우한다는 원칙을 의미한다. XML은 그래서 80%에 해당하는 소스코드에서 사용될 때 성능에 큰 영향을 주지 않지만 나머지 20%의 영역에서는 성능에 영향을 미친다.

소금을 뿌리되 넘치거나 모자라지 않게 뿌리는 요리사의 균형 감각은 음식의 맛을 좌우하는 열쇠다.

마치 중학생,고등학생들도 쉽게 읽을 수 있는 문체로서, 저자가 쉽게 써준 것에 대해서 강한 감사를 드린다.

소프트웨어 공학은 기본적으로 다양한 소프트웨어의 생산성을 높이는데 그 목적을 두고 있다. 제품이던지, 프로세스에 중점을 두고 있는 부분들이 존재하지만, 의외로 사람에 대해서는 투자하지 않는 경향이 강하다.

그리고, 사람을 중심을 두고 있어도 문화에 대해서 생각하지 않는 관리자들이 거의 없는 것 같다.
조직문화가 계속 긍정적으로 바뀌고 생산적으로 바뀌어야 함에도 불구하고, 왜 퇴보하는 것일까?

이 책을 읽고 나름대로 내 생각을 정리해서 관리자, 팀장, 팀원의 관계를 통해서 팀장의 역할을 그려본다.


소프트웨어 엔지니어가 회사에 기여도와 조직문화는 전혀 정비례는 아닌 듯 싶다. 즉, 이것은 관리자와 엔지니어간의 이질적인 간격이 존재함이 분명하다. 회사가 직원들에게 주는 불신임, 우울감, 허탈감은 분명 관리자의 책임이다.

관리자는 문화를 만들어야 한다.

팀장은 팀을 조직하고 생성하는 일만 할 뿐 아니라, 팀의 목적을 분명히 하고, 상급을 적절히 주며, 비젼을 만들어 주어야 하고, 교육을 시켜 주니어 엔지니어들의 캐리어를 높여 강한 팀을 만들 수 있도록 노력해야 한다.

개인적으로 가장 중요한 덕목은 커뮤니케이션 능력이다.
하루종일 앉아서 코딩을 하면서 신경질을 내는 사람보다는 웃으면서, 바쁘지만 여유있게 주위 팀원을 챙겨주고, 목적을 확실하게 만들어주는 일을 만들어야 하며, 항상 앞에 서서 팀의 방향성을 리드할 수 있어야 한다. 그러기 위해서는 팀원들의 사기를 복돋아 줄 수 있고, 팀원 각각의 고충을 풀어주지는 못하지만, 들을 수 있어야 한다.
또한 관리자들의 요구사항을 잘 적절하게 막아줄 수 있는 능력, 커뮤니케이션 능력이 있어야 한다.

팀의 비젼을 공유할 수 있도록 함으로서, 요구사항에 근접할 수 있도록 마음이 오픈이 되어야 한다. 진실된 작은 소리는 시끄러운 아우성보다 더 잘 들린다고 한다. 즉, 실력이 없더라도, 엉뚱한 질문을 하더라도 이해시킬 수 있어야 한다.
프로세스에 너무 얽매이지 않도록, 독력해야 한다.

두번째 중요한 덕목은 실력이다.
아무리 커뮤니케이션 능력이 좋더라도, 실력이 않좋으면, 팀원은 팀장을 무시할 수 있을 수 있다. 항상 공부하는 자세가 되어 방향성을 제시할 수 있어야 한다. 물어보는 것을 다 해결하는 사람보다는 방향성을 제시할 수 있는 사람이 되어야 한다. 팀원이 헤메는 것을 막고 바로 갈 수 있도록 가이드를 해야 한다.

세번째 중요한 덕목은 분석능력이다.
즉, 주어진 요구사항을 분명히 깨닫는 것이 중요하다. 고객의 불확실한 명세사항을 무조건적으로 따르는 것이 아니라, 고객의 가장 중요한 부분, 일을 적게 하려는 것을 캐취하는 것이 중요하다. 그래서, 간결하게, 또는 문제를 해결할 수 있는 방법을 고객에게 또는 시장에게 제시할 수 있어야 한다.

네번째 덕목은 교육 개발 능력이다.
멘토링과 코치능력, 팀원 각자의 개발능력 향상을 위한 교육, 세미나에 참석을 독려 혹은 경력관리가 가능하도록 노력해야한다.즉, 팀원들을 고객처럼 생각하고, 만족시킬 수 있는 능력을 가져야 한다. 슈퍼 소프트웨어 엔지니어가 되도록 여러가지 정보들을 줄 수 있어야 하며, 틈틈히 세미나를 이용하여 개발능력을 향상시킬 수 있어야 한다.

다섯번째 덕목은 용기이다.
관리자는 성과를 보고 싶어한다. 또는 좋다고 하는 프로세스를 팀에게 적용시키고자 한다.
팀장은 적절한 안목이 있어야 한다. 즉, 팀의 문화, 조직의 문화가 프로세스 성숙도를 측정하는 기준과 맞지 않는다면, 회사의 가치를 더 우선순위를 두어야 한다. 즉, 문화를 바탕으로 프로세스가 바뀌는 것이지, 프로세를 무조건으로 신봉해서는 되지 않는다. 관리자 혹은 팀원에게 욕을 먹더라도 중용의 자세가 중요하다.
그냥 아는 것도 아니고, 신봉도 아닌 그 중간적인 성격을 지닌 프로세스를 적절하게 이용해야 한다.

여섯번째 덕목은 계획성이다.
월요일에는 항상 일주일을 시작하는 맘으로 전체 회의를 열고, 어떤 방향으로 나가야 할지, 점검을 꼭 하도록 해야 한다. 헛다리 짚지 않도록 해야 하며, 계획적으로 나가야 한다. 각자 팀원 개개인의 역량을 체크를 해야 한다.
이 때 가장 중요한 부분은 커뮤니케이션 능력이다. 아무리 계획성을 가지고 있어도, 짜증이나 무표정으로 말하는 팀장보다는 당연히 웃으면서 즐거운 분위기에서 하는 게 훨씬 낫다.

커피를 마시고, 쇼파에 앉아서 즐거운 마음으로 주말을 어떻게 쉬었냐 하며, 부드러운 분위기에서 시작하는 것이 가장 좋다. 회의실로 바로 가는 일은 팀원들에게 경직된 마음을 줄 수 있으며, 특히 월요일이라는 분위기에 적응하지 못하는 팀원들에게는 독이 될 가능성이 높다.

가장 먼저 자신의 솔직한 얘기를 통해서 웃으면서, 월요일 아침을 잘 시작하는 방향이 중요하다.

소프트웨어 회사의 분위기가 항상 이렇지는 않을 것이다. 늘 일에 쪄들고 고생할 수 있지만, 반드시 중요한 부분은 팀장과 팀원들간의 신뢰성을 그 기반으로 하는 것이다.

이상으로 조직문화를 아름답게 바뀌기 위한 나름대로의 제안을 해보았다. 책의 내용은 참고용이고, 내가 나름대로 생각했던 부분을 반드시 적용하도록 하는 것이 가장 중요할 것이다.

Chapter 1 The Computer Revolution Hasn't yet

이 글은 Howard Rheingold라는 사람이 MIT Press를 통해서 지은 책중의 가장 맨 앞 부분이다.
컴퓨터 역사학자쯤 되는거 같다. 요즘 내가 좋아하는 컴퓨터 역사학이라 그런지 장기적인 독서의 기쁨이 될 듯 하다.

근 500년과 근 100년을 비교했을 때, 근 100년은 상당히 놀라운 효과가 있었고, 너무 빠른 속도로 세상이 바뀌고 있음을 깨달을 수 있다. 근 100년은 인쇄술의 발달로 지석이 축적되고 전파되어서 놀라운 발전이 있었다.

한편, 미래 예상이 힘들어서, 과거 60대에서 지금의 모습을 그려본 모습과 지금 90년대에서 미래를 예측하는 것은 커다란 차이가 있으며, 어떤 미래가 될 지 전혀 예상하기 힘들다.

computer scientist 는 인간의 지능을 최대한 확장시킬 방법을 기계로 통해서 구현하려고 했다. Charles Baaba와 Ada, Boole의 공학적 이론, Alan Tunig의 이론적 배경, von neuman의 컴퓨터 구현, Norber Wiener의 컴퓨터간의 connection 구현등의 노력등을 통해서 Computer Science 라는 학문이 태동되었다.

어떤 computer scientist는 골방에 메여 그들의 작품이 바로 끝나는 경우가 있었다.

1950년대 이후부터 computer라는 기계의 구현에서 점차 personal화된 computer를 연구하기 시작했다. 인간의 각각의 레벨에 맞는 형태를 생각하게 되었고, user interface에 대한 고려가 시작되었다.

Avron Barr의 expert system, Brenda Laurel의 컴퓨터를 다루는데의 방법론 디자인, Ted Nelson의 Computer library 개념들이 컴퓨터 혁명이 이루어지는데 밑바탕이 되었다..

Java Modeling in Color with UML 에서 Fast Driven Development(FDD) 부분이다.
빨리 개발하기 위해서는 5단계의 프로세스를 거친다. 실제로 이런 프로세스에 대해서, 생각해보고.
내 나름대로의 방법론을 터득하고 다듬어 가기 위해서 적어놓았다.


[요약]

[[ 5단계의 개발 프로세스]]
1. Develop an overall model(using initial requirement/feature, snap together with components, focusing on shape)
2. Build a detailed, prioritized fatures list.
3. Plan by feature.
(Component 별로 개발)
4. Desing by feature(using components, focusing on sequence).
5. Build by feature.


[[5단계의 시간 소요예측 ]]
Develop an overall model : 10% initial, 4% ongoing
Build a features list : 4% initial, 1% ongoing
Plan by feature : 2% initial,2% ongoing
Design by feature, build by feature : 77% (cycle time : every 2 weeks)



이에 대한 프로세스별 문서는 다음과 같다.

FDD Process#1 : Deveolop an Overall Model

고객은 시스템에 대한 구축에 대한 준비를 막 하려고 하고 있다. 그는 특정 형태의 요구사항 명세서를 가지고 있다.
그가 원하는, 즉 회사가 원하는 사항에 대해서 must have, nice to have 등으로 나눠 정리한다.

Form the modeling team
Domain WalkThroght
Study Document
Build an Informal
Features List
Develo Sub-team Models
Develop a Team Model
Log Alternates

Internal and External Assement

이 단계를 끝내기 위해서는 해당 팀은 반드시 다음의 산출물을 만들어서 제출해야 하며, 팀장으로부터 승인을 받아야 한다.
-Class diagram
-Informal features list
-Notes on significant modeling alternatives

FDD Process#2 : Build a Features List

모델링 팀은 domain영역을 바탕으로 개발부분과 팀원들을 구성해야 한다.

Form the Features-List Team
Identify Features, Form Feature Sets
Prioritize Feature Sets and Features
Divce Complex Features

Internal and External Assessment>

이 단계를 끝내기 위해서는 features-list 팀은 반드시 detailed features list를 작성해서 넘겨야 하고, 팀장에게 검토/승인을 받아야 한다.

FDD Prcess#3 : Plan by Feature

feature-list 팀은 반드시 FDD Process#2를 완전하게 마무리 했고, Feature List를 구축한다.

Forms the Planning Team
Sequence Major Features Sets and Features
Assing Classes to Class Ownners
Assign Major Feature Sets and Features to Chief Programmers

Self Assessment

이 단계를 끝내기 위해서는 개발 계획을 만들고, 팀장으로부터 검토/승인을 받아야 한다.
- Overall completion date
- For each major feature set, feautre set, and feature
- For each class, its owner

FDD Process#4 : Desing by Feature

Process#3완수

Form a Design by Features(DBF) Team
Domain Walkthrogh
Study the Referenced Documents
Build a Sequence Diagram
Write Class and method Prologs
Design Inspection
Log Desing-Inspection Action Items

Design Inspection

이 단계를 종료하기 위해서는 다음의 result를 팀장으로부터 검토/승인을 받아야한다.
- The feature and its referenced documents(if any)
- The detailed sequence diagram
- Class-diagram updates
- Class and method proplog updates
- Notes on the team's consideration of significant desing alternavites.

FDD Process#5 : Build by Feature

Process#4 완수

Implement Classes and Methods
Code Inspection
Log Code-Inspection Action Items
Unit Test
Check in and Promote to the Build Process

code Inspection and Unit Test

이 단계를 종료하기 위해서는 다음의 result를 팀장으로부터 검토/승인을 받아야한다.
- Implemented and inspected methods and test methods.
- Unit test results, for each method and for the overall sequence.
- Classes checked in by owners, features promoted to the build process and updated by the chief programmer

2005년 5월 이글루스 내 블로그에서.

 

상당히 부담스러울 정도로 나에게 압박을 준다. 책 한권이 마치 1ton의 무게가 나가는 건물이 나를 누르는 느낌이다. 아직 8장밖에 읽지 못했지만, 앞으로 기대가 되는 책으로, 그동안 읽은 것을 잠깐 소개하고자 한다.

1. 재미있는 명세
나에게 부담스러운 부분은 글쓰기이다. 그 중에 가장 부딪히는 부분은 초안, Proposal, comment라 할 수 있겠다. 특히 주석은 공유할 때, 곧바로 화살이 날아오는 부분이라 가장 신경쓰는 부분이기도 하다.
글을 쓸때 항상 명료하고 딱딱하기 쉬우면, 틀리기 쉽고, 다시 내가 읽을 때에도 무슨 말인지 몰라서, 다시 지우고 글을 쓰게 된다. 조엘 온 소프트웨어에서는 재미있게 쓰는 명세를 권하고 있다. 즉, 시나리오를 생각하며, 글을 쓰기를 바라며 칭찬하고 있다.

2. 가혹하리만큼의 솔직함
책에서 얼간이, 바보, 대단한 사람이라고 표현할 정도로 약간의 비꼬는 기술적인 책은 조엘 온 소프트웨어가 처음이다. 상당히 솔직하고, 명세적이고, 순수하리만큼 잘 쓰여진 책이 마음에 든다.

3. 정확한 진단
이 책에 대해서 가장 멋있는 표현을 썼다. 날카로운 진단, 분석 이라는 말도 괜찮을 법 싶다. 2장 기본으로 돌아가기 파트는 상당히 가슴이 뜨거워지는 부분이다. 삽질하는 러시아 페인트공 알고리즘, XML에 대한 정확한 인식, 하향 평준화에 대한 분석은 가슴깊이 반성하는 부분으로서, 앞으로 계속된 프로그래밍 마인드에 상당히 도움이 될 것으로 보인다.


조엘은 대학생이 갖춰야 할 지식 목록 으로, 다음을 꼽았다.
1. 졸업 전에 작문법을 배운다
2. 졸업 전에 C를 배운다.
3. 졸업 전에 미시 경제학을 공부한다.
4. 따분하다고 비 전산 과목을 등한시하지 마라.
5. 프로그래밍 심화과정을 수강하라.
6. 모든 직업이 인도로 넘어간다는 걱정은 그만둬라.
7. 무엇을 하든 여름 인턴과정을 거쳐라

나는 C와 작문을 소홀히 했고, 심화과정을 수강은 했지만, 올바로 적용을 하지 못하는 부분이 있어서, 이 부분을 고치고 공부하는 것이 중요하다고 생각이 든다. 경제학 원론, 민법 총칙을 수강하였으며, 비 전산과목(법학, 종교, 역사, 심리학)에 관심이 많고, 4학년때 임베디드 시스템과 자바 프로그래밍을 해본 것이 그나다 다행이라는 생각이 든다. 하지만, C코딩과 작문법, 전산 심화과정이 가장 약하므로, 열심히 해야겠다는 생각이 든다.

조엘은 소트프웨어팀 평가 테스트를 다음을 들었다.
1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한방에 빌드를 만들어 낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4. 버그 추적시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
6. 일정을 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업 환경에서 일하고 있습니까?
9. 경제적인 범위 내에서 최고의 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?

팀장님의 뜻을 조금씩 조금씩 이해가 가고 있는 거 같다. 팀원들과 공유하고 어떤 비전을 공유하고 싶은지 서서히 감이 잡힌다. 일찍 잡혀야 했는데, 이제서야 잡히다니, 어서 팀원들을 보고 싶다..


참고 : 3장, 4장에 오타 발견했다.