이를테면 나는 내일 이시간에 내가 무엇을 하고 있을지 약 80%의 확률로 맞출수 있다고 하자. 아마도 컴퓨터 앞에서 자판을 투닥거리고 있을 것이다.

그럼 내가 1년후에 무엇을 하고 있을지 맞출수 있는 확률은 얼마정도일까? 간단한 확률의 문제이다. 다음날 무슨 일을 할지가 독립변수라면 1년후에 내가 무엇을 하고 있을지 맞출 확률도 80%확률이어야 한다. 하지만 다음날 무슨 일을 할지는 독립변수가 아니고 내일모래 무슨일을 할지는 내일 무슨일을 할지에 영향을 받는다. 즉 내일 예상과 다른 일이 일어날 확률이 20%이고 그중의 반은 다음 날들의 일에 영향을 미친다고 하자. 그럴경우 내가 1년후에 무슨일을 하고 있을지 맞출수 있는 확률은 고작 2%에 불과하다.(0.9^365) 그리고 이것도 내일 무슨 일을 하고 있을지 맞출수 있는 확률이 80%라는 아주 낙관적인 기대에서 출발한 것을 잊지 말자.

이런걸 흔히 불확실성의 연속이라고 하는데 그래서 프로젝트에서도 가능하면 3월 이상의 일은 예측이라기 보다 예언이라고 해두는게 좋다. 컨설팅의 비밀이라는 책에서 나오는 의미없는 차이 + 의미없는 차이 + 의미없는 차이.... 는 의미 있는 차이라고 하는 예와 비슷하다. 

'Framework > 아키텍쳐 일반' 카테고리의 다른 글

호출의 빈도  (0) 2009.07.08
한줄짜리 함수  (0) 2009.07.06
패키지의 설계 원칙  (0) 2009.06.08
양화 구축  (2) 2009.06.08
AOP  (0) 2009.06.08
Posted by bleujin
Framework/Another Lore2009. 6. 11. 20:19

AL 개발하면서... 코드가 막힐때면 책을 읽곤 하는데..
"드리밍 인 코드"에 소개된 오픈소스 "챈들러" 프로젝트의 백엔드 저장소와 AL이 상당히 비슷하다는 걸 알았다.

AL은 Node와 Node의 Link로 정보를 저장하는데.
챈들러는 <this> <has-relationship-with> <that> 형태로 저장하는 RDF(Resource Description Framework)를 사용하고 있었다. 챈들러라는 프로젝트는 2003년쯤에 우연히 관련자료를 찾다가 알게된 프로젝트인데 당시에는 개인정보관리 시스템 정도로  알려져 있었지만 오픈된 내용이 거의 없어서 곧 잊혀졌다. (고작해야 1시간 정도 살펴본것뿐이긴 하지만 이걸 기억하는건 당시 프렌즈라는 미국 드라마를 아주 좋아했기 때문이다. 물론 챈들러 프로젝트의 챈들러는 프렌즈의 챈들러가 아니다. )


RDF(이런 용어가 존재한다는 것도 처음 알았다)는 주로 학구적인 성격이 강하기 때문에 구현체가 많지 않지만.
Phthon 구현체인 ZODB는 아직 자세히 살펴보진 않았지만 AL의 현재의 모습과 아주 비슷하다 -ㅅ-..

혼자 하는 AL이니 머 수십명 이상이 하는 ZODB나 챈들러와는
세부적인 모습은 다르지만.. 목적지가 같다..이런...

본래 오픈소스에서 비슷한 걸 발견하면 기뻐해야 겠지만..
첫번째.. 거의 실패 혹은 잊혀진 프로젝트라는 것이고..
두번째.. 파이썬으로 되어 있어서 그들의 경험으로부터 배우기가 쉽지 않기 때문이다. 췟.




'Framework > Another Lore' 카테고리의 다른 글

레이어의 속도  (0) 2009.07.05
read & write  (0) 2009.06.25
AL : Permission  (1) 2009.04.30
AL : 현재의 난제들  (0) 2009.04.30
AL : Workspace  (0) 2009.04.28
Posted by bleujin

패키지의 설계 원칙은 클래스의 설계원칙과 기본적인면에서 큰 차이가 없다. 현재까지 잘 알려진 설계 원리들은 다음과 같다.


CRP (Common Reuse Principle) - 패키지의 클래스들은 전체적으로 재사용됨.

CCP (Common Closure Principle) - 패키지의 클래스들은 동일한 유형의 변경에 대해서 닫혀있어야 함. 만일 클래스가 변경되어야 한다면 패키지의 모든 클래스들은 마찬가지로 변경되어야 함.

SOC (Separation Of Concerns) - 여러 관심사를 혼합시키지 마라.

세개 모두 High Cohension에 관한 얘기이다. 하나의 패키지는 하나의 클래스와 마찬가지로 Single Responsibility를 가져야 한다.



ADP (Acyclic Dependencies Principle) - 패키지들 간의 의존성 구조는 비순환구조이어야 함. A패키지의 일부 클래스가 B패키지를 참조하고 B패키지의 일부 클래스가 C패키지를 참조하고 C패키지의 일부 클래스가 A 패키지를 참조하는 경우를 순환 패키지 구조라고 하는데

SDP (Stable Dependencies Principle) - 패키지는 최소한 그 자체로 안정적인 패키지들에만 의존해야 함. 를 통해 예방할 수 있다. concrete 클래스가 추상클래스 혹은 인터페이스에 의존하는 것처럼 패키지도 좀더 안정적이고 추상적인 패키지에 의존해야 한다. 예컨데 java의 패키지나 apache의 stable project, 일반적인 프레임워크는 상대적으로 더 안정적이다.


SAP (Stable Abstractions Principle) - 패키지가 점점 더 안정될수록 점점 더 추상화되어야 함. 즉 SDP에 의거해 더 추상화된 패키지에 의존해야 한다는 말로 설명할 수있다.



패키지를 만들때 흔히 하는 잘못들은 A Interface의 구현클래스를 모두 하나의 패키지에 넣어야 한다고 생각하는 것이다. 물론 그럴 경우도 있지만 꼭 그래야 할 필요는 없다.

두번째로 클래스의 이름이 모든 패키지에 대해 전역으로 유니크해야 한다고 생각해서 매우 긴 클래스 이름을 만드는 경우이다. 역시 이는 늑대를 피하다가 호랑이를 만나는 실수가 될 수 있다.  

'Framework > 아키텍쳐 일반' 카테고리의 다른 글

한줄짜리 함수  (0) 2009.07.06
예언?  (0) 2009.06.12
양화 구축  (2) 2009.06.08
AOP  (0) 2009.06.08
Self-Signed Java Applets  (0) 2009.06.01
Posted by bleujin