기존의 엔터프라이즈 환경에 새로운 JVM 프로그래밍 언어 소개

현재 직장이 Java 상점이라고 가정하십시오. Java 언어에 대한 많은 기본 지식이 있으며 모든 것을 원활하고 민첩하게 처리 할 수있는 포괄적 인 빌드 및 배포 프로세스가 있습니다.

언젠가 루비와 같이 쓰여질 비명을 지르는 프로젝트가 나옵니다. 선임 개발자 만이 Ruby에 대한 단서를 가지고 있지만 JRuby가 JVM에 존재하므로 기존 인프라를 계속 사용하고 지원할 수 있다는 일반적인 개념이 있습니다. 또한 JRuby는 더 적은 코드로 현재 응용 프로그램을보다 효과적으로 구현할 수있는 방법을 보여 주므로 지속적인 마이그레이션을 나타낼 수 있습니다.

JRuby는 단지 예일 뿐이며 Clojure 또는 Groovy 또는 JVM에서 실행되는 모든 것이 될 수 있습니다.

문제는 이런 종류의 변화를 어떻게 도입 할 것인가입니다.

면책 조항 : JVM에서 Polyglot 프로그래밍에 대한 책을 작성할 때 편견이 있습니다 (Shameless Plug !!-The Well-Grounded Java Developer) :)

첫째, 변경이 진정으로 보장되는 부분 만 소개해야합니다!

시작하기 좋은 곳은 Ola Bini의 프로그래밍 언어 피라미드를 고려하는 것입니다. Ola는 안정적이고 동적 인 언어와 도메인 특정 언어에 대해 이야기합니다.

Java는 안정적인 언어 (정적으로 유형이 지정되고 관리되는)이며 여러 가지 이유로 (사람들이 관심이있는 경우 나중에 사용할 수 있음) 동적 계층 프로젝트 (예 : Rapid Web Development) 또는 도메인 특정 계층 프로젝트 (예 : 모델링)에 이상적인 선택이 아닙니다. 엔터프라이즈 통합 패턴 도메인). 해당 레이어 중 하나에 맞는 프로젝트가 있다면 시작하기에 좋은 장소가 될 수 있습니다.

대체 언어가 제공하는 기본 기능이있는 경우 Java를 대체하기 위해 안정적인 계층에 새 언어를 도입하는 것도 고려할 수 있습니다. 예를 들어 스칼라는 단순히 Java보다 안전하고 자연스러운 방식으로 동시성을 처리합니다.

요청에 따라 이것에 대한 더 많은 것. WRT 자바 :

• 재 컴파일은 힘들다
• 정적 타이핑은 융통성이 없으며 리팩토링 시간이 길어집니다.
• 배포는 헤비급 프로세스입니다
• Java의 구문은 DSL 생성에 적합하지 않습니다.

이 시점에서 다음과 같이 스스로에게 묻습니다.“이러한 계층에 어떤 유형의 프로그래밍 문제가 있습니까? 어떤 언어를 선택해야합니까?”, 은색 글 머리 기호가 없지만 선택을 평가할 때 고려해야 할 몇 가지 기준이 있습니다.

도메인 별

• 빌드 / 지속적인 통합 / 지속적인 배포
• 데브 옵스
• 엔터프라이즈 통합 패턴 모델링
• 비즈니스 규칙 모델링

동적

• 빠른 웹 개발
• 프로토 타이핑
• 대화식 관리 / 사용자 콘솔
• 스크립팅
• 테스트 주도 개발 / 행동 주도 개발

안정된

• 동시 코드
• 응용 용기
• 핵심 비즈니스 기능

위험이 적은 소규모 모듈 (이러한 JVM 언어는 기존 Java 코드와 아름답게 상호 작용하는 경우가 많음) 또는 프로젝트로 시작하십시오. 이것이 프로토 타입이 될 것임을 분명히하십시오.

해당 언어의 프로그래밍 라이프 사이클 및 툴링 측면을 조사했는지 확인하십시오. TDD, 빌드 도구 및 지속적인 통합 실행, 강력한 IDE 지원 및 기타 모든 요소를 ​​사용할 수 있는지 확인해야합니다. 일부 언어의 경우 특정 툴링이 없거나 매우 기본적이라는 것을 받아 들여야합니다. 개발자의 힘과 툴링 지원은 언어의 힘을 능가 할 수 있습니다.

팀이 막힐 때 도움이 될 수있는 활기찬 커뮤니티가 있는지 확인하십시오. 로컬 사용자 그룹이 더 좋습니다.

특히 언어가 OO 스타일 언어가 아닌 경우 개발자가 초기 언어 교육을 받도록하십시오 (클로저로 이동하는 것이 중요하지 않음).

그것은 내 생각에 관한 것입니다. XML 처리, 빠른 웹 사이트 구축 및 일부 데이터 처리와 같은 작업을 위해 Java와 함께 개발시 Groovy, Scala 및 Clojure를 개인적으로 성공적으로 사용했습니다.

"if if"라는 말로 제기 된 주제에 대한 생각을 추가하고 싶습니다. 실제로 왜 팀에 추가 언어를 도입해야합니까? 하나의 프로젝트 만보고 있다면 새로운 언어가이 작업에 이상적인 도구가 될 수 있습니다. 그러나 프로젝트가 많을 경우 시간이 지남에 따라 추가 언어가 추가 될 수 있습니다. 유지 관리주기와 프로젝트 번호에 대해서는 잘 모르지만 팀이 이전보다 더 많은 언어로 많은 전문 지식을 제공해야 할 가능성이 있습니다.

비즈니스 관점에서 언어를 추가한다는 것은 팀에 복잡성과 지식 요구 사항을 추가하는 것을 의미합니다. 이로 인해 직업 조정 기간이 연장되고, 팀 내 휴가 전문가 (또는 영구적 인) 전문가 교체가 더욱 어려워지고 팀원을위한 추가 교육이 필요하므로 단기적으로 속도가 느려집니다.

내 눈에, 소개를 환영하는 전략은 순수한 기능적 측면과는 별도로 그러한 문제를 해결해야한다. 위에서 언급 한 것과 같은 추가적인 문제와 단점의 가치가 기대되는 이득입니까? 이것이 증명 될 수 있다면 수용 률이 훨씬 높을 수 있습니다. 팀원 자격에 대한 훌륭한 투자를 지적하는 것도 도움이 될 수 있습니다.

나는 가장자리에서 시작한다고 말하고 싶습니다. 빌드 스크립트, maven 플러그인, 보고서 실행 등과 같은 일부 비 프로덕션 코드에서 언어를 보여주십시오. 일단 유틸리티와 단순성을보고 나면 소규모 프로젝트 등을 허용하는 경향이 있습니다.