소프트웨어 장인정신

Software Engineering

소프트웨어 엔지니어링의 이해

  • 컴퓨터하드웨어와 소프트웨어를 개발하는 매우 큰프로젝트가 있다면, 소프트웨어 엔지니어링에 의존해야 한다.
  • 오늘날의 소프트웨어 고객은 과거의 국방성뿐만이 아니다. 사용,공개소프트웨어, 어플리케이션패키지,게임소프트의 출현은 고전적인 소프트웨어 엔지니어링 접근방식으로부터 멀어지게 한다.
  • 일단 우리가 소프트웨어 개발 방법을 재평가하기 시작하면, 소프트웨어 개발이 기계적활동이 아님이 명백해진다
    • 그것을 공학으로 간주하는 것은 실수이다
    • 그대신에, 우리는 더 좋은 비유를 필요로한다: 소프트웨어장인정신.

소프트웨어 엔지니어링에 관한 문제

  • 체계적이고 훈련되고 측정가능한 접근방식의 공학적인 방법에 가깝다.
  • 프로젝트의 결함 잠재성을 말하기보단 개발자의 결함잠재성에 관해서 말해야 한다.
  • 언어를 가지고 무엇인가를 정확하고 분명하게 표현한다는 것은 실제적으로 불가능하다.( 대화의 중요성! )
    • 무엇이 소프트웨어 엔지니어링에 대한 대안인가?
    • 일단 소프트웨어 개발의 진정한 본질을 이해해야 한다.

소프트웨어 개발의 이해

  • 프로젝트가 늦어진다고 더 많은 사람을 투입하는것은 소프트웨어 개발의 본질을 진정으로 이해하지 못하고 있는 것이다.
  • 소프트웨어 개발하는 과정은, 분명하게 이해하고 그 이해를 소프트웨어에 구체화하는 과정이다.
    • 예외적으로 특출한 디자인 담당자는 그들의 뛰어난 애플리케이션 도메인 지식으로 해서 특별히 앞서 있었다.
  • 노동의 분할은 소프트웨어 개발에 효과가 있는가?
    • 소프트웨어 개발은, 개발자가 요건, 디자인과 소스코드에 대해 깊이 이해하고 있을때, 가장 잘 진행된다.
  • 한가지 사이즈가 모두에게 맞는 것은 아니다.
    • 게임과 운영체제의 개발프로세스는 다르다.
    • Tom DeMacro
 
하나의 방법이 심지어 두개의 서로 다른 프로젝트를 커버하려는 생각은 매우 의심스럽다. 프로젝트간의 차이는 유사성보다 훨씬 더 중요하다.
  
  • 소프트웨어 엔지니어링은 매우 제한된 적용 가능성 때문에 실패한 것이다.

소프트웨어 엔지니어링보다 더 좋은 비유를 발견하는것

  • eXtrem programmong: 프로젝트 사람들을 팀으로 함께 일하도록 만든다는것이다.
  • 소프트웨어 개발은 예술과 과학과 공학의 창조적 혼합으로 본다.
  • 소프트웨어 장인정신이라는 비유는 개발자가 그들장인적 기술의 모든측면을 이해하게끔 해준디. 측정가능하고 기계적인 측면뿐만아니라 예술적이고 미적인 측면까지.

소프트웨어 장인정신(Software Craftsmanship)

  • 소프트웨어 엔지니어링에서 가장 큰 결점은 소프트웨어 개발 프로세슽의 중앙에 사람을 놓지 않는다는 것이다.
  • 요건과 디자인사이의 갭은 숙려된 개발자만이 효과적으로 이어줄 수 있다.
  • 지식을 갖는다는 것은 그 지식을 적용하는 능력과는 다른것이다. 그 적용기술과 실제적인 능력이 있는 곳에 바로 장인정신이 있다.

사람을 소프트웨어 개발에 다시 참여시키는 것

  • 장인정신은 소프트웨어 개발을 더 잘 하려는 것이다.
    • 그 자신의 독창적인 능력과 재능에 프로세스를 맞출 것을 권장한다. 중요한것은 결과로서의 산출물이지, 그것이 이루어졌던 프로세스가 아니라는 것이다.-> 엔니어링 세계에서는 계승자를 훈련시킨다는 생각이 표준프로세스로부터 불필요한 이탈을 가져오는것으로 생각한다.
  • 장인정신은 개발자가 훌흉한 소프트웨어를 만들도록 권장한다
    • ThePragmaticProgrammer는 소프트웨어를 개발하는 사람, 그리고 그들의 태터와 기술에 초점을 둔다. ThePragmticProgrammer는 그것으 잘표현한다:프로그래밍은 장인적 기술이다
  • 장인적 손재주의 요청**
    • 최고의 프로세스이더라도, 관련된 사람들이 그 프로세스를 실행시키는 데 필요한 기술을 갖고 있지 못한면, 실패한다. 반대로 정말로 훌륭한 개발자는 어떤 프로세스라도 잘 기능하게 할것이다.
    • 중요한것은 소프트웨어개발을 위해 일하는 사람들은 그들이 가진 장인적 기술의 숙련된 실습자라는것과, 그들의 기술을 연마하고 개선하기 위해 끊임없이 일하고 있다는 것이다.

장인정신은 자격증을 받는것과는 반대의 개념이다

  • 소프트웨어 장인정신은 일을 잘 끝내는 것에 있다.
  • 소프트웨어 장인은 그들이 만들어내 어플리케이션과 시스템에 근거하여 평판을 쌓는다. 이는 공인된(licensed) 소프트웨어 엔지니어의 개념과 정확이 정반대에 있다.
  • 장인정신은 인간적인 것이다
    • 사람들은 개인적인 추천에 의거하여 장인을 선택한다. 자격이 나 증명서를 요구하는 것이 아니라, 오히려 각각의 사람을 고유의 능력과 힘을 가진 하나의 개인으로 대우한다.
  • 동료들간의 인정과 추천이 더 좋은 소프트웨어를 위한 길이다.
    • 한 개발자가 다른 개발자를 추천할때, 그 사람은 그 자신의 평판을 걸고 그러는 것이다.
  • 자격증은 환상이다.
    • 자격증개념은 모든 소프트웨어 전문가가 알 필요가 있는 핵심적인 ‘지식의 실체’가 존재한다고 주장한다.
    • 필요한 전제 조건이 적당하지 않기때문에, 자격증은 또한 애플리케이션 개발에 잘 어울리지 않는다.
프로젝트가 빌딩검사인에 의해 종료될 수 있는 도시 공학에서화는 달리, 몇몇 잘못된 일 때문에 소프트웨어 프로젝트를 종료시킨다는 것은 불가능하다. 
안전 필수의 시스템 프로젝트에서, 품질 관리자는 개발을 중단 시킬 수 있다. 그러나 애플리케이션 개발에 있어서, 그에 상응하는 어떤 사람도 몇명 
잘못된 일 때문에 프로젝트를 중단시킬 권한을 갖고 있지는 못하다.
 
  • 어떤 면에서는 소프트웨어 개발은 Chanllenger호 참사의 조사에서 밝혀진 문제들과 유사하다.
"성공적인 기술을 위해서, 실제가 공공관계보다 더 우선해야 한다. 왜냐하면 진실이 외면되어서는 안 되기 때문이다"
  • 자격증은 잘못된 문제를 풀기 위한 시도이다
    • 자격증이 공하글 위해서는 제 기능을 할 수도 있다. 왜냐하면 한 공이된 엔지니어는 훌륭한 관례를 사용하면 무엇인가를 만들었음을 증명할 수 있기 때문이다. 그러나 소프트웨어를 위해서는 그렇지 않다.
    • 증명서는 건물이나 다른 기계적인 구조물에 적용될 수 잇는데, 그것은 그러한 구조물들이 잘 알려진 속성을 가진 표준물질과 디자인을 갖고 있기 때문이다. 그것들은 또한 소프트웨어보다 훨씬 덜 복잡하다.
    • 그래서 장인정신은 자격증보다 더 좋은 선택이다. 그것을 통해 우리는 많은 결함을 만들 필요도, 그결함을 다시 없애기 위해 또 돈을 투자할 필요도 없다.
  • 장인정신은 개인에게 초점을 둔다.
    • 소프트웨어 개발자가 좋은 개발자가 될 수 잇는지에 초점을 맞추어야 한다.
  • 소프트웨어 개발의 문제는 사람이 적다는 것에 있는 것이 아니라 만다는 것에 있다.
    • 특정 기술력을 가진 좋은 개발자는 부족하다
    • 학위를 위해 공부하는 것 대신에 훌륭한 개발자의 도제가 된다며느 아마 결과는 훨씬 더 좋을 것이다.
    • 특정 자격증이나 학위를 주는곳으 많아 졌으나 진정 변한건 아무것도 없었다.
개인적 평판이나 개인적 추천이 소프트웨어 장인정신이 제공하는 대안이다.
  • 많은 소프트웨어 개발자들이 오픈 소스 시스템과 어플리케이션에의 공헌에 의거하여 공적 평판을 쌓아왔다.

소프트웨어 장인정신의 함축된 의미

  • 우리는 대장장이와 같을 필요가 있다. 공학이 우리에게 주는 여분의 툴을 사용하고, 과학으로 얻어진 지식을 이용하여 그렇게 될필요가 있다.
    • 무엇보다도 소프트웨어 개발에 다시 자부심을 가질 필요가 있다

장인정신이 시스템의 사용자에게 미치는 영향

  • 그들의 일이 인정받도 있음을 알게 됨으로써, 그들의 질문이나 제기되는 문제들을 처리할 에너지를 얻게된다.
  • 소프트웨어 장인정신이 가능한것은 소프트웨어가 복사하기 쉽기 때문이다.
    • 소프트웨어 장인정신이 타당한 선택일 수 있는 이유는 ,소프트웨어가 대량생산에 많은 투자를 할 필요가 없기때문이다.
    • ‘Borland Software Craftsmanship’연구가 보여준것처럼, 작은 팀이 훌륭한 소프트웨어를 생산할 수 있다.
    • ‘그정도면 괜찮은’ 소프트웨어는 기능,디리버리 스케쥴, 그리고 품질을 틀이드오프하는 소프트웨어 엔지니어링 개념으로부터 나온 애플리케이션이다.
  • 장인은 그들의 사용자와 남다른 관계를 가진다
 폭넓은 사용자 층을 만족시킬 제품을 만들기 위해서는, 가능한 한 대부분의 사람들에게 사용될
 폭넓은 기능을 만들 로직에 따르게 된다. 그러나 그러한 로직은 잘못된 것이다. 여러분이 오히려
 한사람만을 위해 디자인한다면, 더 크게 성공할 것이다.
 
  • 이는 그정도면 괜찮은 소프트웨어 접근 방식에 대한 대안으로 상욜할수 있다. 즉, 소수 사용자와의 친밀한 작업 관계를 발전시키고, 그 사용자들을 위한 최고의 애플리케이션을 만들어라. 그 사용자들을 최고로 만족시켜라. 그러면 그 애플리케이션은 대량생산 시장에 릴리스될 준비가 된것이다.
  • 훌륭한 소프트웨어는 서명될 가치가 있다.
    • 소프트웨어 장인정신은 책임과 자부심을 소프트웨어 개발 프로세스에 다시 돌려놓는것이다
    • 우리는 다시 “작업에 서명하는 것”을 시작해야 한다. 우리는 작업에 서명하는 것은 개발자와 사용자 간의 연결을 만드는 것이다.
    • 서명은 우리가 그일을 만들었음을 말하는 것이고, 사용 중 생기는 문제에 대해 책임이 있다는 것을 선언하는 것이다.
    • 작업에 서명한다는 것은 상황을 변화시킨다.
우리는 우리가 위협받고 있다고는 생각하지 않았다. 그것은 우리가 급여 시스템에 대해 책음을 떠맡게 되는 자연스러운 과정이었다.
  • 장인은 그들의 일에 책임진다
책임진다는 생각을 불편해 한다. 책임지는것은 쉬운일이 아니다. 그것은 개발자와 사용자간에 신뢰를 쌓아가는 한 과정이다. 평판이 쌓아감에 따라 존경을  얻게된다. 실수가 있게 되면 그결과에 대해 책임을 진다는 것. 사실 모든 사람이 그런 유형의 책임에 대해 준비가 되어 있지는 않다. 그겨우의 사람은 에러의 결과가 덜 심각한 분야에서 일해야 할 것이다.

고객과 장인과의 관계

  • 현실적인 딜리버리 날짜를 설정하는 것
    • 장인의 개인적 평판!
  • 그 정도면 괜찮은 소프트웨어의 오류
    • 가장 낮은 입찰에 근거해 개발자를 선택하지 말라
    • 나쁜 의뢰인은 좋은 개발자를 불러오는데 있어서 어려움을 가질 것이다. 개발자는 프로젝트를 수학하기전에 고객의 평판을 신중하게 알아본다. 그들의 평판은 성공적인 프로젝트를 통해 쌓여지기 때문이다.
  • 개발자의 생산성의 차이
    • 소프트웨어 장인정신은 작은 팀에서 1년 미만의 애플리케이션 딜리버리를 위해 일하는 재능있는 장인을 활용한다.
    • 좋은 개발자로 구성된 작은 팀을 고용하라
    • 훌륭한 개발자는 정말 어떤 가치가 잇는가?

장인을 관리하는것

  • 소프트웨어 장인은 고용된 일꾼이 아니다
    • 개발자는 그들이 일하는 동안 생각하는 것으로 해서 지불받는다.
    • 장인은 무엇을 하고 언제 그것을 해야 하는지에 관한 상세한 지시문을 필요로 하지 않는다. 그 대신에 그들은 그들의 일을 조직의 나머지 다른 사람들의 일과 조화시키고, 필요한 리소스를 스케쥴하고, 기능 개선이나 변경이 필요한 애플리케이션을 식별하기 위해, 관리자를 필요로한다.
    • 장인은 명령이나 통제 관리자가 아니라, 개발자와 사용자와 고객 사이의 관계를 도와주는 데에 기술이 있는 관리자를 필요로 한다
  • 좋은 개발자는 그들의 관리자보다 더 가치 있다.
  • 소프트웨어 장인은 그들의 관리자와 특별한 관계를 가진다
    • 관리자는 개발자를 지식 노동자로 보아야 한다 일을하는 방법에 관한 지식은 관리자가 아니라 개발자의 머리속에 있다. 모든것을 통제하고자하는 현장관리자들의 날들은 얼마 남지 않았다.
  • 훌륭한 개발자를 관리하는 것은 즐거움이면 특권이다
    • 우선 먼저 그들은, 비록 프로젝트가 중요하지만, 정말로 중요한 것이 팀과 그들이 관리하는 어플리케이션의 장기적인 건전성 이라는 것을안다
    • 건전한 팀이 훌륭한 소프트웨어를 생산한다는 것이다!
  • 문제의 본질을 확실히 이해하라, 간단하고 쉬운 솔류션을 찾기위해 충분히 그리고 열심히 생각하라, 그리고 솔류션을 찾으면 작은규모로 먼저 테스트하라.
  • 소프트웨어 장인을 관리하는 것은 다른 것과는 다르다
    • 장인은 무엇인가를 만들고 나서, 그것에 대해 책임을 부인하지 않는다. 관리자는 유지보수 문제를 다룰 필요가 없는데, 그것은 일단 장인은 무엇인가를 만들고 나면 그것을 돌보고, 실력 있는 계승자에게 그것을 넘겨줄 때까지 개선시키기 때문이다.
    • 이러한 프로세스가 효과가 있는것은, 만든 사람의 평판이 그 만들어진 것과 밀접하게 연결되어 있기 때문이다. ( GNU리눅스 / 오픈소스 )

소프트웨어 장인이 되는 것

  • 소프트웨어 장인정신은 편협한 전문화를 거절한다.
    • 소프트웨어 장인정신은 소프트웨어 엔지니어링이 개발자에 강요시켰던 편협한 역할의 전문화를 거절하고, 그대신 처음부터 끝까지 일의전체를 해낼수 있는 진정한 장인을 높히 평가한다
  • 장인정신은 헌신을 요구한다
    • 소프트웨어 장인정신은 지식의 실체라기 보다는 사고방식이면 태도이다.
    • 기술의 완성은 지식의 제한된 실체에 의해 정의되는 것이 아니다. 그것은 오리혀 고품질의 안정된 어플리케이션을 딜리버리하는 것에 따른, 한사람의 평판을 인식하는것에 의해 정이된다.
    • 장인기술의 진정한 완성과 연관된 특징중의 하는 겸손이다. 마스터장인은 항상 배우고자 하고, 그들 자신의 실수를 인정할 줄 안다. 이 두가지 특징이 소프트웨어 개발에 있어서 필수적이다. 모든것은 너무 빨리 변하고 실수하는것은 그만큼 쉽기에 더욱 그렇다.

장인기술을 마스터 하는것

  • 그 사람은 소프트웨어 개발의 장인기술을 위한 열정을 주변의 동료에게 감염시키는가?
  • 기술의 완성에는 시간이 걸린다
    • 마스터 소프트웨어 장인이 되는것은 일련의 성공적이고 안정되고 품질 좋은 애플리케이션, 즉 사용자와 고객과 다른 개발자들에 의해 잘 알려진 애플리케이션을 만드는것에 의해 성취된다.
  • 장인기술의 완성은 그 장인기술을 전수할 책임을내포한다.
    • 장인은 도제와 중간 장인을 선택한다

도제 개발자

  • 대학학위는 학생들의 학구적 삶을 우해 있지, 실제프로젝트를 위해 잇는 것은 아니다.
  • 도제 생활은 장인기술을 배우는 교육이나 훈련보다 더 효과적이다.
  • 도제 생활은 가르치는 것이라기 보다는 배우는 것에 관한 것이다.
  • 도제는 값싼 노동이 아니다
    • 도제를 중간장인의 수준까지 끌어올리면…
    • 중간장인은 도제로부터 배운다.

중간 장인 개발자

  • 중간장인은 소프트웨어 장인정신에있어서 하나의 핵심 역할을 한다
    • 장인을 대신하여 도제에게 많은 훈련과 지도를 제공

소프트웨어 엔지니어링의 재평가

소프트웨어 엔지니어링 프로젝트

  • 소프트웨어 엔지니어링은 큰 시스템 프로젝트를 위해 디자인된다.
  • 전문화는 소프트웨어 엔지니어에게 당연한 것이다.
  • 소프트웨어 엔지니어링 프로젝트는 연전히 Waterfall프로세스를 상용한다.
  • 소프트웨어 엔지니어링 프로젝트에 있어서 소프트웨어 개발은, 그것이 더 빨리 개발되더라고 하드웨어가 계속해서 빠르게 바뀌고 있으면 아무런 도움도 되지 않는다. 이중대한 차이가 소프트웨어 장인전신과의 차이를 설명한다. 장인정신은 알려진 사용자에게 알려진 하드웨어 위에서 어플리케이션을 디릴버리하는 것에 초점이 마주어져 있다. 반면에 소프트웨어 엔지니어링은 하드웨어/소프트웨어 조합을 고객에 딜리버리하기 위한 훨씬 더 큰 프로젝트의 작은 일부를 나타낸다.
  • Agile Methodology는 쳬계적인 소프트웨어 엔지니러이 프로세스에 대한 대안이다..
    • AgileAlliance는 소프트웨어 엔지니어링 접근방식의 알려진 지혜, 즉 소프트웨어 개발을 위한 유일한 방법은 프로세스와 문서화를 통해서라고 알려진 점에 반대하고자 형성되었다.

소프트웨어 엔지니어링 비유의 위험

  • 낮은 예산으로 소프트웨어 엔지니어링을 실행할 수 없다.
  • 견적을 믿어라 – 소프트웨어 엔지니어링 프로젝트는 많은 시간이 걸린다
    • 기계적인 세계에서는 일이 제치되면 열심히일하게할수 있고, 이전력은 성공한다
압력을 적용하는 최고의 방법은 작업자들에게 한계 목표를 주는 것이다. 그러나 이런 생각은 소프트웨어 개발과 관련해서는 완전히 어리석은 짓이다.
  • 오랜기간동안의 재상용은 위험하다
  • 실제로 소프트웨어 개발의 가장 좋은 방법은 점진적이고 진화적인 방법이다.

소프트웨어 엔지니어링으로부터 배우는 것

  • 크기와 복잡성
    • 소프트웨어 엔지니어링 프로젝트에서 프로그래머 팀들의 팀장식 접근방식. ( 소프트웨어 장인정신과 유사 )
  • 요건은 바뀌기 마련이다.
  • 문서는 항상 시대에 뒤떨어지고 틀리다
  • 점진적 개발을 통해 위험을 관리하라
  • 정확한 예측은 매우 값비싼 일이다.
    • 소프트웨어 엔지니어링으로 부터의마지막 교훈은 팀이요건정의와 그에 따른 최종적인 디자인을 위해 많은 일을 해야 한다는 것이다.
    • 고객과 관리자는 프로젝트 변수를 바꾸는 것 없이도 더 낮은 견적을 협상하는 것이 가능할 것이라고 믿는 것 같다.
    • 단지 프로젝트를 얻기 위해서 견적을 깎음으로써 평판을 날려버리는 것은 절대로 가치 있는 일이 아니다.

월요일 아침에 해야 하는 것

겸험 – 프로젝트 성공의 최상의 지표

  • 평판에 의거하여 장인을 선택하라
  • 만일 추천된 사람의 이름을 받으면, 여러분이 알고 잇는 장인으로 하여금 세 사람 모두를 위해 회의를 소집하도록 하라.
  • 소프트웨어 장인이 개발 팀의 나머지를 고르게 하라
  • 소프트웨어 장인정신은 점진적 개발 프로세스를 의미한다
  • 사용자가 개발자에게 피드백을 주지 않고 이틀 이상 계속 일하게 하는 것은 큰 실수이다. 이와 유사하게 개발자가 사용자에게 이틀 이상 무엇인가를 보여주는 것을 연기하는 것도 큰실수 이다.
  • 가능한 한 빨리 팀 선택에 있어서의 실수를 고쳐라
  • 가능하다면 출혈이 너무 심한 기술은 피하라
    • 팀에게 새로운 모든 기술이 출혈이 심한 기술이다.
  • 겸험의 가치를 평가하는 것 – 그들을 가치있게 평가한다는 것을 보여주어야 한다.
    • 그 개인에게 충분한 급여를 지급하라.
    • 일단 개발자가 그 최고치에 도달하면, 앞으로 나아갈수 잇는 유일한 방법은 다른 조직으로 배를 옮겨 타는 것이다. 조직의 정책은 숙련되고 경험있는 개발자들의 보유를 매우어렵게 만든다. 생상적인 개발자들을 효과적으로 봉상하지 못하기 때문이다.
  • 평균개발자에게 초과 지불하는 것을 멈추어라. 단지 2년의 경험을 가진 개발자가 연간 40,000달러-60,000달러의 가치가 있다고는 할 수 없다.
  • 팀원으로 하여금, 그들이 특정 프로젝트를 완료하기 위해 고용된 것이 아니라, 비지니스 요건을 충족하는 어플리케이션의 생성, 지워 및 기능개선을 위해 고용되었음을 암시하게 하라.

테스트와 유지보수를 위한 디자인

  • 프로젝트가 아니라 애플리케이션을 생각하라.
  • 유지보수가 가능한 애플리케이션은 자동회된 테스트를 필요로 한다.
  • 변경가능한 애플리케이션을 만들기 위해 경험잇는 개발자가 필요하다.
  • 소프트웨어 장인은 독점적이지 않은, 오픈 소스 툴들을 선호한다.
  • 유지보수가 가능한 소프트웨어는 문제를 진단하기가 쉽다.
  • 아웃소싱은 소프트웨어 개발의 진정한 의미를 문시하는 소프트웨어 엔지니어링 전략이다.
  • 아웃소싱을 꼭 하고자한다면 소프트웨어 장인정신의 방식으로 접근하라
    • 그 시스템의 계획된 수명을 위한 일에 반드시 참여한다는 약속을 받아내야한다

끊임없는 배움

  • 끓임없는 배움의 여행을 시작하는것은 복잡한 일이 아니다. 쉽고 효과적인 출발점은 각 개발팀에게 좋은 기술서적들을 가진 작은 도서관을 제공하는 것이다.
  • 배울 수 있는 환경을 만드는것.
    • 그것은 조직의 사람들에게 소프트웨어 개발의 장인기술을 마스터할 수잇게 하겠다는 강한 약속을 보여주는 것이다.
  • 소트프웨어 개발의 장인기술을 마스터하는것
    • 개발자들을 관련된 회의나 교육과정에 보내야한다. 이 정책은 끊임없는 배움을 실현하겠다는 여러분의 약속을 보여주는 것이다.
    • 조직자체의 시간을 그들에게 투자하는 것은 모두에게 명백한 메시지를 보내는 것이다.

Epilogue

  • 장인정신은 엔지니어링으로 부터 갈라져 나왔고, 개인의 책임과 분산화를 강조한다
  • 소프트웨어 엔지니어링은 연간 100여명 이상의 개발자를 필요로 하는 프로젝트를 대상으로 하는 것이라고 생각하게 되었다.
  • 소프트웨어 장인정신은 좋은 개발자들의 작은 팀으로 소프트웨어를 개발할 경우에 가능한 것들에 관해 대화를 시작하는 나의 방식이다.
  • 장인정신은 다양성과 개인의 책임을 통해 일의환경을 만들어 나간다
  • 결국 소프트웨어 개발은 예술과 과학, 그리고 공학을 정교하게 섞는 기술, 즉 장인기술이다. 그것은 단지 하루의 일이 아니다; 그것은 열정이 될수 있다.
  • 소프트웨어 개발은 재미있는 것이다. 그렇지 않다면, 그 프로세스는 잘못된 것이다.

External links

시간을 초월한 창조의 원칙 패턴, Wiki 그리고 XP

패턴, Wiki, XP의 기원으로

패턴 브라우저는 패턴을 기록해서 열람하기 위한 기반으로 만들어졌다. 그리고 이 패턴 브라우저를 인터넷에서 작동하도록 한 것이 WikiWkiWeb이다.

  • 1964년 Notes on the Synthesis of Form(형태의 합성에 관한 노트) : 건축이나 도시 등을 설계한다고 하는 행위 그 자체를 수학적으로 형식화하는 시험. 이 전개된 설계의 형식화라는 시험이 패턴 랭귀지라는 아이디어로 이어진다.
  • 1965년 A city is not a tree(도시는 트리가 아니다) : 트리구조가 아닌 세미라티스(semi-latice) 구조가 자연 도시에서 볼 수 있는 구조. 도시계획은 자연도시가 가지는 세미라티스 구조를 가져야 한다고 논했다. 자연도시는 긴 세월을 거쳐서 많은 손에 의해서 만들어지는 것과 관계가 있을 것. 알렉산더는 이 논문에서 트리구조 설계 방법에 대한 자기 비판 성격을 가진다. 세상의 건축에 이런 트리구조 계산은 사실상 불가능하다는 것에 이르렀다. 게다가 세미라티스 구조로 계산을 하게 되면 계산량은 더욱 늘어나 버린다. 알렉산더는 세미라티스 구조를 만들어 내기 위한 일반적인 구조가 있을 것이라고 생각했다.
  • 1968년~1973년 알렉산더는 직접 건축을 함
  • 저작3권 1975년 오레곤 대학교의 실험 정리
  • 저작2권 1977년 A Pattern Language : 패턴을 토대로 건축을 설계하는 방법을 제창
  • 저작4권 1979년 시간을 초월한 건설의 길 The Timeless Way of Building

크리스토퍼 알렉산더에 의한 미의 원리 추구

알렉산더가 추구하는 미란 어떤 힘을 가진 어떤 질서인 것이다.

형태의 합성에 관한 노트

설계 프로세스의 수학적 형식화

형태를 만들어가는 해위를 수학적인 절차로 정식화하는 것을 시험

  • 스텝 1. 대상이 되는 것에 관해 생각할 수 있는 한 모든 조건을 철저히 조사해서 더 이상 나눌 수 없을 때까지 세분화. 이조건의 집합 전체를 시스템이라고 부른다.
  • 스텝 2. 열거한 조건 간의 관계성을 철저히 조사.(어떤 것을 만족하면 다른 어떤 것을 만족할 수 없는 관계나 어떤 것을 만족하면 다른 어떤 것도 만족하게 되는 관계등)
  • 스텝 3. 각각의 조건이 적합하다/적합하지 않다 라는 두개의 파리미터를 가진다고 하면 그들 집합을 1과 0으로 구성되는 수치의 집합으로 간주해서 수학적으로 취급할 수 있다. 이때 1을 만족하면 다른쪽이 0으로 되는 조건을 가질 수 있다. 이런 제약 관계를 고려해서 1이 값이 가장 많이 포함되는 상태를 논리적으로 도출할 수 있다. 단 각각의 조건 간의 관계는 복잡하게 얽혀 있으므로 그 관계성을 모두 계산하려면 답을 구할수 없는 복잡한 문제가 되므로 답을 구하려면 시스템을 몇몇 작은 집합으로 분할할 필요가 있는데 이를 서브시스템이라고 한다. 조건의 관계를 잘 음미하고 서로 영향을 주는 조건만을 모아서 각각을 서브시스템이라 했다. 이렇게 잘개 쪼개진 서브시스템 하위의 요소들간의 관계에서 1과 0값을 도출해 가장 많은 1이 나오는 요소를 이용해 계획을 입안할 수 있게 된다

가능한 한 많은 조건을 만족하는 형태를 찾아낸다 라는 설계 행위를 수학적인 접근으로 풀 수 있는 문제로 환원한 것. 알렉산더는 조건의 관계를 잘 음미하고 서로 영향을 주는 조건만을 모아서 각각을 서브 시스템으로 했다. 이런식으로 반족해나가면서 처음에 조건을 모두 열거기하고 전체구조를 시스템과 서브시스템의 트리구조로 환원해가는 방법은 탑다운 접근법이라 할 수 있다.

  • 주전자
    • 기능
      • 제조
      • 안전
      • 용도
    • 경제
      • 원가
      • 유지

이처럼 그의 설계상 특징은 조건의 집합을 최종적으로 하나의 다이어그램으로 반영하는 것이다. 요구 조건을 철저하게 열겨허면 그것을 수학의 집한론적으로 해석해서 트리 구조로 분석하고, 그 결과를 이런 하나의 다이어그램으로 반영해 보이는 것. 수학적인 방법론의 이용과 결과로서 다어어그램이 주는 아름다움의 두가지 융합이 그의 주장을 매력적으로 보이게 하고 있었다.

요구 조건 간의 방대한 관계성 계산

베이 에어리어 고속철도의 설계 입안시 요구조건이 390개나 있기 때문에 트리구조로 분할한 서브시스템도 방대한 수가 되어버렸다. 그리고 서브시스템 간의 예기치 않았던 연계도 발생함. 여기서 그의 방법론의 결점이 발견. 트리구조 환원 과정에서 본래 잘라 버리지 않ㅇ느면 안되는 중요한 관계성이 무시되버린 것이다. 즉 현실은 질서 있는 계층 구조로 반영할 수 없는, 복잡하게 얽힌 구조로 되어 있나느 것을 알게 된 것이다

Tree-semilattice.png

알렉산더의 여섯 가지 원리

오레곤대학교에서 대규모릐 설계를 한후 오레곤대학교의 실험이라는 문서로 정리. 여기서 그는 건설과 계획을 하기 위한 여섯 가지 원리를 내걸고 있다.

  • 1. 유기적 질서의 원리 The Principle of Organic Order : 계획이나 시공은 전체를 개별적인 행위로 부터 서서히 만들어가는 것과 같은 프로세스에 의해서 인도될 것
  • 2. 참가의 원리 The Principle of Participation : 건설 내용이나 건설 방법에 관한 모든 결정은 이용자의 손에 맡길걸
  • 3. 점진적 성장의 원리 The Principle of Piecemeal Growth: 각 예산년도에 기획되는 건설은 소규모인 프로젝트에 특히 중점을 둘것
  • 4. 패턴의 원리 The Principle of Patterns : 모든 설계와 건설은 정식으로 채택된 패턴이라고 불리는 계획원리의 집합에 의해서 지도될 것
  • 5. 진단의 원리 The Principle of Diagnosis : 커뮤니티 전체의 건상 상태는 커뮤니티 변천의 어느 시점에서도 항상 어떤 공간이 살려지고 어떤 공간이 살려지지 않았는가를 상세히 설명하는 정기적인 진단에 근거해서 보호될 것
  • 6. 조정의 원리 The Principle of Coordination : 전체에 있어서 유기적 질서의 완만한 생성은 이용자가 추진하는 개개의 프로젝트의 흐름을 제어하는 재저정처치에 의해서 확실한 것으로 될것

패턴 랭귀지

알렉산더는 패턴을 건축을 설계하기 위한 기본 단위라고 보았다. 그리고 패턴을 조합해서 구체적인 건축물을 설계할 때 에는 그 조합 방법에 제약을 가하는 조건이 열거되어 저절로 질서가 잡혀가도록 되어 있었다. 알렉산더는 1977년 이제까지 수집한 패턴을 패턴랭귀지라는 서적으로 발표했다.

패턴 형식

  • 패턴명
  • 사진
  • 상위 패턴으로의 이어짐
  • 본문
  • 하위 패턴으로의 이어짐

알렉산더 이론의 발전

형태의 합성에 관한 노트에서 요구조건의 집합을 트리구조로 환원하고 그 관계를 최적화하는 것을 설계라고 보았따. 무수한 요구존건을 컴퓨터 설계로 구별하고 설계의 요점이 되는 다이어그램을 탑다운으로 일제히 도출하려는 시도를 했지만 이것은 너무 복잡한 대상에는 적용일 불가능하다는 결론을 얻음. 그리고 트리구조과 같은 설계의 요소를 완전히 분리해서 엄중이 구별해버리는 것은 이용자인 인간의 성질에 대해서 부적절

그래서 알렉산더는 요구조건의 집합인 다이어그램부터 발전된 패턴이라는 개념을 만들었다. 패턴 간의 관계성은 형태의 합성에 관한 노트때와 같은 엄밀한 트리 구조로 환원하지 않고 서로 겹친 세미라티스 구조로서 상하의 이어짐을 정하는 것으로만 했다. 그리고 패턴의 성질이나 본연의 모습을 검토해가는 간운데 훈련을 쌓아 새로운 패턴을 발견하는 인간의 직감이 컴퓨터로는 계산할 수 없는 정교하고 치밀한 패턴의 조합을 찾아내는 중요한 요소로 생각한 것. 이것이 다이어그램에서 패턴 랭귀지로의 큰 진화였다. 즉 바틈업 방식의 작업이 반복될때마다 조금씩 다른 결과를 만들어내는 생성적인 프로세스였던 것.

알렉산더가 내린 결로은 이용자와 전문가가 협력 관계를 쌓고 패턴 랭귀지를 구축하고 적절한 설계를 현장에서 한 걸음씩 만들어나간다고 하는 새로운 이론과 사상이었던 것이다.

시간을 초월한 걸설의 길

그는 어떻게든 자연도시와 같은 건축을 만들고 싶어했다. 그는 자연도시가 갖추고 있는 질을 무명의질 Quality Without A Name : QWAN(쿠완)이라고 불렀다. 오래된 건물이가 길거리가 가지는 다양한 건축적인 요소가 조화된 느낌을 그는 무명의 질이라고 이름붙인것.

오레곤대학교의 실험에 제시한 여섯가지 원리는 무명의 질을 갖추 도시나 건축을 실현하기 위한 원리. 즉 창조의 원칙. 즉 시간을 초월한 창조의 원칙인 것이다.

패턴랭귀지에 의한 건축의 실제

미리 부품을 준비해서 이어 맞춘다고 하는 생각은 그가 가장 반대하는 생각이다. 패턴 랭귀지는 부품집 사례집이 아닌 이용자와 건축가를 연결하기 위한 다양한 아이디어의 집합체일 뿐이다. 알렉산더가 사용하는 랭귀지 라는 말은 개별적인 개념이 상호 결합해서 새로운 개념을 만들어간다는 의미체계를 나타내는 말이다.

알렉산더의 현재

시간을 초월한 걸설의 길 이후 알렉산더의 작업 진행. 패턴 랭귀지에 의한 이용자 참가로 만들어지는 건축이 어딘가 요란하게 되어버리는 경향이 있다는 것을 알고 있었따. 본질적인 미를 추구하는 그에게 있어서 이 결점은 허용할수 없는 것. 패턴랭귀지에서 패턴은 상위와 하위의 패턴과의 연계를 가지고 있었지만 그것들을 어떻게 조합할 것인가에 대한 룰은 없었다. 즉 조합이 부적절하면 질은 낮아지면 생생한 것으로 되지 않는다.

알렉산더는 문화에 강하게 의존한 패턴이라는 발상으로부터 -> 패턴을 만들어내는 보편적인 힘. 즉 보편성을 가지는 기하학과 인지적, 심리적인 연구로 이행해 갔고 이제까지 무명의 질이라 부르고 있던 개념은 전체성(Wholeness)또는 생명(Life)이라는 말로 표현하게 되었으면 그 본질에 숨어 있는 무언가를 탐구하려고 했다. 이런 성과과 2002~2005년에 The Nature of Order(질서의 본질)이라는 4권짜리 시리즈로 출판되었다. 이 서적은 사물이 자연스럽게 성장하는 방법에 관한 대통일 이론을 세우려는 것이다. 알렉산더는 미를 관용적, 보편적인 것으로 생각해 실험이나 고찰에 의해 그것을 명확하게 정의 가능하다고 생각하고 실천한 것이다.

다양한 실험의 결과로부터 그는 15개의 기하학적 특성 이라 부르는 이념을 정리했다.

  • 스케일의 단계성 Levels of Scale
  • 강한 중심 Strong Centers
  • 경계 Boundaries
  • 상호 반복 Alternating Repetition
  • 양의 공간 Positive Space
  • 좋은 형태 Good Shape
  • 국소적 대칭성 Local Symmetries
  • 깊은 상호결합과 양의성 Depp Interlock and Ambiguity
  • 대비 Contrast
  • 단계적인 변화 Gradients
  • 거침 Roughness
  • 공명 Echoes
  • 중공 The Void
  • 간결함과 평온함 Simplicity and Inner Calm
  • 불가분할 것 Not-Separateness

이 일련의 연구는 건축에 멈추지 않고 자연현상에서 생겨나는 형상, 가구, 회화등의 다양한 역역에 있어서의 미에 공통되는 룰을 찾아 내려는 것이었다.

결론

패턴랭귀지라는 사상은 알렉산더라는 특이한 건축가-이론가를 중심으로 해서 고안된 것으로

당초에는 수학적인 엄밀성을 토대로 한 설계를 목표로 하고 있었지만

점차 이용자 참가의 프로세스에 의한 건축으로 중점이 옮겨 갔다.

패턴랭귀지는 이용자의 참가에 의해서 이용자와 건축에 관련되는 전문가가 합의 형성하고 유기적 질서에 근거하는 건축을 선계하기 위해 고안된 수법인 것이다.

소프트웨어 개발

GoF의 패턴과 알렉산더의 패턴의 다름점

1. 건축물에는 수천년의 역사가 있으면 고전도 많다. 소프트웨어 시스템의 경우에는 역사가 훨씬 짧아서 고전이라고 부를 수 있는 것은 거의 없다

2. 알렉산더는 패턴을 이용하는 우선순위를 매겼는데 우리들은 순위를 매기지 않았다

3. 알렉산더의 패턴을 취급하는 문제를 강조하고 있지만 우리들의 디자인 패턴은 해결 방법에 대해서 더욱 상세하게 기술하고 있다.

4. 알렉산더는 제안한 패턴에 의해서 완전한 건축물을 생성할 수 있다고 주장하고 있지만 우리들은 제안한 패턴에 의해서 완전한 프로그램을 생성할 수 있다고는 주장하고 있지 않다.

알렉산더의 패턴랭귀지에 소개된 마을, 건축, 시공과 비교해 본다면 GoF의 디자인 패턴을 건축에 해당하는 패턴을 다루고 있다.

시공은 소프트웨어 개발의 구현에 해당할 수 있다고 보는데 1991년 코플리엔이 출판한 Advanced C++ Programming Syles and Idions에서 이 기술 방법을 다루고 있다 벡 역시 1996년 Smalltalk Best Practice Patterns를 통해 기술을 정리

마을에 해당하는 패턴은 1996년 POSA, 2002년 마틴파울러에 의한 Patterns of Enterprise Application Architecture가 있다.

이와 같이 다지안 패턴이라는 좁은 범위로부터 시작한 패턴은 응용도 서서히 범위를 넓혀 마을, 시공 등의 다른 범위에 해당하는 패턴도 취급하게 되었다.

  • 1968년 더글라스 엔겔바트 GUI 개념 제시
  • 1972년 엘런 케이 대화형 프로그래밍 언어 Smalltalk라는 객체지향 프로그래밍 언어 개발. (GUI 개념 적용)
  • 1979년 애플 GUI탑재 퍼스널 컴퓨터 리사 발매
  • 1984년 애플 매킨토시 발매
  • 1986년 OOPSLA 설립후 오레곤에서 제1회 심포지엄 개최. 앨런 케이 기조강연. 벡과 커닝엄은 A Diagram for Object-Oriendted Programs 라는 논문 발표
  • 1987년 벡과 커닝엄은 패턴을 사용한 시스템 설계를 시험하고 “객체지향 프로그램을 위한 패턴 언어의 사용”이라는 논문을 OOPSLA에 투고후 발표. 이후 이 논문은 디자인 패턴이라는 개념으로 이어지게 된다
  • 1988년 에릭감마는 “ET++-An Object-Oriented Application Framework in C++”란 이름으로 OOPSLA에 발표
  • 1991년 코플리엔 Advanced C++ Programming Syles and Idioms 출판. 구현 패턴에 관한 카테고리 시도화
  • 1992년 OOPSLA 랠프 존슨은 “Documenting Frameworks using Patterns”를 발표하여 패턴은 단순한 설명문의 나열이 아니라 구체적인 실례화 함께 표시되고 밀접하게 관련된 패턴간의 관계성 하에 구축된 체계라는 것이다.
  • 1994년 8월 힐사이드 그룹의 멤버는 제1회 PLoP(프롭)을 개회하고 해당 내용을 정리한 서적 “Pattern Languages of Program Design”을 출판
  • 1994년 10월 GoF는 “Design Patterns: Elements of Reusable Object-Oriented Software” 서적 발표.
  • 1996년 켄트벡은 Smalltalk Best Practice Pattenrs를 통해 스몰토크에서 반복해서 나타나는 기술을 정리 -> 2007년 자바버전 Implementation Patterns도 출시(알렉산더의 시공에 해당)
  • 1996년 프랭크 부슈만은 POSA를 통해 아키텍쳐 패턴을 소개
  • 2002년 마틴 파울러는 Patterns of Enterprise Application Architecture를 통해 엔터프라이즈 어플리케이션 아키텍쳐 패턴을 소개. (알렉산더의 마을에 해당)