"Mereka menyarankan untuk berkenalan dengan perhitungan satu indikator, dan ada dua lembar dengan integral dan turunan kedua"

Ini adalah wawancara dengan Anton Batiaev dari Deutsche Bank Technology Center. Kita akan berbicara tentang apa yang dilakukan ahli matematika keuangan, dari mana data dari bank berasal, bagaimana mereka diproses dan dioptimalkan. Pada kompleksitas masuk ke sektor keuangan, perdagangan di bursa dan kebutuhan umum untuk bank.



Apa dan bagaimana mereka menghitung di bank?


- Perkenalkan diri Anda, tolong: beri tahu saya siapa Anda, apa yang Anda lakukan.


Saya pindah ke Deutsche Bank TechCenter pada awal Januari tahun ini dan sekarang saya sedang mengembangkan sisi server pada proyek yang mempertimbangkan berbagai jenis risiko instrumen keuangan untuk banyak pedagang yang berbeda di seluruh dunia dan tim lain yang membutuhkan data ini.


Proyek ini telah membangun infrastruktur yang cukup luas yang menggunakan banyak kerangka kerja standar populer, database non-relasional, bekerja dengan data besar tentang Kafka. Kami juga bekerja dengan kisi-kisi untuk puluhan ribu CPU, menggunakan berbagai proyek khusus, mengoptimalkan kerja dengan protobuf, mengimplementasikan perhitungan dalam matematika keuangan,


Sebagai bagian dari infrastruktur, ada sejumlah optimasi dan chip tambahan. Mungkin ini jelas, tetapi sangat sulit untuk secara konsisten dan logis memberi tahu apa yang terjadi di bank. Beberapa persen telah dilemparkan dan mendapatkan sumber daya keuangan - ini rumit matematika, algoritma dan infrastruktur besar, tugas teknis dan tugas optimasi.


- Ayo beres. Anda mengatakan bahwa di TechCenter Anda sedang melakukan perhitungan untuk platform perbankan global. Dan apa yang bisa dipertimbangkan di bank?


Berdasarkan pengalaman saya, dalam rangka kegiatan investasi, baik harga dan sejumlah indikator lain dari berbagai instrumen dipertimbangkan. Jika kita berbicara tentang saham, maka semuanya jelas: kutipan adalah harganya. Untuk obligasi, ini akan menjadi persentase dari nilai nominal.


Jika kita berbicara tentang derivatif (instrumen keuangan derivatif), ada harga ukuran premi yang harus dibayar untuk instrumen ini. Ini dihitung oleh banyak formula berbeda. Ada rumus Black-Scholes yang memperkirakan nilai opsi - ini adalah fungsi yang bergantung pada fungsi kuotasi saat ini, aset dasar, volatilitas, waktu kedaluwarsa, dan banyak faktor lainnya.


Ada beberapa model yang memungkinkan Anda menghitung nilai portofolio pedagang. Departemen atau perusahaan memiliki serangkaian transaksi, instrumen keuangan derivatif dalam portofolio, dan Anda perlu menghitung berapa harganya saat ini. Secara terpisah, mungkin ada satu harga, tetapi secara agregat - mereka entah bagaimana dapat berkorelasi, memberikan diskon, dan sebagainya. Misalnya, posisi sintetis: cara membuat opsi yang setara dengan futures dari opsi. Ini cocok, misalnya, untuk aset non-linier seperti opsi, tetapi belum tentu berlaku untuk semua jenis derivatif. Penilaian didasarkan pada kutipan dari aset yang mendasari di mana derivatif dibangun. Misalnya, kutipan satu atau lebih pasangan mata uang. Derivatif dapat dibangun di atas aset dasar yang berbeda: untuk mata uang, aset dasar adalah euro, dolar, dan sebagainya; untuk turunan komoditas - minyak, emas, gandum; untuk spot - berbagai saham dan obligasi.


Selain menilai derivatif, risiko juga dipertimbangkan - apa yang akan terjadi jika harga di pasar lebih kuat (perubahan volatilitas). Atau apa yang akan terjadi jika dolar tidak bernilai 60, tetapi 100 rubel sehubungan dengan satu atau semua mata uang lainnya. Apa yang akan terjadi pada instrumen tertentu, portofolio.


Anda perlu menghitung ini secara real time, dan juga memperkirakan kondisi portofolio saat ini untuk berbagai hasil buruk dari pergerakan harga untuk masing-masing mata uang, perubahan dalam volatilitas pasar. Untuk melakukan ini, kami sedang membangun matriks dari semua kemungkinan perubahan, yang menunjukkan apa yang sekarang, apa yang akan terjadi besok dan apa yang akan terjadi jika terjadi krisis pasar.


Ini diperlukan untuk menilai apa yang harus dibeli dan dijual pada saat ini dan apa risikonya. Dan, termasuk, mengevaluasi apa yang akan terjadi di masa depan, mengevaluasi strategi perdagangan dan lebih akurat menanggapi perubahan pasar. Misalnya, salah satu kuanta menghasilkan algoritme baru untuk menghitung risiko - Anda perlu memeriksa data historis, drive, misalnya, untuk semua informasi pertukaran selama beberapa dekade dan melihat apa yang terjadi.


Untuk kebutuhan ini, ada infrastruktur yang terhubung ke berbagai platform pertukaran yang mengirimkan data pasar kepada kami. Karena perusahaan kami memiliki banyak data di seluruh dunia, kami perlu menyimpan dan membangun pra-agregat untuk memprosesnya dengan cepat.


- Sebelum kita beralih ke bagian infrastruktur, saya ingin bertanya tentang apa yang telah Anda katakan. Anda berbicara tentang sekelompok semua jenis algoritma analisis, dari mana algoritma ini berasal? Apakah ini semacam pengetahuan buku atau praktik terbaik Anda?


Ada beberapa poin. Pertama, rumus terkenal, algoritma yang ditemukan oleh ahli matematika diambil. Misalnya, model penetapan harga opsi yang diterima secara umum adalah rumus Black-Scholes. Tapi, selain itu, ada perbaikan internal: khususnya, kami menggunakan undang-undang distribusi harga lainnya, kami memutar koefisien dalam formula ini. Formula untuk kurva distribusi untuk harga, penawaran, dan indikator lainnya bisa sangat berbeda.


Jika kita berbicara tentang pengoptimalan, ini sudah merupakan peningkatan internal. Misalnya, pengembang dapat, alih-alih menghitung indikator di setiap titik, menghitung nilai-nilai kunci dan melakukan perkiraan, yang akan menghabiskan waktu komputer 20 kali lebih sedikit, tetapi pada saat yang sama memberikan akurasi yang dapat diterima dan cukup.


Semua data terus berubah, dan ini penting bagi kami tidak hanya untuk pelaporan, tetapi juga untuk memberi para pedagang gambaran terkini tentang keadaan pasar.


- Ini informasi yang agak rumit, dan mungkin cukup sulit untuk ditransfer dari orang ke orang. Berapa ukuran tim Anda, dan bagaimana Anda mentransfer pengetahuan di antara Anda?


Proyek kami di Moskow mempekerjakan 35 orang. Ini adalah beberapa tim yang berurusan dengan beberapa fungsi tertentu: UI, backend, infrastruktur, matematika keuangan. Setiap tim tersebut memiliki keahlian yang mendalam dalam fungsi modul tertentu. Tapi selain orang-orang ini, ada banyak orang yang terlibat dalam sistem yang berkaitan dengan proyek kami.


Semua informasi tentang proyek kami dijelaskan oleh analis di Confluence, dan itu juga terkandung dalam deskripsi tugas di JIRA, di mana ada tautan ke mekanisme standar dan formula publik. Contoh penggunaan fungsionalitas dapat ditemukan dalam tes. Yah, komunikasi manusia belum dibatalkan.


- Matematikawan finansial: ada berapa banyak dan siapa mereka? Adakah ilmuwan penting?


Ya, mereka terutama adalah spesialis (kuanta) yang duduk di London dan membangun model keuangan tentang bagaimana pasar bekerja. Paling sering mereka memiliki gelar PhD di bidang keuangan atau matematika. Mereka tahu bagaimana pasar bekerja, apa yang dibutuhkan pedagang, dan dapat menghasilkan beberapa jenis model matematika yang menggambarkan keadaan pasar, algoritma perhitungan risiko dan penilaian derivatif yang benar.


Sebagai contoh, kolega saya, Alexander, menulis sebuah artikel tentang Habrรฉ , di mana dia telah menyebutkan pengalaman dengan kuantum.


- Dapatkah pengembang biasa berkomunikasi dengan mereka? Bagaimana komunikasi ini? Memang, matematika dan pengembangan konvensional memiliki dunia yang sama sekali berbeda.


Mereka dapat berkomunikasi dan berkomunikasi: jelas bahwa beberapa tugas dan konsep bisnis tingkat atas didiskusikan dengan para pemimpin, tetapi dalam kerangka perhitungan risiko tertentu atau indikator lain, pengembang berkomunikasi langsung dengan pedagang atau kuantum yang membangun model ini.


Namun pada kenyataannya, ini adalah proses interaksi timbal balik, karena algoritma teoretis tidak selalu diterapkan dalam praktik. Oleh karena itu, pengembang dapat mengusulkan perubahan pada model sehingga bersandar pada arsitektur aplikasi saat ini.


Ada banyak cara untuk berinteraksi - Skype, telepon, semua alat komunikasi standar yang sama.


- Perangkat lunak yang keluar otomatis? Apakah ini robot atau ada sesuatu untuk pedagang yang terlibat dalam analisis teknis - grafik atau sesuatu yang lain?


Ada beberapa opsi untuk menggunakan perangkat lunak: yang pertama adalah otomatis, mis. robot perdagangan, yang kedua adalah asisten bagi pedagang, yang menunjukkan keadaan portofolio saat ini, merinci risiko pada berbagai indikator, opsi untuk perdagangan yang sekarang dapat ia lakukan, serta keadaan portofolio di masa depan dan risiko berdasarkan hasil operasi ini. Ada juga indikator untuk pedagang, perhitungan risiko dan data tentang status portofolio.


- Metrik lain adalah frekuensi analisis data, seberapa sering Anda melakukannya? Di satu sisi spektrum, seperti yang saya pahami, beberapa mikrodetik, dan di sisi lain, analisis data besar yang dapat memakan waktu berminggu-minggu.


Bergantung pada kompleksitas dan pentingnya indikator, ini bisa menjadi indikator langsung, yang dihitung ulang untuk setiap centang, dan kemudian perhitungan berlaku untuk milidetik. Dan jika kita menghitung biaya portofolio, maka pembaruan terjadi sekali dalam satu detik, sehingga mata manusia punya waktu untuk melihatnya.


Jika Anda menggambarkan perhitungan panjang (misalnya, beberapa risiko kompleks), data yang diperlukan pada siang hari, maka tugas dikirim ke kisi, skenario perubahan kutipan mata uang dipertimbangkan. Mekanisme umum adalah sebagai berikut: Anda mempertimbangkan semua transaksi baru dalam siklus tertentu, kemudian Anda melakukan tugas yang sulit di grid untuk menghitung ulang indikator untuk seluruh rangkaian transaksi dalam keadaan pasar saat ini.


Tugas semacam itu dapat diperbarui sekali per jam. Jika Anda perlu mengusir strategi perdagangan - ini adalah tugas yang panjang, mereka dilemparkan, dan selama beberapa jam itu dipertimbangkan, tergantung pada kompleksitas dan jumlah data. Tugas di grid dapat berupa sangat kecil, misalnya, menghitung satu rumus dan memberikan satu hasil, atau besar, misalnya, untuk tabel di mana Anda perlu menghitung korelasi semua skenario risiko yang mungkin dan memberikan hasil gabungan.


Di sini muncul tugas mengoptimalkan beban kisi dan memprediksi waktu menghitung tugas tergantung pada jenis alat, jumlah data dan indikator lain untuk memuatnya secara maksimal. Karena, jika Anda melempar satu tugas besar, semua orang akan menunggu dalam antrean, meskipun selama ini Anda bisa menghitung sesuatu yang lain.


Secara umum, tugas ransel dan optimasi lainnya. Jika ping ke grid lebih panjang dari waktu perhitungan itu sendiri, kami akan melakukannya di backend, di mana mini-cluster telah digunakan untuk tugas-tugas kecil seperti itu.


- Bisakah saya memasukkannya ke dalam semacam struktur? Sejauh yang saya mengerti, berbagai metode optimasi diterapkan tergantung pada volume tugas. Pada tugas kecil, masuk akal untuk mengoptimalkan kompiler JIT, dan pada tugas besar, sesuatu yang lain. Katakan apa bidang masalahnya dan metode apa yang digunakan di sana untuk mempercepat dan mengoptimalkan.


Contoh dari tugas besar adalah untuk menghitung semua instrumen keuangan dan risiko ketika mengubah kuotasi dari setiap mata uang dengan 1-2-3-10%. Dalam hal ini, pengoptimalan akan terdiri dari pengelompokan penawaran ke dalam bundel sehingga dalam satu bundel ada penawaran untuk satu jenis portofolio atau satu mata uang.


Agar tidak ada banyak perhitungan risiko untuk setiap transaksi, kami menyajikannya sebagai satu transaksi untuk volume besar, dan kemudian membagi hasilnya secara proporsional. Dengan demikian, kami mengurangi jumlah perhitungan yang diperlukan.


Contoh optimasi lain adalah kali ini dengan pasangan mata uang. Katakanlah ada dua pasang "rubel-dolar" dan "rubel-euro". Pada pasangan pertama, Anda dapat membayangkan bahwa rubel jatuh, tetapi ada kemungkinan bahwa dolar tumbuh. Sebenarnya, ini satu dan sama. Hal yang sama berlaku untuk pasangan rubel-euro. Dengan demikian, kita dapat mempertimbangkan pasangan yang berbeda pada pandangan pertama dalam satu paket, dengan dasar bahwa perubahan rubel dalam kedua kasus.


Jumlah kalkulasi dikurangi dan hasilnya dipercepat. Tampaknya telah mengubah satu mata uang (dalam contoh kami, rubel), tetapi pada kenyataannya, kami menghitung risiko aset heterogen.


- Dan bisakah Anda memecahkan masalah secara langsung dan menggulungnya menjadi kelompok yang sangat besar?


Ada cluster seperti itu, tetapi sudah dimuat dengan banyak perhitungan. Cluster ini bukan karet, meskipun ada puluhan ribu CPU yang saat ini ada.


- Dan dari sudut pandang perangkat lunak, In-Memory DataGrid atau Hadoop?


Ya, ada Hadoop, dan Kafka untuk memproses semua ini, dan database ClickHouse untuk mengoptimalkan pekerjaan dengan data besar. Dalam hal penumpukan data, jelas bahwa mengemudi JSON adalah, secara halus, tidak efisien. Dalam hal ini, ada saat-saat optimasi dengan Protobuf. Sangat penting bagi kita untuk tidak hanya meletakkan data biner, tetapi pada saat yang sama melakukannya sekencang mungkin, menggunakan kamus.


Di dalamnya kami akan menyimpan, misalnya, spesifikasi kontrak dari jenis yang sama untuk semua transaksi. Karena pengoptimalan dengan kamus ini, seorang kolega menghemat 30% dari memori yang digunakan.


- Apakah kamus-kamus ini pada simpul-simpul tertentu dan digandakan atau terletak di pangkalan pusat?


Dengan cara yang berbeda. Sebagian besar di pangkalan pusat. Dan ada kamus yang Anda transfer ke grid dengan banyak perhitungan. Dia ingin menjadi seringkas mungkin agar tidak menyeret banyak data, karena saluran internet bukan karet.


Bagaimana cara kerjanya? Anda mengirim tugas perhitungan ke grid dengan semua informasi yang diperlukan untuk itu, yang Anda kemas dalam kamus untuk menghindari duplikat. Di dalam, sudah ada semua konten, dan Anda tidak perlu pergi ke repositori tambahan. Ini menghemat lalu lintas jaringan dan mengurangi latensi dalam perhitungan.


- Sejauh yang saya tahu, bank memiliki analisis pada data historis, yang merupakan satu paket besar data per gigabyte-terabyte. Dan pendekatan dengan satu basis data tidak berfungsi? Anda dapat menggunakan 2 TB pada kunci, tetapi itu tidak baik.


Ya, momen seperti itu diputuskan dengan pembagian. Anda akan memiliki cache lokal per negara, disebarkan melalui pertukaran informasi, karena mengirim informasi tentang semua transaksi dari New York ke Singapura intensif sumber daya. Jelas bahwa di sini pembagian berdasarkan negara adalah logis: misalnya, transaksi di Amerika Serikat akan ditempatkan di pusat data Amerika. Situasi yang serupa dengan tanda kutip - Anda perlu membangun perutean dan menentukan jenis kesepakatannya, wilayah mana yang dimiliki, untuk memahami di mana cache berada, mengirimkannya ke penyimpanan dan database yang diperlukan dan tidak mengejar data lagi.


- Dan kebetulan Anda perlu menggabungkan data dari berbagai daerah?


Ya, benar, dan itu adalah tugas yang sulit. Jelas bahwa kami tidak akan memompa data terabyte dari semua wilayah untuk mendapatkan hasil agregat. Kemungkinan besar di setiap wilayah Anda akan menghitung agregat lokal dari wilayah ini dan kemudian Anda akan mengumpulkan semua hasil ini untuk mendapatkan data ringkasan.


- Kemungkinan besar, ada data eksternal, misalnya, riwayat pertukaran. Dan bagaimana cara menanganinya? Apakah Anda mencerminkan diri Anda di dalam, atau adakah cara untuk memprosesnya?


Ada protokol dan koneksi ke penyedia data standar: Reuters, Bloomberg, yang menyediakan informasi pertukaran. Kami menyimpan data yang diperlukan pada penyimpanan internal, tetapi beberapa hal dapat diminta kembali dari penyedia data. Sekali lagi, berdasarkan wilayah, agar tidak mengarahkan lalu lintas.


Jelas bahwa mereka juga telah menyebarkan server di seluruh dunia untuk memastikan kecepatan dan kinerja.


- Dan data untuk membaca atau membaca / menulis? Jika catatan tidak menakutkan untuk menggulung volume seperti itu?


Pada dasarnya, untuk membaca, menulis berjalan sambil mencatat informasi tentang transaksi dan informasi lain yang diperlukan oleh regulator. Pada dasarnya, perhitungan untuk kebutuhan domestik: risiko, nilai portofolio, dan sebagainya. Ini adalah dapur internal, Anda menyerahkan data beberapa wilayah atau pusat data, tanpa mengirimnya ke luar.


- Jika sepotong memecah bulan dan terbang ke pusat data, lalu apa yang akan terjadi? Apakah semuanya sudah berakhir?


Data di pusat data dicerminkan. Jelas bahwa di wilayah tersebut, data tidak terletak pada satu hard drive di satu pusat data. Kalau tidak, seperti di sepeda itu, setiap petugas kebersihan bisa secara tidak sengaja mengurangi server. Semuanya disalin secara online: ada aliran data di kedua arah, Anda membaca dari cermin terdekat, dan Anda menyinkronkan ke rekaman untuk memastikan konsistensi.


Tetapi, sebagai suatu peraturan, informasi yang tersedia untuk perekaman jauh lebih sedikit, karena itu perlu ditampilkan kepada pengguna. Jika dia melihat penghitungan ulang tidak sekarang, tetapi 2 detik kemudian dari sumber lain, itu menyedihkan, tetapi Anda dapat hidup. Jelas bahwa data yang diperlukan untuk regulator, pemasar eksternal dan pelaku pasar digandakan dan disinkronkan dalam beberapa sumber agar tidak kehilangan apa pun.


Bagaimana Tech Center Deutsche Bank menyiapkan data dan mengumpulkan sampah



- Pertanyaan tentang persiapan data. Sejauh yang saya mengerti, setiap sumber memiliki formatnya sendiri, dan mengonversinya secara instan bukanlah ide yang baik. Apakah Anda entah bagaimana menyiapkannya untuk perhitungan?


Ada format tunggal internal. Jelas bahwa lebih nyaman untuk bekerja dengan data yang sama, tetapi ini diterjemahkan menjadi kebutuhan untuk mengubahnya. Ada aliran data dan tim yang bertanggung jawab untuk bertukar informasi, menghubungkan ke pemasok. Mereka membentuk dan memperkaya data dalam format tunggal kami. Untuk mengatasi masalah kinerja akan ada dua aliran data, salah satunya adalah siklus cepat yang akan memberikan informasi yang berasal dari aliran data pertukaran. Karena ini, kurang perlu untuk pergi ke berbagai penyimpanan dan membentuk struktur standar. Anda dapat menghitung indikator yang dibutuhkan secara real time.


Dan ada siklus yang lebih lambat yang memproses aliran yang sama, tetapi dengan semua set bidang yang diperlukan, dalam format kami. Ini menjalankan perhitungan yang semakin lambat, yang membutuhkan banyak informasi tambahan, bidang, dan yang lainnya.


- Seperti apa dari sudut pandang pengembang? Apakah Anda selalu tahu area basis data mana yang dipengaruhi oleh perhitungan yang berat?


Beberapa acara datang kepada Anda, bidang di mana dapat diisi 100% dan hanya sebagian. Pada acara cepat, Anda menghitung indikator yang dihitung ulang secara online dengan cepat. Pada siklus yang panjang dan lebih lambat dengan set data lengkap, Anda menghitung ulang tugas yang membutuhkan semua indikator. Ini jika Anda tidak terlalu dalam, karena semuanya tergantung pada spesifikasi tugas.


- Dan data disimpan pada apa? HDD, SSD, RAM, seluruhnya dalam RAM?


Sebagian besar di memori. Kami bekerja dengan hep besar pada backend yang mengkonsumsi dan menyimpan data baik dalam struktur standar di Jawa atau di beberapa In-Memory Data Grid, tergantung pada seberapa cepat dan seberapa dekat data yang Anda butuhkan. Jelas bahwa data historis beberapa hari terakhir akan disimpan pada SSD dan disk. Tetapi apa yang dibutuhkan atau mungkin diperlukan untuk perhitungan akan dimuat ke dalam cache, dalam memori.


- Apakah mungkin untuk melakukan sesuatu tanpa caching, tetapi dengan kehilangan informasi, menggunakan perhitungan yang tidak akurat?


Ya Saya sebutkan sedikit bahwa kadang-kadang Anda perlu menghitung risiko pada rantai perubahan aset dari 0 hingga 100%, karena indikator telah berubah. Bagan distribusi dibangun sebagai persentase, sesuai dengan rumus atau hubungan linear. Anda membangun poin-poin penting dan melakukan perkiraan. Hasil perkiraan diperoleh, yang tidak akan bertepatan dengan nilai riil sebesar 100% jika kita menghitung pada setiap titik tertentu dalam grafik, tetapi akan cukup untuk bekerja dengan data ini.


Pendekatan ini sering digunakan karena memungkinkan, misalnya, untuk tidak melakukan semua perhitungan ketika mengubah nilai setiap mata uang dalam kaitannya dengan semua mata uang lainnya, dengan selisih satu sen. Anda menghitung bergerak dengan langkah langka, atau memilih beberapa titik tertentu, dan menginterpolasi sisanya. Nilai untuk akurasi akan cukup.


- Apakah selalu memanas di Jawa atau semuanya serba keren?


Sebagian besar terletak di pinggul.


- Bagaimana Anda berjuang dengan pengumpulan sampah?


, - huge pages, . , Shenandoah. full GC .


: flame graph, , , , .


โ€” , flame graph?


, - Java-, , . ELK-, GC- , , . 150 โ€” , . , 150 . , .


โ€” Java GC ?


Java 8, 11- . . , , G1.


โ€” ?


, . JVM.


โ€” , , . - , ?


, . , . . ( UAT โ€” user acceptance testing ) โ€” , . , , . 2 , โ€” 3 , , .


. , , , . , .


โ€” , - , , ? ?


. : , GC, live set . - . โ€” . , . , .


-, - . , . , JSON diff. JSON .


, . , , . .


โ€” , , ?


, , . 100 ยซยป, . , . .


master, , , . , , , , . .


, , , , . , , . CI, .


โ€” ?


. โ€” , , . , , , , . - , .



โ€” , .
โ€” , , . , , , , - .


, - , โ€” - , UI, . , , , , UI.


โ€” ? ยซยป Spring?


Spring, Java, MongoDB Protobuf, dependency injection. UI React, gRPC , .


โ€” Mongo, Oracle. - ?


, , . . - , JDBC . - SpringData , JDBC. , , , .


โ€” - CQRS?


, , .



โ€” ? , โ€ฆ


.


โ€” ? , .


, . , , ++ . GNU/Linux, Java. -, . , . , , , . .


, .


โ€” ?


, ยซยป . , , - , - . , , - ยซยป . , , , , , .


โ€” ?


-, , .
: , , . . , , , . , .


, 150 , . - . , .


, , , . , , , โ€” . , , .


-



โ€” - , , , ?


, โ€” . , - , - . , . , 4, .


, - . โ€” . , .


, , . , .


โ€” - - , ?


ยซ ยป. โ€” , โ€” , .


- - , , - . , , .


, . , , . โ€” . - , . , -.


, , . , , - ( -, - ).


โ€” ?


. , . , , .


โ€” , , , - . , โ€” , .


. , : , - , .


, , - , , . , , , , โ€” . , , , .


( , )


โ€” , ? ?


, , Java. dependency injection, , , โ€” , . , . . : , - .


, . , , , , happens-before. , , .


Seperti yang Anda ketahui, hal-hal seperti IntStream#distinct melibatkan membungkus primitif dalam tipe Java dan selanjutnya operasi terbalik. Tampaknya tidak terlalu menakutkan, tetapi pada sejumlah besar data, tinju massal dan anboxing akan terlihat, memori akan digunakan dengan sia-sia. Anda perlu memahami nyali Jawa itu sendiri, karena pada hal-hal sepele seperti tinju, Anda dapat menghasilkan banyak alokasi tambahan yang tidak Anda butuhkan. Dan untuk mengetahui hal ini tepat waktu, Anda harus dapat menggunakan alat untuk mengevaluasi kinerja, mengumpulkan metrik, dan memahami hal-hal standar lainnya.


- Apakah Anda perlu mengetahui spesifikasi bank?


Tidak, pada dasarnya. Kita semua mengerti bahwa orang-orang yang mengetahui spesifikasi bank sudah bekerja di bank. Ketika Anda datang dari bidang lain, kemungkinan besar Anda tidak mengenalnya. Pada awalnya, Anda dapat mempelajari dokumen-dokumen tentang poin-poin umum: apa yang berjangka, apa opsi, bagaimana perbedaannya, apa risikonya. Dan Anda baru saja terjun dan mulai memahami spesifik bisnis.


Namun demikian, ini penting. Pada awalnya, Anda cukup menerapkan fungsionalitas yang tidak terkait dengan kekhususan bisnis tertentu, tetapi secara bertahap mempelajari hal-hal yang lebih kompleks dan spesifik subjek. Apa yang ada di sini, apa yang ada di tempat kerja terakhir (ketika saya, sebagai kepala departemen, merekrut karyawan) - Anda perhatikan bahwa jika dari sepuluh orang setidaknya satu memahami apa masa depan, ini sudah baik.


Jika Anda memiliki pengetahuan tentang algoritma, multithreading, dan Java secara umum, maka mempelajari spesifik bisnis tidak akan sulit. Ternyata itu sendiri ketika Anda terjun ke lingkungan ini, membaca dokumen dan mengerti.


- Bagaimana Anda akan menguji pengetahuan mendalam tentang Jawa pada saat wawancara? Apakah ini nyata?


Jelas bahwa Anda kemungkinan besar tidak akan memeriksanya. Tetapi ada tugas standar pada logika, algoritma, pemahaman struktur internal. Ini adalah tugas tes, dan coding papan tulis. Misalnya, tugas untuk menerapkan cache dalam antrian yang akan memberikan pemahaman apakah seorang kandidat memahami multithreading - ras, deadlock, dan yang lainnya. Sepanjang jalan, Anda dapat mengajukan pertanyaan tentang berapa banyak memori yang dikonsumsi, mengapa TreeMap, bukan HashMap. Dengan demikian, menyelesaikan satu masalah umum, Anda dapat melihat momen dari spesifik yang berbeda. Di sini, alih-alih, praktik yang dengannya nuansa tertentu dihitung.


- Menurut Anda apa yang perlu dilakukan untuk menjadi lebih baik sebagai seorang programmer?


Berkembang! Mengkode dan mengawasi teknologi dan algoritma apa, bahasa baru apa, memecahkan masalah algoritmik. Faktanya, banyak tergantung pada pengalaman. Jika Anda telah memecahkan banyak masalah pada algoritma, maka Anda dapat menemukan sesuatu yang serupa dari tugas-tugas sebelumnya di sebuah asing baru. Penting untuk mengembangkan pemikiran, kemampuan untuk cepat menemukan jawaban. Kemampuan untuk mencari dan menemukan solusi di StackOverflow sangat berguna. Jika Anda tidak tahu sesuatu, tetapi Anda tahu di mana menemukannya, ini adalah jalan menuju sukses.


Bahasa sedang berubah, teknologi dan kerangka kerja sedang diubah. Pola baru datang, tetapi beberapa pola tetap digunakan semua orang. Konferensi Java tanpa laporan tentang Aliran Reaktif dan pembicaraan tentang Kotlin tidak lagi lulus. Duduk dalam kepompong dan tidak mengerti bahwa sekarang sumber acara, dalam arti tertentu, secara bertahap mengambil alih dunia adalah aneh.


Perlu untuk mengembangkan latar belakang. Misalnya, buku-buku Knut masih relevan. Basis ditambah teknologi baru. Dan Anda perlu tahu di mana dan apa yang harus google.


- Apa hal terakhir yang dia mengerti?


Di Kotlin Coroutines. Keren, aku suka itu. Baik dalam sintaks dan logika. Saya melihat bagaimana bekerja di dalamnya dengan multithreading dan asynchrony. Sebelumnya, saya harus menggunakan Kotlin sangat sedikit. Sekarang saya aktif mempelajarinya, beberapa proyek sudah mengeksploitasinya. Bahkan ada di beberapa modul kecil di prod.


Source: https://habr.com/ru/post/id449630/


All Articles