프로그래머는 건설 업계에서 무엇을 배울 수 있습니까? [닫은]

소프트웨어 설계 및 개발 원칙에 대해 동료들과 이야기 할 때, 유추의 가장 일반적인 소스 중 하나가 건설 산업이라는 것을 알았습니다. 우리는 소프트웨어를 구축 하고 디자인과 구조를 아키텍처 로 간주합니다 .

배우거나 가르치는 가장 좋은 방법 중 하나는 유추를 분석하는 것입니다. 건축에서 다른 유추를 이끌어 낼 수 있습니까? (소프트웨어에서 이미 사용 중인지 여부).

프로그래밍 개념이 구성 개념과 어떻게 다른지에 대한 설명 또는 개인 경험을 제공하십시오.

^{[ 아이디어를위한 예술과 인문학에서 얻은 프로그래밍 개념에 대한 학점 ]}

그것이 디자인 패턴의 유래입니다.

이 개념을 세계에 소개 한 사람은 1977 년 그의 책 "A Pattern Language : Towns, Buildings, Construction"에서 Christopher Alexander였습니다 . 거기에서, Gang of Four (GoF) 는 그것을 골 랐고 나머지는 역사입니다.

지금도 강의와 소프트웨어 개발 및 건축 서적에서 건축 세계와 소프트웨어 개발 세계 사이의 유사점이 계속 우세합니다.

내가 생각하거나 기억할 수있는 몇 가지 유추와 참고 문헌 :

• 예를 들어, 건물을 건설 하는 동안 요구 사항을 변경 하면 "OH, 방금 완성한 부엌 대신 차고를 원합니다"라는 말이 얼마나 터무니 없는지 고객에게 더 분명해질 것입니다.
• 비계 와 같은 임시 지원 ( 건설 세계 에서 의미 | 소프트웨어 개발 )
• 고객은 비용을 들이지 않고 기능 을 계속 추가 할 수 없으며 , 많은 경우 무료로 작업을 원하며, 때로는 수용하기에 멍청합니다. 건설 세계에서는 일어날 수 없었습니다. 요구 사항 creep ).
• 역할소프트웨어 개발 : 설계자는 솔루션 설계의 중심입니다. 컨설턴트와 계약자는 상호 교환 가능한 용어 일 수 있습니다. 노동자는 프로그래머입니다.
• 클라이언트는 두 경우 모두 정확한 요구 사항 을 제공 할 수 없습니다 .
• 예산 과 시간 추정치 는 종종 틀립니다.
• 제품은 실제로 끝날 때까지 실제 형태로 볼 수 없습니다 .
• 소프트웨어에 버그 가있는 것과 같은 방식으로 건물에 건축 결함 이있을 수 있습니다 .
• 제품이 잘못 수행되면 때로는 제품을 수리하는 것보다 철거하고 다시 시작 하는 것이 좋습니다.
• 품질이 좋지 않은 작업의 실제 결과와 실제 결과를 알지 못하는 고객은 가장 저렴한 솔루션을 원합니다 .
• 오픈 소스 . " 모든 비즈니스가 오픈 소스를 기반으로하는 이유 "라는 Doc Searls의이 강연을보고 있었는데 , 건축 관련 커뮤니티가 오픈 소스 커뮤니티와 유사하게 특허를 부여하는 대신 기술과 일반 지식을 공유하는 방법을 알려줍니다. 독점 제품이 내장되어 있습니다.
• 고객이 적극적으로 참여하면 모든 사람에게 더 나은 프로젝트 가 나옵니다 .

(더 많은 것이 생각 나면 추가하겠습니다.)

일반적인 유추가 맞지 않다고 생각하는 사람들이 있습니다. 권장되는 독서는 The Software Construction Analogy is Broken 입니다. 또한 소프트웨어와 건물 건설의 비유에서 무엇이 문제입니까? 라는 제목 의 SO에 대한 질문이 있습니다 . .

우리는 소프트웨어 개발의 역사를 통해 건설 업계에서 많은 단어와 아이디어를 얻었으며 실제로 많은 사람들에게 가져 갔을 것입니다.

우리는 고객이 사양을 작성하고, 건축가 계획을 세우고, 건설 산업에서 구현하는 원숭이를 설계하고 마지막으로 코딩하는 전체 프로세스를 취했으며 완전히 잘못 인도되었습니다.

집을 지을 때 기초가 잘못되면 효과가 있기 때문입니다. 심각하게 효과가 있습니다. 건물을 들어 올리고 기초를 교체하려면 전체를 폐기하고 처음부터 다시 시작해야합니다. 그러나 소프트웨어에서는 완전히 가능합니다. 모뎀을 서버 룸으로 옮겼다는 점을 제외하고는 사용자가 아무 것도 알리지 않고 클라이언트 소프트웨어를 클라이언트-서버 솔루션으로 다시 만들었습니다. 주민들이 자고있는 동안 콘크리트 기초를 보트로 교체하는 것과 같습니다.

소프트웨어가 아닙니다 건설처럼. 이것이 바로 전체 소프트웨어 산업이 장난 꾸러기 초기에 시작된 이유이며 프로젝트를 실행하는 전체 "폭포"프로세스가 불과 몇 년 만에 민첩한 프로세스로 대체되었습니다.

말에 관해서는 많은 것이 건축에서 옳고 그름으로 취해지고 있습니다.

프레임 워크 는 아직 취하지 않은 가장 확실한 것입니다. 그리고 파이프가 있습니다.

저는이 비유를 사용했습니다. 소프트웨어를 필요로하는 사람이 "핸디맨"과 동등한 것을 알고 있기 때문에 많은 사람들이 소프트웨어 프로젝트를 시작하고이 사람을 고용하여 정원 창고와 같은 소프트웨어를 만듭니다. 작고 유용한 작은 응용 프로그램으로 잘 작동합니다.

그런 다음 고객은 재주꾼에게 돌아가 작업에 만족하고 소프트웨어를 한 번 더 변경하도록 요청합니다. 이 새로운 기능은 원래 요청과 관련이없는 경우가 많으므로 별도의 입구가있는 정원 창고 뒤에 다른 방을 지을 것을 요구하는 것과 거의 같습니다.

그런 다음 헛간에 빛을 넣고 싶어서 핸디맨이 돌아오고 집의 메인 패널에서 단일 회로를 실행하고 각 방의 천장에 풀 체인 전등 스위치를 설치하고 회로에 연결합니다 .

그런 다음 고객은 일부 전동 공구를 사용하기로 결정했지만 회로 차단기를 계속 불고 있기 때문에 사람에게 전화를 걸어 실제로 메인 패널에 연결된 단일 회로를 제거하고 더 큰 도체와 장치를 설치해야합니다. 창고의 하위 패널. 그는 와이어를 두 번 돌리고 두 개의 전기 허가 등을 지불해야했습니다. 이것은 비효율적입니다.

그런 다음 고객이 부조리 한 것을 요청합니다. 내 정원 창고를 차고로 바꿀 수 있습니까? 나는 당신이 한 일을 다시하지 않기를 원합니다 ... 나는 거기에 내 차를 주차 할 수 있도록 더 크게 만들기를 원합니다. 그런 다음, 많은 경우에, 핸디맨은 "고객이 항상 옳다"고 생각하고 창고의 3면에 추가 물을 만들어 더 크게 만들고 칸막이 사이의 벽을 떨어 뜨립니다. 물론, 지붕 끝 제대로 구성되지 않았기 때문에 늘어짐

따라서 고객은 더 이상 감동하지 않지만 여전히 더 많은 것을 원합니다. 그들은 재주꾼에게 계속해서 방을 하나 더 추가하거나 기존 방을 변경하여이 작업 등을 수행하도록 요청합니다 . 버로우 처럼 보이고 건축 적으로 소리가 나는 것으로 끝납니다 .

이제 대부분의 사람들은 건설 세계에서 이것을 시도하기에 어리석은 것이 아니지만 사람들은 이러한 연결을 만들지 않기 때문에 소프트웨어 세계에서 항상 발생합니다.

1. 정말 멋진 정원 창고를 지을 자격이있는 사람이 반드시 집을 지을 자격이있는 것은 아닙니다.

2. 단계적으로 집을 지을 것이라는 것을 미리 알고 있었지만 정원 헛간으로 만 시작한다면 다른 일을하고 정원 헛간이 훨씬 더 많이들 것입니다. 정말 두꺼운 패드라면 완성 된 집 등을 충분히 실을 수있을 정도로 큰 도체를 작동시켜야합니다.)

3. 많은 경우에, 한 단계에서 다른 단계로 업그레이드하는 것은 이전에 수행 된 많은 작업을 취소하여 원래보다 더 비싸게 만듭니다.

4. 건설 세계에서는 디자인 단계에서 결과가 어떻게 보일지 고객에게 좋은 아이디어를 제공 할 수 있지만 소프트웨어 세계에는 그러한 능력이 없습니다. 그 시점에 도달하면 기본적으로 소프트웨어의 상당 부분을 작성했습니다.

애자일 선언문은 소프트웨어 / 구성 유추가 손상되었음을 인정한 결과입니다. 자동화 된 단위 테스트 및 반복 릴리스주기와 같은 것은 구성에서 병렬이 아닙니다. 이러한 것들은 디자인에서 프로토 타입으로가는 거의 제로 비용 (컴파일 또는 빌드라고 함)을 이용합니다.

Finish work 와 Trim 이라는 용어가 떠 오릅니다.

주요 구조 결정이 완료 될 때 미학적 선택을 미룰 수 있다는 생각.

오래된 속담 : 두 번 측정하고 한 번 자릅니다.

편집 : Atul Gawande 의 Checklist Manifesto 의 섹션에는 대규모 건설 작업 관리에 대한 내용이 있습니다. 그들이 정말로 복잡한 시점에 도달하면, 문제를 다시 방문하고 모든 사람이 알아야 할 프로젝트가 발생했는지 확인하기 위해 관련 전문가와 회의를합니다. 아마도 미리 계획 할 수 없을 것입니다.

제한 사항은 건설 및 프로그래밍에 모두 존재한다 .

고객이 주말에 완성 된 호텔 건물을 연장하고 공항을 지하층과 활주로에 꽂는 것과 같은 우스운 요구를 할 수 없다면, 완성 된 모든 조정이 완료되지 않을 수는 없습니다. 소프트웨어가 가능합니까? 그것은 0과 1의 마술 공이 아니며 복잡한 구조이지만 중요하지는 않지만 한계가 있습니다.

나는 학교를 통해 건축 작업을했으며 비슷한 개념조차 적용되지 않는 곳도 있습니다. 그러나 종종 비교 유혹이 너무 멀어집니다.

직업에 대한 견적을 받았을 때, 어떤 일을하는 데 걸리는 시간이 꽤 튼튼하다는 것을 알았습니다. 예를 들어, 상점 창을 제작하기 위해 계획에서 프레임의 조인트 수를 계산하고 시간이 얼마나 걸리는지 꽤 잘 알고있었습니다. 프로그래밍과 마찬가지로 스케줄에서 변수를 고려해야했지만 수명이 단축 될 수 있습니다. 예를 들어, 배관 승무원이 주차장을 포장하고 있으며 뜨거운 아스팔트 때문에 건물에 들어갈 수 없다는 것을 알기 위해 비용이 많이 듭니다.

그러나 건설에는 수천 년의 경험이 있습니다. 거래의 기본 규칙은 항상 똑같은 물리 법칙에 의해 좌우됩니다. 풍하중 및 데드 하중 계산은 슬라이드 규칙을 사용했을 때와 동일합니다. 도구와 기술이 향상되었지만 우리가 경험하는 것과 비교하여 빙하 속도로 진행되었습니다.

반면에, 우리는 여전히 많은 패턴과 관행이 개선의 여지가 필요하다는 것을 발견하고 있습니다. Singleton은 좋은 생각 이었지만 지금은 대부분 IoC / DI 패턴을 선호한다고 생각합니다.

우리에게 부족한 부분은 의미있는 라이센스 및 인증에 있습니다. 많은 지역에서 설치자뿐만 아니라 수리공 일지라도 배관공은 허가를 받거나 누군가의 감독하에 작동해야합니다. 해당 라이센스를 받으려면 현장에서 작업하는 데 일정 시간이 필요합니다. 라이선싱을 반대하거나하지 않고 단지 큰 차이가 있기 때문에 지적하고 있습니다.

물론 두 분야에서 건축가는 구현할 수없는 무언가를 그릴 수 있습니다.

비계 , "건물 및 기타 대형 구조물의 건설 또는 수리시 사람과 자재를 지원하는 데 사용되는 임시 구조물" ^{[wikipedia에서 정의]}

이 개념은 프로그래밍 에서 스캐 폴딩을 빠르게 생성 할 수 있고 실제 구조가 제자리에있을 때까지 임시 기능을 제공 하기 때문에 작동 합니다.

나는 가장 낮은 입찰자를 위해 농사를 짓고, 엉성한 일을하고, 품질 보증 일에 집중하고, "완성 된"제품에 대해 엄청난 이익을 청구하는 일부 건설 회사를 알고 있습니다.

그러나 나는 프로그래머 나 컨설팅 에이전시가 그러한 관행으로부터 무언가를 배운 것으로 생각하지 않는다.

버그는 지옥처럼 비싸거나 사람들을 죽일 수 있습니까?

모든 분야의 복잡한 엔지니어링 프로젝트에 대한 기본 지침이 있습니다.

1. 계획, 청사진, 디자인 등의 중요성
2. 기초 수학의 중요성
3. 다른 유사한 프로젝트에서 아이디어 재사용 / 학습
4. 다른 사람이 만든 기성품 빌딩 블록 / 구성 요소 사용
5. 수명주기
   등 초기에 문제를 수정

아키텍처, 토목 및 소프트웨어 엔지니어링 분야 간의 공통점은 주로 조립 라인 이 없는 것에서 비롯된 것 같습니다 . 모든 프로젝트는 그 자체로 고유합니다.

시간 외에

그러나 건설 산업에서는 근로자가 초과 근무 수당을받습니다.

표준, 규칙 및 사전 구축 된 구성 요소 사용 이런 종류의 문제는 발생하지 않을 것입니다.

시장에서 우리의 맞춤형 소켓에 맞는 것을 찾을 수 없습니다.

당신이 가진 전부 망치라면 모든 것이 못처럼 보입니다. :)

반복성 긴장 손상

두 산업 모두에서 직업 상 위험 요소이므로이를 예방하기 위해 예방 조치를 취해야합니다. 일단 시작하면 치료가 어렵습니다.