문제를 해결하기위한 프로그래밍 패러다임 선택에 대한 경험적 증거

C2 위키에는 객체 지향 프로그래밍에 대한 경험적 증거에 대한 토론이 있으며 기본적으로 권위에 호소력이 없다고 결론 내립니다. 이 글은 2008 년에 마지막으로 편집 된 내용입니다. 여기에서 논의 할 내용은 다음과 같습니다. OO가 오래되었는지 , 기능적 프로그래밍이 나쁜 선택 이고 AOP의 장단점 은 모두 증거에 의존하지 않고 기고자의 의견으로 답변됩니다.

물론, 확립되고 평판이 좋은 실무자의 의견은 환영받을만한 가치가 있지만, 실험 데이터와 일치 할 경우 더 타당합니다. 이 증거가 있습니까? 증거 기반 소프트웨어 엔지니어링이 문제라는 것을 알고 있지만 이러한 맥락에서이를 연습 할 수 있습니까? 특히, P소프트웨어를 작성하여 해결하고자 하는 특정 문제가있는 경우, 문제 해결의 결과 P가 프로그래밍 패러다임의 선택에 어떻게 영향을 미치는지 알 수있는 지식, 연구 및 연구가 있습니까?

"올바른 답"으로 나오는 패러다임은 특정 연구가 어떤 메트릭에주의를 기울여야하는지, 연구가 일정하거나 다양한 조건에 의존하는지, 그리고 다른 요인들에도 의심 할 여지가 없다는 것을 알고 있습니다. 그것은이 정보를 찾아 비판적으로 평가하려는 나의 소망에 영향을 미치지 않습니다.

어떤 사람들은 내가 "크랭크를 돌려라"해결책을 찾고 있다고 생각한다는 것이 분명 해졌다.-내 문제에 대한 정보를 넣은 소시지 기계 중 "기능적"또는 "구조적"과 같은 단어가 나온다. 이것은 나의 의도가 아니다. 내가 찾고있는 것은 어떻게 여기에 들어 가지 않을 것이라는 많은주의와 가정으로 문제에 관한 좋은 문헌이 될지에 대한 연구입니다. 소프트웨어의 특정 속성은 문제와 패러다임의 선택에 따라 다릅니다.

다시 말해, 어떤 사람들은 "OO가 더 나은 유연성을 제공합니다"또는 "기능적 프로그램에 버그가 더 적습니다"라고 말합니다. 나머지는 이것에 대한 증거 나 이러한 진술이 참인 가정 또는 이러한 고려 사항이 중요하지 않다는 증거를 요구하고 있습니다. 한 패러다임이 왜 다른 패러다임보다 나은지에 대한 많은 의견이 있습니다. 이것들 뒤에 객관적인 것이 있습니까?

이전 답변에 대해서는이 답변의 개정 1을 참조하십시오 . 그러나 질문에 대한 의견과 편집 내용은 질문이 무엇을 더 명확하게하고 더 명확하게 해줍니다.

예, 증거 기반 소프트웨어 엔지니어링 (EBSE)은 중요합니다. Calham 의 교수가 시작한 Durham University 및 SEED 와 같은 EBSE 데이터베이스에 대한 몇 가지 노력이있는 것으로 보입니다 . 이러한 모든 노력과 IEEE Xplore 서버 또는 ACM 디지털 라이브러리를 통해 찾을 수있는 여러 논문에서 논의 된 내용(둘 다 많은 논문에 필요한 가입 또는 구매)은 근거 기반 의약품을 기반으로합니다. 발표 된 경험적 (관찰 및 실험) 데이터에 대한 문헌 검토를 제공합니다. 실제로 모든 출판물 검색에서 검색 문자열에 "문학적 검토"를 포함하면 ACM에서 14000 개가 넘고 IEEE 데이터베이스에서 1000 개가 넘는 (주제 컴퓨팅 주제로 제한되는 경우) 대부분의 주제에 대한 정보를 얻을 수 있습니다.

이러한 EBSE 데이터베이스 및 문헌 검토에서 논의 된 일반적인 유형의 주제를 살펴보면 공통 스레드가 있습니다. 이들은 기술에 독립적 인 경향이 있습니다. 소프트웨어 엔지니어링을 수행하는 데 사용되는 특정 도구가 아닌 프로세스 및 방법론에 중점을 둔 것으로 보입니다.

따라서이 개념은 소프트웨어 엔지니어링에 존재합니다. 학계는 증거 기반 개념을 알고 있으며이를 소프트웨어 공학에 성공적으로 적용 할 수 있습니다.

구체적으로,이 질문은 EBSE 기법을 패러다임의 선택에 적용하는 데 어려움을 겪고있다. 관련 변수의 수가 많기 때문에 가정을 강요하고 실험 또는 관찰을 반복하는 능력을 감소시킨다. 그것은의 권리 문제에 말했다 - "특정 연구 조건 연구를 일정하게 유지 또는 변화, 너무 다른 요인에 의심 할 여지없이 무엇에 관심을 지불 메트릭 무엇인지에 따라 달라질 수 있습니다"정답 "으로 나오는 어떤 패러다임" . 그렇다고 특정 상황에서 어떤 패러다임이 "최고의"패러다임을 연구한다는 것은 아니지만, 이러한 문서에 대한 모든 종류의 문헌 검토는 작성하기가 매우 어렵고 여전히 정보를 추출하기가 어렵습니다.

패러다임을 선택하는 데 "크랭크를 돌리는"솔루션은 없습니다.

프로그래밍 패러다임이 주어지면 해당 패러다임이 지식, 경험의 범위에서 다양한 특정 조건에서 소프트웨어 개발의 다양한 측면 (품질, 결함, 효율성 등)에 어떻게 영향을 미치는지에 대한 다양한 학술 및 산업 데이터베이스의 연구를 찾을 수 있습니다. 문제 도메인에 팀. 모든 엄격한 논문은 데이터가 수집 된 조건과 가정을 명확하게 식별해야합니다. 문제는 이러한 각 조건에서 좋은 요인을 찾아 내려고합니다.

학문적으로 연구하기 쉬운 진술이 있습니다. 예를 들어, 기능적 패러다임이 동시성을 필요로하는 응용 프로그램에 적합하다는 진술은 Church-Rosser 정리 에서 비롯됩니다 . 이 때문에 기능적 언어로 작성된 소프트웨어 시스템은 절차 적 또는 객체 지향 언어로 작성된 동일한 시스템보다 동시성 관련 결함이 적습니다.

그러나 실제적인 관점에서 소프트웨어 팀은 연구 결과에 따르면 항상 "최고의"도구 나 기술을 업무에 사용할 수는 없습니다. 최고 품질의 소프트웨어 시스템을 생산하기 위해 노력하고 있지만 제약 조건 내에서 운영하고 있습니다. 종종 방법론의 효과를 논의 할 때 이러한 제약 조건이 최소화되거나 방정식에서 제거되는 것을 볼 수 있습니다.

실무자로서 사용할 기술을 선택할 때 가능한 최고의 도구를 찾아 내려고 노력합니다. 그러나 나는 내가 가진 팀이 알고 이해하는 것에 자신을 구속합니다. 이전 예제로 돌아가서 C ++에서 동시 응용 프로그램을 작성하는 데 능숙하고 Haskell에 경험이없는 팀이 있다면 Haskell에서 시스템을 구축하는 것이 불가능할 것으로 생각하는 것은 의미가 없습니다. 일정 및 예산 제약이 있으며 툴체인에 대한 경험 부족으로 인해 품질이 저하 될 수 있습니다.

요약하자면, 증거 기반 소프트웨어 엔지니어링은 일반적으로 존재하는 좋은 일이며 문헌 검토가 존재하며 쉽게 이용할 수 있습니다. 그러나 증거 기반 접근 방식을 적용해도 별 가치가없는 소프트웨어 엔지니어링 측면이 있습니다. 대규모 개발 노력에 대한 프로그래밍 패러다임의 선택은 그 중 하나입니다.

객체 지향이 함수형 프로그래밍에서 재사용 성 또는 결함을 해결하는 방법에 대해 알아 보려면 해당 출판물을 쉽게 찾을 수 있습니다. 그러나, 광범위한 실제 소프트웨어 엔지니어링 프로젝트에서 패러다임 선택을 효과적으로 처리 할 수있는 출판물을 찾지 못했습니다.

Eric S. Raymond 의 The Art of Unix Programming 을 읽었습니다 . 그것은 우리가 당연한 것으로 여기는 것들에 대한 매우 흥미로운 역사적 통찰력을 가지고 있습니다. 그는 결함 밀도와 같은 경험적 증거를 사용하는 IEEE 소프트웨어의 좋은 연구를 인용합니다 . 학업 스타일의 연구를 찾고 있다면 좋은 자료가 될 수 있습니다.

함수를 사용한 모듈화와 같은 기술조차 항상 일반적인 관례는 아닙니다. 지금까지이 책에서 내가 가장 좋아하는 인용문 중 하나 :

Dennis Ritchie는 C에서 함수 호출이 실제로 매우 저렴하다는 사실을 모두에게 알리고 모듈화를 장려했습니다. 모두가 작은 함수를 작성하고 모듈화하기 시작했습니다. 몇 년 후 우리는 PDP-11에서 함수 호출이 여전히 비싸다는 것을 알았으며 VAX 코드는 종종 CALLS 명령에서 50 %의 시간을 소비하고있었습니다. 데니스는 우리에게 거짓말을했다! 그러나 너무 늦었다. 우린 모두 푹 빠졌어

-스티브 존슨

그래도 너무 실증적이는 데는 두 가지 문제가 있습니다. 첫 번째는 코드 품질이 매우 주관적인 것입니다. 코드는 끔찍하지만 여전히 정확할 수 있습니다. 프로그래밍 패러다임에 대한 사람들의 인식 은 매우 유효한 척도입니다. 코드는 사람들이 컴퓨터만큼 읽을 수 있도록 작성 되었기 때문입니다.

두 번째 문제는 개발자의 50 %가 평균 프로그래밍 재능보다 낮다는 것입니다. "라블"이 아름답고 잘 설계된 소프트웨어는 물론 소프트웨어를 사용하여 작업 소프트웨어 를 작성 하는 데 어려움을 겪고 있다면 최상위 개발자가 기능적 프로그래밍을 사용하여 생산성을 높이는 것은 중요하지 않습니다 . TMTOWTDI 프로그래밍 언어 와 마찬가지로 최고의 개발자는 여전히 깔끔한 모듈 식 코드를 작성하려고하지만 부과 된 구조가 없기 때문에 재능이 적은 코더는 라인 노이즈를 씁니다.

그렇기 때문에 OOP가 결함에도 불구하고 인기를 얻었습니다. 그것은 매우 재능이 많을 정도로 제한적이지는 않지만 그 구조는 가장 재능이 적은 사람에게 좋은 디자인 원칙을 전달하고 전달하는 간결한 방법을 제공합니다.

업무 라인에서 우리는 기술적 장점만으로 너무 많은 솔루션을 평가하는 경향이 있습니다. 성공적인 노력은 방정식의 인간적 측면도 설명해야합니다.

컴퓨터 등급 시스템을 사용하는 프로그래밍 콘테스트가 있으며 다양한 언어로 작성하고 모든 종류의 결과와 사물을 게시 할 수 있습니다. 나는 그들이 당신을 위해 좋은 데이터를 가지고 내기. 다음은 8의 목록입니다. http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

제곱합 또는 피보나치 시리즈와 같은 매우 간단하고 명확한 문제에 대한 솔루션을 의미있게 비교하거나 Bresenham의 선 알고리즘을 사용하여 직선을 그릴 수 있다고 생각합니다. 대부분의 실제 프로그래밍 작업에는 명확한 목표 게시물이 없으며 모든 언어에는 장점이 있습니다. 언어의 많은 장점은 주관적입니다. 코드 줄이나 결함 수를 세는 것보다 프로그래머와 고객의 행복을 조사하면 더 의미있는 데이터를 찾을 수 있습니다.

반나절 동안 첫 Awk 프로그램 중 하나를 작성했을 때 Java에서 "동일한"작업을 수행하는 데 1 주일이 걸렸다 고 생각했습니다. 그러나 그것은 Java 솔루션이 Awk 솔루션이 빠르고 더러워서 입력 및 출력에 대한 수동 조정이 필요했던 곳의 견고함에 초점을 맞추었기 때문에 실제로 완료했을 때 버려졌습니다. Awk와 Java는 모두 같은 것이 아니라 훌륭합니다.

내가 말하는 것은 실제 응용 프로그램의 경우 언어 나 도구를 의미있는 방식으로 비교하는 것이 매우 어렵다는 것입니다. 오래된 사과와 오렌지 문제입니다. 행운을 빕니다! 당신이 찾은 것을보고 싶습니다.

30 년 이상 소프트웨어를 개발하는 다양한 방법을 연구 해 왔습니다. 패러다임을 선택하는 데는 좋은 증거가 부족합니다.

검색 가능한 큰 ASCII 참고 문헌을 정리했습니다. 여기에는 많은 IEEE 및 ACM 논문과 기사가 포함됩니다. 제공된 증거 유형으로 항목에 태그를 지정합니다. 가장 일반적인 태그는 다음과 같습니다.

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

이제 PARADIGM을 검색하고 태그를 세십시오.

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

더 깊이 파고 싶다면 http://cse.csusb.edu/dick/lab.html 그리고 도움이되기를 바랍니다.

많은 경우에 소프트웨어 엔지니어링의 한 사례가 다른 사례보다 나은지에 대한 일반적인 결론을 도출 할 수있을만큼 충분히 크거나 충분한 품질의 연구 집단이없는 것 같습니다. 나는 다른 패러다임에서 일하는 것에 대한 연구를 구체적으로 찾고 있었지만 가용성 부족은 그 분야에만 국한되지 않으므로 더 넓은 의미에서 답을 구할 것입니다.

Kitchenham 등의 증거 기반 소프트웨어 엔지니어링 2004 년의 논문은 증거 기반 접근법에서 파생 된 이점과 소프트웨어 엔지니어링에서 구현할 때의 문제점을 간결하게 설명합니다. 나는 여기서 이점 측면에 대해 논의하지 않을 것입니다 (이 방법으로 일하고 싶다는 질문에서 분명합니다). 그러나 문제는 내가 묻는 질문에 대한 답변과 관련이 있습니다.

• 첫째, ACM 회원이 아닌 경우 위의 링크를 전혀 읽을 수 없으며 아마도 첫 번째 문제를 다루고 있습니다. 현존하는 모든 연구가 실제로 실무자가 이용할 수있는 것은 아닙니다.
• 상업적인 기밀 프로세스의 일부로 많은 소프트웨어 엔지니어링 실무가 비밀리에 진행되므로 이러한 사람들에게 무엇이 효과가 있었는지에 대한 가시성이 없습니다.
• 소프트웨어 엔지니어링은 숙련 된 관행이므로, 적절하게 맹검 된 연구를하는 것은 어렵습니다 (불가능하지 않고 단지 어렵습니다).
• 소프트웨어 수명주기의 다른 부분은 실험에서 제어하기 어려운 정도로 서로의 결과에 영향을 미칩니다.
• 여기서 논의한 바와 같이, 많은 실무자들은 자신의 작업과 관련하여 "문헌"(또는 소프트웨어 공학의 학문적 측면)을 보지 못한다.

그래서 내가 따르는 대답은 "아니오"입니다. 내가 찾은 증거는 아마도 존재하지 않을 것입니다. 내가 아는 것, 시원하고 전문가의 의견에 대한 기존의 인기있는 기준에 따라 패러다임을 선택해야합니다.

나는 이런 유형의 연구가 존재하지 않는다고 생각합니다. 사용되는 실제 알고리즘만큼 중요한 것은 프로그래밍 패러다임이 아니라고 생각할 것입니다. 예를 들어 작은 공간 알고리즘에 의존하는 사소한 시스템은 작은 시간 알고리즘에 의존하는 시스템은 다른 메트릭을 생성합니다. 더 나은 시간을 가진 사람은 공간이 문제가 아니라면 그 반대가 사실이 아니라면 더 유효한 것으로 여겨 질 것입니다. 나는 도로를 포장하는 것과 비슷하다고 생각합니다. 모든 프로세스에서 재료를 만들기위한 알고리즘 또는 레시피는 일정하지만 한 회사는 한 번에 두 개의 차선을 포장하는 것이 (길의 각면에 하나씩) 한 번에 도로의 같은면에 두 개의 차선을 포장하는 것보다 낫다고 생각할 수 있습니다 . 마지막 날에는 검은 상단을 만드는 과정이 여전히 동일하므로 중요하지 않습니다. 유일한 차이점은 접근 방식입니다. 프로그래밍으로 돌아가서 C 개발자 팀이있는 경우 Java 개발자 팀이 OO로 작성하는 경우 절차 방식으로 코드를 작성하십시오. 알고리즘의 구현만큼 패러다임에 매달리지 마십시오. 하루가 끝나면 C와 같은 Java를 작성할 수 있고 C와 같은 Java를 작성할 수 있습니다.

최신 정보

그레이엄 의견에 답장을 남기려면 :
아키텍처에서는 프로그래밍 패러다임을 의미한다고 생각합니다. Clojure를 사용하려는 경우 Clojure 프로그래머 팀을 고용해야합니다. 그러나 빠른 검색을 기반으로 Clojure는 Java 기반 언어이므로 작동합니다. 그 정보를 바탕으로 Java 프로그래머를 취하거나 (기술적으로 Java를 작성하면 동일한 결과를 얻을 수 있기 때문에) Haskell 개발자와 같은 기능적 프로그래머를 찾습니다. 이제 가장 좋은 것을 선택하는 것은 팀에 전적으로 달려 있습니다. 관계형 데이터베이스 전문가 팀이 클라우드 솔루션을 구성하지 않아도되고 기능 프로그래머 팀도 객체 지향 솔루션을 구축 할 수 없습니다. 당신은 팀이 무엇을해야하는지에 대해 당신의 머리 속에있는 영광스러운 비전을 갖지 못한 팀의 강점을 사용해야합니다

다른 패러다임은 다른 솔루션으로 이어집니다. 어떤 것이 '최고'인지는 크게 다음에 달려 있습니다.

• 해결책
• 개발팀
• 운영 환경

나는 그러한 결정적인 연구를 알지 못하며, 그 연구가 있었더라도 그것을 신뢰하지 않을 것입니다.

이것이 건축가의 일입니다.

연구의 관련성이없는 결론으로 ​​건축가의 지혜를 대체하는 것은 재난의 요리법입니다.

참고 : "알고리즘"을 결정하고 언어를 선택한다는 언급이 있습니다. 알고리즘은 절차 언어의 중심 구조 메커니즘입니다. 객체 지향 언어는 클래스와 협업 / 통신 패턴에 중점을 둡니다. 알고리즘 중심 솔루션이 '최고'라고 확신한다면 (건축가로서) 절차 적 또는 기능적 언어를 고수하십시오.

부록 : 연구를 신뢰하지 않는 것은 '미신'이 아니라 상식입니다. 과학 실험은 객관적이고 반복 가능해야합니다. 소프트웨어 프로젝트는 매우 주관적이지만 더 나쁜 것은 반복 할 수없는 실험 입니다. 팀 Y로 프로젝트 X를 구현하고 결과를 측정 한 다음 시간을 롤백하고 메모리를 지우고 동일한 팀과 동일한 프로젝트를 다시 실행할 수는 없습니다. 연구에 의해 발견되거나 암시 된 정보는 건축가에게 유용 할 수 있지만 절대로 결정적인 것은 아닙니다.