좀 더 표현적인 프로그래밍 언어가 발전함에 따라 소프트웨어 설계 사양의 필요성이 크게 줄었습니까?

몇 년 전에 저를 포함한 많은 IT 직원들에게 이상적인 소프트웨어 개발 프로세스에는 코드 줄을 작성하기 전에 많은 UML 다이어그램이 포함 된 상세 설계 문서를 작성하는 것이 포함됩니다. (이것은 폭포 모델에 대한 설명처럼 보이지만 반복이 더 작다는 점을 제외하면 민첩성과 동일합니다.)

지난 2 ~ 3 년간 나는 마음을 완전히 바꿨습니다. 관련 테스트 사례와 함께 자세한 요구 사항 사양이 반드시 필요하다고 생각합니다. 대규모 프로젝트의 경우 코딩을 시작하기 전에 전체 아키텍처에 대한 개요가 필요합니다. 그러나 나머지는 가능한 한 코드로 수행해야합니다. 이상적인 경우에는 코드 자체를 제외하고 소프트웨어 디자인에 대한 설명이 없어야합니다.

이 결론을 어떻게 얻었습니까? 다음은 몇 가지 주장입니다.

피드백

문서 작성 또는 다이어그램 작성 도구는 거의 피드백을 제공하지 않습니다. 예, UML 다이어그램에 대한 일관성 검사를 수행하는 모델링 도구가 있지만 제한적이고 많은 오버 헤드가 있습니다.

피드백이 없으면 오류를 인식하고 수정하기가 어렵습니다.

코드를 작성하자마자 다음과 같은 많은 피드백을받습니다.

• 컴파일러의 오류 및 경고
• 정적 코드 분석 결과
• 단위 테스트

오류를 신속하게 인식하고 수정할 수 있습니다.

일관성

코드가 문서와 일치하는지 확인하려면 다시 확인해야합니다. 자주 변경하면 코드와 문서를 동기화하기가 어렵습니다.

리팩토링

텍스트 설명이나 다이어그램을 리팩토링하는 것은 일반적으로 어렵고 오류가 발생하기 쉬운 코드 리팩토링을위한 강력한 도구와 기술이 있습니다.

이 작업을 수행하려면 하나의 전제 조건이 있습니다. 코드는 읽고 이해하기에 충분히 쉬워야합니다. 아마도 어셈블러, 기본 또는 포트란으로는 달성 할 수 없지만 현대 언어 (및 라이브러리)는 훨씬 표현력이 좋습니다.

따라서 제 주장이 유효하다면, 소프트웨어 설계 사양과 문서가 다소 가벼운 경향이 있습니다. 이 추세에 대한 경험적 증거가 있습니까?

나는 언어가 점점 더 표현력이 있다는 전제에 의문을 제기한다. c #에서 오늘의 ASP.NET 코드를 사용하면 Visual Basic에서 ASP 코드를 작성할 때와 거의 같은 수준으로 작성합니다. 우리는 여전히 C ++을 사용합니다. Javascript에 기능이 추가되었지만 언어는 변경되지 않았습니다. SQL과 동일합니다.

다른 변경 사항이 더 중요하다고 생각합니다.

1. 자동화 된 단위 테스트 채택. 일부는 테스트 가 사양 이라고 말합니다 . 따라서 스펙 작성의 필요성을 제거하지 않았습니다. 오히려 Word 문서가 아닌 코드로 작성합니다.

2. 배포 방법이 변경되었습니다. 과거에는 업데이트 된 소프트웨어 사본을 배송해야했기 때문에 실수하는 데 비용이 많이 듭니다. 따라서 조심해야합니다. 웹 기반 응용 프로그램을 사용하면 즉시 사용할 수 있도록 수정 프로그램을 배포 할 수 있으며 문제를 예상하지 않고 대응하여 코드를 재구성 할 수 있습니다.

3. 디자인 패턴 채택. 모두가 패턴을 알면 아무것도 디자인 할 필요가 없습니다. "리포지토리 팩토리 추가"라고 말하면 팀이 UML을 보지 않아도해야합니다.

4. SOA의 데이터 계약. 요즘 거의 모든 것이 SOA입니다. WSDL 만 있으면됩니다. 데이터 전송 형식을 정의하고 문서화하는 시대는 지났습니다. 보다 RESTful 및 마이크로 서비스로의 현재 이동은 이러한 추세를 계속합니다.

5. 소프트웨어가 더 작습니다. SOA 아키텍처의 결과로, 팀은 함께 묶여있는 더 작은 프로그램을 작성하고 있습니다. 각 개별 구성 요소는 덜 복잡하고 초기 설계가 덜 필요합니다. 또한 구성 요소 간의 인터페이스 정의로 인한 화재로 인해 전체 솔루션을 중단하지 않고도 아키텍처의 일부를 쉽게 변경할 수 있습니다.

6. 기존 라이브러리를 훨씬 더 많이 사용합니다. .NET CLR은 다양한 기능을 제공하므로 세션 데이터 캐싱을위한 계획을 설계 할 필요가 없습니다. jQuery UI 또는 Bootstrap과 같은 타사 라이브러리는 특정 방식으로 작동하는 코드 작성 표준을 설정합니다. 이것들을 문서화 할 필요는 없습니다. 팀은 그것들을 사용할 수 있어야합니다.

7. 산업 성숙도. SWE는 "Battlestar Galactica"프로젝트가 특정 목표에 도달하기 위해 몇 년과 몇 년을 보내는 프로젝트는 없다는 것을 배웠습니다. 그 세월이지나면서 목표가 바뀌었을 것입니다. 오늘날 우리는 디자인에서 원하는 방식대로 모든 것을 얻는 것보다 출시 시간이 훨씬 중요하다는 것을 알고 있습니다.

8. 더 좋고 일관되게 교육받은 엔지니어. 요즘 베스트 프랙티스를 이해하는 엔지니어를 고용 할 수 있으며, 설계 문서없이 수행 할 작업을 구현할 수 있습니다.

9. TFS와 같은 생산성 도구를 사용하면 사용 사례를 참조하고 모호한 기술 결정에 대한 몇 가지 요점을 제공하는 간단한 작업을 작성할 수 있습니다. 그 이상은 필요하지 않습니다. 개발자는 도구를 통해 모든 것을 검토, 추정, 코드 검토, 체크인 등을 할 수 있습니다. 이것은 모든 것을 하나로 묶기 때문에 외부 문서로 작업하는 것보다 훨씬 효율적입니다.

예를 들어, 응용 프로그램이 다른 팀에서 개발 한 다른 구성 요소로 분할 된 경우에는 최소한 어떤 구성 요소가 어떤 요구 사항을 담당하는지 알려 주어야합니다. 그러나 대부분의 경우 오늘날의 개발 방법론은 훨씬 더 많은 자유를 허용하는 동시에 개발자가 잘못된 결정을 내릴 때 발생할 수있는 위험을 관리하고 포함 할 수있는 도구를 제공합니다.

나는 아니오를 주장 할 것이다 .

간단한 이유로

몇 년 전에 저를 포함한 많은 IT 직원들에게 이상적인 소프트웨어 개발 프로세스에는 코드 줄을 작성하기 전에 많은 UML 다이어그램이 포함 된 상세 설계 문서를 작성하는 것이 포함됩니다.

익스트림 프로그래밍은 1990 년대부터 존재 해 왔기 때문에 결코 "이상적인"것으로 간주되지 않았습니다 . 그리고 당신이 말한대로 :

이상적인 경우에는 코드 자체를 제외하고 소프트웨어 디자인에 대한 설명이 없어야합니다.

몇 년 전에 주장되었습니다. 예를 들어 1992 년이 전설적인 기사 : 소프트웨어 설계 무엇입니까 .

위의 내용은 복잡한 언어 나 IDE없이 고도로 진화 된 아키텍처와 반복적 인 접근 방식으로 "극단적 인"프로세스를 수행 할 수 있음을 보여줍니다.

대신,이 "추측"은 많은 다이어그램과 사용 사례 문서가있는 설계 초기 단계에서 더 진화적이고 반복적 인 접근 방식은 단순히 "구식"관리자가 새로운 관리자로 대체되어 훨씬 더 많이 성장했다고 말합니다. 역동적 인 환경과보다 "민첩한"환경에서 작업하기가 훨씬 쉬운 사람.

나는 이것에 거의 동의하지만 그것이 당신이 암시하는 것보다 훨씬 일찍 시작되었다고 생각합니다. 또한 표현 성과는 별도로 또 다른 큰 요소가 있다고 생각합니다. 아버지는 처음 프로그래밍을 시작했을 때 펀치 카드를 작성하고 컴퓨터에서 시간을 예약해야했습니다. 프로그램을 실행할 기회는 하루에 한 번입니다. 건물 코드를 낭비하고 실패하게 한 다음 수정해야 할 시간이 많지 않았습니다. 당신은 그것에 2 또는 3 발의 탄을 얻었다. 그것이 작동하지 않으면, 당신은 곤경에 빠졌다.

이 위험은 프로그램을 계획하는 데 많은 시간을 소비하는 것이 중요하다는 것을 의미했습니다. 사람들은 자신의 코드를 연필로 쓴 다음 천공 카드로 옮길 것입니다. 기술이 발전함에 따라 터미널에 바로 코드를 작성할 수 있었지만 여전히 공유 리소스를 사용하고 있었고 CPU가 비쌌습니다. 테스트 우선 방법론은 그 세계에서 완전히 불가능합니다. 미리 계획하지 않았다면 동료들은 책상에 갈퀴를 가지고있을 것입니다.

컴퓨팅 리소스는 놀라운 속도로 저렴하고 향상되었습니다. 이러한 모든 관행이 개발 된 많은 제약이 완전히 사라졌습니다. Euphoric이 지적했듯이, 이것으로부터의 이동은 실제로 90 년대에 시작되었습니다. 큰 초기 설계의 많은 부분이 순수한 관성이었다.

따라서 프로그래밍 언어의 표현력이 향상되면 표현 코드를 자체 문서로 사용하는 것이 더 쉽다는 단순한 사실 때문에 이에 영향을 미쳤습니다. 코드가 말하는 것을 알려주는 문서를 만드는 비용은 매우 높으며 그 가치는 (어떤 수준에서는 필연적으로 잘못되었습니다.) 동시에 벽에 똥을 던지고 막대기를 보는 비용은 기본적으로 무시할 수 있습니다.

처음부터 디자인 문서를 작성한다는 목적을 잊어 버린 것 같습니다.

설계 문서 (요구 사항, 사용 사례, 모형 등)를 통해 시스템을 상세하게 설명하고 이해하고 토론 할 수 있습니다. 그러한 문서에서 남은 세부 사항의 양은 유용하게 만듭니다.

실제로 소스 코드 자체가이 목적을 달성하기 때문에 모든 세부 사항 에서 시스템 시스템의 정확한 동작을 설명하는 문서가 필요하지 않습니다 .

소프트웨어 개발은 ​​사람이 읽을 수있는 높은 수준의 사양을 기계가 실행할 수있는 낮은 수준의 명확한 사양으로 변환하는 프로세스로 간주 될 수 있습니다. 그러나이 프로세스에는 약간의 입력 이 필요 합니다.

이상적인 경우에는 코드 자체를 제외하고 소프트웨어 디자인에 대한 설명이 없어야합니다.

이것은 당신이 암시하는 것보다 더 떨어져 있습니다. 의존적 유형과 같은 것조차도 (이론적으로 이론적으로 유망한) 수년이 지났습니다.

공식 검증은 매우 어렵 기 때문에 공식 검증이 일반적으로 사용되는 유일한 장소는 암호화 라이브러리입니다.

단위 테스트

만약 부동산 테스트가 주류에 미치지 못했다면, 이것이 오랫동안 실용적이지 않을 것이라고 생각합니다.

또한, 모든 리 팩터로 편집 할 필요는 없지만 여전히 충분한 오류를 잡을 수있는 좋은 테스트를 작성하는 것은 매우 어렵습니다.

코드가 문서와 일치하는지 확인하려면 다시 확인해야합니다. 자주 변경하면 코드와 문서를 동기화하기가 어렵습니다.

현재 문서 테스트 도구를 사용하는 것이 더 쉬울 것입니다.

이 작업을 수행하려면 하나의 전제 조건이 있습니다. 코드는 읽고 이해하기에 충분히 쉬워야합니다.

불행히도, 표현력이 뛰어나고 읽기 쉬운 언어를 디자인하는 것은 어렵습니다. Go와 같은 언어는 가독성을 우선시하며 더 높은 수준의 사고를 방해합니다.

마지막으로 제 경험상 언어와 툴링이 향상되면 버그가 적은 소프트웨어가 아니라 더 큰 프로젝트로 이어집니다. pandoc1970 년에 실제로 그럴듯한 방법 은 없었습니다.