에 없음 실버 총알 , 프레드 브룩스 가장으로 요약 소프트웨어 공학의 미래에 대한 예측의 다양한 있습니다 :
기술 또는 관리 기술에있어 단일 개발만으로는 생산성, 신뢰성, 단순성에서 1 배의 크기 향상 을 약속 합니다.
그의 주장은 매우 설득력이 있습니다. Brooks는 1986 년에 글을 썼습니다. 2014 년 개발자는 1986 년에 비해 소프트웨어를 10 배 미만의 속도로 생산합니까? 적절한 측정 기준으로 실제로 생산성이 얼마나 큰가?
답변:
2014 년 개발자는 1986 년에 비해 소프트웨어를 10 배 미만의 속도로 생산합니까?
그 이후로 최소한 생산성이 크게 향상되었다고 생각합니다. 그러나 기술 또는 관리 기술에서 하나의 단일 개발을 활용하는 것은 아닙니다 .
여러 요인으로 인해 생산성이 향상되었습니다. 참고 : 다음은 포괄적 인 목록이 아닙니다.
등등. 이러한 기술은 모두 생산성 향상을 위해 결합됩니다. 단 한 번의 속도 향상을 가져온 단일 은색 총알은 없습니다.
이 기술 중 일부는 60 년대 이래 존재했지만 최근에 널리 인식되고 채택 된 것으로 나타났습니다.
Robert Harvey의 대답은 좋지만 프로그래머가 생산성을 향상시키는 가장 큰 이유 인 소프트웨어 라이브러리의 광범위한 가용성을 제외했다고 생각합니다.
내가 경력을 시작했을 때 STL, .NET, QT 등은 없었습니다. 당신은 원시 C 또는 C ++을 가지고 있었고 그 정도였습니다.
며칠 또는 몇 주 또는 작업 (XML 구문 분석, TCP / IP 연결, HTTP 통신)에 사용 된 작업을 이제 몇 줄의 C # 코드로 수행 할 수 있습니다. 여기에서 전반적인 개발자 생산성 측면에서 수십 배가 향상되었습니다.
현재 제품은 공급 업체로부터 구매 한 도킹 윈도우 프레임 워크를 사용합니다. 이를 통해 몇 분 안에 완전히 작동하는 도킹 윈도우 UI를 사용할 수 있습니다. 나는 win32 API를 사용하는 날에 그렇게 할 것이 무엇인지 생각하고 떨었습니다.
people just found other (generally better) solutions[인용 필요]. 라이브러리를 사용하여 XML의 "산"을 빠르게 구문 분석하는 것은 여러 가지면에서 고유 한 솔루션을 직접 코딩하는 것보다 낫습니다. XML은 확실히 간결하고 반복적 일 수 있지만, 라이브러리는 대부분의 상황에서 XML을 사용하는 것을 매우 쉽게 만듭니다.
논쟁을 위해, 나는 Fred Brooks의 주장에 동의하지 않습니다 .
인터넷의 생산성 , 그리고 지난 20 년 동안 모든 가정에서 인터넷 연결의 점진적인 가용성을 향상시키는 기술의 향상이 있습니다 .
개발자가 겪을 수있는 거의 모든 문제에 대한 해답을 즉시 찾을 수 있으면 생산성이 크게 향상됩니다. JQuery에서 n 번째 요소를 선택하는 방법을 모르십니까? Google 검색은 스택 오버플로에 대한 정확한 질문에 대한 답변을 제공 합니다 . overflowCSS 에서 사용하는 방법을 모르 십니까? Mozilla의 MDN은 여기에 있습니다 . virtualC #에서 키워드의 의미를 잊었 습니까? Google이 다시 도움을줍니다 .
프로그래밍을 시작했을 때 인터넷이 없었습니다. 책과 함께 일부 디지털 형식의 문서를 로컬에 저장했지만 책과 문서를 검색하는 과정은 느리게 진행되었으며, 책 수에 관계없이 언급되지 않은 많은 문제가있었습니다.
더 중요한 것은, 당신이 겪는 거의 모든 문제는 이미 다른 누군가가 이미 경험 한 것입니다. 인터넷은이 오류가 발생하여 성공적으로 해결 한 사람들을 찾는 데 도움이됩니다. 이것은 MSDN과 같은 책이나 공식 문서에서 찾을 수있는 일종의 정보가 아닙니다. 대신 이러한 정보는 대개 다음과 같습니다.
스택 오버플로에서 분명히. 예를 들어, 나는 이 문제 를 언급 한 어떤 책도 보지 못했다 .
블로그에서. 나는 발견 많은 내가 특별한 문제가 있었다 때 WCF 구성 또는 EN-US에서 문화 다른있는 컴퓨터에서 특정 API를 사용할 때 시작하거나 비밀 버그하지 않는 프록시 서버와 것, 블로그에 도움을.
오픈 소스 소프트웨어에 관한 버그 보고서. 예를 들어, Ubuntu의 MAAS를 사용하려고 할 때와 PXE를 사용할 때 최근에 매우 도움이되었습니다. 책에서도 이런 종류의 정보를 찾을 수 없습니다.
팀이 프로젝트에 소비하는 대부분의 시간이 프로젝트를 유지 하는 데 소비된다는 점을 고려할 때 발생할 수있는 대부분의 문제에 대한 즉각적인 답변 제공의 중요성은 특히 두드러집니다 .
인터넷은 아키텍처 및 디자인 단계에서 많은 도움이되지 않습니다 (Programmers.SE는 도움이 될 수 있지만, 건축가가 아키텍처 및 디자인에 관한 책을 읽고 디자인 패턴 등을 배우는 것이 훨씬 더 가치가있을 것입니다).
실제 문제가 발생할 때 테스트 및 구현 단계에서 도움이되기 시작합니다.
그러나 유지 관리 중에 나타나는 대부분의 문제는 인터넷을 통해 다른 사람의 도움이 중요하게 나타나는 시점 입니다. 기본 예 : WCF 서비스는 내 컴퓨터 에서 완벽하게 작동 하지만 프로덕션 환경에 배포 할 때 예외없이 마지막 2 주 동안 작동했습니다. 이 문제는 저에게 일어 났으며 몇 주가 아니라 몇 시간 안에 문제를 해결하는 데 도움을 주신 블로그 작성자와 Stack Overflow 커뮤니티에 감사합니다.
x10의 생산성 향상을 정당화 할 수 있습니까? 말하기 어렵다.
한편으로는 즉시 답변을 찾을 수 있지만 혼자서 검색하는 데 며칠을 보냈을 수도 있고 (또는 응용 프로그램의 많은 부분을 다시 작성해야 할 수도 있습니다).
반면, 프로젝트 관리 개선 (애자일, TDD 등), 팀 관리 개선 ( 스티븐 데닝의 급진적 관리 ), 더 나은 도구 (디버거, 프로파일 러) 와 같은 여러 요소를 기반으로 전반적인 생산성이 향상되었습니다. , IDE 등), 더 나은 하드웨어 (아니오, 느린 CPU와 매우 제한된 RAM을 위해 어셈블러에서 강제로 쓰면 생산성이 떨어질 것입니다) 등
인터넷은 꽤 좋은 후보라고 말하고 싶습니다. StackOverflow와 Google은 현대 개발자의 가장 강력한 도구입니다. 전 세계적으로 즉각적인 지식 공유! 요즘에는 답변을 알 필요가 없으며 답변을 얻는 방법 만 알면됩니다 . 개발자가 읽기 및 코딩에 더 많은 시간을 할애하여 생산성을 높일 수있는 완벽한 대안입니다. 이는 전 세계의 모든 프로그래머가 모든 답변에 액세스 할 수 있으며 올바른 질문을하는 방법을 알아야한다는 것입니다.
다른 방향으로 (즉, 낮은 생산성으로) 끌어 당기는 트렌드는 적어도 당신이 요청한 트렌드만큼 강력하다고 제안합니다. VB6 또는 PowerBuilder와 같은 클라이언트 / 서버 개발 도구를 사용한 경험은 "Rapid Application Development"(RAD) 이상에 매우 가깝습니다. 양식을 작성해야하고 절차 또는 SQL 코드에 대한 확실한 연결 고리가있었습니다.
웹 개발은 적어도 초기에 이러한 기술을 가능하게하는 많은 기술과 인프라를 파괴했으며 많은 클라이언트 / 서버 개발자는 개발자가되는 것을 중단했거나 VB6에 필사적으로 매달 렸습니다.
클라이언트 중심의 웹 개발로의 전환은 또 다른 슬래시 앤 번 경험이었습니다. Microsoft는 WebForms를 통해 RAD의 이상을 되찾았고 그 후 빠르게 유리하지 않았습니다. 대신 개발자는 인프라 (예 : XML에 거의 사용되지 않는 XMLHttpRequest)를 악용하고 그렇지 않으면 웹 사이트를보다 대화식으로 만들기 위해 낮은 수준의 추상화로 원숭이를 움직여야합니다.
이러한 모든 전환의 배후에는 정당한 이유가 있으며, 개별 .EXE (개별 클라이언트의 설치 및 관리 필요)를 생성 한 프로세스와 웹 개발을 비교하는 것은 공평하지 않으며, 크게 의존하는 프로세스를 비교하는 것도 공정하지 않습니다. 보다 원활한 경험을 제공하는 포스트 백에 그러나 현재 유행하고있는 관행은 클라이언트 / 서버, RAD 등을 놓친 사람들 사이에서 놀랍게도 낮은 수준의 사고 과정을 초래한다고 말할 것입니다. 클라이언트 / 서버 버튼은 방금 작동했으며,이를 위해 이벤트 처리기로 데이터를 가져 오는 기본 데이터 채널에 대해 걱정할 필요가 없었습니다.
반대로, 더 현대적인 개발자들은 클라이언트 / 서버 개발 (또는 포스트 백 기반 웹 개발)을 한 우리 개발자들은 지름길에 의존하는 경향이 있다고 생각하는 경향이 있습니다 (나쁜 방식으로). 이해할 수는 있지만, 현대의 발전 방식은 놀랍게도 낮은 수준이며, "은 총알"을 찾는 시대는 광업과 우리 자신의 단을 제련.
기술은 매우 발전했으며 이제 Robert Harvey가 그의 답변에 열거 한 모든 것을 가지고 있지만
문제는 변화하는 요구 사항 인 것 같습니다 . 클라이언트는 소프트웨어 프로젝트의 요구 사항을 변경할 때 재료 낭비가 없다는 것을 알고 있습니다. 빌딩과 같은 물리적 세계 프로젝트가 절반 만 완료되면 이런 종류의 요구 사항 변경은 거의 일어나지 않습니다.
또 다른 중요한 측면은 프로그래밍이 계속 높은 기술력이라는 것 입니다 . RAD에서 생성 된 코드는 손으로 직접 수정하지 않고 프로덕션에 들어가는 경우가 거의 없습니다.
코드는 계속 복잡 하고 새로운 기술로 복잡성이 줄어들지 않는 것 같습니다.
충족되지 않은 기한 또는 예산을 초과 한 기한 은 다른 분야 의 기한 보다 계속 높으며, 종종이를 충족하기 위해 기술 부채가 발생하여 숨겨진 비용이 발생합니다.
의심의 여지없이 일어난 일은 구획화 가 발생 했다는 것 입니다. 우리가 알아야 할 수많은 기술은 프로그래머가 기술을 제대로 활용하기 위해 적은 수의 기술을 전문화해야했기 때문에 다양한 종류의 전문가가 대규모 프로젝트를 완료해야했습니다.
소프트웨어 복잡성에 대해 이야기하는 한 가지 사실은 전 세계에 말 그대로 수백 대의 자동차 제조업체가 있지만 운영 체제 (데스크톱, 모바일, 임베디드 또는 기타) 를 만들고 유지 관리 할 수있는 회사 목록은 손가락으로 계산할 수 있다는 것입니다. 당신의 손의.
위의 모든 것들은 프로그래머 가되기 위해 공부하는 사람들이 충분하지 않은 상황을 만들어 냈으며 , 따라서 정부는 더 많은 학생들이 그 진로를 선택하도록 동기를 부여하기 위해 캠페인을 만들었습니다.
소프트웨어 산업 의 성숙도 에 대한 한 가지 취향은 소프트웨어 라이센스에 "<companyX>가 특정 목적에 대한이 소프트웨어의 적합성을 나타내지 않으며 명시 적 또는 묵시적 보증없이"있는 그대로 "제공된다는 것입니다. 제품이 특정 목적에 적합하지 않다고 말하는 하드웨어 제조업체를 상상해보십시오. 지금이 최첨단입니다.
특정 지표 (즉, 9.98의 요인으로 개선 된 것이 있습니까?)로 논쟁 할 수는 있지만, 나는 (고참 타이머라고 말하면) Brooks의 의견에 대한 일반적인 감정에 동의해야합니다.
우선 1970 년 이래로 발명 된 진정한 신기술은 거의 없었습니다. 그렇습니다. 집적 회로는 더 길고, 더 낮고, 넓으며, 유리 섬유는 통신 속도를 향상 시켰습니다.
컴파일러 기술은 1970 년대에 비해 프로그래머의 "생산성"이 약 10 배 향상되었는데, 하나의 수치 함수가 실제 코딩 시간으로 나눈 값이지만 새로운 또는 "개정 된"프로그래밍 언어 및 환경의 확산으로 인해 평균 프로그래머가 점점 더 많은 시간을 소비하고 있음을 의미합니다 "캐치 업"모드에서는 시간이 걸리고 생산적인 활동에서는 줄어 듭니다. 애플, 구글, 마이크로 소프트는 모두 고객들에게 프로그래밍 고객들에게 반란을 불러 일으킬 수있는 수준 이하의 속도로 환경에 새롭고 실질적으로 호환되지 않는 "업그레이드"를 내놓았다. 마찬가지로 HTML / CSS / Javascript / 더 복잡 해지는 일이 있습니다.
한 번에 문서를 제작하고 전파 할 수있는 속도는이 "혁신"을 모두 제한하고 연관 시켰지만 인터넷 덕분에 더 이상 엄격한 문서가 더 이상 필요하지 않습니다. 세부 사항을 확인하고 사용 가능하게 만드십시오.
추가 : 나는 어제부터 이것에 대해 생각 해 왔으며 특히 1978 년부터 2008 년까지 일한 프로젝트에 대해 생각했습니다.이 프로젝트 (IBM System / 38 및 그 후속 프로젝트)는 시작 노력에서 다소 독특했습니다. 소프트웨어의 복잡성을 제어하기 위해 만들어졌다 (하나는 소프트웨어를 "기계"인터페이스를 통해 두 개의 동일한 부분으로 나눈다). 내가 일했던 특정 분야에서, 몇몇 동료들이 비슷하게 복잡성을 통제하는 데 전념했습니다 (당시 우리는 그 용어를 많이 사용하지 않았지만). 결과는 (처음에는) 매우 견고하고 고객이 git-go에서 거의 인기를 얻은 제품이었습니다. 그리고 잘 훈련 된 오케스트라에서 연주하는 것처럼 작업하는 것이 즐거웠습니다.
물론, 수년에 걸쳐 복잡성을 통제하는 것에 대해 감사하지 않은 시장 기획자 및 관리자의 요구에 따라 복잡성이 증가했습니다. 나는 이것이 불가피하다고 생각하지는 않았지만 (글렌 헨리처럼 원래) 관리자가 혼란의 세력을 뒤로 밀지 않으면이 경우를 막을 수 없었습니다.
지난 30 년 동안 소프트웨어 엔지니어링 실무에서 배운 많은 부분은 "기술 X는 새로운 소프트웨어의 초기 개발 속도를 높일 수 있지만 시간 과 시간을 낭비하지 않으면 어떻게 때 당신이 당신에게 유지 보수의 크기에 더 많은 시간과 노력의 주문 비용,이 기술 부채의 빠는 늪에 응용 프로그램을 켜집니다 장기적으로,이를 사용하여 저장된로 사용할 수 있습니다. "
이 면도기에 속하는 기술에는 다음이 포함됩니다. 수작업으로 코딩 된 어셈블리 언어, 컴파일러, 인터프리터, 프로 시저 라이브러리, 명령형 프로그래밍, 함수형 프로그래밍, 객체 지향 프로그래밍, 수동 메모리 할당, 가비지 수집, 정적 유형, 동적 유형, 어휘 범위, 동적 범위 "안전한"포인터, "안전하지 않은"포인터, 언어 개념으로서의 포인터 부재, 이진 파일 형식, 구조화 된 마크 업 파일 형식, 매크로, 템플릿, 매크로 및 템플릿의 회피 , 공유 메모리, 메시지 전달, 스레드, 코 루틴, 비동기 이벤트 루프, 중앙 집중식 원격 서비스, 분산 서비스, 로컬로 설치된 소프트웨어, 어레이, 링크 된 목록, 해시 테이블 및 트리
위 목록의 많은 항목이 알려진 솔루션 공간을 모두 소진하는 그룹으로 제공된다는 사실은 매우 의도적이며 그 자체로 무언가를 말해야합니다. 하나는 주장 할 수 있다는 유일한 모호 전면적가 먼저 Z3에 블록 구조 (스파게티 코드와 반대) 프로그래밍 및 메모리 보호 (소년합니까 적이다 전환 이후 우리가 했어 습관의 개선 하지 미스 오타가 내 컴퓨터 전체를 중단시킬 수있는 날).