코 틀린
Kotlin은 비교적 새로운 JVM 언어이며 JetBrains는 2011 년부터 적극적으로 개발해 왔습니다.
수년에 걸쳐이 언어는 Android 커뮤니티에서 점점 더 많은 관심을 받았으며 Google IO 2017 컨퍼런스 이후 Android 개발에서 가장 인기있는 주제가되었습니다. 이 회의는 Android가 공식적으로 Kotlin을 지원한다고 발표했습니다.
불행히도, Kotlin에 대한 기사가 이미 많지만 객관적인 정보는 많지 않으며 많은 개발자들이 Kotlin으로 이사하는 것이 올바른 길인지에 대해 여전히 생각하고 있습니다.
이 기사의 나머지 부분에서는 Kotlin을 Java의 대안으로 평가할 때 고려해야 할 사항의 전체 목록을 제공하려고합니다.
Kotlin과 Java의 주관적 비교
"Kotlin은 Java보다 낫다", "Kotlin은 Java보다 읽기 쉽다", "Kotlin Development Speed는 Java보다 빠릅니다", 이와 같은 진술은 관련 정확한 데이터의 지원이 부족하므로 모두 주관적인 견해로 분류됩니다.
개별 개발자가 Kotlin 또는 Java와 관련된 주제에 대해 하나 이상의 주관적인 판단을 할 때 주관적인 견해가 형성됩니다.
개발자의 주관적인 판단에는 문제가 있습니다.
주관적 판단과 관련된 정량적 지표는 없습니다.
주관적 판단에는 큰 편견이 있습니다.
주관적 판단의 편견은 개발자마다 크게 다릅니다.
주관적 판단과 관련된 정량적 지표는 없기 때문에 이러한 판단에 근거한 관점은 개발자가 이전에했던 편견에 대해서만 반영합니다. 개발자마다 편견이 매우 다를 수 있으므로 다른 개발자도 그렇게 생각한다는 의미는 아닙니다.
더욱이, 객관적인 지표가 없기 때문에, 주관적 차이를 객관적으로 제거 할 수 없으며, 이는 종종 "단어의 전쟁"으로 이어집니다.
주관적 판단의 오류
주관적 판단으로 이어질 수 있다는 오해를 설명하기 위해 매우 일반적인 주관적인 견해를 자세히 살펴 보겠습니다.
Kotlin은 Java보다 더 읽기 쉬움 - 웹에서 수많은 기사
이론적으로는 Kotlin과 Java의 가독성 차이를 측정하는 실험을 설계 할 수 있지만, 내가 아는 한 아무도 그러한 실험을 수행하지 않습니다. 따라서 현재이보기에는 데이터 지원이 없습니다.
Kotlin의 구문은 많은 개발자들이 가독성을 칭찬하는 이유 중 하나입니다. 그들의 논리는 다음과 같습니다.
Kotlin은 더 나은 구문을 가지고 있으므로 웹에서 수많은 기사를 읽을 수 있습니다.
이 문장에서, "더 나은 문법"은 또 다른 주관적인 판단이며, 그 자체로 논쟁의 여지가 있지만 논쟁을 피하기 위해 코 틀린의 문법이 실제로 더 좋다고 가정합니다. 그러나 이것은 Kotlin이 더 읽기 쉬운 것을 의미합니까?
가독성에 대한 구문의 영향을 관찰하려면 "텍스트"의이 단락을 읽으십시오.
처음에는이 "텍스트"는 이해하기 어렵지만 천천히 읽기가 더 쉬워집니다. 두세 번 읽으면 비표준 문자로 구성되어 있음을 알 수 없습니다. 정확하게 말하면, 문자 교체는 구문 변화가 아니지만, 외관이 숙련 된 독자의 가독성에 대한 장벽이되지 않는다는 것을 보여줍니다.
이 예를 자연어로 확장 할 수도 있습니다. 나는 완전히 다른 세 가지 언어를 이해합니다. 그것들은 크게 다르지만 텍스트에 사용 된 단어를 이해하지 못할 때 어느 언어로든 텍스트를 읽는 것이 매우 어렵다는 것을 알게됩니다. 일단 텍스트를 구성하고 문맥에 익숙해지는 단어를 알았을 때, 어떤 언어에 있든, 나는 그것을 읽는 데 어려움을 겪지 않았습니다.
따라서 나에게 언어 선택은 가독성에 영향을 미치지 않고 내용과 컨텍스트를 이해합니다.
언어를 프로그래밍하는 것도 마찬가지입니다.
새로운 언어를 사용하기 시작하면 소스 코드를 이해하는 데 어려움이 있으며 각 구문 구조를 신중하게 이해해야합니다. 그러나 특정 언어에 대한 코드를 읽고 쓸 때, 우리는 점차 해당 언어의 구문에 익숙해지며, 어느 시점에서 우리는 더 이상 구문 구조에주의를 기울이지 않을 것입니다.
Verilog, Bash, Perl, TCL, LISP, Java와 같은 여러 언어 로이 경험을했습니다.
위의 언어에 대한 나의 경험을 바탕으로, 나는 당신에게 말할 수 있습니다. 사람이 LISP의 코드에 적응하고 더 이상 괄호를 알아 차리지 않으면 Kotlin의 구문은 "더 나은"경우에도 Java에 비해 가독성에 무심코 영향을 미칠 수 없습니다.
우리는이 주제에 대해 논의하기 때문에 소스 코드의 가독성에 영향을 미치는 요인에 대한 주관적인 판단을 공유 할 것입니다.
다른 개발자가 여러 언어로 작성한 코드를 읽은 후 (위의 언어 만 목록에만 적합한 언어 만 목록을 작성하고, 이보다 더 많은 언어를 사용했습니다) 다음과 같은 결론을 내 렸습니다. 개발자가 한 언어로 읽을 수 있고 이해할 수있는 코드를 작성할 수 있다면 일반적으로 다른 언어로 읽을 수 있고 이해할 수있는 코드를 작성할 수 있습니다.
따라서, 내 자신의 경험을 바탕으로 한 주관적인 판단은 소스 코드의 가독성이 선택된 언어와 관련이 없으며 코드 작성자의 기술과 독자의 기술에 달려 있다는 것입니다 (작가의 기술은 더 중요합니다).
여전히 주관적인 견해가 대표적이라고 생각한다면 최소한이 블로그 게시물에서 Robert“Uncle Bob”Martin이 어떻게 생각하는지 생각하고 생각하십시오.
Kotlin과 Java의 객관적인 비교
주관적 비교와 달리, 객관적인 비교는 정량적 지표를 사용하여 Kotlin이 Java에 대한 장점을 측정하거나 평가합니다.
한 표준 세트를 가진 프로그래밍 언어가 다른 표준보다 넓은 지 여부를 객관적으로 증명한다는 아이디어는 매우 매력적이지만 문제가 있습니다. 내가 아는 한, 프로그래밍 언어와 관련된 일반적인 목표 지표는 없습니다.
우리가 정확하고 직접 비교할 수 없다는 것을 감안할 때, 우리는 Kotlin과 Java를 객관적으로 비교할 수 있습니까? 할 수 있는! 우리는 여전히 Java에서 Kotlin으로 전환하는 긍정적 및 메시징 영향의 정도를 평가 한 다음 결과를 비교하고 그 영향에 대해 논의 할 수 있습니다.
Kotlin이 생산할 수있는 최상의 결과를 평가하기 위해 다음과 같은 가정을 할 것입니다.
개발자는 즉시 Kotlin으로 전환 할 수 있습니다.
Kotlin으로 전환 한 후 개발자는 기술을 잃지 않습니다 (예 : 2 년간의 Java 개발 경험을 가진 개발자는 2 년간의 Kotlin 개발 경험을 마술로 얻을 수 있습니다).
Kotlin은 Java만큼 안정적입니다.
Kotlin 도구는 Java 도구만큼 성숙합니다.
실제로, 위의 가정 중 어느 것도 합리적이지만 처음에는 쉬운 설명을위한 이상적인 설정이 있습니다. 그런 다음 이러한 가정을 제쳐두고 실제 효과의 영향에 대해 논의 할 것입니다.
Kotlin 최상의 결과 추정치
Code Complete에서 Steve McConnell이 제안한 모델에 따라 소프트웨어 구성 활동을 세부 디자인, 코딩 및 디버깅, 개발 및 테스트의 세 가지 하위 활동으로 분류 할 수 있습니다.
Kotlin은 하위 활동을 자세히 설계하는 데 거의 영향을 미치지 않습니다 (이 활동은 일반적으로 선택한 특정 객체 지향 프로그래밍 언어와 무관합니다) 따라서 Kotlin과 Java는이 섹션에서 동일한 노력을 기울여야합니다.
내가 아는 한, Kotlin은 개발 테스트 하위 활동에 대해 혁명적 인 것을 제안하지 않았습니다. 따라서 테스트 개발도 마찬가지입니다.
모든 코딩 및 디버깅 하위 활동이 남아 있습니다.
Java를 Kotlin으로 교체하면 코딩 및 디버깅 활동에서 얼마나 많은 작업을 저장할 수 있습니까? 이 질문은 대답하기가 어렵고이 값은 프로그래머마다 크게 다릅니다 (일부 프로그래머는 Java를보다 효율적으로 사용합니다). 그러나 이제 우리는 최상의 상황을 평가하고 있기 때문에 Java에서 Kotlin으로 전환하면 코딩 및 디버깅 단계에서 개발자의 생산성을 평균 10% 증가시킬 수 있다고 가정 할 수도 있습니다.
10%의 생산성 증가는 놀랍게도 비현실적인 가치입니다. 텍스트 편집기에서 모든 코드를 수동으로 입력하더라도 비현실적입니다. IDE의 현재 기능을 고려할 때이 값은 훨씬 비현실적입니다. 일부 개발자가 Java를보다 효율적으로 사용한다는 점을 고려하면이 값은 의미가 없습니다.
나는 Kotlin의 평가에 비현실적이고 유리한 그러한 가치를 사용하는 것을 신경 쓰지 않습니다. 왜냐하면 나는 비현실적인 긍정적 인 평가 결과에 아무리 긍정적이지 않더라도, 우리가 "이상적인 가정"중 일부를 제쳐두고 부정적인 영향을 미치면 이러한 긍정적 인 영향을 상쇄 할 것입니다.
따라서 코딩 및 디버깅 측면에서 10% 증가했습니다. 제품을 고객에게 얼마나 빨리 제공하고 있습니까?
다음 그림은 책 코드 전체에서 나온 것입니다. 소프트웨어 프로젝트의 다양한 활동의 비율을 보여줍니다.
사진의 작은 프로젝트는 건설 활동에 중점을 둡니다. 대규모 프로젝트에는 프로젝트의 성공을 위해 더 많은 아키텍처, 통합 및 시스템 테스트가 필요합니다. 이 그림은 다른 활동과 달리 요구 사항 작업이 직접 프로그램 기능이 아니기 때문에 요구 사항을 표시하지 않습니다. (Albrecht 1979; Glass 1982; Boehm, Gray 및 Seewaldt 1984; Boddie 1987; Card 1987; McGarry, Waligora 및 McDermott 1989; Brooks 1995; Jones 1998; Jones 2000; Boehm et al. 2000)
코드 완료, 두 번째 판
코드 완료 의이 이미지에 따르면, 더 큰 소프트웨어 프로젝트 (10K 라인 이상)에서 인코딩 및 디버깅은 총 프로젝트 워크로드의 20% 미만을 설명합니다.
따라서 더 큰 소프트웨어 프로젝트에서 코딩 및 디버깅 효율성은 10%이며 프로젝트를 완료하는 데 필요한 총 작업량 만 2%줄일 수 있습니다.
예를 들어, 5 명이 수년간 완료하는 데 필요한 프로젝트 (비교적 큰 안드로이드 프로젝트) 전체 작업량의 2%는 다음과 같습니다.
5 인 -E 년 * 12 * 4 * 5 * 0.02 = 24 (People- Day)
프로젝트 워크로드를 실제로 24 명까지 줄일 수 있다면 Java에서 Kotlin으로 전환하는 것이 좋은 이유입니다. 그러나 우리는 위의 긍정적 평가가 이상적인 상황에서 파생되었으며 비현실적인 가정에 근거한 것임을 기억해야합니다.
실제 세계에서는 다른 프로그래밍 언어로 전환하는 것은 불가피한 영향을 미치며, 위에서 언급 한 이상적인 평가와 평가하고 비교할 것입니다.
개발자 준비
최상의 사례 시나리오를 평가하기 위해 개발자가 즉시 Java에서 Kotlin으로 전환 할 수 있다고 가정합니다.
실제로 Kotlin은 Java와 매우 유사하지만 개발자는 여전히 학습 시간을 보내고 개발 관행과 도구를 조정하는 데 시간을 보내야합니다. 준비 시간은 사람마다 다릅니다. 일부 개발자는 3-4 일 사이를 전환 할 수 있고 다른 개발자는 10 일 이상이 걸릴 수 있습니다.
평균적으로 각 개발자는 단 5 일 만에 Java에서 Kotlin으로 전환 할 수 있습니다.
완료하는 데 5 년이 걸리는 프로젝트에는 3-5 명의 개발자가 있습니다 (최선의 경우). 각 개발자의 평균 전환 시간은 5 일이므로 프로젝트는 총 15 ~ 25 인분 전환 시간이 걸립니다.
Kotlin (낙관적 추정)으로 전환하여 절약 된 노력은 전환에 필요한 총 노력과 거의 동일합니다.
개발자 기술 손실
특정 프로그래밍 언어에서 효율적으로 작업하는 능력은 기술입니다.
우리는이 기술의 한 가지 측면에 대해 논의했지만 (코드 가독성), 다른 많은 것들이 있습니다. 한 언어에서 다른 언어로 전환 할 때 이전 프로그래밍 언어와 관련된 일부 기술을 새로운 언어에 적용 할 수 있지만 기술의 다른 부분이 손실됩니다.
프로젝트 워크로드에 대한 프로그래밍 언어 능력 상실의 영향을 평가하기 위해 CoCOMO2 평가 모델에서 파생 된 "언어 및 도구 경험"요소를 사용합니다.
언어 및 도구 경험 (LTEX)
이 메트릭은 프로그래밍 언어 및 소프트웨어 도구를 사용하여 소프트웨어 시스템 또는 서브 시스템을 개발하는 프로젝트 팀의 경험을 측정하는 데 사용됩니다. 소프트웨어 개발에는 도구를 사용하여 요구 사항, 표현 설계 및 분석, 구성 관리, 문서 추출, 도서관 관리, 프로그램 스타일 및 형식, 일관성 검사, 계획 및 제어 등을 포함하여 프로젝트 프로그래밍 언어 경험 외에도 프로젝트 지원 도구 세트의 경험도 개발 노력에 영향을 줄 수 있습니다. 2 개월 미만의 경험은 매우 낮은 등급을 얻을 수 있으며 6 개월 또는 몇 년 미만의 경험은 매우 높은 등급을 얻게됩니다. 아래 표를 참조하십시오.
나는 이것이 어떤 종류의 감소인지, 얼마나 많은 프로젝트가 영향을 받았는지 모르겠지만, 내 뇌는 "중요한 성능 감소"의 조합을 "많은 시간의 개발 시간 낭비"로 자동 번역했습니다.
또한 게시 노트에 대한 의견을 읽으면 많은 사람들이 마이그레이션 문제가 있음을 알 수 있습니다. 버전 1.1.2에 대한 의견에서 일부는이 "패치"릴리스가 파괴적 (뒤로 호환되지 않는) 수정을 도입했다고 지적했습니다.
대조적으로, Oracle JDK8의 릴리스 노트를 읽으면 비교적 안정적임을 알 수 있습니다. 수정의 대부분은 보안 개선입니다.
따라서 Kotlin은 Java에 비해 불안정하고 미숙 한 언어입니다. Kotlin과의 마이그레이션은 프로젝트에 무엇을 가지고 있습니까? 이 질문에 답하기 위해 Cocomo 2 평가 모델의 "플랫폼 변동성"작업 요소를 사용하겠습니다.
플랫폼 변동성 (PVOL) 여기서 "플랫폼"이라는 용어는 소프트웨어 제품이 작업을 수행 할 때 호출되는 복잡한 하드웨어 및 소프트웨어 (OS, DBMS 등)를 나타냅니다. 개발 된 소프트웨어가 운영 체제 인 경우 플랫폼은 컴퓨터 하드웨어입니다. 데이터베이스 관리 시스템이 개발되면 플랫폼은 하드웨어 및 운영 체제입니다. 네트워크 텍스트 브라우저가 개발되면 플랫폼은 네트워크, 컴퓨터 하드웨어, 운영 체제 및 분산 정보 라이브러리입니다. 이 플랫폼에는 소프트웨어 시스템의 개발을 지원하는 데 필요한 컴파일러 또는 어셈블러가 포함되어 있습니다. 다음 표에서 볼 수 있듯이 플랫폼이 12 개월마다 한 번만 변경되면 등급은 매우 낮으며 2 주마다 큰 변화가 있으면 등급이 매우 높습니다.
COCOMO2 모델 정의 설명서
이 작업 요소에 대한 설명에 프로그래밍 언어가 직접 나타나지 않지만 컴파일러 및 어셈블러가 나타납니다. 내 생각에,이 설명은 CoCOMO2 모델을 도출하는 모든 프로젝트에 안정적인 언어를 사용하기 때문에 프로그래밍 언어를 명시 적으로 포함하지 않습니다.
컴파일러와 어셈블러는이 작업 요소에 속하므로 프로그래밍 언어 및 관련 도구를 추론 할 수도 있습니다.
이 플랫폼 변동성의 등급 범위를 기준으로 Java는 '매우'이어야하며 Kotlin은 '낮은'이상이어야합니다. Kotlin은 다른 도구에 내부적으로 의존하여 호환성 문제의 위험을 증가시키기 때문에 등급이 높을 수 있습니다.
"verylow"는 작업 요소를 제공하지 않기 때문에 견적이 필요합니다.
"매우 높은"에서 "낮음"으로 요인의 감소하는 규칙을 살펴보면, 우리는 "verylow"의 점수가 0.82보다 높지 않다는 확신을 가지고 있다고 생각할 수 있다고 생각합니다.
이러한 가정에 따라 (Kotlin에 유리하게) 프로젝트에 연간 5 명이 정격 작업량이 필요한 경우 Kotlin을 사용하면 하루에 1,044 명이되고 Java를 사용하는 총 작업량은 하루 984 명입니다.
Java 대신 Kotlin을 사용하여 이러한 프로젝트를 구현하도록 선택하면 총 작업량이 60 명으로 증가합니다.
언어와 도구 불안정성으로 인한 추가 작업은 Kotlin으로 전환하여 작업이 줄어드는 것보다 두 배 이상입니다.
모든 요소를 결합합니다
내가 예제로 논의한 프로젝트에는 매년 5 명으로 구성된 정격 작업량이 필요합니다.
위의 평가에 따르면, 프로젝트가 평균 1 년의 Java 개발 경험을 가진 개발자가 Java를 사용하여 구현하는 경우 총 작업량은 다음과 같습니다.
5 년*LTEX (Java)*PVOL (Java) = 984 (People-Day)
Kotlin 개발에 대한 경험이 거의없는 개발자가 Kotlin을 사용하여 동일한 프로젝트를 구현하는 경우 총 작업량은 다음과 같습니다.
5 인년*ltex (Kotlin)*Pvol (Kotlin)*0.98+t_ramp_up = 1115+5*n_developers (Human-Heaven)
Java를 대체하기 위해 Kotlin을 선택하여 발생하는 추가 작업량은 131+5*N_Developers (Man-Day) 인 것으로 추정됩니다.
평가 예방 조치
평가 토론에서 우리는 Kotlin 및 Java와 관련된 작업량에 대한 편리한 단일 포인트 값을 제시했습니다.
그러나 실제로 단일 포인트 값은 전혀 추정치가 아닙니다. 단지 추측입니다. 실제 추정치에는 관련된 불확실성이 있어야합니다. 다시 말해, 추정치는 단일 점 값이 아닌 가능성의 범위를 나타냅니다.
추정 범위에서 Kotlin의 가장 유리한 값을 선택하고 모든 추정치를 단일 포인트 값으로 변환했기 때문에 범위 대신 단일 점 값을 사용하게되었습니다.
예를 들어, 코딩 및 디버깅 활동에 대한 Kotlin의 영향에 대해 논의 할 때, 나는 예상 가능성 범위에서 10%의 최대 생산성 향상 값을 선택했습니다 [-5%, 10%]. 다른 경우, 우리는 평균 시간에 대해 논의 할 때 개발자가 Kotlin으로 전환하는 경우, 예상 가능성 범위에서 가장 작은 5 일을 선택했습니다 [5 일, 21 일].
또한 COCOMO2 추정 모델 전용 작업 계수를 사용했습니다. 이러한 요소는 보편적 인 진실이 아니며 가장 일반적인 경우에는 관련 불확실성도 있어야합니다. 나는 Kotlin에게 실제로 가치가 있다고 생각했던 것보다 높은 등급을 할당했으며, 이런 식으로 그 불확실성을 제거하기를 희망합니다.
말할 것도없이, 우리가 얻는 단일 포인트 값은 100% 정확하지 않습니다. 보다 완전한 추정치를 얻으려면 Montecarlo 시뮬레이션에 실제 추정치를 사용할 수 있습니다. 이 기술을 통해 가능한 결과의 분포를 관찰하고 어떤 결과가 발생할 가능성이 가장 높은지 알아낼 수 있습니다.
Kotlin에게 가장 유리한 단일 포인트 값으로 추정치를 압축하므로 다른 가능한 결과는 더 큰 Kotlin 전환 오버 헤드를 보여줍니다. 따라서 가능한 모든 결과 중에서 위에서 설명한 단일 포인트 값은 Kotlin에게 가장 유리합니다.
요약
이 기사의 시작 부분에서 우리는 개발자의 프로그래밍 언어 비교에 오도 될 수있는 주관적인 판단을 보여줍니다.
다음으로, 우리는 프로그래밍 언어를 객관적으로 비교하는 데 어려움을 논의하고 소프트웨어 프로젝트를 완료하기 위해 Kotlin 스택 및 Java 스택에 필요한 총 작업량을 파악하기 위해 일련의 추정치를 수행합니다. 추정을 수행 할 때는 항상 추정 범위에서 Kotlin의 가장 유리한 값을 사용합니다.
분석을 통해 Java에서 Kotlin으로 전환하면 소프트웨어 프로젝트를 완료하는 데 필요한 총 작업량이 증가하는 것으로 보입니다.
더 많은 작업은 기업이 동일한 기능을 얻기 위해 Kotlin으로 전환하기 위해 더 많은 돈을 쓸 필요가 있음을 의미하는 반면 사용자는 제품을 얻기 위해 더 오래 기다려야합니다.
일부 개발자는 놀랐고이 결과를 받아들이 기 쉽지 않다는 것을 알 수 있습니다.
모든 상황을 고려한 후 Google은 마침내 Kotlinanroid 개발을 지원하기로 결정했습니다. Google은 이에 대한 상당한 투자가 필요할 수 있습니다. Google Cloud 플랫폼 팀의 어느 누구도 새로운 언어로 전환하는 데 미치는 부정적인 영향을 파악하기 위해 유사한 분석을 수행 할 수있는 사람이 없습니까?
Google 직원이 모두 매우 똑똑한 사람들이라고 생각하며 Kotlin을 지원하기로 결정하기 전에 매우 심층 분석을 수행했다고 생각합니다.
위의 내용은 Kotlin과 Java의 주관적이고 객관적인 비교 및 분석에 대한이 기사의 모든 내용입니다. 모든 사람에게 도움이되기를 바랍니다. 관심있는 친구는이 사이트의 다른 관련 주제를 계속 참조 할 수 있습니다. 단점이 있으면 메시지를 남겨주십시오.