"Berapa banyak pemirsa yang akan datang ke pembicaraan Java Anda?" Itu tergantung pada apakah Venkat tampil di aula yang berdekatan pada saat yang sama. ”
Ini adalah lelucon dengan kebenaran yang lumayan: di dunia Jawa,
Venkat Subramaniam adalah salah satu pembicara paling terkenal, yang benar-benar mampu menarik penonton dari aula lain di konferensi. Dia telah bergerak tanpa henti di planet ini dan baru-baru ini mencetak rekor yang mengesankan, dengan ulang tahunnya yang ke 50 berbicara dalam satu tahun sebelum 50 Kelompok Pengguna Java yang berbeda.
Bagaimana rasanya ketika karir Java Anda bukan "duduk di kantor", tetapi "terus bergerak"? Dan apa pendapat Venkat tentang masalah Java saat ini? Pada bulan Oktober, ia akan tiba di St. Petersburg, dan untuk mengantisipasi hal ini, kami (
phillenium ,
olegchir ) mewawancarainya secara terperinci, di mana kami memulai dengan “life on the plane” dan tip-tip untuk pembicara
pemula , dan kemudian beralih ke teknologi.
Karena Venkat menjawab secara detail, teksnya panjang. Jika mau, Anda dapat langsung menuju ke bagian kedua:
Seumur hidup
- Mari kita mulai dengan tur Anda, di mana Anda mengunjungi 50 grup pengguna Java, hampir tidak ada yang pernah melakukan ini sebelumnya. Apa kesan Anda?- Hal yang paling menarik bagi saya adalah kesadaran bahwa, dalam budaya yang berbeda di berbagai belahan dunia, orang yang berbicara bahasa yang berbeda, terlepas dari semua perbedaan ini, disatukan oleh pemrograman sebagai satu utas penghubung. Ketika kita mulai berbicara tentang pemrograman, ternyata masalah yang kita hadapi setiap hari adalah sama. Ini adalah penemuan hebat bagi saya - Anda dapat bertemu seorang programmer di bandara mana pun di dunia, dan Anda pasti akan menemukan topik umum untuk percakapan. Saya tanpa henti dapat membuat daftar kasus di mana saya terlibat dalam pembicaraan tentang Jawa di sisi lain Bumi.
Karena itu, pengalaman dengan kelompok-kelompok ini sangat berguna bagi saya. Mengelola grup pengguna sangat sulit ... Saya tidak ingin mengatakan "bekerja" karena itu tidak berfungsi, tetapi Anda harus menghabiskan banyak usaha. Saya sangat menghormati semua pemimpin yang mengumpulkan acara ini berulang-ulang setiap bulan. Kelompok yang berbeda memiliki dinamika yang berbeda - beberapa memiliki 20 atau 30 orang di pertemuan, yang lain 200 atau 300. Namun, jumlahnya tidak terlalu penting, karena hal utama adalah hasrat pengembang yang datang ke pertemuan ini, minat mereka pada teknologi dan keinginan mereka untuk belajar. Jadi saya sangat beruntung mendapat kesempatan untuk bertemu dengan kelompok-kelompok ini, dan saya sangat berterima kasih karenanya.
- Dan dengan kesamaan yang Anda sebutkan, apakah grup pengguna di berbagai belahan dunia memiliki perbedaan lokal yang nyata?- Perbedaan-perbedaan ini sangat sedikit. Saya perhatikan bahwa di beberapa daerah lebih banyak preferensi diberikan pada kerangka kerja kelas berat, dan di tempat lain untuk solusi yang lebih ringan. Tetapi, sebagai suatu peraturan, semua fitur ini dangkal, dan pertanyaan dan masalah yang mendalam, sebaliknya, bersifat universal. Dengan tulus saya ingin memberi tahu Anda bahwa pada titik tertentu di peta orang melakukan hal yang sama sekali berbeda dari kita, dan semuanya menarik dan tidak terduga di sana, tetapi saya tidak bisa mengatakan itu.
Kita semua berjuang untuk kompleksitas, itu menyeret kita, dan ketika itu menyeret, kita mulai melawannya. Ini adalah tren umum hampir di semua tempat. Masalah penting lain yang tidak ada yang lolos adalah persyaratan ketat dari bisnis dan kurangnya waktu untuk bekerja pada kualitas. Saya dapat berbicara tentang beberapa contoh kepada orang-orang di mana saja di dunia, dan setelah kisah saya, saya akan ditanya: "Apakah Anda kebetulan bekerja di perusahaan kami?" Masalah kita begitu dalam dan universal sehingga, tampaknya, itu biasa terjadi di seluruh dunia. Yang tanpa sadar membuat kita berpikir tentang esensi manusia kita bersama, tentang psikologi dan filsafat, yang akhirnya kita ikuti. Tidak peduli seberapa besar kita membayangkan diri kita sendiri ketika para Geeks beralih ke teknologi, kita tidak boleh melupakan aspek manusia dalam pengembangan perangkat lunak. Tampaknya, ia adalah kekuatan pemersatu dan universal.
- Saya ingin bertanya tentang gaya hidup "berkemah". Ketika Anda duduk di kantor, mungkin tidak jelas apakah Anda menginginkan kehidupan seperti kehidupan Anda. Sebagai contoh, bagi banyak orang, jetlag adalah masalah, dan karena ini, penerbangan konstan dapat tampak seperti mimpi buruk. Tapi mungkin dengan latihan, Anda beradaptasi dengan ini?- Untuk menjawab pertanyaan Anda, mari kita ingat integrasi berkelanjutan. Jika sebuah tim melakukan integrasi sebulan sekali, maka Anda menyarankan agar mereka melakukannya setiap saat, mereka akan menganggap Anda gila. Dalam hal ini, hubungan perjalanan menyerupai integrasi berkelanjutan dan pengiriman terus-menerus: jika Anda sering berurusan dengannya, pendekatan Anda terhadapnya berubah.
Jangan salah paham, saya tidak bangga dengan cara hidup saya, menurut saya, tidak layak hidup seperti itu. Saya selalu mengatakan bahwa dalam perjalanan saya paling tidak suka perjalanan itu sendiri. Duduk di pesawat melelahkan, tubuh aus, dan dengan bertambahnya usia, masalah ini tidak pergi ke mana pun. Tetapi ketika saya sampai di tujuan, ketika saya bertemu dengan pengembang lain, saya melihat hasrat mereka akan teknologi, antusiasme mereka, saya mendapatkan kesempatan untuk membagikan hasrat ini, mempelajari sesuatu yang baru dan membantu mempelajarinya, semua kesulitan terbayar dengan bunga.
Jika kita berbicara tentang perubahan zona waktu, maka itu tidak mengganggu saya sama sekali. Karena penerbangan konstan, dalam arti tertentu saya tidak punya waktu, "rumah" konstan. Saya punya aturan: Saya selalu bangun pada waktu yang sama, sekitar jam 3.30 malam, dan tubuh dengan sangat cepat memasuki irama tertentu. Dan, tentu saja, kopi selalu diterima.
- Banyak orang ingin melihat dunia, tetapi mereka biasanya melakukan perjalanan wisata, dan bukan melakukan perjalanan bisnis. Apakah Anda dapat melihat kota-kota, atau karena kurangnya waktu hanya di ruang konferensi?- Ya, sebagian ada masalah dengan waktu. Tapi, selain itu, karena penerbangan terus-menerus, saya punya beberapa prinsip yang saya patuhi. Jika perjalanan dihubungkan dengan pekerjaan, maka saya tidak melakukan apa-apa selain bekerja. Saya mencoba menghabiskan waktu sebanyak mungkin dengan para pengembang. Ketika saya memiliki hari Sabtu atau Minggu gratis, misalnya, di Eropa, saya biasanya menghabiskannya dalam grup pengguna. Ini memberi saya kesenangan besar untuk berkomunikasi dengan pengembang, jadi dalam perjalanan bisnis saya, saya hampir tidak pernah pergi ke tempat-tempat menarik.
Tetapi setiap tahun selama empat atau enam minggu di musim panas saya bepergian dengan keluarga saya, dan kami pergi bertamasya. Ini adalah waktu kita untuk istirahat bersama, dan di bulan-bulan berikutnya saya fokus pada pekerjaan.
Selain itu, pendekatan saya memungkinkan saya untuk memberikan perhatian maksimal pada berbagai acara komunitas, yang juga memberi saya kesenangan besar. Ini menghabiskan banyak waktu dan semacam kompromi, tetapi itu cocok untuk saya. Hidup kadang-kadang terlalu menegangkan, dan saya senang dengan kesempatan untuk kadang-kadang terganggu dan mendengarkan pengembang yang mungkin tidak memiliki kesempatan untuk menghadiri konferensi atau kursus pelatihan. Selain itu, saya percaya bahwa ini juga tugas profesional saya, karena alasan inilah yang menginspirasi saya di masa muda saya. Saya mengunjungi grup pengguna, mendengarkan pertunjukan dan bermimpi pada waktu saya juga untuk tampil sendiri. Jika saya, pada gilirannya, berhasil menginspirasi setidaknya satu orang dengan cara yang sama, kali ini akan dihabiskan dengan baik.
- Pertanyaan perjalanan terakhir. Dalam film "Up in the Air," karakter George Clooney, yang terus terbang di antara kota-kota, mengetahui banyak trik untuk meningkatkan efisiensi perjalanan: cara mengantre, cara mengemas barang bawaan, dan sebagainya. Mungkin Anda juga memiliki pengetahuan tidak jelas yang ingin Anda bagikan?“Saya malu mengakuinya, tapi kadang-kadang saya mengirim pakaian antar kota di FedEx, karena saya tidak punya waktu untuk pulang dan membawa pakaian untuk minggu depan. Seringkali, ketika saya tiba di hotel, pakaian saya sudah ada di sana, dan ketika saya pergi, saya mengirim mereka pulang. Untungnya, ini tidak terjadi terlalu sering, mungkin tiga atau empat kali setahun, ketika saya dalam perjalanan selama tiga minggu berturut-turut. Ada satu momen canggung ketika istri saya harus pergi ke bandara untuk menyerahkan tas-tas itu kepada saya, karena saya hanya punya waktu setengah jam antar penerbangan. Namun seiring waktu, Anda benar-benar belajar melakukan beberapa hal dengan lebih efisien. Kadang-kadang itu mengejutkan saya ketika orang mengatakan "Saya harus berkemas" karena barang-barang saya dikumpulkan sepanjang waktu.
Berbicara tentang efisiensi, saya memiliki setidaknya satu keuntungan: Saya adalah orang yang sangat lajang. Kita hidup di dunia Facebook, Twitter dan berbagai rasul, mereka terus-menerus mengganggu kita. Saya bekerja keras untuk mengurangi efek ini, karena menit berubah menjadi jam, jam berubah menjadi hari, hari berubah menjadi minggu, dan cepat atau lambat Anda menyadari bahwa Anda tidak dapat mencapai apa yang Anda inginkan. Biasanya saya memiliki jurnal di mana saya menuliskan hal-hal yang perlu dilakukan untuk setiap perjalanan. Jadi, saya memiliki jadwal untuk setiap hari (misalnya, untuk 7 November atau 8 Oktober), dan telepon saya mengingatkan saya pada setiap tugas pada hari yang sama. Selama penerbangan delapan jam, saya bisa menulis sebagian besar dari satu bab buku, atau menyiapkan contoh untuk kursus. Karena itu, penerbangan untuk saya adalah waktu yang sangat efektif. Saya tidak pernah membutuhkan hiburan tambahan selama penerbangan - hiburan yang cukup terkait dengan debugging kode sudah cukup. Jadi seorang pelancong profesional (jika istilah seperti itu berlaku umum) menghabiskan waktu dalam penerbangan dengan cara yang sangat berbeda dari turis.
- Mungkin, karena ketenaran Anda, Anda mendapatkan lebih banyak surat daripada pengembang biasa. Berapa banyak yang mereka tulis untuk Anda dan berapa banyak waktu yang dibutuhkan untuk mengirim surat?- Perlu ditambahkan bahwa saya mengajar di universitas dan menerima banyak surat dari siswa. Biasanya saya mendapat 20 atau 30 surat sehari. Sekitar setahun yang lalu saya
menulis di blog tentang salah satu prinsip saya: "jawab sekarang atau katakan ketika Anda menjawab."
Saya sangat menghargai waktu saya, yang berarti saya menghargai waktu orang lain. Menurut pendapat saya, menghormati orang lain bukan di banding tuan, tapi menghargai waktu masing-masing. Karena itu, jika ada surat yang datang kepada saya, saya selalu membalas dalam 24 jam. Tetapi ada kalanya itu tidak berhasil untuk memberikan jawaban penuh - misalnya, jika penyelenggara konferensi meminta untuk mengirim anotasi atau jika seorang kolega di industri mengajukan pertanyaan tentang penyelesaian masalah tertentu, meminta untuk membuat ulang beberapa kode, atau bertanya tentang menggunakan metode tertentu. Terkadang jawabannya mungkin memakan waktu sepuluh menit, dan kadang-kadang dua jam, tetapi bahkan sepuluh menit tidak selalu bisa dihabiskan. Ini mungkin terdengar agak aneh, tetapi saya masih merespons dalam beberapa kasus dalam waktu 24 jam dan menulis: Saya menerima surat Anda, saya akan mengatasi masalah ini, katakanlah, 2 September dan menulis kepada Anda tanggal 3. Pada saat yang sama, kalender saya diperbarui dengan entri yang sesuai pada hari ketika saya memiliki waktu penerbangan atau di sore hari.
Berkat pendekatan ini, kotak masuk saya selalu kosong, saya membersihkannya setiap malam sebelum tidur. Jadi saya sangat disiplin dalam menjawab surat. Orang-orang sering terkejut bahwa saya menanggapi surat-surat mereka begitu cepat, tetapi saya, sebaliknya, tidak mengerti bagaimana sebaliknya. Saya tidak ingin menghalangi orang, untuk mencegah mereka berkembang. Selain itu, saya menganggap penting untuk mengatakan tidak. Saya suka mengulangi bahwa semakin sering Anda menjawab ya, semakin buruk Anda mendapatkan apa yang Anda lakukan. Pada saat tertentu, Anda perlu menyadari bahwa kami tidak dapat mencapai segalanya di dunia. Karena itu, terkadang saya menjawab itu, sayangnya, saya tidak bisa membantu. Pada gilirannya, saya lebih suka diberitahu tidak segera, dan tidak menarik karet dan berkata tidak nanti. Menurut pendapat saya, ini juga berbicara tentang menghormati orang tersebut dan keengganan untuk membuang-buang waktu dengan sia-sia. Anda tidak harus membantu, tetapi setidaknya jangan repot-repot. Karena itu, penting untuk mengatakan tidak. Ini adalah bagaimana kehidupan diatur, jangan mencoba untuk berpura-pura bahwa Anda dapat melakukan segalanya di dunia. Bagi saya, kemampuan untuk merespons dengan cepat dan jujur adalah tanda profesionalisme.
- Anda adalah pembicara yang sangat berpengalaman. Sebagai penyelenggara konferensi, kami bertemu orang-orang yang tidak memiliki pengalaman berbicara di depan umum atau yang memiliki sangat sedikit. Mungkin Anda punya rekomendasi untuk mereka? Anda memiliki tip yang menarik di Twitter "untuk mengunjungi aula di mana laporan akan diadakan sebelumnya" - apakah ada lagi?- Laporan pertama saya ada di grup pengguna, itulah sebabnya saya terus membuat 15 laporan di dalamnya setiap tahun. Dan saya sarankan orang lain memulai dengan hal yang sama: dengan grup pengguna di wilayah Anda, lalu di negara tetangga, dan seterusnya.
Karena banyak alasan, laporan-laporan ini memiliki risiko lebih sedikit daripada di konferensi besar: ada suasana yang bersahabat, orang-orang datang ke sana untuk berbagi pengetahuan, setelah laporan Anda akan mudah bagi Anda untuk mendapatkan respons. Anda dapat memulai presentasi dengan baik dengan mengatakan bahwa Anda memiliki sedikit pengalaman dalam hal ini dan ingin mengetahui pendapat audiens. Tahun ini saya punya laporan baru, selama persiapan yang saya alami banyak. Saya menulis tentang ini di Twitter: sepertinya semuanya bisa dikatakan dalam dua menit, tetapi dalam kenyataannya materi tidak dapat dimasukkan dalam satu setengah jam. Dan saya sangat senang bahwa pertama kali saya membuat laporan ini dalam kelompok pengguna, karena ini memberi saya kesempatan untuk lebih mempersiapkannya untuk konferensi.
Dalam grup pengguna atau di perusahaan tempat Anda bekerja, Anda memiliki peluang besar untuk berlatih presentasi. Pertama, Anda akan menerima kritik dari rekan kerja, yang akan memungkinkan Anda untuk meningkatkan laporan. Kedua, bahkan jika mereka tidak mengatakan apa pun secara langsung kepada Anda, Anda masih akan banyak memahami diri sendiri ketika Anda mulai berbicara. Saya percaya bahwa adalah mungkin untuk benar-benar memperbaiki laporan dari ketiga kalinya. Pertama kali Anda hanya mencoba menyatukan semua pikiran. Dan inilah yang menarik: berlatih sendiri tidak akan membantu di sini, kesadaran akan masalah hanya datang ketika berbicara dengan orang lain. Pada ketiga kalinya, rantai logis narasi Anda menjadi lebih jelas untuk Anda, itu selesai. Ini tidak selalu terlihat, tetapi kadang-kadang saya berhenti selama pidato saya untuk ketiga kalinya - pada saat ini saya menyadari apa yang saya coba katakan dalam laporan bahwa semacam momen kebenaran datang. Jadi, latihan itu sangat penting, tetapi tidak sendirian, tetapi dengan orang-orang. Ini bisa memberi pengembang muda kepercayaan yang diperlukan.
Benar, beberapa membuat laporan pertama mereka di konferensi. Terkadang lebih mudah bagi seseorang untuk mati daripada berbicara di depan umum, dan mereka mudah dimengerti - dibutuhkan banyak kegelisahan. Dua atau tiga tahun lalu, saya berbicara di sebuah konferensi. Seseorang yang sangat tertarik mendatangi saya dan mengatakan bahwa, tampaknya, saya sangat khawatir, dan saya menjawab bahwa ini memang benar. Dia bertanya, "Apakah ini laporan pertamamu?", Dan aku menjawab: "Tidak, mungkin sepuluh ribu, itu sebabnya aku khawatir." Setiap kinerja di depan audiens membutuhkan banyak tekanan emosional, bahkan jika Anda memiliki banyak pengalaman, hanya karena Anda peduli tentang bagaimana laporan berjalan. Anda akan melakukan pekerjaan dengan baik jika Anda meredakan ketegangan ini dengan beberapa laporan pengujian dalam kelompok pengguna atau di perusahaan Anda. Ini berlaku untuk semua pembicara, termasuk yang berpengalaman.
- Tetapi adakah sesuatu dalam pembicaraan di depan umum yang harus, sebaliknya, dihindari?“Saya membuat banyak kesalahan dalam hidup saya yang mengajari saya bahwa orang-orang belajar terbaik dari pengalaman.” Saat Anda berbicara kepada audiens, ada beberapa hal yang perlu diingat. Pertama, Anda perlu mempertahankan kepercayaan diri: Anda banyak bekerja pada topik, dan Anda tahu banyak tentang itu. Kedua, ingat: tidak mungkin mengetahui segalanya, dan ketidaktahuan akan sesuatu bukanlah kesalahan Anda. Itu hanya berarti bahwa Anda tidak memiliki kesempatan untuk memperhatikan ini, dan tidak ada yang salah dengan itu. Sangat penting untuk secara jujur mengakui hal ini kepada diri Anda sendiri. Anda dapat menjawab pertanyaan di konferensi seperti ini: maaf, saya tidak dapat memberi tahu Anda apa pun, saya tidak memiliki kesempatan untuk mempelajari masalah ini.
Poin penting lainnya adalah bahwa pendengar dapat dibagi menjadi tiga jenis. Ada orang yang ingin belajar sesuatu yang baru dari Anda. Orang lain menjaga diri mereka sedikit lebih hati-hati, mereka akan mendengarkan Anda, tetapi mereka tidak akan siap untuk memahami semua yang Anda katakan. Akhirnya, ada kelompok orang ketiga, untungnya, agak kecil: mereka yang bermusuhan dan berusaha untuk menangkap Anda sepanjang waktu. Cepat atau lambat, laporan Anda pasti akan memiliki satu pengembang yang akan mengganggu Anda sepanjang waktu dan mengganggu kemajuan laporan. Dalam kasus seperti itu, sangat penting untuk tetap tenang, untuk membiarkannya berbicara dan mengembalikan diskusi ke arah yang Anda butuhkan - tetapi, saya harus mengakui, saya juga seorang pribadi, dan saya tidak selalu berhasil melakukan ini. Anda dapat, misalnya, mengatakan: Saya mengerti bahwa ini penting bagi Anda, mari kita diskusikan setelah laporan, topik ini penting bagi banyak orang di sini. Benar, sangat sering Anda memiliki sekutu di antara hadirin, dan ketika seseorang benar-benar melanggar jalannya pidatonya, ia diminta untuk tenang. Semua ini saya katakan kepada fakta bahwa penting untuk tidak terlalu berkonflik dalam situasi seperti itu, meskipun sifat kita dapat menolak ini. Sebagai pembicara muda, saya cukup sering mengadakan konfrontasi dengan kekuatan penuh, dan ini tidak pernah membawa orang baik. Adalah perlu untuk menunjukkan kedewasaan emosional dan tidak mencoba untuk membuktikan apa pun kepada siapa pun tentang diri Anda, memasuki jenis pertempuran kecil ini. Sebaliknya, dalam kasus-kasus seperti itu, topik tersebut harus dibawa kembali ke hal yang menarik bagi audiens.
Saya juga ingin berbicara tentang beberapa kebiasaan negatif selama pertunjukan, yang, menurut pendapat saya, dimiliki oleh para pengembang. Sebagai permulaan, orang harus melihat mata mereka. Saya mengerti bahwa ini sangat sulit dan membutuhkan banyak upaya emosional, tetapi Anda perlu berlatih ini. Pembicara sering melihat monitor mereka atau, lebih buruk lagi, di layar, berdiri dengan membelakangi penonton. Anda selalu harus menghadap audiens dan Anda harus selalu melihatnya. Selain itu, kepercayaan diri harus dijaga. Anda berbicara kepada audiens programmer, dan Anda dapat bertaruh bahwa tidak satu pun dari mereka memiliki kode yang berfungsi pertama kali. Jika demonstrasi Anda tidak berhasil selama presentasi, tidak ada yang salah dengan itu. Semua yang hadir kemungkinan besar akan berpikir: "Sial, semuanya persis sama dengan saya." Selama bertahun-tahun, saya telah belajar dalam situasi seperti itu untuk meminta bantuan kepada audiens dengan debugging. Biasanya, penutur dalam situasi seperti itu mulai menggumamkan sesuatu dengan pelan dan mencoba menyelesaikan semua kesulitan mereka sendiri. Sebagai gantinya, Anda harus bertanya kepada hadirin - teman, dapatkah Anda memberi tahu saya di mana saya bodoh?
Anda akan segera menerima banyak penawaran, dan sangat sering mereka akan membantu Anda menemukan kesalahan. Sulit bagi satu orang untuk berbicara dan menulis kode pada saat yang sama, jangan takut untuk meminta bantuan. Bagi pendengar, pengalaman ini juga berharga. Ini adalah salah satu alasan mengapa saya mengunjungi laporan orang lain: untuk melihat apa yang mereka lakukan dan untuk memahami apa yang sebenarnya tidak boleh dilakukan. Menurut pendapat saya, kebiasaan ini akan membantu Anda memperbaiki keterampilan berbicara Anda.
Tentang teknologi
— Java- , Java «Hello world». «public static void main» , , .
: Java- , , , . , . - - Java?— , . , , Java — , 2000-. , , , .
, , , , , . , , 70 try-catch . , , , .
— . , , , . , , . , . , .
Java 12, 13 14 : , , Java , , . , , Java , . , , . , , Java . , , , Java . , , , , , Java .
. Joker «Don't walk away from complexity, run» . , Joker , , .
- Dalam konteks "Jawa yang kurang bombastis," tidak mungkin untuk tidak bertanya tentang Kotlin, yang sering disebut demikian."Ya, itu benar." Dan masalahnya bukan hanya dalam kurang sok. Bagi saya, salah satu hal paling menarik dalam hidup adalah mengenal bahasa baru dan kemampuan mereka. Satu kemungkinan di Kotlin adalah menjalankan lambda dalam konteks suatu objek, meskipun itu bukan bagian dari kelas. Saya menjadi sangat tertarik ketika saya tahu, karena kemungkinan yang sama ada di JavaScript. Di sana Anda dapat melewati objek konteks dalam panggilan (Kotlin memanggil penerima), dan kemudian menjalankan fungsi global arbitrer ini seolah-olah itu adalah fungsi dari beberapa objek. Fakta bahwa fitur ini dalam JavaScript tidak mengejutkan, karena bahasa ini dinamis. Tapi Kotlin adalah bahasa statis, dan ia melakukan hal yang sama, sementara menghormati keamanan jenis. Kurangnya kepura-puraan, tentu saja, merupakan keuntungan besar dari bahasa, seperti halnya fakta bahwa ia menghasilkan bagian penting dari kode secara otomatis, sehingga kita tidak dapat menulis templat yang sama berulang kali. Tetapi manfaatnya tidak berakhir di sana, karena fitur ini memungkinkan Anda untuk membuat DSL internal.
Sains dan matematika membimbing saya ke pemrograman, tetapi 30 tahun kemudian saya tetap menjadi programmer karena fakta bahwa ini adalah seni. Bidang kami menggabungkan ilmu pengetahuan dan seni, tidak ada jalan lain. Kemampuan untuk membuat sistem bekerja tidak terbatas, di sini Anda dapat menggambar analogi dengan menulis puisi: minta dua orang untuk menulis tentang cinta, dan masing-masing akan menulis dengan caranya sendiri. Kode untuk tugas apa pun dapat ditulis dengan berbagai cara. Inilah yang menarik saya untuk bahasa seperti Kotlin dan banyak lainnya: kemampuan untuk mengekspresikan beberapa ide ini, memberikan fleksibilitas dan keringanan kode. Anda dapat kurang memikirkan sintaks bahasa dan lebih banyak tentang pemikiran yang ingin Anda sampaikan.
- Kualitas kode sangat penting bagi Anda. Tampaknya penting untuk semua orang, dan sepertinya semua orang ingin menulis lebih baik, tetapi diketahui bahwa sebagian besar dari kode yang ada memiliki masalah. Karena itu, pertanyaannya adalah: agar kolega Anda tidak membenci Anda karena kode Anda, Anda hanya perlu disiplin diri, dapatkah Anda memberikan rekomendasi khusus?"Saya yakin bahwa satu-satunya cara untuk menulis kode yang dapat dibaca adalah dengan membacanya." Ketika mereka memberi tahu saya bahwa kode tersebut dapat dibaca, saya bertanya - siapa yang membacanya? Jika penulis sendiri membacanya segera setelah menulis, ini tidak masuk hitungan. Karena itu, saya sangat percaya pada tinjauan kode. Saya ingin mengklarifikasi: Saya menentang membawa tim ke ruangan dengan layar besar, menunjukkan kode dan mengkritiknya. Ini pasti mengarah pada keluhan, okhayanie publik seperti itu tidak ada yang baik.
Kita harus jujur mengakui: kita semua menulis kode yang buruk. Saya bangga mengakui: kode saya menyebalkan, saya tidak tahu bagaimana menulis kode yang baik. Jika Anda bertanya bagaimana ini cocok dengan pembicaraan saya tentang kualitas kode, saya akan menjawab: menulis kode adalah proses dengan inovasi terus-menerus, dan ketika Anda mencoba menerapkan beberapa gagasan, kualitas kode tidak terlalu mengganggu Anda. Selalu perlu untuk kembali dan menolak, dan bahkan ketika saya melakukan ini, biasanya tidak ada yang berhasil untuk saya. Tetapi selama bertahun-tahun, saya menyadari bahwa, meskipun kode saya sendiri adalah basis, tetapi saya dapat dengan sangat baik menemukan kekurangan dalam kode orang lain. Karena itu, alih-alih berpura-pura bahwa kode saya sudah sangat bagus, saya akan menulisnya sebaik mungkin dan memberikannya kepada Anda untuk verifikasi, sementara itu saya akan mengambil kode rekan saya dan memeriksanya. Akibatnya, kode saya dan kode rekan saya akan memiliki kualitas yang lebih tinggi.
Sangat penting untuk melepaskan kesombongan palsu. Saya selalu mengingatkan pengembang bahwa mereka adalah bagian dari tim, tidak masuk akal untuk bersaing satu sama lain dan mencari tahu siapa yang lebih keren, tidak. Saya siap untuk jujur mengakui bahwa pengetahuan saya sangat terbatas - tetapi apa yang saya tahu, saya tahu betul. Dan kolega saya juga memiliki pengetahuan yang sangat mendalam di beberapa bidang lainnya. Bersama-sama kita menjadi lebih kuat ketika kita siap untuk saling belajar. Oleh karena itu, saya selalu menyarankan untuk memeriksa kode masing-masing, dan kebanggaan ekstra sama sekali tidak berguna di sini. Anda harus jujur satu sama lain, ini adalah salah satu kualitas terpenting dari tim yang baik. Kejujuran tidak boleh dihukum jika seseorang mengakui bahwa dia menulis kode yang buruk - ini normal. Kami meningkatkan standar dengan saling menawarkan cara lain untuk meningkatkan kode.
Poin penting lainnya: Anda tidak perlu memberi tahu seseorang bahwa ia melakukan kesalahan, harus dikatakan apa sebenarnya yang bisa diperbaiki. Jangan katakan: "Ya Tuhan, nama yang sangat buruk untuk sebuah variabel," lebih baik begini: "Anda mungkin ingin mengatakan bahwa variabel ini menunjukkan frekuensi distribusi - mungkin itu harus dipanggil sesuai." Ini akan membantu Anda menyampaikan maksud Anda dengan lebih baik. Ini juga berlaku untuk penyuntingan buku: bicara tidak hanya tentang apa yang perlu diperbaiki, tetapi juga tentang apa yang telah dilakukan dengan baik. Kita sering melupakan ini. Ketika saya mengedit kode orang lain dan melihat tempat yang dieksekusi dengan baik, saya menulis dalam komentar bahwa saya sangat menyukainya, bahwa kita perlu melakukan ini lebih sering, dan menjelaskan alasannya. Ini menciptakan umpan balik yang konstruktif, menjelaskan kepada pengembang bahwa Anda tidak memusuhi dia, dan pada akhirnya meningkatkan kualitas kode tim Anda.
- Anda menulis bahwa menggunakan alat yang membuat Anda rindu seperti terjebak dalam hubungan beracun: dalam situasi ini, Anda hanya perlu pergi, dan sesegera mungkin. Ini kedengarannya hebat, tetapi seringkali instrumen tidak memiliki alternatif tertentu, lalu apa?- Pertanyaan yang sepenuhnya dibenarkan. Memang, ada situasi di mana tidak ada tempat untuk pergi. Tetapi saya lebih suka berbicara tentang kasus-kasus itu ketika masih ada kemungkinan pilihan, dan hanya keinginan untuk membuatnya kurang. Menurut pendapat saya, ini adalah faktor penting.
Ketika tidak ada pilihan, alih-alih mengeluh, poin rasa sakit harus diidentifikasi: apa sebenarnya yang membuat alat ini tidak nyaman bagi Anda. Dan kemudian Anda bisa melakukannya dengan cara yang berbeda. Anda dapat menghubungi pengembang dan mengatakan - terima kasih atas pekerjaan Anda, bagi kami tampaknya alat Anda bisa jauh lebih baik jika Anda memperhatikan aspek ini dan itu. Atau Anda dapat mengadakan hackathon - berkumpul di akhir pekan bersama beberapa pengembang, mengatur grup pengguna, memberi tahu mereka bahwa Anda menghabiskan sembilan jam sehari dengan alat ini, itu mengerikan, dan meminta mereka untuk mencoba menambahkan beberapa fitur ke dalamnya.
Mungkin Anda tidak bisa menyelesaikan semua masalah sendirian, tetapi setidaknya Anda bisa menyatukan orang lain dan menyelesaikan masalah ini, terutama jika minat mereka serupa dengan Anda. Akhirnya, jika alat Anda benar-benar menyebabkan banyak masalah, Anda dapat mencoba menulis yang baru sendiri - jika Anda memiliki tiga atau empat teman di komunitas dengan sikap yang sama dengan Anda.
Jadi, menurut saya, masih ada alternatif. Anda tidak harus tahan dengan hubungan beracun. Anda selalu harus bisa menemukan jalan keluar - baik setuju dengan pasangan dan mencapai saling pengertian, atau pergi.
- Anda menulis buku tentang lambdas, dan Anda dikenal berkat buku ini. Saya juga membacanya, dan saya percaya itu ditulis dengan indah, memberikan apa yang dibutuhkan pengembang aplikasi, dan tidak memberikan apa pun yang berlebihan. Sebagai seorang profesional sejati, saya ingin bertanya kepada Anda: apa pemrograman fungsional untuk Anda? Bisakah Anda menggambarkannya dengan kata-kata Anda sendiri? Saya mengajukan pertanyaan ini karena semua orang mendefinisikannya sedikit dengan cara mereka sendiri, dan setiap kali makna tersembunyi diungkapkan yang berbeda dari definisi standar dari Wikipedia.- Ini pertanyaan yang bagus. Pemahaman saya tentang konsep ini telah berkembang selama bertahun-tahun, dan sekarang bagi saya hal yang paling penting dalam pemrograman fungsional adalah penghapusan kompleksitas yang asing. Kita berbicara tentang fakta bahwa dalam pemrograman imperatif Anda tidak hanya menunjukkan apa yang perlu dilakukan, tetapi juga menentukan secara rinci bagaimana melakukannya. Bagi saya, pemrograman fungsional merupakan tambahan gaya pemrograman deklaratif, di mana kami menunjukkan apa yang perlu dilakukan, tetapi tidak mengatakan bagaimana.
Biarkan saya memberi Anda analogi primitif: sahabat saya suka mobil, tetapi mereka sama sekali tidak menarik minat saya. Ketika kami berkumpul, kami sepakat untuk tidak membahas mobil, karena kami ingin tetap berteman. Saya tidak akan pernah mengendarai mobil dengan gearbox manual - kebutuhan untuk terus-menerus mengubah persneling merusak seluruh perjalanan saya, dan hal yang sama berlaku untuk gaya pemrograman yang imperatif. Transmisi otomatis membuat mengemudi sedikit lebih mudah, tetapi bagi saya pilihan terbaik adalah pengemudi menyetir saya. Dalam hal ini, saya hanya mengatakan di mana saya harus mendapatkan, dan sepanjang jalan saya menulis kode di laptop saya di kursi belakang. Bagi saya, ini adalah perbedaan antara pemrograman imperatif dan fungsional. Dengan pemrograman imperatif, Anda sendiri yang mengemudi, Anda perlu tahu ke mana harus pergi, bagaimana cara pergi, ke mana harus berpaling, ke mana Anda bisa memotong. Dengan pemrograman fungsional, Anda duduk di kursi belakang, memberi tahu pengemudi ke mana harus membawa Anda, dan perhatian Anda sepenuhnya terfokus pada pekerjaan Anda.
Bagaimana kompleksitas luar ini dihapus? Melalui komposisi fungsi. Saat membuat fungsi, kode Anda mengalami serangkaian transformasi selama data berpindah dari satu formulir ke formulir lainnya. Selain itu, bagi kami penting bukan bagaimana masing-masing langkah ini dilakukan, tetapi apa yang sebenarnya dicapai. Bagi saya, aspek pertama pemrograman fungsional adalah komposisi fungsional. Masalahnya adalah bahwa banyak bahasa di mana komposisi fungsional diimplementasikan - Ruby, Python, JavaScript, Groovy, dan sebagainya - memberikan keanggunan dan ekspresi karena ini, tetapi mereka memiliki kinerja yang sangat rendah. Komposisi fungsional di dalamnya diimplementasikan secara tidak efisien. Saya percaya bahwa keanggunan tanpa efisiensi tidak layak. Kode ini tidak hanya cantik, tetapi juga harus bekerja dengan cepat. Dan di sini kita sampai pada aspek penting kedua dari pemrograman fungsional - kita berbicara tentang komputasi malas. Hasil dari fungsi tertentu dihitung hanya pada saat dibutuhkan. Berkat ini, kombinasi keanggunan dan efisiensi dicapai dalam pemrograman fungsional. Jadi, bagi saya, pemrograman fungsional adalah penekanan pada apa yang harus dilakukan, bukan bagaimana melakukannya; penggunaan komposisi fungsional sebagai serangkaian transformasi data; dan kemampuan untuk melakukan transformasi ini secara efisien berkat komputasi malas.
Harap dicatat bahwa saya tidak berbicara tentang kekebalan dan fungsi tingkat tinggi. Faktanya adalah mereka hanyalah bahan untuk mendapatkan hasil yang saya jelaskan. Kami menggunakan pemrograman fungsional bukan untuk imunitas dan fungsi tingkat tinggi, mereka hanya sarana untuk mencapai tujuan yang lebih tinggi: menyingkirkan kompleksitas yang asing.
- Definisi yang bagus. Saat ini ada bahasa yang menjadi patokan untuk pemrograman fungsional apa yang seharusnya: Haskell (dan mungkin F #).- Benar.
"Setidaknya banyak orang berpikir begitu." Tetapi Java jelas bukan Haskell, sebagian besar terbatas. Apakah pemrograman fungsional masuk akal sebagai disiplin ketika diterapkan ke Jawa? Bagaimanapun, bahasa kita memiliki seperangkat alat yang sangat terbatas untuk pendekatan ini.- Bagi saya, aspek pragmatis daripada mengejar keunggulan lebih penting. Saya ingin tahu tentang kesempurnaan, tetapi agar semuanya berhasil, saya harus menjadi pragmatis. Saya tergila-gila pada Haskell dan menghabiskan banyak waktu bersamanya, hanya untuk mengetahui bagaimana tugas tertentu diselesaikan dalam pemrograman fungsional. Tetapi untuk klien saya, saya tidak menulis di Haskell. Di sini Anda dapat menggambar analogi dengan "Katedral dan Bazaar." Katedral itu indah, tetapi sebagian besar waktu saya habiskan di pasar. Pertanyaannya adalah bagaimana bertahan hidup di dunia ini. Ketika bahasa berkembang dan ketika kami mencoba untuk menggabungkan beberapa paradigma yang berbeda bersama, kami, sebagai programmer, harus sangat berhati-hati dengan implementasinya.
Saya tidak berpikir bahwa pemrograman fungsional tidak mungkin sama sekali di Jawa. Dalam situasi di mana ada pilihan, saya akan fokus pada bahasa yang paling cocok untuk saya. Tapi saya tidak akan pernah memberi tahu klien: Anda harus menggunakan bahasa ini. Paling sering saya bertanya apa yang sebenarnya mereka lakukan, dan mencoba mencari cara untuk melakukan hal yang sama dengan cara yang lebih optimal dalam kerangka lingkungan yang sudah mereka miliki. Saya percaya bahwa dalam bahasa seperti Java kombinasi pemrograman imperatif dan fungsional sangat mungkin dan bahkan direkomendasikan, tetapi ini harus dilakukan dengan sangat hati-hati. Bayangkan Anda memiliki semacam lingkaran fungsi murni, yang di sekitarnya akan ada cincin ketidakmurnian. Segala sesuatu yang Anda ingin ubah harus berada di luar lingkaran. Di dalam lingkaran ini, Anda dapat menerapkan rantai fungsi Anda sendiri, tetapi semua perubahan harus di luarnya.
Ini adalah salah satu alasan mengapa saya senang belajar bahasa baru. Saya baru-baru ini berkenalan dengan bahasa Elm, yang merupakan sintaksis Haskell dengan F # intersperses yang mengkompilasi dalam JavaScript. Pendekatan ini menarik minat saya sejak awal, karena JavaScript adalah bazaar. Ketika Anda melakukan perjalanan melalui JavaScript, Anda terus-menerus melangkah ke genangan air. Berkat sintaksis Haskell, Elm jelas merupakan sebuah katedral. Namun demikian, kode konsiliar ini dimungkinkan untuk dijalankan di pasar. Arsitektur Elm elegan, memiliki model (yaitu, data), ada tampilan yang menampilkan data ini, dan ada transformasi, pembaruan. Prinsip utama pertama adalah bahwa data disimpan dalam tampilan. Ketika pengguna melakukan tindakan (misalnya, menekan tombol), data dari tampilan dikirim ke fungsi pembaruan, tempat konversi berlangsung. Data tidak dapat diubah, dan fungsi pembaruan mengembalikan data baru yang disimpan bukan tampilan lama.
Jika Anda memikirkannya, maka dengan cara yang sama persis berfungsi Redux. Ada data di dalamnya dan reduksi ada. Ketika data dikirim ke reduksi, Anda mendapatkan salinan baru sebagai imbalan, yang Anda simpan bukan yang lama. Tetapi jika Elm dan Redux beroperasi pada skema yang sama, maka skema yang sama dapat diimplementasikan di Jawa. Kita dapat membuat fungsi murni yang akan mengambil data, mengubahnya, dan mengembalikan salinan baru. Dengan belajar dari Redux dan Elm, kita dapat membuat arsitektur Java lebih fungsional. Saya membicarakan hal ini karena Redux mengkompilasi ke dalam JavaScript, yang merupakan bazaar yang unik. JavaScript, saya pikir, adalah yang paling jauh dari ideal kemurnian fungsional, di sini pada setiap langkah Anda melangkah ke genangan air. Namun demikian, Redux memberi Anda kemurnian fungsional di dunia yang sangat kotor ini. Pendekatan ini sangat memengaruhi saya karena mengubah pandangan saya tentang pemrograman fungsional dan menunjukkan bahwa saya dapat menerapkan prinsip-prinsip ini di Jawa juga.
- Bagus terima kasih. Menurut Anda, apakah seperangkat alat yang kami miliki di Jawa lengkap dan memadai? Apakah kita memerlukan hal lain selain ekspresi lambda, referensi metode, koleksi dengan stream?- Menurut saya, masih banyak yang harus kita lewatkan. Dunia Jawa terus berkembang. Saya baru-baru ini berdialog dengan seorang pria yang mengatakan: "Saya mendengar bahwa Anda berada di kota kami beberapa tahun yang lalu dan banyak berdebat tentang obat generik," yang saya jawab: "Saya selalu berdebat banyak tentang obat generik." Saya percaya bahwa di Jawa generik dilakukan dengan sangat buruk. Brian Goetz marah kepada saya sepanjang waktu: "Akan selalu ada seseorang yang mengeluh tentang obat generik," dan yang ini, tentu saja, adalah saya. Menurut pendapat saya, banyak yang dapat ditingkatkan di bidang ini. Reformasi sangat penting, menurut saya. Banyak yang bisa dilakukan dalam hal mengurangi perut kembung, menyingkirkan kode boilerplate. Kode dapat dibuat lebih lancar. Dan gerakan tertentu ke arah ini sudah terlihat hari ini. Java sekarang mengimplementasikan pencocokan pola, yang membuat saya sangat bahagia - Saya sangat suka bagaimana ini diterapkan di Scala dan Kotlin. Saya pikir ini sangat penting, dan analogi dengan mesin pengolah uang kertas muncul di pikiran saya. Jika Anda melewati satu bundel catatan melalui itu, itu akan mengurutkannya sesuai dengan nilai masing-masing uang kertas. Demikian pula, pencocokan pola dalam karya pemrograman. Anda melewatkan data melalui parameter yang dapat mengambil data untuk diproses. Saya pikir ini bisa membantu menyingkirkan sejumlah besar operator cabang yang kami tulis di Jawa. Kode akan menjadi lebih ekspresif. Secara umum, saya percaya bahwa Java membutuhkan banyak tambahan, tetapi, tampaknya, sudah bergerak ke arah ini.
Saya ingin menyebutkan satu aspek lagi yang sangat menarik bagi saya. Saya tumbuh di dunia pemrograman tradisional. Saya tidak takut untuk secara terbuka mengakui bahwa bahasa pertama saya adalah Visual Basic. Dalam arti tertentu, ini adalah bahasa yang baik untuk percobaan pertama, karena itu bisa lebih buruk. Kemudian saya menulis untuk waktu yang lama dalam C dan C ++, dan sebagian besar waktu dari semua bahasa yang saya habiskan dengan C ++. Setelah itu, saya mulai menulis dalam bahasa Java, C #, seperti Ruby. Pada titik tertentu, saya menyadari bahwa saya selalu menulis dalam bahasa dengan multithreading. Jadi, mengenal Node adalah semacam wawasan - butuh beberapa saat sebelum saya menemukan pemrograman yang tidak sinkron. , , — , Java. (coroutines) (continuations). , Java , , , . , Java , . , . . , , , , Java-, . , , , . Java , .
— , ? JVM-, . . ?— , . , . , , : , , , , , . , . . , , , , . Big Data. , . , . , , , -. , , . , .
, , . , . , . , , . , , , . , , , . . , , : . , 30 . , -, .
, . , , , . . . , , , . : , . , , .
— . , ? , , . , Reactive Streams, Spring Reactor, CQRS event sourcing. - , CQRS?— , , . , , — . Angular 1, , , . Angular «$» . , : « . ». , . , , , . , . — — Angular 2, , .
, , . , , API — . ? - ? , , - . . Java — — deprecated-. Angular 1 — . , , .
— - (event-driven systems), , . , -. , , API , . , . , , 5-10 , . -, , - . , . , , — , . — ++. — . , , , . - , , , . , , , .
— , , .
Java Champions, Microsoft MVP, JavaScript, . : Java ? .NET, JavaScript - ?— , Java , .NET - . # Java, , C# . . Java , # LINQ, , (, Func). C# , Java. , , Java 2014 CompletableFuture. C# .
Java JavaScript. , « JavaScript» , JavaScript , . «callback hell», , - , . JavaScript Promises (), CompletableFutures Java. : , . Promises , . — Promises . , , , . , , , , . JavaScript async await. , Promise. , , , , , . CompletableFuture , continuations Java . , coroutines Kotlin.
, , . . , , , , , , . , , . , , — , , . async C#, async/await Promises JavaScript coroutines Kotlin, , , — , , . . Java . , Java , , , , . , . , , , . Java , . , Java — .
Java. . , Java , . Java , invokedynamic, , . , JVM. Java , — . , , . , Java , Java , JVM. . , , . , Java , .
— . , , , . , 5 . — . — , Common Lisp, JavaScript Meta Object Protocol, DSL Kotlin JetBrains MPS, GraalVM Java Java . . ?— . , . , , . . -, , . -, , . , , , . , . , , . , , . , , : ? — ? , , ? , . : , Angular, — React? , React. — ? , , , , - , . , , . , , . , , — , , . , .
, . , . - : , . , : , , , , . 1 10, 10 « », 1 «». 1 10, 1 « », 10 — « ». , , . , . , . , Angular, React Java . : ? , . , : . . , , , . , , , , ; ; .
, , — . — , . . - , , . , , . , . , , . , , . , . , , , .
"Terima kasih, itu jawaban yang bagus." Di konferensi Joker kami, Anda juga akan berbicara tentang kompleksitas , sehingga Anda dapat melanjutkan diskusi di sana.- Ya, saya akan menantikannya dengan antusias.