나름대로의 요약을 했다.

마켓 중심의 개발자가 되는 3가지 조건
1. 시대와 어울리는 개발자야여 한다.
몸과 마음을 늘 열어야 한다.
혁신가 - 선각 수용자 - 전기다수 - 후기 다수 - 지각수용자 중에서 지각수용자에는 포함되지 않도록 해야 한다.

2. 혁신지향의 개발자야 한다.
내가 어디쯤에서 뛰는 것이 좋을지 결정해야 한다.

3. 균형 잡힌 개발자여야 한다.
많은 경험과 학습을 많이해서, 실패의 경험속에서 배워야 한다. 항상 프로젝트가 끝나면, 반드시 평가회(postmortem)을 거치고 이를 기록해야 한다.


소프트웨어 엔지니의 윤리
- 1988년 AC과 IEE는 소프트웨어 공학 윤리 강령과 업무 규범(Software Engineering Code of Ethics and Professional Practive)를 채택했다.

"소프트웨어 엔지니어는 소프트웨어의 분석, 명세, 설계, 개발, 테스팅, 유지보수가 유익하고 존경받는 전무직이 되도록 헌신해야 한다. 공공의 행복, 안전, 번영에 대한 헌신과 더불어...

정도를 걸어라.
나에게는 가장 어려운 일인 듯 싶다. 이 현실세상은 잔머리와 술수의 세계라고 생각해오는 세계관을 가지고 있기 때문에 정도를 걸어라 하는 말에는 이상주의자들의 말이겠거니 하는 생각을 자주 하게 된다.

스티브 맥코넬(Steve McConnell)이 나에게 정직을 가르켜 주었다.
"가치와 옳은 일을 하는데 집중하면 돈을 벌 수 있습니다. 하지만 돈을 버는데 집중하는 오히려 부를 얻을 수 없을 것입니다."

바르게 일하는 것은 무엇을 의마하는 것일까? 의도적인 수련과 함께 요즘 나의 머리를 짓누리는 이 느낌은 말로 설명하기 어려울 정도로 버겹다. 정직하게 코딩한다..

스티브 코넬은 이렇게 말했다. 전형적인 실수를 피하고, 개발 기본에 충실하고, 위험을 사전, 사후관리를 통해 피하며, 일정위주로 개발을 하는 등, 4가지의 전략을 가지고 함께 진행해야 빠르고 좋은 결과를 얻을 수 있다고 한다.

그리고, 그 사람 생각에다가 문득 떠오르는 내 생각을 2가지를 추가하고 싶다.

1. 구현방법이 모를 때는 붙잡고 아는대로 얘기해본다. 해결책이 문득 떠오를지 모른다.
2. 땜빵과 완전 뒤엎고 시작하는 것을 잘 파악한다. 남의 꺼를 쓸때는 특히나.

내 일을 잘해야 겠다..

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 개념들이 컴퓨터 혁명이 이루어지는데 밑바탕이 되었다..

내가 반복되는 실수
1. 빨리 인터페이스에 익숙하지 못해서, 혼자서 끙끙앓다가 문제를 엉뚱하게 푼다는 것
2. 모를 때는 바로 바로 물어보는 것보다, 좀 더 노력해보고, 도저히 못 풀 때 물어본다는 점
3. 내가 닥친 문제에 대해서 올바르게, 이해하기 쉽게 설명을 못한다는 점
4. 게으르다는 점
5. 한번 실수에 대해서는 또 같은 실수를 하는 것
6. 메소드, 프로퍼티의 이름을 잘 짓지 못하는 것

=> 해결 방법
1. 실수에 대해서 네이버 블로그를 이용하여 팁형태로 제공하여 나의 문제를 해결.
2. 모를 때는 그 자리에서 물어봄.
3. 엉뚱하게 풀 것 같으면, 선임자에게 이렇게 구현을 하려고 한다하며, 해결 방법을 같이 모색
4. 자주 코드를 들여다보는 습관을 가짐.

보통 자바 클래스들을 배포할 때에는 JAR로 묶는 경우가 많다.
효과적인 Archive 방법을 이용하여 용량을 크게 줄이는 방법을 제시한 이 논문을 보자.

Jazz는 중복을 제거기 위해서 자바 클래스의 특징을 이해하였다. 모든 Constant pool을 한 공간에 할당하고, Constant pool에 대한 Huffman Table을 생성하며, 비슷한 Method들을 분류하고, 나머지 필드등을 각각 클래스별로 압축하는 방법을 사용하는 File Format을 가지고 있다.

Jazz 압축은 다음과 같은 전략을 가지고 있다.

1. Huffman codes are used for constant pool indices.
2. A unified constant pool is used for all classes in the Jazz archive.
3. Strings, opcodes, and arbitrary data compressed with Zip.
4. Start-step-stop code are used for instruction and string lengths; they are also used to encode the tables of Huffman codes.
5. Redundant constant pool entries are eliminated.

(Start-step-stop 인코딩 방법, 허프만 방식은 공부를 더 해야하는 부분이다. 추후, 이 부분에 대한 공부를 더 할 계획이다.)

이런 Jazz 압축을 통해서, uncompressed JAR 파일에 비해서, 대략 1/4정도로 줄여주는 특징이 있다. compressed JAR에 비해서 약 2배정도의 압축 효율이 있음을 알 수 있다.
메모리 공간차지와 속도에 대한 자료는 전혀 나와 있지 않으나, 논문 저자들은 속도에 큰 오버헤드는 존재하지 않는다고 밝혔다. 그리고, 압축을 풀어 소스를 decoding할때는 예전소스와는 약간 다르게 소스가 생성된다고 하였다. 그리고, 동작은 잘 동작된다고 하였다.

약간의 los가 있지만, 동작의 신뢰성이 보장되며, 효율이 좋은 형태로 저장될 수 있는 Jazz 파일 포맷을 쓰는 것은 참 매력적이다.

1955~60년대에 Licklider는 ARPANET에서 시분할 연구를 진행한 연구자로 유명한 사람이다.
Licklider는 1960년 Man-Computer Symbiosis, 1968년 Taylor와 함께 공저한 The Computer as a Communication Device 를 쓴 것으로 유명하다.
두 편의 논문을 통해서, 컴퓨터의 기능을 좀 더 효과적으로 통신의 수단으로 사용하려 했던 것을 찾으려 했음을 알 수 있었다. Calculating 뿐 아니라, Communication의 Tool로서 보고 아이디어를 내었다.

릭라이더는 매우 친밀하고, 유사한 기관이 함께 엮는 컴퓨터의 인간과의 관계 설정에 대한 비젼을 보여주었다. 그리고, 컴퓨터는 통계적 추론, 의사결정론, 패턴, 게임이론등과 같은 이론등이 컴퓨터에 적용될 것이라고 생각을 했다. 인간과 컴퓨터의 한계인, 스피드, 메모리의 크기와 영속성, 언어와 IO등의 문제를 해결해야 비젼이 성립된다고 Man-Computer Symbiosis에서 의견을 피력했다.

8년의 시간이 지나, 제자 테일러와 함께 The Computer as a Communication Device라는 제목으로 좀 더 그의 컴퓨터에 대한 비젼을 확실히 밝혔다. (상당히 쉬운 논문이라, 중학생이상이면 이해할 수 있다.) 통신 모델로서의 컴퓨터의 기능을 통해서, 서로 멀리 떨어져 있는 경우나, 말로 설명하면서 일어나는 경우에 대해서, 의사소통등에 대한 오해의 소지등을 도식화한 이미지를 통해서 생산성을 높이고, 마치 face to face 의사소통을 가능케 한다고 생각했다.

그리고, 인간 몸체의 신경 명령 체제(뉴런)을 바탕으로 컴퓨터의 쓰임을 그런 모습으로 비교하며, 운영체제와 컴퓨터, 소프트웨어, 프로세서등을 도식화하였다. 그래서, 뉴런과 비슷한 개념으로 Node를 들었으며, 프로세서는 메세지를 분석하고 처리하는 것으로 인식하였다. 이 메시지 프로세서는 서로 통신이 가능하다는 그림을 통해 보여주었다.

data 통신에 대한 상업적인 평가 또한 놓치지 않아 console당, 사람당, 시간당 비용의 affodable을 생각해 보았다.

릭라이더는 컴퓨터는 의사소통을 도와주는 도구로서, 비서의 역할과 비슷한 모습으로, 학습과 경험하는 모델로 생각하였다. 그의 생각이 테일러에게 큰 영향을 주고, 테일러의 영향을 통해서 네트웍이 점차 구성화하고 초기화하는 아이디어가 되었음을 간과할 수 없다.

인터냇을 결국 만들어낸 45년전의 연구자로서, 그 당시에는 획기적인 아이디어를 제공하고, 진보적인 생각을 통해서 많은 후배들을 양성해서 실효성을 거두었다고 생각이 든다.

나는 40~50년후의 컴퓨터의 모습, 임베디드 시스템의 모습을 상상할 수 있을까?

상상을 해본다면, 다음과 같을 것이다.
앞으로 10년후의 모습은 상당히 다를 것이다. 모든 전자부품에서는 블루투스나, 무선랜이 장착된 통신성/Wireless가 강한 제품군들이 나올 것이며, 전력선이 굳이 없어도, Wireless한 전자부품들이 나와 충전/통신이 될 것이다. 특히, 집안의 TV가 홈 네트워크의 결정적인 게이트웨이가 될 것이며, 인공지능의 로봇들이 천천히 현실화되는 모습으로 변해갈 것이다.

릭라이더, 테일러를 통해서 미래에 대한 비젼을 생각해 보는 좋은 시간을 가졌다.

급한 데모를 위해서 간단하게 만든 코드들이 있었다.
지저분하고 도저히 알아먹기 힘든 코드들이기 때문에, 다시 짜는 게 좋을 정도로 지저분했고, 실제 데모 당일날 제대로 동작을 하지 못했다.
어느 정도 시간이 지난 이후에, 사후처리를 확실히 안하고 넘어가다가, 다시 똑같은 데모가 와서, 그 데모를 위해서 하루를 버려야 했다.

즉, 한번 끝난 데모에서 적절하지 마무리를 못했을 경우는 반드시 그 작업을 끝내야 한다. 그래야, 다시 똑같은 데모가 왔을때, 손 털고 구경을 할 수 있다. 마무리를 철저히 하도록 선임자에게 설득을 해야 한다. 코드에 대한 감이 생생히 남아 있을때에...

문서(매뉴얼), 주석없는 코드는 아무런 쓸데 없는 코드이다.
이 두가지가 없으면, 결국은 다시 때려 부수는 일을 하게 마련인 것이다.
혼자서 하게 되면, 이런 것이 필요없으나, 여러 사람들이 공동으로 할 때에는 주석말고, 반드시 문서로 쉽게 매뉴얼로 작성해야 한다. 이는 Macro적 시야는 문서에서, Micro적 시야에서는 주석에서 알 수 있기 때문이다.

적절한 프로세스를 기반으로 가이드라인을 제시하고, 상식적인 혹은 확인할 수 있는 범위내에서, 구성원들이 따라야 할 규칙과 표준을 지키도록 해야 한다.
특히, 코딩 컨벤션, 백업 같은 경우는 반드시 지켜야 한다. 중요한 철학등은 문서화하여 반드시 공유할 수 있도록 해야 한다.

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월 이글루스 내 블로그에서.

 

이 내용은 Hoare라는 사람이 자신이 해온 과업을 평가하며 적은 글이다.
sorting의 한 장르(quicksorting)를 열었으며, Algol 60 Compiler를 설계, 디자인을 하면서, 나름대로 정한 룰을 통해서, 컴파일 이론을 정립시켰다.
Ellliott 503 Mark II 소프트웨어 시스템을 만들다 실패한 일을 통해서 이겨내는 모습이 적혀 있었다.
실패요인, 문제, 그 문제를 인정을 통해서, 앞으로 어떠한 소프트웨어를 만들어야 할지를 분석하였다.
소프트웨어의 가장 큰 문제를 complexity를 꼽았다. 복잡성이 증가하면 즐가할수록 실패할 수 있는 가능성이 높다는 그 진심을 꼭 가슴속에 잘 넣어야 하겠다.