프로젝트 규모와 언어의 엄격 성 사이에 상관 관계가 있습니까?

언어의 엄격 성과 패러다임의 차이를 동료에게 설명하면서 나는 다음과 같이 주장했다.

• 동적 언어 및 해석 언어와 같은 허용 언어는 프로토 타입 및 소규모 프로젝트 또는 중간 규모 웹 응용 프로그램에 가장 적합합니다. Node.js를 사용하여 Python 또는 JavaScript와 같은 우아한 동적 언어를 선택할 때 이점은 다음과 같습니다.

  1. 빠른 개발,

  2. 상용구 코드 감소

  3.   Java와 같은 "기업 언어" 를 피하는 젊고 창의적인 프로그래머를 끌어들이는 능력 .

• 정적 유형 / 컴파일 언어는 비즈니스 크리티컬 앱 또는 중대형 앱용 앱과 같이 더 엄격해야하는 애플리케이션에 가장 적합합니다.

  1. 수십 년 동안 잘 알려진 패러다임과 패턴이 개발되었습니다.

  2. 정적 점검의 용이성

  3. 수십 년의 경험을 가진 많은 전문 개발자를 찾을 수있는 능력.

• Haskell, Ada와 같은 엄격한 언어 또는 C #의 Code contracts와 같은 기술은 생명에 중요한 시스템 및 매우 안정적인 시스템과 같이 유연성보다 안전을 선호하는 시스템 (하스켈이 매우 유연하더라도)에 적합합니다. 이점은 다음과 같습니다.

  1. 컴파일 타임에 가능한 많은 버그를 잡을 수있는 능력

  2. 정적 점검의 용이성

  3. 공식적인 증거의 용이성.

그러나 대기업의 대규모 프로젝트에 사용되는 언어와 기술을 살펴보면 내 주장이 잘못된 것 같습니다 . 예를 들어 Python은 YouTube 나 다른 Google 애플리케이션과 같은 대규모 시스템에 성공적으로 사용됩니다.

프로젝트 규모와 사용해야하는 언어 / 패러다임의 엄격 성 사이에는 여전히 상관 관계가 있습니까?

내가 고려해야 할 세 번째 요소가 있습니까?

내가 어디 틀렸어?

다이나믹하고 해석되는 언어를 사용하는 프로젝트 확장에 관한 흥미로운 사례 연구 는 David Pollak의 Beginning Scala 에서 찾을 수 있습니다 .

뇌에서 코드를 더 간단하고 직접적으로 표현하는 방법을 찾기 시작했습니다. 루비와 레일즈를 찾았습니다. 나는 해방되었다고 느꼈다. 루비를 사용하면 훨씬 적은 코드 줄로 개념을 표현할 수있었습니다. Rails는 Spring MVC, Hibernate 및 기타 "능률화 된"Java 웹 프레임 워크보다 훨씬 사용하기 쉬웠다. Ruby와 Rails를 사용하면 짧은 기간 동안 머릿속에있는 내용을 더 많이 표현할 수있었습니다. C ++에서 Java로 옮길 때 느꼈던 해방과 ​​비슷했습니다 ...

Ruby 및 Rails 프로젝트 가 수천 줄의 코드를 넘어서면서 프로젝트 에 팀원을 추가 함에 따라 동적 언어의 과제가 분명해졌습니다.

우리는 테스트 작성에 코딩 시간의 절반 이상을 소비 했으며, 테스트 작성 과정에서 생산성 향상의 상당 부분을 잃었습니다 . 대부분의 테스트는 메소드 이름이나 매개 변수 수를 변경하여 코드를 리팩토링 할 때 호출자를 업데이트하도록하기 위해 Java에서 필요하지 않았을 것입니다. 또한, 2 ~ 4 명의 팀원 사이에 마음이 합병 된 팀에서 일하는 것이 루비에서는 잘 진행되었지만 새로운 팀원을 팀에 데려 오려고 할 때 정신 연결이 새로운 팀원에게 전달되기 어려웠습니다 .

나는 새로운 언어와 개발 환경을 찾고 갔다. Ruby만큼 표현력이 뛰어나고 Java 만큼 안전 하고 고성능 인 언어를 찾고있었습니다 .

보시다시피, 저자를위한 프로젝트 스케일링의 주요 과제는 테스트 개발 및 지식 이전에있는 것으로 나타났습니다.

특히, 저자는 7 장에서 동적 언어와 정적으로 형식화 된 언어 간의 테스트 작성의 차이점을 설명하는 데 대해 더 자세히 설명합니다.

왜 Lucky Stiff ...는 Dwemthy 's Array 에 루비의 메타 프로그래밍 개념을 소개 합니다. N8han14 가 Scala에서 작동 하도록 예제를 업데이트했습니다 ...

Ruby 코드와 비교할 때 Scala 코드의 라이브러리 부분은 더 복잡했습니다. 우리는 유형이 올바른지 확인하기 위해 많은 노력을 기울여야했습니다. DupMonster 및 CreatureCons 클래스에서 Creature의 속성을 수동으로 다시 작성해야했습니다. 이것은보다 많은 작업 method_missing입니다. 또한 생물과 무기의 불변성을 지원하기 위해 상당한 양의 작업을 수행해야했습니다.

반면에 결과는 Ruby 버전보다 훨씬 강력했습니다. 스칼라 컴파일러가 보증하는 것을 테스트하기 위해 루비 코드에 대한 테스트를 작성해야한다면 훨씬 더 많은 코드가 필요하다. 예를 들어, 토끼가 도끼를 휘두를 수 없다는 것을 확신 할 수 있습니다. 루비에서 이러한 확신을 얻으려면 |^토끼 호출 이 실패 하는지 확인하는 테스트를 작성해야 합니다. 스칼라 버전은 주어진 생물에 대해 정의 된 무기 만 루비에서 많은 런타임 반영이 필요한 생물에 사용될 수 있도록합니다.

위의 내용을 읽으면 프로젝트가 더 커짐에 따라 테스트 작성이 엄청나게 번거로울 수 있습니다. 이 질문에 언급 된 매우 큰 프로젝트의 성공 사례 ( "Python은 성공적으로 YouTube에 사용됩니다")에서 알 수 있듯이 이러한 추론은 잘못된 것입니다.

문제는 프로젝트의 확장이 실제로 간단하지 않다는 것입니다. 매우 크고 오래 지속되는 프로젝트는 생산 품질 테스트 스위트, 전문 테스트 개발 팀 및 기타 무거운 물건으로 다른 테스트 개발 프로세스를 "적절하게"수행 할 수 있습니다.

Youtube 테스트 스위트 또는 Java Compatibility Kit 는 Dwemthy 's Array 와 같은 작은 튜토리얼 프로젝트에서 테스트와는 다른 삶을 살고 있습니다.

당신의 주장은 틀리지 않습니다. 조금 더 깊이 파고 들면됩니다.

간단히 말해서, 큰 시스템은 하나의 언어 만이 아니라 여러 언어를 사용합니다. "엄격한"언어를 사용하여 제작 된 부품이있을 수 있으며 동적 언어를 사용하여 제작 된 부품이있을 수 있습니다.

귀하의 Google 및 YouTube 예제에 관해서는 다양한 시스템간에 Python을 "접착제"로 주로 사용한다고 들었습니다. 구글 만이 그 시스템이 무엇인지 알고 있지만, 구글의 중요한 시스템 중 상당수는 C ++ 또는 Java와 같은 엄격하고 "기업"언어를 사용하여 구축되거나 Go와 같이 자체적으로 생성 된 시스템을 사용한다고 확신합니다.

대규모 시스템에 관용 언어를 사용할 수있는 것은 아닙니다. 많은 사람들은 페이스 북이 PHP를 사용한다고 말하지만 페이스 북이이 규모에서 효율적으로 사용하기 위해서는 매우 엄격한 프로그래밍 가이드 라인을 만들어야했다고 언급하지 않습니다.

따라서 대규모 프로젝트에는 어느 정도 엄격해야합니다. 이는 언어 나 프레임 워크의 엄격 성 또는 프로그래밍 지침 및 코드 규칙에서 비롯 될 수 있습니다. 몇 명의 대학 졸업생을 데려 가서 파이썬 / 루비 / 자바 스크립트를 제공 할 수 없으며 수백만 명의 사용자를 대상으로하는 소프트웨어를 작성할 수 있습니다.

확인해야 할 오류에는 유형 오류 (정수 + 실수 목록 포함)와 비즈니스 논리 오류 (은행 계좌로 송금, 소스 계좌에 금액이 있는지 확인)가 있습니다.

동적 프로그래밍 언어의 "동적"부분은 유형 검사가 이루어지는 곳입니다. "동적 형식의"프로그래밍 언어에서 각 문을 실행하는 동안 형식 검사가 수행되고 "정적 형식의 언어"형식 검사는 컴파일시 수행됩니다. 정적 프로그래밍 언어 (예 : emscriptem 처럼 )에 대한 인터프리터를 작성하고 동적 프로그래밍 언어 ( gcc-python 또는 shed-skin 처럼)에 대한 정적 컴파일러를 작성할 수도 있습니다 .

Python 및 Javascript와 같은 동적 프로그래밍 언어에서는 프로그램 비즈니스 로직뿐만 아니라 프로그램에 구문 또는 유형 오류가 없는지 확인하기 위해 단위 테스트를 작성해야합니다. 예를 들어, "+"정수를 부동 소수점 목록에 추가하면 (이는 말이되지 않으며 오류가 발생 함) 동적 언어에서 명령문을 실행하려고 할 때 런타임시 오류가 발생합니다. C ++, Haskell 및 Java와 같은 정적 프로그래밍 언어에서 이러한 종류의 오류는 컴파일러에 의해 발생합니다.

동적으로 확인 된 프로그래밍 언어의 작은 코드베이스 는 소스 코드 의 100 % 적용 범위 를 가지기 때문에 유형 오류를 찾기가 더 쉽습니다 . 그것은 다른 값으로 몇 번 손으로 코드를 실행하고 완료된 것입니다. 소스 코드를 100 % 적용하면 프로그램에 형식 오류 가 없을 수 있다는 힌트가 있습니다 .

동적으로 검사되는 프로그래밍 언어의 큰 코드베이스를 사용하면 특히 부주의하고 인수에 따라 문자열, 목록 또는 사용자 정의 객체를 반환 할 수있는 함수를 작성하는 경우 가능한 모든 유형 조합으로 모든 명령문을 테스트하기가 더 어렵습니다.

정적으로 검사 된 프로그래밍 언어에서 컴파일러는 컴파일시 대부분의 유형 오류를 포착합니다. 0으로 나누기 오류 또는 범위를 벗어난 배열도 유형 오류이기 때문에 가장 많이 말합니다.

실제 토론이 아니라 프로그래밍 언어가 아니라 해당 언어를 사용하는 사람들에 대한 이야기가 자주 있습니다. 예를 들어 어셈블리 언어는 다른 프로그래밍 언어와 마찬가지로 강력하지만 JavaScript로 코드를 작성하기 때문입니다. 왜? 우리는 인간이기 때문입니다. 첫째, 우리 모두는 특정 작업에 특화된 전용 도구를 사용하여 실수를 저지르기 쉽고 오류가 적습니다. 둘째, 자원 제약이 있습니다. 우리의 시간은 제한되어 있으며 어셈블리에 웹 페이지를 작성하는 데는 오랜 시간이 걸릴 것입니다.

대규모 시스템에 대한 저의 경험은 언어 선택이 아니라 디자인 / 아키텍처 또는 테스트 범위 문제에 의한 것 입니다. 차라리 큰 자바 프로젝트보다는 유능한 파이썬 팀이 큰 엔터프라이즈 프로젝트에 있습니다.

코드를 훨씬 적게 작성할 수있는 모든 언어는 살펴볼 가치가 있어야합니다 (예 : Python vs Java). 아마도 미래는 고급 유형 추론 (예 : Scala 금형)을 가진 영리하고 정적으로 유형이 지정된 언어 일 것입니다. 아니면 C #과 같은 하이브리드가 dynamic한정자를 사용 하려고합니다 ...?

그리고 "다른"정적 타이핑 이점을 잊지 말자 : 적절한 IDE 코드 완성 / 지능, 필자가보기에는 필수 기능이 아니라 필수 기능이다.

또 다른 고려 사항은 대규모 응용 프로그램을 작성 하는 사람 입니다. 대규모 엔터프라이즈 스타일 프로젝트에서 Ruby 또는 Python을 사용하려는 많은 곳에서 근무했지만 프로젝트의 오픈 소스 특성으로 인해 IT 관리자 및 기업 보안 팀이 지속적으로 "샷 다운"했습니다.

"루비 온 레일즈는 오픈 소스이기 때문에 누군가가 중요하거나 보호 된 정보를 훔치는 해킹을 할 수 있기 때문에 루비 온 레일즈를 사용할 수 없다"고 들었습니다. 죄송 합니다만 누군가 오픈 소스 == evil라는 마음가짐을 갖기 시작하면 거의 바꿀 수 없습니다. 그 사고 방식은 기업 질병입니다.

C # 및 Java는 신뢰할 수있는 플랫폼을 갖춘 신뢰할 수 있는 언어입니다 . 루비와 파이썬은 신뢰할 수있는 언어가 아닙니다.