이화식 선생님이 대표로 있는 En-Core 사이트 두번째 퀴즈 문제.

아래와 같은 SAMPLE 테이블이 있다고 하자.

성명	시작일	종료일
홍길동	19961001	19981230
홍길동	19981230	19990605
홍길동	19990605	19991002
홍길동	20000201	20000301
홍길동	20000501	99991231
김동훈	19910106	19910731
김동훈	19910731	19940201
김동훈	19940201	19941021
김동훈	19941021	19961031
김동훈	19990501	20000331
김동훈	20000331	99991231
마동탁	19980103	19980727
마동탁	19980727	20000103
마동탁	20000103	20000601
마동탁	20000601	99991231
.	.	.
.	.	.

어떤 특정 사원은 이력이 중간에 끊어진 경우가 있는데 이러한 끊어진 시작일과 종료일을 추출하고자 한다.

사원별로 끊어진 시작일과 종료일을 추출하면 아래와 같은 결과가 나타난다.

성명	시작일	종료일
홍길동	19991002	20000201
홍길동	20000301	20000501
김동훈	19961031	19990501

●문제 : 위와 같은 결과를 추출할 수 있는 한개의 SQL문을 작성하시오

내가 작성한 답안 :

select a.name, b.end, a.start
from test.quiz2 a, test.quiz2 b
where a.start <> b.end
and a.rowid - 1 = b.rowid
and a.name = b.name
group by b.rowid;

모범답안 :

select name, end_r start_date, start_l end_date
from (select name, sum(decode(no,1,start_dt)) start_l, sum(decode(no,1,end_dt)) end_l,
              sum(decode(no,2,start_dt)) start_r, sum(decode(no,2,end_dt)) end_r
     from (select name, start_dt, end_dt, rownum rn
           from (select name, start_dt, end_dt
                  from quiz2
                 order by name, start_dt, end_dt )) x, copy_t y
     where y.no <= 2
     group by name, decode(no,1,rn,rn+1)
  )
where end_r <> start_l;

모처럼 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.....