- Allison Randal
- 블로그 : http://allisonrandal.vox.com/
Allison Randal은 오픈 소스 프로젝트인 Parrot의 최고 아키텍트이며 선임 개발자이다. 프로그래머로 25년이 넘게 그녀는 게임에서 언어 분석 도구, e-commerce 웹 사이트, 쇼핑몰, 컴파일러, DB 복제 시스템까지 모든 것을 개발했다. 또한, 언어 설계자, 프로젝트 관리자, 컨퍼런스 주최자, 편집자, 컨설턴트로 일했으며, 오픈 소스 소프트웨어 재단의 회장이기도 했으며, 2권의 책을 집필했고, 기술 출판 회사를 세웠다.
설계는 아름다운 일입니다. 문제 영역과 해결책에 대한 체계적이고 세밀한 표현과 검토는 때로 놀랄 만한 극적인 방법으로 오류와 개선에 대한 기회를 나타냅니다. 명세는 구현에 대한 패턴을 제공하기 때문에 중요합니다. 아키텍처를 통해 사고하는 시간을 갖는 것은 컴포넌트 간의 상호작용에 대한 시각을 가지는 거시적인 차원에서 그리고, 컴포넌트 내의 행위에 대한 시각을 가지는 미시적인 차원에서 중요합니다.
불행히도 추상화시킨 아키텍처에 의해 사로잡혀서 설계 과정에서 이를 이끌어 내기가 쉽지 않습니다. 사실은 명세는 그 자체로 아무런 가치가 없습니다. 소프트웨어 프로젝트의 궁극적인 목적은 제품화된 시스템입니다. 소프트웨어 아키텍트는 이러한 목적에 시각을 항상 유지해야 하며, 설계는 그 자체가 목적이 아니라 목적을 위한 수단이라고만 생각해야 합니다. 빌딩을 더 아름답게 만들기 위해서 물리 법칙을 무시하는 건축 아키텍트는 곧 후회하게 될 것입니다. 실행되는 코드의 목적에 대한 시각을 잃어버린다는 것은 프로젝트에 대한 심각한 문제를 야기시킵니다.
여러분의 비전을 실현하는데 작업하는 팀 멤버에게 가치를 부여하십시오. 그들의 이야기를 들어야 합니다. 그들이 설계에 대해 문제를 가지고 있다면 그들이 옳고 설계가 그르거나 혹은 최소한 불명확하다는 것을 나타내는 기회입니다. 이러한 경우에 어떤 것이 동작하고 어떤 것이 동작되지 않는지를 결정하기 위해 여러분의 팀 멤버들과 같이 작업함으로써 실세계에서의 제약사항을 충족하도록 설계를 수정하는 것은 여러분의 몫입니다. 어떠한 설계도 처음부터 완벽하지 않습니다. 모든 설계는 구현될 때 수정될 필요가 있습니다.
여러분이 만일 프로젝트에서 개발자 역할을 수행한다면, 코드를 작성하는데 보내는 시간에 가치를 부여하고, 아키텍스트로서 여러분의 작업에 방해가 된다고 말하는 다른 사람들의 말을 믿지 마십시오. 거시와 미시적인 차원에 대한 여러분의 비전은 괴물의 심장에 생명을 불어넣는데 소요하는 시간을 통해 매우 구체화될 것입니다.
원문 : 모든 아키텍트가 알아야 하는 97가지 사실 - One line of working code is worth 500 of specification
'Homo Architect > Things Every SW Architect Should Know' 카테고리의 다른 글
성능은 조기에 고려해야 한다. (0) | 2009.04.03 |
---|---|
한번에 딱 맞는 해결책은 없다. (0) | 2009.04.01 |
정량화시켜라 (0) | 2009.03.25 |
당신이 생각한 것보다 더 자주 협상한다. (0) | 2009.03.24 |
모든 것은 궁극적으로 실패하게 된다. (0) | 2009.03.24 |