이 해석은 이상하게 보이지만 심사숙고한 결과이다. 이 기사는 프로그래밍과 프로그래밍의 관계에주의를 기울이고 싶습니다. 최근 10 년 동안, 나는 전체 소프트웨어 업계가 소프트웨어 디자인과 진정한 소프트웨어 디자인의 미묘한 차이를 인식하지 못했다고 줄곧 느꼈다. 이를 보면 C++ 성장의 트렌드에서 더 나은 소프트웨어 엔지니어가 되는 방법을 배울 수 있을 것 같습니다. 이 지식은 프로그래밍이 소프트웨어를 구축하는 것이 아니라 소프트웨어를 설계하는 것이다.
몇 년 전, 나는 소프트웨어 개발이 공학과인지 여부를 토론하는 세미나에 참석했다. 토론 결과는 기억나지 않지만, 소프트웨어 업계와 하드웨어 엔지니어링이 잘못된 비교를 하고 절대적으로 정확한 것을 간과한 것을 어떻게 깨닫게 되었는지 기억합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 사실 저는 우리가 소프트웨어 엔지니어가 아니라고 생각합니다. 왜냐하면 우리는 진짜 소프트웨어 디자인이 무엇인지 깨닫지 못했기 때문입니다. 지금, 나는 이 점을 더욱 확신한다.
모든 엔지니어링 활동의 최종 목표는 특정 유형의 문서입니다. 설계 작업이 완료되면 설계 문서가 제조 팀에 전달됩니다. 팀과 디자인 팀은 완전히 다른 그룹이며, 기술도 디자인 팀과 완전히 다릅니다. 설계 문서가 완전한 설계를 올바르게 설명하면 제조 팀이 제품 제조를 시작할 수 있습니다. 실제로 설계자의 추가 개입 없이 제품의 많은 물리적 객체를 구축하기 시작할 수 있습니다. 내 이해에 따라 소프트웨어 개발의 라이프 사이클을 검토한 후, 엔지니어링 설계 표준을 실제로 준수하는 소프트웨어 문서는 소스 코드 목록밖에 없다는 결론을 내렸습니다.
이 관점에 대해 사람들은 이미 많은 논쟁을 벌였고, 찬성과 반대는 모두 무수한 논문을 쓰기에 충분했다. 이 문서에서는 최종 소스 코드가 실제 소프트웨어 설계라고 가정하고 이러한 가설의 결과 중 일부를 자세히 살펴봅니다. 이 관점이 정확하다는 것을 증명할 수는 없지만, C++ 의 유행을 포함하여 소프트웨어 업계의 관찰된 사실들을 확실히 설명하고 있다는 것을 증명하고 싶습니다.
코드를 소프트웨어 설계의 결과로 볼 때 한 결과가 다른 모든 결과를 완전히 압도합니다. 그것은 매우 중요하고 명백하다. 이 때문에, 그것은 완전히 대부분의 소프트웨어 조직의 맹점이다. 결과적으로 소프트웨어 구축 비용은 매우 낮습니다. 비싼 자질이 전혀 없습니다. 매우 싸고 거의 무료입니다. 소스 코드가 소프트웨어 설계인 경우 실제 소프트웨어 구성은 컴파일러와 커넥터에 의해 수행됩니다. 우리는 종종 완전한 소프트웨어 시스템을 컴파일하고 연결하는 과정을' 한 번의 구축' 이라고 부른다. 소프트웨어 구축 장비에 대한 주요 투자는 매우 적습니다. 필요한 것은 컴퓨터, 편집기, 컴파일러 및 커넥터뿐입니다. 일단 구축 환경이 생기면, 실제 소프트웨어 구축은 단지 약간의 시간이 걸린다. (존 F. 케네디, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어) 50,000 줄 C++ 프로그램을 컴파일하는 데는 시간이 오래 걸릴 수 있지만, 50,000 줄 C++ 프로그래밍의 복잡성과 같은 하드웨어 시스템을 구축하는 데는 얼마나 걸립니까?
소스 코드를 소프트웨어 설계로 간주하는 또 다른 결과는 소프트웨어 설계를 비교적 쉽게 만들 수 있다는 것입니다. 적어도 기계적으로는 그렇습니다. 일반적으로 대표 소프트웨어 모듈 (50 ~ 100 행 코드) 을 작성 (설계) 하는 데 며칠이 걸립니다 (완전히 디버깅하는 것은 또 다른 주제이며 나중에 자세히 설명하겠습니다). 이렇게 짧은 시간 내에 소프트웨어만큼 복잡한 디자인을 만들 수 있는 다른 학과가 있는지 묻고 싶지만, 우선 복잡성을 측정하고 비교하는 방법을 알아야 합니다. 그러나, 소프트웨어 설계가 곧 매우 커질 수 있다는 것은 분명하다.
소프트웨어 설계가 비교적 쉽게 만들어지고 본질적으로 비용이 많이 들지 않는다고 가정하면, 소프트웨어 설계가 일반적으로 매우 크고 복잡하다는 것을 발견하는 것은 놀라운 일이 아닙니다. 이것은 명백한 것 같지만, 문제의 중요성은 종종 간과된다. 학교의 프로젝트에는 보통 수천 줄의 코드가 있다. 10 000 줄 코드 (디자인) 가 있는 소프트웨어 제품도 해당 디자이너에 의해 폐기됩니다. 우리는 이미 더 이상 간단한 소프트웨어에 관심을 기울이지 않았다. 전형적인 상용 소프트웨어의 설계는 수천 줄의 코드로 구성되어 있다. 많은 소프트웨어 설계가 수백만 줄의 코드에 도달했습니다. 또한 소프트웨어 설계는 거의 항상 진화하고 있습니다. 현재 설계에는 수천 줄의 코드만 있을 수 있지만, 제품 수명 주기 동안 실제로 코드를 여러 번 써야 할 수도 있습니다.
소프트웨어 설계만큼 복잡해 보이는 하드웨어 설계도 있지만 현대 하드웨어에 대한 두 가지 사실에 유의하시기 바랍니다. 첫째, 복잡한 하드웨어 엔지니어링 결과가 항상 잘못된 것은 아닐 수 있습니다. 이 점에 있어서, 우리가 소프트웨어처럼 믿는 판단기준은 없다. 대부분의 마이크로프로세서는 다리 붕괴, 댐 파열, 비행기 사고, 수천 대의 자동차 및 기타 소비재 리콜 등 판매 시 논리적 오류가 발생합니다. 이 모든 것이 설계 오류의 결과입니다. 둘째, 복잡한 하드웨어 설계에는 그에 상응하는 복잡하고 비싼 건설 단계가 있습니다. 따라서 이러한 시스템을 제조하는 데 필요한 능력은 복잡한 하드웨어 설계를 실제로 생산할 수 있는 회사의 수를 제한합니다. 소프트웨어에 대해서는 이러한 제한이 없습니다. 현재 수백 개의 소프트웨어 조직과 수천 개의 매우 복잡한 소프트웨어 시스템이 있으며, 그 수와 복잡성은 매일 증가하고 있습니다. 이는 소프트웨어 업계가 하드웨어 개발자를 모방하여 자신의 문제를 해결할 방법을 찾을 수 없다는 것을 의미한다. 공통점이 있다면 CAD 와 CAM 이 하드웨어 디자이너가 점점 더 복잡한 설계를 만드는 데 도움을 줄 수 있을 때 하드웨어 엔지니어링이 소프트웨어 개발과 점점 더 비슷해진다는 것입니다.
디자인 소프트웨어는 복잡성을 관리하는 활동입니다. 복잡성은 소프트웨어 설계 자체, 회사의 소프트웨어 조직, 전체 소프트웨어 산업에 존재합니다. 소프트웨어 설계와 시스템 설계는 매우 유사합니다. 그것은 많은 기술을 뛰어넘을 수 있으며, 종종 많은 학과를 포함한다. 소프트웨어 사양은 일반적으로 고정되어 있지 않으며 소프트웨어 설계 과정에서 자주 빠르게 변경됩니다. 마찬가지로, 소프트웨어 개발 팀도 종종 불안정하고 설계 과정에서 자주 변한다. 여러면에서 소프트웨어는 하드웨어보다 복잡한 사회 또는 유기 시스템과 더 비슷합니다. 이 모든 것이 소프트웨어 설계를 어렵고 오류가 발생하기 쉬운 과정으로 만듭니다. 이 모든 것이 창조적인 생각은 아니지만, 소프트웨어 엔지니어링 혁명이 시작된 지 거의 30 년이 지난 오늘날 소프트웨어 개발은 다른 엔지니어링 산업에 비해 여전히 훈련되지 않은 기술처럼 보입니다.
실제 엔지니어가 설계를 완성할 때 아무리 복잡하더라도 이 설계가 작동할 수 있다고 확신하는 것이 보편적으로 받아들여지고 있다. (윌리엄 셰익스피어, 템페스트, 과학명언) 그들은 또한 공인된 기술을 사용하여 설계를 만들 수 있다고 자신한다. 이를 위해 하드웨어 엔지니어는 설계를 검증하고 개선하는 데 많은 시간을 할애합니다. 예를 들어 교량 설계를 고려해 보십시오. 이러한 설계가 실제로 구축되기 전에 엔지니어는 구조 분석을 수행합니다. 즉, 컴퓨터 모델을 구축하고 시뮬레이션하며, 비율 모델을 설정하고 풍동이나 다른 방식으로 테스트합니다. 결론적으로, 시공하기 전에 디자이너는 생각할 수 있는 모든 방법으로 설계가 정확하다는 것을 증명할 것이다. 새 여객기의 설계에는 상황이 더욱 심각하다. 원래와 같은 크기의 원형을 만들어야 하고, 비행 실험을 실시하여 설계의 각종 예상을 검증해야 한다.
대부분의 사람들에게 소프트웨어 측면에는 하드웨어 설계만큼 엄격한 프로젝트가 없는 것이 분명하다. 그러나 소스 코드를 하나의 디자인으로 보면 소프트웨어 엔지니어가 실제로 설계에 대해 많은 검증과 개선을 수행했다는 것을 알 수 있습니다. 소프트웨어 엔지니어는 이를 엔지니어링이 아닌 테스트 및 디버깅이라고 합니다. 대부분의 사람들은 테스트와 디버깅을 진정한' 프로젝트' 로 생각하지 않는다. 소프트웨어 업계에서는 분명 없을 것이다. 이러한 견해는 소프트웨어 업계가 실제 엔지니어링 차이보다는 코드를 디자인으로 간주하기를 거부했기 때문에 더 많이 발생합니다. 실제로 테스트 모델, 프로토타입 및 회로 테스터는 이미 다른 엔지니어링 분야에서 인정받는 부분이 되었습니다. 소프트웨어 설계자가 자신의 설계를 검증하기 위해 더 공식적인 방법을 사용하지 않았거나 사용하지 않은 이유는 소프트웨어 구축 주기라는 간단한 경제 법칙이기 때문이다. (윌리엄 셰익스피어, 윈스턴, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어)
첫 번째 계시: 하나의 디자인만 구축하고 테스트하는 것이 다른 어떤 일보다 싸고 간단하다. 우리는 얼마나 많은 빌드를 구축했는지 신경 쓰지 않습니다. 이러한 빌드의 시간 비용은 거의 0 입니다. 빌드를 폐기하면 사용된 리소스를 완전히 재사용할 수 있습니다. 테스트는 현재 설계를 올바르게 만드는 것이 아니라 설계 프로세스 개선의 일부입니다. 복잡한 시스템의 하드웨어 엔지니어는 종종 모델을 만듭니다 (또는 최소한 컴퓨터 그래픽을 사용하여 디자인을 시각화합니다). 이것은 그들이 디자인에 대해 "느낌" 을 가지게 하지만, 단지 설계를 점검함으로써 이런 느낌을 얻을 수는 없다. 소프트웨어는 그러한 모델을 만들 수 없거나 필요하지 않습니다. 우리는 단지 제품 자체를 만들 뿐이다. 공식 소프트웨어 검증을 컴파일러처럼 자동화할 수 있더라도 구축/테스트 주기를 거치게 됩니다. 따라서 형식 검증은 소프트웨어 업계에 큰 실질적인 의미가 없다.
이것이 현재의 소프트웨어 개발 과정의 현실이다. 점점 더 많은 사람들과 조직이 더 복잡한 소프트웨어 설계를 만들고 있다. 이러한 설계는 일부 프로그래밍 언어로 작성된 다음 구축/테스트 주기를 통해 검증 및 개선됩니다. 이 과정은 실수하기 쉬우며, 특히 엄격하지도 않다. 상당수의 소프트웨어 개발자들은 이것이 프로세스의 작동 방식이라고 믿고 싶지 않아 문제를 더욱 복잡하게 만듭니다.
현재 대부분의 소프트웨어 프로세스는 소프트웨어 설계의 여러 단계를 여러 범주로 나누려고 합니다. 톱 레벨 설계가 동결되어야 인코딩을 시작할 수 있습니다. 테스트 및 디버깅은 구성 오류를 제거하기 위한 것입니다. 프로그래머가 중간에 있다. 그들은 소프트웨어 업계의 건축공이다. 많은 사람들은 프로그래머가' 해커' 행동을 멈추고 설계에 따라 구축 (그리고 과정에서 실수를 덜 하면) 할 수 있다면 소프트웨어 개발이 성숙해 진정한 엔지니어링 학과가 될 수 있다고 생각한다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 예술명언) 그러나, 이 과정이 공사와 경제 사실을 무시하기만 하면 이런 상황은 일어나지 않을 것이다.
예를 들어, 어떤 현대 산업도 그 제조 과정에서 100% 이상의 재작업률을 견딜 수 없다. 만약 건축공이 처음으로 자주 잘하지 못한다면, 그는 곧 직장을 잃을 것이다. 그러나 소프트웨어 업계에서는 가장 작은 코드 조각이라도 테스트 및 디버깅 과정에서 수정되거나 완전히 다시 쓰여질 수 있습니다. 디자인과 같은 창의적인 과정에서, 우리는 이러한 개선이 제조 과정의 일부가 아니라는 것을 깨달았다. 엔지니어가 처음으로 완벽한 디자인을 만들 수 있기를 기대하는 사람은 아무도 없다. 설령 그녀가 해냈다 하더라도, 그녀는 그것이 완벽하다는 것을 증명하기 위해 여전히 개선 과정을 거쳐야 한다.
비록 우리가 일본의 관리 방법에서 아무것도 배우지 않았더라도, 과정의 잘못을 노동자들에게 탓하는 것은 생산성 향상에 불리하다는 것을 알아야 한다. 우리는 항상 소프트웨어 개발이 잘못된 프로세스 모델을 따르도록 강요해서는 안 된다. 대신, 우리는 더 나은 소프트웨어의 생산을 방해하기보다는 프로세스를 개선해야 한다. 이것은 소프트웨어 공학의 시금석이다. 프로젝트는 최종 설계 문서를 생성하기 위해 CAD 시스템이 필요한지 여부가 아니라 프로세스를 구현하는 방법에 관한 것입니다.
소프트웨어 개발에 대한 압도적인 문제가 있는데, 그것은 모든 것이 설계 과정의 일부라는 것이다. 코딩은 설계, 테스트 및 디버깅이 설계의 일부이며, 일반적으로 설계는 여전히 설계의 일부라고 생각합니다. 소프트웨어 구축 비용은 매우 낮지만 설계 비용은 믿을 수 없을 정도로 높습니다. 소프트웨어는 매우 복잡하며 여러 가지 설계 내용과 설계 고려 사항이 있습니다. 문제는 모든 다른 측면이 상호 연관되어 있다는 것이다 (하드웨어 엔지니어링처럼). 최상위 설계자가 모듈 알고리즘 설계의 세부 사항을 무시할 수 있기를 바랍니다. 마찬가지로 프로그래머가 모듈 내부 알고리즘을 설계할 때 최상위 설계 문제를 고려하지 않기를 바랍니다. 불행히도, 한 디자인 수준의 문제가 다른 수준에 침입할 수 있다. 전체 소프트웨어 시스템의 성공에는 특정 모듈에 대한 알고리즘을 선택하는 것이 상위 수준의 설계 문제만큼 중요할 수 있습니다. 소프트웨어 설계의 여러 측면에서 중요도가 없는 수준입니다. 최하위 모듈의 잘못된 설계는 최상위 모듈의 오류만큼 치명적일 수 있습니다. 소프트웨어 설계는 완전해야 하며 모든 측면이 정확해야 합니다. 그렇지 않으면 이 설계를 기반으로 하는 모든 소프트웨어가 잘못된 것입니다.
복잡성을 관리하기 위해 소프트웨어는 계층적으로 설계되었습니다. 프로그래머가 한 모듈의 상세한 설계를 고려할 때, 수백 개의 다른 모듈과 수천 개의 세부 사항이 있을 수 있으며, 그는 동시에 고려할 수 없다. 예를 들어, 소프트웨어 설계에서 데이터 구조와 알고리즘의 범주에 완전히 속하지 않는 몇 가지 중요한 측면이 있습니다. 프로그래머는 코드를 디자인할 때 설계의 다른 측면을 고려하지 않는 것이 이상적입니다.
그러나, 디자인은 이렇게 작동하지 않고, 그 이유는 명확해지기 시작했다. 소프트웨어 설계는 작성 및 테스트 전에 불완전합니다. 테스트는 설계 검증 및 개선 프로세스의 기본 부분입니다. 고층 구조의 설계는 완전한 소프트웨어 설계가 아닙니다. 그것은 단지 상세하게 설계된 구조적 틀일 뿐이다. 높은 수준의 설계를 엄격하게 검증하는 우리의 능력은 매우 제한적이다. 세부 설계가 궁극적으로 상위 수준 설계에 미치는 영향은 적어도 다른 요소만큼 크거나 허용되어야 합니다. 설계를 개선하는 모든 측면은 전체 설계 주기를 관통해야 하는 과정입니다. 설계의 어떤 측면이 개선 과정 밖에서 동결되면 최종 설계가 나쁘거나 작동하지 않을 수 있다는 것은 놀라운 일이 아닙니다.
고급 소프트웨어 설계가 좀 더 엄격한 엔지니어링 프로세스가 될 수 있다면 좋겠지만 소프트웨어 시스템의 실제 상황은 엄격하지 않습니다. 소프트웨어는 매우 복잡하며, 너무 많은 다른 것에 의존한다. 일부 하드웨어는 디자이너가 생각하는 대로 작동하지 않거나 라이브러리 루틴에 문서에 해석되지 않는 제한이 있을 수 있습니다. 모든 소프트웨어 프로젝트는 조만간 이런 문제를 겪게 될 것이다. 이러한 문제들은 모두 테스트 중에 발견될 것이다. (만약 우리가 테스트를 잘 한다면) 왜냐하면 조기에 발견할 방법이 없기 때문이다. 발견되면 설계를 강제로 수정합니다. 만약 우리가 운이 좋다면, 디자인에 대한 변화는 부분적이다. 종종 변경은 전체 소프트웨어 설계의 중요한 부분 (머피의 법칙) 에 영향을 미칩니다. 영향을 받는 설계의 일부가 어떤 이유로 인해 변경될 수 없는 경우, 이러한 영향에 적응하기 위해서는 설계의 다른 부분을 파괴해야 합니다. 이로 인해 일반적으로 관리자가 "임의 코딩" 이라고 생각하는 경우가 많지만 이것이 소프트웨어 개발의 현실입니다.
예를 들어, 최근에 참여한 프로젝트에서 모듈 A 의 내부 구조와 다른 모듈 B 사이의 시간 의존성을 발견했습니다. 불행히도 모듈 A 의 내부 구조는 하나의 추상체 뒤에 숨겨져 있습니다. 이 추상체는 모듈 B 에 대한 호출을 어떤 방식으로도 정확한 호출 시퀀스로 결합할 수 없습니다. 문제를 발견할 때 당연히 A 의 추상체를 바꿀 기회를 놓쳤다. 예상대로, A 의 내부 설계에 점점 더 복잡한' 수정' 을 적용하는 일이 발생했다. 우리가 아직 1 버전을 설치하지 않았을 때, 디자인이 내리막길을 걷고 있다는 것이 보편적으로 느껴졌다. 매번 새로운 개정판마다 낡은 것을 파괴할 수 있다. 이것은 공식적인 소프트웨어 개발 프로젝트이다. 결국, 동료들과 나는 디자인을 바꾸기로 결정했지만, 경영진의 승인을 받기 위해 우리는 자발적으로 야근을 해야 했고, 보수가 없었다.
어떤 대규모 소프트웨어 프로젝트에서든 이런 문제는 불가피하다. 사람들은 이미 여러 가지 방법으로 그것의 출현을 막았지만, 여전히 몇 가지 중요한 세부 사항을 간과했다. 이것이 바로 기술과 공학의 차이다. 경험이 우리를 올바른 방향으로 인도할 수 있다면 이것이 기술이다. 경험이 우리를 알 수 없는 분야로만 인도한다면, 우리는 우리가 처음에 사용했던 방법을 사용하고 제어된 개선 과정을 통해 그것을 더 좋게 만들어야 한다. 이것이 바로 엔지니어링이다. (알버트 아인슈타인, 경험명언)
한번 봅시다. 그 중 작은 부분으로서, 모든 프로그래머들은 이전에 소프트웨어 설계 문서를 작성하지 않고 인코딩한 후에 더 정확한 문서를 만들 수 있다는 것을 알고 있습니다. (윌리엄 셰익스피어, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머) 그 이유는 분명합니다. 코드로 표현된 최종 설계는 구축/테스트 주기 중 유일하게 개선된 것입니다. 이 주기 동안 초기 설계가 변경되지 않을 가능성은 프로젝트의 모듈 수와 프로그래머 수에 반비례합니다. 곧 쓸모 없게 될 것입니다.
소프트웨어 엔지니어링에서, 우리는 모든 수준의 우수한 디자인이 필요하다. 우리는 특히 우수한 최상층 디자인이 필요하다. 초기 설계가 좋을수록 상세 설계가 쉬워집니다. 디자이너는 도움이 되는 것은 무엇이든 사용해야 한다. 맵, 부치도, 상태표, PDL 등 -도움이 된다면 쓰세요. 그러나 이러한 도구와 기호는 소프트웨어 설계가 아니라는 점을 기억해야 합니다. 마지막으로, 우리는 진정한 소프트웨어 설계를 만들어야 하며, 프로그래밍 언어로 완성해야 한다. 그래서 우리가 디자인을 시작할 때, 우리는 코드를 두려워해서는 안 된다. 우리는 필요할 때 그것들을 개선하기를 원해야 한다.
지금까지 톱 레벨 설계와 세부 설계에 모두 적용할 수 있는 설계 기호는 없습니다. 디자인은 결국 프로그래밍 언어로 작성된 코드로 표현될 것이다. 즉, 세부 설계가 시작되기 전에 톱 레벨 설계 기호를 대상 프로그래밍 언어로 변환해야 합니다. 이 변환 단계는 시간이 걸리고 오류가 발생합니다. 프로그래머는 선택한 프로그래밍 언어와 완전히 매핑되지 않을 수 있는 기호에서 변환하는 대신 요구 사항을 검토하고 최상위 설계를 재설계한 다음 실제 상황에 따라 인코딩하는 경우가 많습니다. 이것은 또한 소프트웨어 개발 현실의 일부이다.
아마도 디자이너가 다른 사람이 나중에 언어와 무관한 디자인을 개조하게 하는 대신 초기 코드를 직접 쓰면 더 좋을 것 같다. (윌리엄 셰익스피어, 윈프리, 독서명언) 우리가 필요로 하는 것은 모든 수준의 설계에 적합한 통일된 기호이다. 즉, 높은 수준의 디자인 개념을 캡처하는 데 적합한 프로그래밍 언어가 필요합니다. C++ 는 이 요구 사항을 정확히 충족합니다. C++ 는 실제 프로젝트에 적합한 프로그래밍 언어이자 표현력이 뛰어난 소프트웨어 설계 언어입니다. C++ 를 사용하면 설계 어셈블리에 대한 고급 정보를 직접 표현할 수 있습니다. 이렇게 하면 설계를 더 쉽게 할 수 있으며 앞으로 설계를 더 쉽게 개선할 수 있습니다. 더 강력한 유형 검사 메커니즘을 가지고 있기 때문에 설계 오류를 탐지하는 데도 도움이 됩니다. 이로 인해 더욱 견고한 설계가 이루어졌는데, 이것은 사실상 더 나은 엔지니어링 설계이다.
마지막으로 소프트웨어 설계는 프로그래밍 언어로 표현된 다음 구축/테스트 주기를 통해 검증 및 개선되어야 합니다. 그 외의 어떤 생각도 전혀 쓸모가 없다. 어떤 소프트웨어 개발 도구와 기술이 유행하는지 생각해 보세요. 구조화 프로그래밍은 당시 창의적인 기술로 여겨졌다. 파스칼은 그것을 유행시켰고, 그로 인해 스스로도 유행하게 되었다. 객체 지향 설계는 새롭게 부상하는 인기 기술이며, C++ 는 그 핵심이다. 지금, 그 무효한 일들을 고려해 보세요. 사례 도구, 유행인가요? 있습니다. 보편성을 가지고 있습니까? 아니요. 구조도는 어때요? 상황은 똑같다. 마찬가지로 워너 오르투, 부치투, 대상도 있고, 당신이 생각할 수 있는 모든 것도 있습니다. 각각은 자신의 장점을 가지고 있고, 단 하나의 근본적인 약점만 있다. 그것은 진정한 소프트웨어 디자인이 아니다. (알버트 아인슈타인, 자기관리명언) 사실, 보편적으로 인정받는 유일한 소프트웨어 디자인 기호는 PDL 인데, 그것은 무엇처럼 보입니까?
이는 * * * 소프트웨어 업계의 중요성이 압도적이라는 것을 보여준다. 프로그래밍 기술, 특히 실제 개발에 사용되는 프로그래밍 언어의 향상은 소프트웨어 업계에서 무엇보다 중요하다. 프로그래머가 디자인에 관심이 있다는 것을 보여줍니다. 소프트웨어 개발자는 보다 표현적인 프로그래밍 언어가 나타날 때 이를 사용합니다.
마찬가지로 소프트웨어 개발 프로세스가 어떻게 변경되었는지 고려해 보십시오. 예전에 우리는 폭포 과정을 사용했다. 자, 우리는 나선형 개발과 신속한 프로토타입에 대해 이야기하고 있습니다. 이러한 기술은 종종 "위험 제거" 및 "제품 배송 시간 단축" 으로 간주되지만 실제로는 소프트웨어 수명주기 초기에 코딩을 시작하기 위한 것입니다. 이것은 좋은 일이다. 이를 통해 구축/테스트 주기가 설계 검증 및 개선을 더 일찍 시작할 수 있습니다. 이것은 또한 최고의 소프트웨어 디자이너가 상세한 설계를 할 가능성이 높다는 것을 의미한다.
앞서 언급한 바와 같이, 공사는 최종 제품이 어떻게 생겼는지보다는 프로세스를 실현하는 방법에 대해 더 많이 다루고 있다. 소프트웨어 산업에서, 우리는 이미 엔지니어의 기준에 접근했지만, 약간의 인지적 변화가 필요하다. 프로그래밍 및 구축/테스트 주기는 엔지니어링 소프트웨어 프로세스의 중심입니다. 우리는 이런 방식으로 그것들을 관리해야 한다. 구축/테스트 주기의 경제 법칙과 소프트웨어 시스템이 거의 모든 것을 대표할 수 있다는 사실은 소프트웨어 설계를 검증할 수 있는 일반적인 방법을 찾을 수 없습니다. 우리는 이 과정을 개선할 수는 있지만, 그것을 벗어날 수는 없다.
마지막 요점: 모든 엔지니어링 프로젝트의 목표는 일부 문서 제품입니다. 실제로 설계된 문서가 가장 중요한 것은 분명하지만, 제작해야 할 유일한 문서는 아닙니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 결국, 누군가는 이 소프트웨어를 사용할 것이다. 마찬가지로 이 시스템에는 후속 수정 및 향상이 필요할 가능성이 높습니다. 즉, 보조 문서는 소프트웨어 및 하드웨어 프로젝트만큼 중요합니다. 사용 설명서, 설치 가이드 등 설계 프로세스와 직접적인 관련이 없는 문서는 일시적으로 무시되지만 보조 설계 문서를 사용하여 해결해야 하는 두 가지 중요한 요구 사항이 있습니다.
보조 문서의 첫 번째 목적은 문제 공간에서 중요한 정보를 캡처하는 것입니다. 이 정보는 설계에 직접 사용할 수 없습니다. 소프트웨어 설계에서는 문제 공간의 개념을 모델링하기 위해 소프트웨어 개념을 만들어야 합니다. 이 과정은 우리가 문제 공간의 개념을 이해해야 한다. 일반적으로 이러한 이해에는 소프트웨어 공간에서 직접 모델링하지 않는 정보가 포함되지만 디자이너는 기본 개념이 무엇인지, 가장 잘 모델링하는 방법을 결정하는 데 도움이 됩니다. 나중에 모델을 변경하려는 경우에 대비하여 이 정보를 어딘가에 기록해야 합니다.
보조 문서의 두 번째 중요한 요구사항은 설계 자체에서 직접 추출하기 어려운 설계의 일부 측면을 기록하는 것입니다. 상위 수준 컨텐츠 또는 하위 수준 컨텐츠일 수 있습니다. 이러한 많은 면에서 그래픽은 이러한 측면을 설명하는 가장 좋은 방법입니다. 이로 인해 코드에 주석으로 포함하기가 어렵습니다. 프로그래밍 언어 대신 그래픽 소프트웨어 디자인 기호를 사용해야 한다는 뜻은 아닙니다. 이는 몇 가지 문자 설명으로 하드웨어 과목을 보완하는 그래픽 디자인 문서와 다르지 않다.
실제 디자인의 실제 모습을 결정하는 것은 보조 문서가 아니라 소스 코드라는 것을 결코 잊지 마십시오. 소프트웨어 도구를 사용하여 소스 코드를 사후 처리하여 보조 문서를 생성하는 것이 좋습니다. 우리는 이것에 대해 너무 많이 기대할 수 있다. 다음으로 프로그래머 (또는 기술 작성자) 는 소스 코드에서 특정 정보를 추출할 수 있는 도구를 사용하여 다른 방식으로 기록할 수 있습니다. 이러한 문서를 수동으로 업데이트하는 것은 매우 어렵다는 것은 의심의 여지가 없습니다. 이것은 더 표현력이 필요한 프로그래밍 언어를 지지하는 또 다른 이유이다. 마찬가지로, 이 보조 문서를 최소한으로 유지하고 프로젝트에서 가능한 한 늦게 공식화할 수 있도록 지원하는 이유이기도 합니다. 마찬가지로, 우리는 좋은 도구를 사용할 수 있습니다. 그렇지 않으면, 우리는 연필, 종이, 칠판에 도움을 청해야 한다.
요약은 다음과 같습니다.
실제 소프트웨어는 컴퓨터에서 실행됩니다. 일종의 자기 매체에 저장된 0 과 1 의 시퀀스입니다. C++ (또는 다른 프로그래밍 언어) 로 작성된 프로그램이 아닙니다.
프로그램 목록은 소프트웨어 설계를 나타내는 문서입니다. 실제로 컴파일러와 커넥터가 소프트웨어 설계를 구축했습니다.
믿을 수 없는 것은 실제 소프트웨어 설계를 구축하는 것이 얼마나 저렴한지, 그리고 컴퓨터 속도가 빨라짐에 따라 항상 더 싸게 변한다는 것이다. (윌리엄 셰익스피어, 윈스턴, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어)
실제 소프트웨어를 설계하는 데 드는 비용은 믿을 수 없습니다. 소프트웨어의 복잡성은 믿을 수 없고 소프트웨어 프로젝트의 거의 모든 단계가 설계 프로세스의 일부이기 때문입니다.
프로그래밍은 일종의 설계 활동이다. 좋은 소프트웨어 설계 과정은 이 점을 인식하고, 코딩이 의미가 있을 때 주저하지 않고 코딩한다.
코드는 우리가 생각했던 것보다 더 자주 그것의 의미를 보여준다. 일반적으로 코드로 설계를 표현하는 과정은 누락과 추가 설계 요구 사항을 노출시킵니다. 이런 상황이 일찍 발생할수록 디자인이 좋아진다.
소프트웨어가 매우 저렴하기 때문에 공식적인 엔지니어링 검증 방법은 실제 소프트웨어 개발에 유용하지 않습니다. 단지 하나의 디자인을 만들고 그것을 테스트하는 것이 그것을 증명하려고 시도하는 것보다 더 간단하고 저렴하다. (존 F. 케네디, 디자인명언)
테스트 및 디버깅은 설계 활동입니다. 소프트웨어의 경우 다른 엔지니어링 분야의 설계 검증 및 개선 프로세스와 같습니다. 좋은 소프트웨어 설계 프로세스는 이를 인식하고 이러한 단계를 줄이려고 시도하지 않습니다.
고위층 설계, 모듈 설계, 구조 설계, 아키텍처 설계 등 다른 설계 활동도 있습니다. 좋은 소프트웨어 설계 프로세스는 이를 인식하고 이러한 단계를 신중하게 포함합니다.
모든 디자인 활동은 상호 작용합니다. 서로 다른 설계 단계가 필요성을 나타낼 때 좋은 소프트웨어 설계 프로세스가 이를 인식하고 설계 변경을 허용하며 때로는 근본적인 변경까지 허용합니다.
많은 다른 소프트웨어 설계 기호가 유용할 수 있습니다. 보조 문서 및 도구로 설계 프로세스를 단순화할 수 있습니다. 소프트웨어 설계가 아닙니다.
소프트웨어 개발은 여전히 공예이지 공학 학과가 아니다. 주로 설계를 검증하고 개선하는 중요한 과정에서 엄격하지 않다.
마지막으로, 소프트웨어 개발의 진정한 발전은 프로그래밍 기술의 진보에 달려 있으며, 프로그래밍 기술의 진보는 프로그래밍 언어의 진보를 의미합니다. C++ 는 이러한 개선입니다. 더 나은 소프트웨어 설계를 직접 지원하는 메인스트림 프로그래밍 언어이기 때문에 폭발적인 인기를 얻었습니다.
C++ 는 이미 올바른 방향으로 한 걸음 내딛었지만 더 많은 발전이 필요하다.