1 - Pengembangan perangkat lunak dan revisi perangkat lunak yang ada di C ++ (Qt5). 2 - Pengembangan GUI pada QtWidgets / QML. 3 - Partisipasi dalam desain arsitektur berbagai sistem. 4 - Pengalaman pengembangan di C ++. 5 - Pengetahuan yang baik tentang Qt5. 6 - Pengalaman dalam mengembangkan aplikasi multi-threaded. 7 - Memahami OOP. 8 - Pengetahuan tentang Linux sebagai pengguna berpengalaman.
Sekarang mari kita lihat poin-poinnya. Atau lebih tepatnya, bagaimana saya membacanya ketika saya menemukan proposal semacam itu.
1. Pengembangan perangkat lunak dan revisi perangkat lunak yang ada di C ++ (Qt5)
Pada titik ini, semuanya baik-baik saja. Versi pustaka dan bahasanya hanya ditunjukkan.
2. Pengembangan GUI pada QtWidgets / QML
Ya, QML adalah bagian dari Qt, tidak ada yang membantah. Tetapi ada satu poin kecil: tentu saja, adalah mungkin untuk menulis sebuah proyek yang duduk di dua kursi pada saat yang sama, tetapi mengganggu keduanya adalah pertanda arsitektur yang buruk. Mungkin maksud orang-orang hanya pengembangan QML? Sebenarnya: proyek ini ditulis dalam QML, tetapi Anda memerlukan komponen Anda sendiri, dan mereka ditulis dalam C ++ menggunakan QtWidgets ... Ini masih belum jelas, jadi lanjutkan membaca. Ngomong-ngomong, kita akan kembali ke arsitektur nanti.
3. Partisipasi dalam desain arsitektur berbagai sistem
Sistem spesifik apa yang Anda maksud? Pertanyaan segera muncul: berapa banyak dari mereka yang Anda miliki? Apakah ini beberapa proyek yang perlu dikerjakan oleh satu orang pada saat yang sama atau apakah pemrograman Qt klasik dicampur menjadi satu proyek mengerikan dengan QML dan beberapa pendekatan lainnya? Dilihat oleh fakta bahwa QtWidgets di paragraf sebelumnya mengacu pada apa yang disebut "pengembangan Qt klasik" (kami membuat formulir - kami menulis kelas untuknya) tanpa QML, menjadi jelas bahwa programmer harus duduk di dua kursi pada saat yang bersamaan.
4. Pengalaman pengembangan di C ++
Untuk apa itu ditulis? Sehingga petinju QML yang belum pernah melihat C ++ seumur hidupnya tidak akan datang? Atau apakah pengalaman pengembang saat ini tidak cukup untuk beralih dari QML kembali ke QtWidgets? Mungkin mereka tidak ingin terlibat dalam pemeliharaan kode lama?
Menurut saya semuanya agak lebih rumit: faktanya adalah kemampuan QML standar biasanya tidak cukup untuk aplikasi yang lengkap - jadi Anda harus membuat plugin QML Anda sendiri. Untuk itu C ++ dibutuhkan. Dengan kata lain, proyek untuk orang-orang sudah sebagian ditulis dalam QML, tetapi kemudian mereka mengalami sangat kurangnya peluang - dan kemudian kotak QML ternyata kurang terampil, atau sibuk selama dua ratus persen waktunya hanya dengan membuat formulir, tetapi QML -komponen dalam C ++ dia entah bagaimana tidak bisa menulis. Menjadi jelas apa yang akan kita lakukan: ini adalah dukungan dari kode klasik dan pembuatan komponen QML baru.
Namun, ini bukan hanya satu, tapi dua lowongan. Dalam kode Qt klasik, biasanya ada lautan bug yang sulit diperbaiki dan programmer yang duduk di dukungan akan sibuk memperbaiki lebih dari seratus persen waktunya (bekerja dengan pengerjaan ulang). Anda juga tidak akan dapat menulis komponen QML baru "dari waktu ke waktu", Anda harus melakukannya sepanjang waktu. Mungkin mereka berpikir bahwa seseorang terutama akan mendukung kode lama, terkadang "dengan cepat dan entah bagaimana" menggantinya dengan QML. Dalam hal ini, muncul pertanyaan, siapa yang terlibat dalam arsitektur semua aib ini? Ingat poin ketiga: "kami adalah penyelamat itu." Singkatnya, lakukan apa yang Anda inginkan, tidak ada yang berurusan dengan arsitektur, tidak ada yang akan menyewa arsitek proyek, dan manajernya bukan seorang arsitek dan tidak tahu topik ini, jadi semuanya akan disalahkan pada kami.
5. Pengetahuan yang baik tentang Qt5
Benar? Tidak, saya tidak percaya bahwa dengan pengetahuan yang buruk tentang sesuatu, Anda bisa pergi ke suatu tempat untuk mendapatkan pekerjaan. Artinya, secara umum layak untuk menulis tentang itu, jika tidak benar, mereka akan datang dengan hal-hal buruk? Mungkin kita akan menguraikan sesuatu saat ini? Ternyata ketika mereka menulis ini, mereka berpikir bahwa pengembang mereka saat ini tidak cukup mengenal Qt (apa pun artinya), dan jika demikian, maka mereka telah mencoba menghemat uang untuk programmer.
6. Pengalaman dalam mengembangkan aplikasi multi-threaded
Memang, mereka berhasil memecahkannya. Mengembangkan aplikasi multi-thread dengan Qt membutuhkan pengetahuan yang sangat baik tentangnya. Tetapi saya pribadi membaca sesuatu yang sama sekali berbeda dalam persyaratan ini, bukan apa yang mungkin dimaksudkan ketika mereka menulis frasa ini. Pertama, mari kita cari tahu mengapa Qt adalah multithreading?
Bagian klasik dari Qt adalah perpustakaan berbasis peristiwa . Namun, fungsionalitas selanjutnya telah ditambahkan ke dalamnya yang memungkinkan Anda untuk menjalankan utas. Namun, seluruh antarmuka masih bekerja dalam satu utas utama, dan hingga Anda keluar dari fungsi sebelumnya, utas lainnya tidak akan dipanggil, tidak peduli bagaimana Anda menghubungkannya dengan slot sinyal.
Multithreading biasanya diperlukan pada tingkat non-antarmuka: dalam aplikasi Qt, pemisahan klien-server sering digunakan dengan satu atau lain cara - dan jika arsitektur server tidak dirancang dengan baik (misalnya, panggilannya sangat sinkron), maka dalam hal ini, utas akan diperlukan untuk mengatur menunggu di tingkat antarmuka. Apa artinya ini saat melamar lowongan?
Pertama, front-end antara klien dan server dirancang dengan buruk atau tidak ada sama sekali. Kami menulis sebaik mungkin dan setidaknya sebagian dari logika bisnis bercampur dengan kode klien, dan kami harus menangani sebagian dengan pemrograman sistem (menyelesaikan apa yang tidak diselesaikan oleh pemrogram sistem di tingkat server). Di sini saya harus mengatakan bahwa biasanya ada pemrogram sistem dalam tim seperti itu - tetapi sangat spesifik. Dialah yang akan datang ke wawancara untuk menyalahkan Anda dengan pertanyaan tentang tumpukan protokol TCP / IP, meskipun dialah yang berkewajiban untuk merancang sistem sehingga tidak ada kode sistem sama sekali di jendela. Dan dia, omong-omong, menerima gaji maksimum dari semuanya - dan Anda harus menerima tanggung jawab atas ketidaksempurnaannya, menggunakan pemrograman multi-thread.
Kedua: sebagai akibat dari panggilan sinkron, program menjadi sangat lambat sehingga manajemen perusahaan (jangan disamakan dengan manajer) telah menerima umpan balik pengguna
7. Memahami OOP
Oh ... ini adalah sesuatu dari kategori "Saya bisa membuat kode dalam C ++, tapi saya tidak tahu apa itu OOP." Tidak seperti itu. Kecuali mungkin untuk mahasiswa pascasarjana yang telah menulis kursus C-style tunggal dalam C ++ dan yang segera diidentifikasi berdasarkan usia dan dengan menanggapi lowongan. Oleh karena itu, ada maksud lain. Apa tepatnya?
Dari pengalaman saya sendiri, saya dapat berasumsi bahwa program itu terkenal mengacaukan kami. Tentunya semuanya dimulai, seperti biasa, sangat keren, menarik dan menyenangkan: arsitektur yang benar, lapisan abstraksi, dan segala sesuatu yang biasanya menyertai proyek yang kompeten. Tapi kemudian perlombaan untuk fungsionalitas dimulai, yang mengaburkan lapisan abstraksi. Kemungkinan besar, jika ternyata proyek tersebut sudah lama, pengembang aslinya membuatnya di QtWidgets, tetapi mereka pergi untuk waktu yang lama - begitu lama sehingga siswa yang sangat muda yang mulai memahat QML berhasil bekerja alih-alih mereka (meyakinkan bos mereka bahwa itu keren) ... Yang, pada gilirannya, juga tumbuh - dan menyadari bahwa kode mirip mie yang mereka tulis di awal, akhirnya berubah menjadi ravioli dari abstraksi (lihat antipatterns).Dan sekarang, untuk setiap jendela, selusin microclass yang hampir kosong dipanggil alih-alih satu kelas bentuk normal, yang menyulap data di antara mereka sendiri - dan tidak secara langsung, tetapi melalui semacam injektor penguat (ini menjadi mode beberapa tahun yang lalu). Juggling ini berakhir dengan fakta bahwa setelah melewati lusinan lapisan ekstra, Anda menemukan kode mirip mie yang sama dengan"TODO: tulis ulang semuanya secara manusiawi ketika waktu muncul" di suatu tempat di sudut terpencil proyek.
Akibatnya, kode tersebut tidak dapat dipahami terlalu banyak sehingga tidak memungkinkan lagi untuk dikembangkan. Para programmer telah memikirkan semuanya sejak lama dan membuangnya di tempat yang lebih ramah. Namun, manajemen proyek tidak mempelajari apa-apa dan sekarang (setelah melihat skrip QML sederhana) percaya bahwa masalah tersebut dapat diselesaikan "dengan cepat" dengan bantuan peluru perak lainnya. Poin berikut memberi tahu kita bahwa ini kemungkinan besar terjadi:
8. Pengetahuan tentang Linux sebagai pengguna berpengalaman
Akhirnya, menjadi jelas untuk apa proyek itu. Orang mungkin berpendapat, orang dapat membantah (di komentar), tetapi pengembangan Linux di masa-masa sulit kita sama sekali bukanlah cita-cita perangkat lunak bebas (yang mungkin kita semua impikan). Dalam sembilan puluh sembilan persen kasus, ini adalah penjaga keamanan dengan gagasan untuk memantau segalanya dan semua orang, dan sebagai Linux yang kami maksud adalah Astra, karena Kamerad Mayor mengatakan demikian. Artinya, ini bukan perusahaan IT dan tidak ada yang pernah mendengar pendekatan arsitektural normal di sana, dan semua masalah (dari pengalaman) diselesaikan dengan cara "menepuk kutu". Oleh karena itu kesimpulannya: gaji tidak disebutkan karena suatu alasan. Di sini Anda perlu mempekerjakan tiga senior (dengan jumlah yang sesuai dari pertengahan dan Juni untuk masing-masing dari mereka) untuk refactoring kode secara lengkap, dan tidak mencari "orang yang akan menyelesaikan semua masalah." Namun, majikan tidak mampu membelinya,karena ini hanya mungkin dalam perekonomian normal dengan pasar investasi yang matang. Tapi ini adalah topik yang berbeda dan tentang itu di lain waktu.