모처럼 SQL문을 이용한 Quiz를 풀었다.
그런데 오랜만에 그래서인지 너무 어려웠다.-.-..

문제는 다음과 같다.

COL1	COL2
A	10
C	20
D	30
B	10

위의 테이블을 이용해서 다음과 같은 결과를 만들어 내는 거다.

COL1	COL2	누계
A	10	10
C	20	30
D	30	60
B	10	70

정답은? 다음 Query...

Select b.col1, b.col2, sum(a.col2) as "누계" From quiz_table a, quiz_table b Where a.rowid <= b.rowid Group by b.rowid

정말 간만에 땀을 좀 뺐네..ㅠ.ㅠ

방법론 엑소더스, 그리고 기민함의 시대로

방법론이란 소프트웨어를 만들어 내기 위해 행하는 모는 것을 의미하며
우리가 속한 그룹이 동의한 약속이다.
따라서 적절한 방법론을 가지고 있다면
체계적인 절차와 적합한 도구 및 기법을 사용하여
효율적으로 소프트웨어를 개발할 수 있게 된다.

그러나 방법론이 모든 문제를 해결하려고 시도하는 순간 자기 모순에 빠지게 된다.
그동안 우리는 모든 개발 문제를 해결해 줄 수 있는
보편적인 개발 방법론이 존재할 수 있으리라는 어리석은 생각에 빠지고 말았다.
방법론을 모든 질병을 치료해줄 만병 통치약으로 착각했던 것이다.

애석하게도 이것은 불가능하다.
다시 말해 방법론이 일반화되면 될수록 그 가치는 더욱 하락한다는 뜻이다.
모든 문제를 해결하기 위한 방법론이 만약 있다면,
역설적이게도 그 방법론은 구체적이고 특수한 문제를 해결하는 데에는
거의 도움을 주지 못할 것이다.

"애자일 동맹 선언"의 핵심은 다음의 4가지 문장으로 압축된다.

- 개인과 상호작용이 프로세스와 툴보다 우선이다.
- 동작하는 소프트웨어가 포괄적인 문서보다 우선이다.
- 고객 협력이 계약 협력보다 우선이다.
- 변화에 대한 반응이 계획을 따르는 것보다 우선이다.

변화의 수용과 즉각적인 피드백이 애자일의 모토로 자리잡으면서
개발 방법 역시 많은 변화를 겪게 되었다.

통합 시 실패에 대한 피드백을 받을 수 있는 방법은 무엇인가?
지속적인 통합(Continuous Integration)을 적용하라.

고객에게 원하는 가치를 제공하고 있는지에 대한
피드백을 받을 수 있는 방법은 무엇인가?
최대한 빨리 배포하고 반복(iteration) 주기를 통해 주기적으로 배포하라.

피드백 주기가 길어지는 사전 설계(Big Up-front Design)대신
피드백 주기가 짧은 TDD(Test-Driven Development)를 적용하라.

그리고 리팩토링(Refactoring)을 통해 설계와 코드를 지속적으로 개선함으로써
코드를 항상 최상의 상태로 유지하라.
점진적인 설계 사이클을 도입함으로써
설계와 구현을 독립적인 활동이 아닌 상호 영향을 주고 받는
유기적인 절차로 바라볼 수 있게 되었다.
따라서 경험을 기반으로 한 지속적인 리팩토링을 통해
최적의 소프트웨어의 설계를 얻을 수 있다.

애자일에서 강조하는 또 하나의 핵심 주제는 문서를 통한 의사소통을
가능하면 배제하고 이해관계자 간의 직접적인 대면과 대화를 통해
의사소통의 효율성을 촉진시키라는 것이다.

이것은 DDD를 지탱하는 두 가지 축 중 하나인 UBIQUITOUS LANGUAGE를 구축하기 위한 핵심 조건이다.

분석과 설계의 근본적인 차이는 분석이란 도메인을 이해하는 것인 반면,
설계는 도메인을 지원하는 소프트웨어를 이해하는 것이라는 점이다.
명확하게 이 두 가지는 밀접하게 연결되어 있으며 둘 사이의 경계가 매우 모호해질 때가 많다.
그러나 경계가 뚜렷할 필요는 없다. 유용성보다 순수성을 강조해서는 안 된다.
이론적으로는 분석인 동시에 설계의 특성을 가지는 하이브리드 모델이
절대로 좋은 것이 아니지만 이런 하이브리드한 특징이 가장 좋은 모델을 만든다고 믿는다.

분석 모델과 설계 모델의 하이브리드한 특징이 가장 좋은 모델을 낳는 토양이라면
프로그래밍 언어를 사용하여 구현한 코드가
이 모델을 최대한 반영하는 것이 가장 이상적일 것이다.

만약 설계 모델의 일부가 적용 기술 내에서 구현 불가능하다면 설계 모델을 변경해야 한다.
프로그래밍 과정 동안 설계의 실현 가능성과 정확성이 검증되고 테스트되며
그 결과 잘못된 설계가 수정되거나 새로운 설계로 대체된다.
따라서 프로그래밍은 설계의 한 과정이며 설계는 프로그래밍을 통해 개선된다.

분석/설계/구현이 별개의 것이 아닌 단일 행위라는 사상은
DDD를 지탱하는 두 가지 축 중 하나인 MODLE-DRIVEN DESIGN을 지지하는 핵심 사상이다.
이러한 분석/설계/구현에 대한 시각의 변화는
새로운 주류의 방법론이 출현할 수 있는 토양을 만들어 주었다.

애자일 진영이 바로 그것이다.

DDD (Domain Driven Design)

                                                                   Eternity(http://aeternum.egloos.com/)

분석/설계 미신

소프트웨어 개발 분야는 다른 성숙한 분야에 비해 상대적으로 그 역사가 짧기 때문에 다양한 분야로부터 메타포를 받아 들였다. 가장 대표적인 것이 제조(manufacturing)와 건축(architecture)이며 두 분야는 소프트웨어 개발에 필요한 어휘와 개념을 제공하기도 했지만 개발 프로세스와 사람이라는 관점에서 부정적인 영향을 끼치기도 했다.

제조 메타포에서 숙련된 엔지니어는 UML과 같은 표기법을 사용해서 구현에 필요한 설계 도면을 작성하고 덜 숙련된 노동자는 기계적으로 다이어그램에 명시된 요소를 프로그램 명령문으로 변환한다. 프로그래밍이란 설계 문서를 프로그램으로 변환시키는 것이므로 이 과정에서 오류를 줄이기 위해 자동으로 코드를 생성해주는 기법을 적용시키는 겂이 효과적이다. 과연 그럴까?

제조 메타포를 기반으로 한 역할 분리는 근본적으로 두 가지 오류를 범하고 있다. 첫 번째 오류는 설계자와 구현자 간의 차이를 고려하지 않고 기계적으로 설계를 구현으로 변환할 수 있다는 믿음을 전제로 한다는 점이다. 유사한 경험과 경력을 가진 사람들 간에도 커뮤니케이션이 불완전해지는 경우를 자주 보게 된다. 하물며 서로 다른 역할과 경험을 기반으로 하는 두 계층 간에 다이어그램과 문서 중심의 커뮤니케이션이 가능하다는 근거 없는 믿음은 어디에서 기인한 것일까?

이는 설계자가 코더보다 똑똑하거나 숙련된 사람이어야 하는가에 대한 문제가 아니라, 그들이 같은 경험과 기본 단위를 가지고 있는가에 대한 문제이다.

소프트웨어 개발은 팀원들의 머리에서 일어난다. 사람들을 특정 활동에 전문화시킴으로써 간단한 프로젝트의 딜리버리도 여러 경로를 통해야 한다. 각 경로는 실수와 결함에의 잠재성을 갖고 있는 값비싼 과정이다.

제조 메타포의 두 번째 오류는 구현 전에 설계를 완성시키는 것이 가능하다고 가정하는 점이다.
그러나 실제로는 개략적인 설계를 구현으로 옮기는 도중에 전체 구조에 대한 가장 중요한 통찰을 얻게 된다. 구현 전에 대략적인 설계를 동결시키는 방식은 구현으로부터 얻게 되는 피드백을 원천적으로 차단하는 역효과를 가져온다. 따라서 UML과 같은 표기법을 사용해서 설계를 동결시키고 이를 구현자에게 전달해서 프로그램을 구현하도록 하거나 코드를 생성하는 아이디어는 소프트웨어 개발에는 적합하지 않다. (즉 구현과 분리된 설계는 의미가 없다.)

우리는 분석 모델, 설계 모델, 구현 모델이 서로 달라야 한다는 오랜 미신 속에 살아 왔다. 이론적으로 분석 모델은 해결 방법에 대한 언급 없이 문제 도메인을 설명하는 모델이다.

분석 모델이 완성되면 이를 바탕으로 기술적인 관점에서 솔루션을 서술하는 설계 모델이 만들어 진다. 프로그래머는 이렇게 만들어진 청사진을 프로그래밍 언어를 사용하여 컴퓨터가 이해할 수 있는 명령어로 변환한다.

그러나 분석 모델, 설계 모델, 구현 모델을 명확하게 구분하는 것은 가능하지도 않을 뿐만 아니라 오히려 소프트웨어의 품질에 악영향을 미친다. 짂실로 우리가 원하는 것은 소프트웨어의 영혼에 영광을 안겨줄 분석과 설계와 구현의 삼위일체론이다.

                                                                                    -- continue.....

1. Visual C++, C# and Visual Basic 및 윈도우즈 .Net에 관련된 소스코드들이 공유되는 대표적인 사이트
http://www.codeguru.com/

2. 인터넷 상의 돌아다니는 코드들을 모아놓은 사이트
http://www.planet-source-code.com/

3. Codeguru와 더불어 많은 소스코드와 튜토리얼을 제공하고 있는 사이트
http://www.codeproject.com/

4. 전세계를 석권하고 있는 구글에서 제공하는 오픈소스 사이트
http://code.google.com/
http://code.google.com/projects.html

5. C++, Visual Basic, ASP, sourcecode, programming, javascript, code, delphi, ... 일반적인 조그만 코드들이 많이 모여있음.
http://www.programmersheaven.com/

6. OSI에 대한 정보가 나와 있는 사이트
http://www.opensource.org/

7. 프로젝트 단위의 소스코드를 오픈해주는 세계에서 가장 유명한 사이트
http://sourceforge.net/index.php

8. 자바스크립트가 많이 오픈되어 있는 사이트
http://javascript.internet.com/

9. Gamelan.com is a leading site for Java articles, tutorials, news, discussions, and other resources. ...
http://www.developer.com/open/

10. 세계적인 오픈소스에 대한 라이센스 정책을 세우는 GNU 사이트
http://www.gnu.org/copyleft/gpl.html

11. 세계적인 모바일 업체인 노키아에서 공유하고 있는 소스코드 사이트
http://opensource.nokia.com/projects/S60browser/

12. 애플컴퓨터를 위한 오픈소스 사이트
http://developer.apple.com/opensource/index.html

13. 영국의 개발자들의 소스코드 공유 커뮤니티 사이트
http://www.developerfusion.co.uk/

14. 한국의 대표적인 VS 개발자 공유 사이트
http://www.devpia.com/

15. 개발자 포럼 및 소스공유사이트, BREW에 대한 정보 제공을 잘해주고 있는 사이트
http://www.developer.com/ws/brew/