Kotlin
Kotlin adalah bahasa JVM yang relatif baru, dan JetBrains telah berkembang secara aktif sejak 2011.
Selama bertahun -tahun, bahasa ini telah menerima perhatian yang semakin meningkat di komunitas Android dan telah menjadi topik terpanas dalam pengembangan Android setelah konferensi Google IO 2017. Konferensi mengumumkan bahwa Android secara resmi mendukung Kotlin.
Sayangnya, sementara sudah ada banyak artikel tentang Kotlin, tidak ada banyak informasi objektif, dan banyak pengembang masih berpikir apakah pindah ke Kotlin adalah jalan yang benar.
Di sisa artikel ini, saya akan mencoba memberikan daftar hal yang lebih lengkap untuk dipertimbangkan ketika mengevaluasi Kotlin sebagai alternatif untuk Java.
Perbandingan subyektif antara Kotlin dan Java
"Kotlin lebih baik dari Java", "Kotlin lebih mudah dibaca daripada Java", "Kecepatan pengembangan Kotlin lebih cepat dari Java", pernyataan seperti ini tidak memiliki dukungan dari data akurat yang relevan, sehingga semuanya diklasifikasikan sebagai pandangan subyektif.
Pandangan subyektif dibentuk ketika pengembang individu membuat satu atau lebih penilaian subyektif tentang topik yang terkait dengan Kotlin atau Java.
Ada masalah dengan penilaian subyektif pengembang berikut:
Tidak ada indikator kuantitatif yang terkait dengan penilaian subyektif.
Ada bias besar dalam penilaian subyektif.
Bias penilaian subyektif sangat bervariasi di antara pengembang.
Karena tidak ada metrik kuantitatif yang terkait dengan penilaian subyektif, perspektif berdasarkan penilaian ini hanya mencerminkan bias yang dimiliki pengembang sebelumnya. Pengembang yang berbeda mungkin memiliki bias yang sangat berbeda, jadi itu tidak berarti pengembang lain juga berpikir begitu.
Selain itu, karena tidak ada indikator objektif, perbedaan subyektif tidak dapat dihilangkan secara objektif, yang sering mengarah pada "perang kata -kata".
Kekeliruan penilaian subyektif
Untuk mengilustrasikan kesalahpahaman yang dapat ditimbulkan oleh penilaian subyektif, mari kita lihat lebih dekat pandangan subyektif yang sangat umum:
Kotlin lebih mudah dibaca daripada Java - artikel yang tak terhitung jumlahnya di web
Secara teori, dimungkinkan untuk mencoba merancang eksperimen yang mengukur perbedaan dalam keterbacaan antara Kotlin dan Java, tetapi sejauh yang saya tahu, tidak ada yang benar -benar melakukan percobaan seperti itu. Oleh karena itu, sampai sekarang, pandangan ini tidak memiliki dukungan data.
Sintaks Kotlin adalah salah satu alasan mengapa banyak pengembang memuji keterbacaannya. Logika mereka adalah sebagai berikut:
Kotlin memiliki sintaks yang lebih baik, jadi lebih mudah dibaca - artikel yang tak terhitung jumlahnya di web
Dalam kalimat ini, "tata bahasa yang lebih baik" adalah penilaian subyektif lain, yang sendiri dapat diperdebatkan, tetapi untuk menghindari argumen, kami berasumsi bahwa tata bahasa Kotlin memang lebih baik. Namun, apakah ini berarti bahwa Kotlin lebih mudah dibaca?
Untuk mengamati efek sintaks pada keterbacaan, baca paragraf "teks" ini:
Pada awalnya, "teks" ini sulit dipahami, tetapi perlahan, menjadi lebih mudah untuk dibaca. Jika Anda membacanya dua atau tiga kali, Anda tidak akan melihat bahwa itu terdiri dari huruf-huruf non-standar. Tepatnya, penggantian surat bukanlah perubahan sintaksis, tetapi itu menunjukkan bahwa penampilan jarang menjadi penghalang untuk keterbacaan bagi pembaca yang terampil.
Kami juga dapat memperluas contoh ini ke bahasa alami. Saya mengerti tiga bahasa yang sama sekali berbeda. Meskipun sangat berbeda, saya merasa sangat sulit untuk membaca teks dalam bahasa mana pun ketika saya tidak memahami kata -kata yang digunakan dalam teks. Begitu saya tahu kata -kata yang membentuk teks dan menjadi terbiasa dengan konteksnya - tidak peduli bahasa apa pun itu, saya tidak kesulitan membacanya.
Oleh karena itu, bagi saya, pilihan bahasa tidak mempengaruhi keterbacaan, hanya memahami konten dan konteksnya.
Hal yang sama berlaku untuk bahasa pemrograman.
Ketika kita mulai menggunakan bahasa baru, kita akan mengalami kesulitan dalam memahami kode sumber dan perlu memahami dengan cermat setiap struktur sintaksis. Namun, ketika kita membaca dan menulis kode untuk bahasa tertentu semakin banyak, kita secara bertahap menjadi terbiasa dengan sintaksis bahasa itu, dan pada titik tertentu kita tidak akan lagi memperhatikan struktur sintaksis.
Saya sendiri memiliki pengalaman dalam berbagai bahasa ini: Verilog, Bash, Perl, Tcl, Lisp, Java.
Berdasarkan pengalaman saya dengan bahasa di atas, saya dapat memberi tahu Anda: Jika seseorang beradaptasi dengan kode LISP dan tidak lagi memperhatikan tanda kurung, maka sintaksis Kotlin tidak dapat memiliki dampak yang tidak dapat diyakini pada keterbacaan dibandingkan dengan Java, bahkan jika itu "lebih baik".
Karena kita membahas topik ini, saya akan membagikan penilaian subyektif saya pada faktor -faktor yang mempengaruhi keterbacaan kode sumber.
Setelah membaca kode yang ditulis oleh pengembang lain dalam banyak bahasa (daftar di atas hanya bahasa yang saya kuasai pada tahap tertentu; Saya telah menggunakan lebih banyak bahasa daripada ini), saya sampai pada kesimpulan berikut: Jika pengembang dapat menulis kode yang dapat dibaca dan dapat dimengerti dalam satu bahasa, mereka biasanya dapat menulis kode yang dapat dibaca dan dimengerti dalam bahasa lain juga.
Oleh karena itu, penilaian subyektif yang saya buat berdasarkan pengalaman saya sendiri adalah bahwa keterbacaan kode sumber tidak ada hubungannya dengan bahasa yang dipilih, dan itu tergantung pada keterampilan penulis kode dan keterampilan pembaca (keterampilan penulis lebih penting).
Jika Anda masih berpikir pandangan subyektif itu representatif, setidaknya membaca dan berpikir tentang apa yang dipikirkan Robert "Paman Bob" Martin dalam posting blog ini.
Perbandingan objektif antara Kotlin dan Java
Berbeda dengan perbandingan subyektif, perbandingan objektif menggunakan indikator kuantitatif untuk mengukur atau mengevaluasi di mana Kotlin memiliki keunggulan dibandingkan Java.
Gagasan untuk membuktikan secara obyektif apakah bahasa pemrograman lebih baik daripada yang lain dengan satu set standar sangat menarik, tetapi ada masalah: sejauh yang saya tahu, tidak ada indikator objektif umum yang terkait dengan bahasa pemrograman.
Mengingat bahwa kita tidak dapat membuat perbandingan yang tepat dan langsung, dapatkah kita secara objektif membandingkan Kotlin dan Java? mampu! Kami masih dapat mengevaluasi tingkat dampak positif dan pesan dari pengalihan dari Java ke Kotlin, kemudian membandingkan hasilnya dan mendiskusikan dampaknya.
Untuk mengevaluasi hasil terbaik yang dapat dihasilkan Kotlin, kami akan membuat asumsi berikut:
Pengembang dapat segera beralih ke Kotlin;
Setelah beralih ke Kotlin, pengembang tidak kehilangan keterampilan apa pun (misalnya, pengembang dengan dua tahun pengalaman pengembangan Java secara ajaib dapat memperoleh dua tahun pengalaman pengembangan Kotlin);
Kotlin sama stabilnya dengan Java;
Alat Kotlin sama matangnya dengan alat Java.
Faktanya, tidak ada asumsi di atas yang masuk akal, tetapi pada awalnya, ada pengaturan yang ideal untuk penjelasan yang mudah. Kemudian, kami akan mengesampingkan asumsi-asumsi ini dan mendiskusikan dampak efek dunia nyata.
Kotlin Estimasi Hasil Terbaik
Mengikuti model yang diusulkan oleh Steve McConnell dalam kode lengkap, kami dapat memecah kegiatan konstruksi perangkat lunak menjadi tiga sub-aktivitas: desain terperinci, pengkodean dan debugging, dan pengembangan dan pengujian.
Kotlin memiliki sedikit efek pada merancang sub-aktivitas secara rinci (aktivitas ini biasanya tidak tergantung pada bahasa pemrograman berorientasi objek spesifik yang dipilih), sehingga Kotlin dan Java perlu melakukan upaya yang sama di bagian ini.
Sejauh yang saya tahu, Kotlin belum mengusulkan sesuatu yang revolusioner tentang sub-aktivitas uji pembangunan. Oleh karena itu, hal yang sama berlaku untuk mengembangkan pengujian.
Semua sub-aktivitas pengkodean dan debugging tersisa.
Jika kami mengganti Java dengan Kotlin, berapa banyak pekerjaan yang dapat saya simpan dalam kegiatan pengkodean dan debugging? Pertanyaan ini sulit dijawab, dan nilai ini sangat bervariasi antara pemrogram (beberapa programmer menggunakan Java lebih efisien). Namun, sekarang kami mengevaluasi situasi terbaik, kami mungkin juga berasumsi bahwa beralih dari Java ke Kotlin dapat meningkatkan produktivitas pengembang dengan rata -rata 10% selama fase pengkodean dan debugging.
Peningkatan produktivitas 10% adalah nilai yang sangat tidak realistis. Bahkan jika kita secara manual memasukkan semua kode dalam editor teks, itu tidak realistis. Mempertimbangkan fungsi IDE saat ini, nilai ini bahkan lebih tidak realistis. Mempertimbangkan bahwa beberapa pengembang menggunakan Java lebih efisien, nilai ini tidak masuk akal.
Saya tidak keberatan menggunakan nilai seperti itu yang tidak realistis dan menguntungkan untuk penilaian Kotlin, karena saya tahu bahwa tidak peduli seberapa tidak realistis positifnya pada hasil penilaian, begitu kami mengesampingkan beberapa "asumsi ideal" di dalamnya, dampak negatif yang dihasilkan akan mengimbangi efek positif tersebut.
Jadi, dalam hal pengkodean dan debugging, kami telah meningkat sebesar 10% - seberapa cepat kami mengirimkan produk kami kepada pelanggan kami?
Gambaran berikut ini dari kode buku lengkap, menunjukkan proporsi berbagai kegiatan proyek perangkat lunak:
Proyek kecil gambar berfokus pada kegiatan konstruksi. Proyek yang lebih besar membutuhkan lebih banyak arsitektur, integrasi, dan pengujian sistem untuk memastikan proyek berhasil. Gambaran ini tidak menunjukkan persyaratan karena tidak seperti kegiatan lainnya, persyaratan kerja bukan fungsi program langsung. ;
Kode lengkap, edisi kedua
Menurut gambar ini dari kode lengkap, dalam proyek perangkat lunak yang lebih besar (lebih dari 10 ribu baris), akun pengkodean dan debugging kurang dari 20% dari total beban kerja proyek.
Oleh karena itu, dalam proyek perangkat lunak yang lebih besar, efisiensi pengkodean dan debugging yang kami asumsikan adalah 10%, yang hanya dapat mengurangi total beban kerja yang diperlukan untuk menyelesaikan proyek sebesar 2%.
Misalnya, proyek yang membutuhkan 5 orang untuk diselesaikan selama bertahun -tahun (ini adalah proyek Android yang relatif besar), 2% dari total beban kerja adalah:
5 orang - Tahun * 12 * 4 * 5 * 0,02 = 24 (orang - hari)
Jika kita benar-benar dapat mengurangi beban kerja proyek dengan 24 orang-hari, itu akan menjadi alasan yang baik untuk beralih dari Java ke Kotlin. Namun, kita harus ingat bahwa penilaian positif di atas diturunkan dalam situasi yang ideal dan didasarkan pada asumsi yang tidak realistis.
Di dunia nyata, beralih ke bahasa pemrograman lain memiliki dampak yang tak terhindarkan, yang akan kami evaluasi dan bandingkan dengan evaluasi ideal yang disebutkan di atas.
Persiapan pengembang
Untuk mengevaluasi skenario kasus terbaik, kami berasumsi bahwa pengembang dapat beralih dari Java ke Kotlin segera.
Faktanya, sementara Kotlin sangat mirip dengan Java, pengembang masih perlu menghabiskan waktu belajar dan kemudian menghabiskan waktu mengutak -atik praktik dan alat pengembangan. Waktu persiapan bervariasi dari orang ke orang: beberapa pengembang dapat beralih antara tiga atau empat hari, sementara yang lain dapat memakan waktu 10 hari atau lebih.
Mari kita optimis, rata -rata, setiap pengembang dapat beralih dari Java ke Kotlin hanya dalam 5 hari.
Sebuah proyek yang membutuhkan waktu 5 orang untuk menyelesaikannya akan memiliki 3 hingga 5 pengembang (dalam kasus terbaik). Waktu switching rata-rata untuk setiap pengembang adalah 5 hari, sehingga suatu proyek membutuhkan waktu 15 hingga 25 hari switching waktu secara total.
Upaya yang disimpan dengan beralih ke Kotlin (estimasi optimis) tampaknya hampir sama dengan upaya total yang diperlukan untuk beralih.
Kehilangan Keterampilan Pengembang
Kemampuan untuk bekerja secara efisien dalam bahasa pemrograman tertentu adalah keterampilan.
Kami telah membahas satu aspek dari keterampilan ini (keterbacaan kode), tetapi ada banyak lainnya. Saat beralih dari satu bahasa ke bahasa lain, beberapa keterampilan yang terkait dengan bahasa pemrograman lama dapat diterapkan pada bahasa baru, tetapi bagian lain dari keterampilan itu hilang.
Untuk mengevaluasi dampak hilangnya keterampilan bahasa pemrograman pada beban kerja proyek, kami akan menggunakan faktor "Bahasa & Alat Pengalaman" yang berasal dari model evaluasi Cocomo2:
Pengalaman Bahasa dan Alat (LTEX)
Metrik ini digunakan untuk mengukur pengalaman tim proyek yang mengembangkan sistem perangkat lunak atau subsistem menggunakan bahasa pemrograman dan perangkat perangkat lunak. Pengembangan perangkat lunak termasuk menggunakan alat untuk menyelesaikan persyaratan, desain dan analisis ekspresi, manajemen konfigurasi, ekstraksi dokumen, manajemen perpustakaan, gaya dan pemformatan program, pemeriksaan konsistensi, perencanaan dan kontrol, dll. Selain pengalaman bahasa pemrograman proyek, pengalaman alat pendukung proyek juga dapat memengaruhi upaya pengembangan. Pengalaman di bawah 2 bulan akan mendapatkan peringkat yang sangat rendah, dan pengalaman di bawah 6 bulan atau tahun akan mendapatkan peringkat yang sangat tinggi, lihat tabel di bawah ini:
Saya tidak tahu penurunan seperti apa ini, berapa banyak proyek yang telah terpengaruh, tetapi otak saya secara otomatis menerjemahkan kombinasi "penurunan kinerja yang signifikan" menjadi "yang terbuang berjam -jam waktu pengembangan."
Juga, jika Anda membaca komentar pada catatan posting, Anda akan melihat bahwa banyak orang mengalami masalah migrasi. Dalam komentar pada versi 1.1.2, beberapa bahkan menunjukkan bahwa rilis "patch" ini memperkenalkan modifikasi destruktif (tidak kompatibel ke belakang).
Sebaliknya, jika Anda membaca catatan rilis Oracle JDK8, Anda akan menemukan bahwa itu relatif stabil. Sebagian besar modifikasi adalah peningkatan keamanan.
Oleh karena itu, Kotlin adalah bahasa yang tidak stabil dan tidak matang dibandingkan dengan Java - apa yang akan dimiliki migrasi ke Kotlin pada proyek? Untuk menjawab pertanyaan ini, saya akan menggunakan faktor kerja "Platform Volatility" dari model evaluasi Cocomo 2:
Platform Volatility (PVOL) Di sini istilah "platform" mengacu pada perangkat keras dan perangkat lunak yang kompleks (OS, DBMS, dll.) Yang disebut ketika produk perangkat lunak melakukan tugas. Jika perangkat lunak yang dikembangkan adalah sistem operasi, maka platformnya adalah perangkat keras komputer. Jika sistem manajemen basis data dikembangkan, maka platform adalah perangkat keras dan sistem operasi. Jika browser teks jaringan dikembangkan, maka platform adalah jaringan, perangkat keras komputer, sistem operasi, dan pustaka informasi terdistribusi. Platform ini mencakup kompiler atau perakit yang diperlukan untuk mendukung pengembangan sistem perangkat lunak. Seperti yang ditunjukkan pada tabel berikut, jika platform hanya berubah sekali setiap 12 bulan, peringkat akan sangat rendah, dan jika ada perubahan besar setiap 2 minggu, peringkatnya akan sangat tinggi:
Manual Definisi Model Cocomo2
Anda mungkin telah memperhatikan bahwa bahasa pemrograman tidak muncul secara langsung dalam deskripsi faktor kerja ini, tetapi kompiler dan perakit muncul. Menurut pendapat saya, deskripsi ini tidak secara eksplisit mencakup bahasa pemrograman karena semua proyek yang mendapatkan model COCOMO2 menggunakan bahasa yang stabil.
Karena kompiler dan perakit termasuk faktor kerja ini, kami juga dapat menyimpulkan bahasa pemrograman dan alat terkait.
Berdasarkan kisaran peringkat volatilitas platform ini, Java harus 'sangat rendah', sedangkan Kotlin harus 'rendah' atau lebih tinggi. Kotlin mungkin memiliki peringkat yang lebih tinggi karena bergantung secara internal pada alat lain, meningkatkan risiko masalah kompatibilitas.
Karena "sangat rendah" tidak memberikan faktor kerja, kami membutuhkan perkiraan.
Melihat penurunan aturan faktor dari "sangat tinggi" menjadi "rendah", saya pikir kita dapat berasumsi dengan keyakinan bahwa skor "sangat rendah" tidak lebih tinggi dari 0,82.
Berdasarkan asumsi -asumsi ini (mendukung Kotlin), jika suatu proyek membutuhkan beban kerja yang dinilai 5 orang per tahun, maka menggunakan Kotlin akan menjadi 1.044 orang per hari, sedangkan total beban kerja menggunakan Java adalah 984 orang per hari.
Memilih untuk mengimplementasikan proyek seperti itu menggunakan Kotlin, bukan Java akan meningkatkan total beban kerja oleh 60 orang.
Pekerjaan ekstra yang disebabkan oleh ketidakstabilan bahasa dan alat lebih dari dua kali lipat dari pekerjaan yang dikurangi dengan beralih ke Kotlin.
Menggabungkan semua faktor
Proyek yang saya diskusikan sebagai contoh membutuhkan beban kerja teringkat 5 orang per tahun.
Menurut evaluasi di atas, jika proyek dilaksanakan menggunakan Java oleh pengembang dengan rata -rata 1 tahun pengalaman pengembangan Java, total beban kerja adalah:
5 orang-tahun*ltex (java)*pvol (java) = 984 (hari orang)
Jika proyek yang sama diimplementasikan menggunakan Kotlin oleh pengembang dengan sedikit pengalaman dalam pengembangan Kotlin, total beban kerja adalah:
5 orang-tahun*ltex (Kotlin)*pvol (Kotlin)*0.98+t_ramp_up = 1115+5*n_developers (human-heaven)
Diperkirakan bahwa beban kerja tambahan yang disebabkan oleh memilih Kotlin untuk menggantikan Java adalah 131+5*n_developer (hari manusia).
Tindakan pencegahan evaluasi
Selama diskusi evaluasi, kami menghasilkan nilai titik tunggal yang nyaman untuk beban kerja yang terkait dengan Kotlin dan Java.
Tetapi pada kenyataannya, nilai -nilai titik tunggal bukanlah perkiraan sama sekali - mereka hanya tebakan. Perkiraan sebenarnya harus memiliki ketidakpastian terkait. Dengan kata lain, perkiraan mewakili rentang kemungkinan, bukan nilai titik tunggal.
Kami akhirnya menggunakan nilai titik tunggal alih -alih rentang karena saya memilih nilai yang paling menguntungkan untuk Kotlin dari rentang estimasi dan mengubah semua estimasi menjadi nilai titik tunggal.
Misalnya, ketika membahas dampak Kotlin pada kegiatan pengkodean dan debugging, saya memilih nilai peningkatan produktivitas maksimum 10%dari perkiraan kisaran kemungkinan [-5%, 10%]. Dalam kasus lain, ketika kita membahas waktu rata -rata pengembang beralih ke Kotlin, saya memilih 5 hari terkecil dari perkiraan kisaran kemungkinan [5 hari, 21 hari].
Selain itu, kami menggunakan faktor kerja yang didedikasikan untuk model estimasi COCOMO2. Faktor -faktor ini bukan kebenaran universal, dan dalam kasus yang paling umum, juga harus ada ketidakpastian terkait. Saya menugaskan Kotlin peringkat yang lebih tinggi daripada yang saya kira layak, dan saya berharap untuk menghapus ketidakpastian itu dengan cara ini.
Tak perlu dikatakan, nilai titik tunggal yang kita dapatkan tidak 100% benar. Untuk mendapatkan perkiraan yang lebih lengkap, kita dapat menggunakan perkiraan nyata untuk simulasi Montecarlo. Melalui teknik ini, kita dapat mengamati distribusi hasil yang mungkin dan mencari tahu hasil mana yang paling mungkin terjadi.
Ingatlah bahwa karena kami memampatkan estimasi ke dalam nilai titik tunggal yang paling menguntungkan untuk Kotlin, hasil lain yang mungkin akan menunjukkan overhead switching Kotlin yang lebih besar. Oleh karena itu, dari semua hasil yang mungkin, nilai titik tunggal yang kami jelaskan di atas paling menguntungkan bagi Kotlin.
ringkasan
Pada awal artikel, kami menunjukkan beberapa penilaian subyektif yang mungkin menyesatkan dengan perbandingan pengembang bahasa pemrograman.
Selanjutnya, kami membahas kesulitan dalam membandingkan bahasa pemrograman secara objektif dan melakukan serangkaian perkiraan untuk mengetahui total beban kerja yang diperlukan untuk tumpukan Kotlin dan Java Stack untuk menyelesaikan proyek perangkat lunak. Saat melakukan estimasi, kami selalu menggunakan nilai Kotlin yang paling menguntungkan dalam kisaran estimasi.
Melalui analisis kami, beralih dari Java ke Kotlin tampaknya menghasilkan peningkatan total beban kerja yang diperlukan untuk menyelesaikan proyek perangkat lunak.
Lebih banyak pekerjaan berarti bahwa bisnis perlu menghabiskan lebih banyak uang untuk beralih ke Kotlin untuk mendapatkan fitur yang sama, sementara pengguna perlu menunggu lebih lama untuk mendapatkan produk.
Beberapa pengembang mungkin terkejut dan menemukan hasil ini tidak mudah diterima.
Setelah mempertimbangkan semua situasi, Google akhirnya memutuskan untuk mendukung pengembangan Kotllagnoid. Google mungkin memerlukan investasi yang cukup besar dalam hal ini - apakah tidak ada orang di tim Google Cloud Platform yang dapat melakukan analisis serupa untuk mengetahui dampak negatif dari beralih ke bahasa baru?
Saya pikir karyawan Google adalah orang-orang yang sangat pintar dan saya percaya mereka telah melakukan analisis yang sangat mendalam sebelum mereka memutuskan untuk mendukung Kotlin.
Di atas adalah semua isi artikel ini tentang perbandingan subyektif dan obyektif dan analisis Kotlin dan Java. Saya harap ini akan membantu semua orang. Teman yang tertarik dapat terus merujuk ke topik terkait lainnya di situs ini. Jika ada kekurangan, silakan tinggalkan pesan untuk menunjukkannya!