동적 언어는 민첩한 개발에 불리한가?

내가 애자일 개발에서 읽은 내용에는 종종 리팩토링 또는 엔지니어링 코드를 다이어그램으로 뒤집는 것이 포함됩니다. 물론 그 이상의 것이 있지만,이 두 가지 방법에 의존하는 관행을 고려한다면 동적으로 유형이 지정된 언어가 불리한가?

정적 유형의 언어는 리팩토링 및 리버스 엔지니어링을 훨씬 쉽게 만듭니다.

동적으로 입력되는 언어에서는 불가능하지 않은 경우 리팩토링 또는 (자동화 된) 리버스 엔지니어링이 어려운가요? 실제 프로젝트는 민첩한 방법론을위한 동적 유형 언어의 사용법에 대해 무엇을 알려줍니까?

동적 언어는 이론적으로 불리한데, 코드가 작동하는 방식 (제약 조건)에 대해 덜 명시하기 때문에 리팩토링을 자동으로 수행 할 수 없으며 발생하는 문제도 자동으로 감지 할 수 없기 때문입니다. .

그러나 다른 모든 것은 평등하지 않습니다. 가장 널리 사용되는 동적 언어는 매우 작지만 이해하기 쉬운 코드를 허용하므로 일반적으로 개발 속도가 빨라지고 리팩토링에서 변경 될 수있는 논리를 시각적으로 쉽게 확인할 수 있습니다. 따라서 동적 언어로 작업 할 때의 상대적 이점을 잃을 수도 있지만 특히 리팩토링을 직접 수행하려는 경우 특히 앞서 나올 수 있습니다.

다른 한편으로, 동적 언어와 본질적으로 동일한 장점을 가진 정적 유형 언어가 존재합니다 (즉, 대부분 유추되지만 그 유형이 많은 컴팩트하고 이해할 수 있음). Haskell이 가장 대표적인 예이지만 OCaML / F #, Scala, 다른 사람들도이 범주에 속합니다. 불행히도, 가장 널리 사용되는 정적 유형 언어보다 많이 사용되지 않기 때문에 리팩토링과 같은 툴셋이 없습니다.

결론적으로, 대부분의 언어에서 민첩한 방법론을 적절하게 사용할 것이라고 생각합니다. 연습이 아직 이론을 따라 잡지 않았기 때문에 지금 당장 확실한 승자가 있다고 말하고 싶지 않습니다.

자동 리팩토링은 동적 유형 언어 인 스몰 토크에서 발명되었습니다. 따라서 동적으로 유형이 지정된 언어로 자동 리팩토링을 수행하는 것은 불가능하지 않습니다. 그것이 얼마나 어려운지는 타이핑 분야 외에 다른 요소에 훨씬 더 의존합니다. C ++ 및 Java는 모두 정적으로 유형이 지정되어 있지만 리팩토링 도구는 실제로 Java에만 존재합니다. 내성 및 간단한 구문이 포함 된 스몰 토크는 리팩토링 도구의 훌륭한 후보였습니다.

어떤 식 으로든 동적 타이핑은 실제로 리팩토링을 더 쉽게 만듭니다. 테스트 스위트가 좋은 경우 리팩토링으로 인해 문제가 발생하지 않았는지 확인할 수 있습니다. 동적으로 형식화 된 코드베이스는 일반적으로 더 작습니다. 또한 리팩토링은 적은 코드에 영향을주는 경향이 있습니다. 동적 코드베이스를 수동으로 리팩토링하는 데 드는 노력은 정적 코드베이스의 노력보다 적습니다.

리팩토링은 동적 언어로 개발되었습니다. 자동 리팩토링 툴은 동적 언어로 개발되었습니다. IDE는 동적 언어로 개발되었습니다. 몇 가지 애자일 방법론이 동적 언어로 발명되었습니다.

나는 정말로 어떤 문제도 보지 못한다.

익스트림 프로그래밍 (XP)으로 알려진 "민첩한"작업 방식은 스몰 토크 프로젝트에서 생성되었으며 스몰 토크 는 "동적"언어로 간주됩니다.

다음은 동적으로 유형이 지정된 언어와 함께 제공되는 리팩토링 도구의 산업적 사용에 대한 사례 연구입니다.

곡물 엘리베이터 및 관련 상품 거래 활동을 지원하기 위해 카길에서 매우 큰 스몰 토크 애플리케이션이 개발되었습니다. Smalltalk 클라이언트 응용 프로그램에는 385 개의 창이 있으며 5,000 개가 넘는 클래스가 있습니다. 이 응용 프로그램에서 약 2,000 개의 클래스가 초기 (1993 년경) 데이터 액세스 프레임 워크와 상호 작용했습니다. 프레임 워크는 객체 속성을 데이터 테이블 열에 동적으로 매핑했습니다.

분석 결과 동적 조회는 클라이언트 실행 시간의 40 %를 소비했지만 불필요하다는 것을 보여주었습니다.

비즈니스 클래스가 명시 적으로 코딩 된 메소드에서 열 속성에 오브젝트 속성을 제공해야하는 새로운 데이터 계층 인터페이스가 개발되었습니다. 테스트 결과이 인터페이스가 훨씬 빠릅니다. 문제는 데이터 계층의 2,100 비즈니스 클래스 사용자를 변경하는 방법이었습니다.

개발중인 대규모 응용 프로그램은 인터페이스 변환을 구성하고 테스트하는 동안 코드를 고정 할 수 없습니다. 주요 개발 스트림에서 코드 저장소의 병렬 브랜치에서 변환을 구성하고 테스트해야했습니다. 변환이 완전히 테스트되면 단일 작업으로 기본 코드 스트림에 적용되었습니다.

17,100 개의 변경 사항에서 35 개 미만의 버그가 발견되었습니다. 모든 버그는 3 주 동안 빠르게 해결되었습니다.

변경 사항을 수동으로 수행 한 경우 변환 규칙을 개발하는 데 235 시간이 걸리는 데 비해 8,500 시간이 걸린 것으로 추정됩니다.

다시 쓰기 규칙을 사용하여 작업이 예상 시간의 3 % 안에 완료되었습니다. 이것은 36 배 향상되었습니다.

“애플리케이션 데이터 계층의 변환”Will Loew-Blosser OOPSLA 2002

또한 "불가능한 변경을위한 도구-대규모 스몰 토크 프로그램을 변환하는 도구를 사용한 경험"

당신의 원칙은 나에게 맞다고 생각 합니다 .

C #과 같은 강력한 형식의 언어는 지속적으로 리팩터링이 필요한 코드 기반에 적합합니다. 시장에서 기본적으로 대부분의 리팩토링 도구 (예 : Resharper, JustCode 등)는 정적으로 유형이 지정된 프로그래밍 언어에서 매우 효과적입니다.

실제 프로젝트는 민첩한 방법론을위한 동적 유형 언어의 사용법에 대해 무엇을 알려줍니까?

Agile / Scrum 방법론을 실행하는 개발 팀의 경우 갑옷 아래에 좋은 리팩토링 도구 세트를 갖는 것이 매우 유용합니다. 그렇지 않으면, 다가오는 스프린트의 모든 갑작스런 변화는 수정 또는 재 설계의 악몽 일 수 있습니다.

따라서 민첩한 방법론은 정적으로 유형이 지정된 언어 나 동적으로 한 번만 이점을 제공하지 않습니다. 그것이 제공하는 것은 견고한 응용 프로그램을 구축하기위한 반복적 인 접근 방식입니다.