답변:
회사 관점에서 스칼라로 마이그레이션하여 얻을 수있는 뚜렷한 이점이없는 경우 Java를 유지하는 것이 좋습니다. 애플리케이션을 빌드하고 유지 보수하기 위해 Java 프로그래머를 고용하는 것이 더 쉽습니다. 스칼라에서 모든 것을 구현 한 후에 떠날 수도 있습니다 :-) 공격 없음 :-)
상사에게 다음과 같은 경험을 읽게하십시오.
저는 현재 스칼라에서 대부분의 일을하고 있습니다. (나는 얼마 전에 바퀴가 발명 된 이후 스칼라가 가장 좋은 것이라고 생각해야합니다. :-D)
겸손한 견해로는 사람들이 (보다) 객체 지향적 (기능적) 접근 방식 사이에서 불필요한 분리없이 작업에 대한 최상의 접근 방식을 실제로 선택할 수있는 유일한 언어입니다.
전에 이와 같이 주장한 언어를 보면 기본적으로 두 개의 경쟁 언어 디자인 캠프를 볼 수 있습니다.
기능 지향 프로그래밍이 최근에 약간의 관심을 끌었다는 것을 보았던 객체 지향 측면의 사람들은 "글쎄, 우리는 실제로 그 기능적인 것을 이해하지 못하지만, 언어에 멋진 구문 설탕을 추가하여 기능적이라고 주장 할 수 있습니다. 너무!" (예 : Java, Python)
"기능적 접근 방식이 다른 어떤 것보다 훨씬 뛰어나고 객체 지향적 인 말도 안되는 일이 성가시다.하지만 언어에 학문을 피할 수 있도록 언어에 키워드를 추가해 보자" ! " (예 : F #, OCaml)
스칼라의 디자이너들은 양쪽에서 오는 많은 접근 방식을 통합하고 잘 디자인 된 언어를 만들었습니다. 제 생각에는 프로그래밍 언어 디자인에 "프랑켄슈타인"접근 방식을 채택하기로 결정한 다른 언어와의 가장 큰 차이점입니다.
Lift로 아직 작은 일만하고 Rails와 Django에서 피상적 인 경험을 한 결과, Lift의 무언가가 예상 한 것과 다른 이유를 궁금해 할 때 대부분의 시간을 인정해야했습니다. 결함과 리프트의 접근 방식이 우수합니다.
Lift는 확실히 "Scala에 대한 쉬운 소개"는 아니지만 Lift의 작동 방식을 배우는 것은 전에 Scala를 배우는 것만큼이나 보람이 있습니다.
어떤 논리도없이 "깨끗한"관점을 가질 수있는 능력은 같은 주장을하는 다른 프레임 워크에 비해 크게 개선되었지만 부족했습니다. Scala의 XML 리터럴 지원을 통해 응답의 올바른 형식을 확인할 수 있습니다. 컴파일러는 컴파일 할 때 올바른 형식의 XML 만 클라이언트에게 내 보낸다는 것을 증명합니다.
Lift는 실행 가능한 기술이며 현재 엄청난 양의 코드를 직접 작성하지 않고도 "실제"데스크탑 응용 프로그램처럼 보이고 느껴지고 작동하는 웹 응용 프로그램을 구축하려는 경우 유일한 실제 접근 방식입니다.
[ 출처 ]
지난 2 년 동안 우리는 guardian.co.uk에서이 여정을 따라 공정한 방식으로 발전했습니다. Open Platform 은 Scala를 기반으로하며 핵심 CMS (원래 Java)는 점차 더 많은 Scala를 통합하고 있습니다. 우리의 빌드 를 위해 SBT 에 Maven ) 그리고 그것은 훌륭한 경험이었습니다. 우리 개발자들에게 활력을 불어 넣었습니다.
전환에 대한 다음 두 기사를 읽고 뾰족한 머리를 가진 증거로 사용하십시오.
http://skillsmatter.com/podcast/home/how-we-moved-from-java-to-scala
http://www.infoq.com/articles/guardian_scala
몇 가지 빠른 팁 :
스칼라로 테스트를 작성하여 시작하십시오. 이렇게하면 언어에 익숙해지고 언어에 대한 자신감이 높아지며 프로덕션 서버에 런타임을 즉시 추가하는 것에 대한 두려움을 극복 할 필요가 없습니다.
새로운 기술을 시험해 볼 수있는 권한 을 요청하지 마십시오 . 당신이해야 할 경우 용서를 구하는 것이 좋습니다 :-)
Scala에서 Java 앱에 대한 테스트를 작성 중이며 시작하기에 좋은 곳이라는 데 동의합니다. 더 빠르고 쉽게 작성할 수 있기 때문에 테스트 범위가 더 좋습니다 (스칼라를 사용하기 때문에 테스트 작성에 기꺼이 집중합니다).
또한 Scala에서 프로토 타입과 POC를 거의 독점적으로 시작했습니다. 저는 일회성으로 Scala를 사용했음을 관리자와 감독자에게 가능한 한 많이 알리고 Scala로 인해 빠르게 무언가를 얻을 수 있다고 강조합니다. 우리는 휴일 파티 흰 코끼리 게임을 추적하기 위해 웹 앱이 필요했습니다. Scalatra와 MongoDB와 1.5 시간이 걸렸으며 부서 전체 가이 응용 프로그램을보고 그것에 대해 묻고 있습니다. 이를 직시하자면, 언어가 얼마나 표현력이 좋거나 동시성 모델이 훨씬 더 우수하다는 것을 관리자에게 설명하는 곳은 결코 없습니다. 그러나 당신이 그들에게 보여 주면 더 빨리 더 많은 일을 할 수있게됩니다.
그러나 가장 큰 부분은 개발자가 스칼라에 대해 흥분하게 만드는 것입니다. 나는 우리 모두가 새로운 기술을 적극적으로 따르지 않는 개발자와 함께 일할 것이라고 확신합니다. 때로는 새로운 사람들이 새로운 일을하는 것에 흥분을 느끼기가 어렵습니다 (왜, 나는 정말로 이해하지 못합니다). 그 사람들에게 Scala (REPL 시도)의 이점을 보여주는 것이 중요합니다. 개발자가 생산성의 동일한 이점에 대해 윙윙 거리는 충분한 개발자를 확보하게되면 스칼라가 조직에 공식적으로 채택 될 가능성이 훨씬 높아집니다.
단어를 퍼 뜨리고 풀뿌리 노력을 기울이는 것이 2011 년의 나의 주요 목표입니다. 우리는 대량의 작업에 스칼라를 사용할 날을 기다릴 수 없기 때문에 그것이 어떻게 진행되는지 볼 것입니다.
왜 하나를 선택해야하는지 궁금합니다. 왜 자바를 문 밖으로 던져 버리고 스칼라로 가려고합니까?
작업을위한 완벽한 도구는 없습니다. 한 언어로 전문 지식을 완전히 버리고 다른 언어로 대체 할 이유가 없습니다.
한 언어 나 환경에 중점을 둔 회사에서 더 이상 일하고 싶지 않습니다. 많은 것을 알고 작업에 적합한 도구를 선택하는 것이 좋습니다.
그 옆에서 조직이 스칼라로 완전히 전환하는 것이 불가능하지는 않더라도 어렵습니다. 대신, 나는 전혀 또는 전혀 접근하지 않고 스칼라에서 일부 프로젝트 (또는 프로젝트의 일부)를 수행하려고합니다. 예를 들어 Specs2로 Java 코드를 테스트하도록 선택할 수 있습니다. Specs2는 평범한 JUnit과 비교할 때 꽤 좋은 구문을 가지고 있습니다. 복잡하고 혼란스럽고 어려운 스칼라 코드와 패러다임도 아니며 애플리케이션의 동작을 정의하는 데 도움이되는 구문 설탕입니다. .