Suatu hari dalam kehidupan seorang pengembang Java. Bagian 1

Salam, rekan-rekan terkasih! Setelah terbitnya " 20+ Years Later ", beberapa pembaca meminta kelanjutan ceritanya. Apa lagi yang bisa saya bicarakan? Sepertinya saya telah sepenuhnya membahas topik mengubah "enikey berjanggut" menjadi pengembang Java. Beberapa kesimpulan dapat ditarik tidak lebih awal dari setelah satu tahun bekerja. Dan kemudian saya memutuskan untuk menjelaskan secara sederhana bagaimana hari kerja saya biasanya. Di bawah potongan “Suatu hari dalam kehidupan seorang pengembang Java.” Ketika saya masih muda, saya suka tidur. Waktu saya masih enikey, kebetulan saya tidur sampai siang, dan masuk kerja jam tiga, atau bahkan setengah tiga. Setiap kali saya menanggapi tuntutan periodik manajemen untuk “datang seperti orang lain,” yaitu, pada jam 9 pagi, dengan cara yang sama setiap saat—mereka mengatakan, saya harus bekerja dengan komputer ketika saya tidak mengganggu siapa pun. Itu berguling. Namun seiring bertambahnya usia, rupanya ada sesuatu yang berubah pada tubuh saya, dan sekarang saya lebih seperti “burung” daripada “burung hantu malam”. Itu sebabnya sekarang saya masuk kerja dulu (atau salah satu yang pertama). Hari ini saya yang pertama, dan saya memiliki waktu hening selama setengah jam atau satu jam sampai orang lain yang tidak begitu “early bird” menyusul. Saatnya membuat rencana hari ini. Saya mengembangkan di Linux Mint. Saya suka tombol Start, sederhana dan elegan, tidak seperti ubin ini. Manajer desktop Cinnamon tidak dipenuhi dengan efek visual, tetapi dalam hal penyempurnaan, ia sedikit lebih rendah dari MacOS, yang tentu saja merupakan standar dalam hal ini. Sangat mudah untuk membandingkannya, ada Mac di meja sebelah, seorang desainer UX bekerja di belakangnya. Saya juga hampir tidak memiliki keluhan tentang OS itu sendiri: ia bekerja dengan cepat dan sangat stabil, saya hanya me-rebootnya tiga kali selama ini - ketika saya mematikan komputer selama liburan panjang. Sebenarnya juga memuat hampir seketika, bahkan splash screen tidak sempat muncul, karena semua komputer pengembang dilengkapi dengan drive SSD. Pertama-tama, saya membuka klien email Thunderbird, surat datang ke sana dengan informasi tentang perubahan pada halaman yang saya minati di wiki (ada pengaturan dan spesifikasi), tetapi yang utama adalah pemberitahuan dari pelacak. Hal menarik apa yang terjadi pada kita? Oh, mereka kembali dari pengujian fitur yang saya selesaikan kemarin, sepertinya mereka menemukan bug. Ya, benar. Saya perlu memperbaikinya sesegera mungkin, mungkin saya akan punya waktu sebelum penguji tiba dan dia akan segera melihat koreksi sebelum dia masuk ke beberapa “konstruksi yang belum selesai”. Itu hal pertama untuk hari ini. Jadi, ini tentang “konstruksi yang belum selesai” saya, yang saya tulis sepanjang sprint terakhir. Tampaknya kali ini dia berhasil bertahan dari semua lingkaran nerakatahap pengujian dan hari ini, mungkin, perlu digabungkan ke dalam cabang utama proyek. Tapi itu akan terjadi nanti, setelah makan siang. Bahkan saat ini kami harus bekerja di devops dan memperbarui stand dari cabang tempat pengembangan sedang berlangsung, kami perlu menunjukkan fungsionalitas baru. “Dengan kekuatan yang besar, datang pula tanggung jawab yang besar,” perintah sudo menampilkan peringatan sebelum memberikan hak akses root. Dalam terjemahan saya yang agak longgar, frasa ini terdengar seperti “semakin banyak yang dapat Anda lakukan, semakin banyak pula yang harus Anda lakukan.” Oleh karena itu, tidak mengherankan jika saya yang menyandang “cap administrator” sering menerima tugas-tugas yang “batas” seperti itu. Baiklah, mari kita mulai. Kemarin saya sedang mengerjakan fitur lain, dan sekarang saya harus kembali ke cabang tempat bugnya. Pengguna Windows biasanya menyukai semua jenis shell grafis dan menggunakan Turtle (TortoiseGit), tetapi bagi saya lebih mudah dan familiar melalui baris perintah. Secara umum, baris perintah di Linux adalah sebuah mahakarya kecil, sangat bijaksana dan kuat, terutama jika dikombinasikan dengan Midnight Commander. Kami beralih, sekarang kami perlu membangun kembali proyek tersebut. Saya mengetikkan perintah gradle clean ass. Saya tidak tahu apakah perintah ini awalnya dimaksudkan oleh penulis gradle atau dibuat secara kebetulan, tetapi perintah ini hanya membersihkan dan membangun kembali proyek (ass adalah kependekan dari assemble, dan bukan yang pertama kali terlintas dalam pikiran). Di javarush, gradle hanya disebutkan secara singkat, sebagai “dan sistem build lainnya.” Ya, gradle tidak memiliki keunggulan dibandingkan pakar dalam menyusun proyek pendidikan. Kebanyakan tutorial dan cara di internet juga menggunakan pakar. Kemunculan dan semakin populernya gradle kemungkinan besar disebabkan oleh meningkatnya kompleksitas proyek bangunan modern. Proyek yang saya ikuti terdiri dari beberapa lusin komponen, dengan backend ditulis dalam Java, frontend dalam Javascript, dan pengujian dengan Python. Omong-omong, saat ini, merakit proyek Javascript adalah proses yang terpisah dan sangat rumit, yang bahkan memiliki nama - Alur Kerja Web, dan pohon ketergantungan di sana hampir sama luasnya dengan di Java. Yah, setidaknya Anda tidak perlu merakit komponen Python, hampir tidak perlu... Setelah perakitan dan peluncuran (yang juga tidak sepele), Anda perlu menaikkan dan menginisialisasi dengan data uji seluruh lingkungan dengan relasional dan database NoSql, antrian pesan dan cache dalam memori. Kemudian semua ini perlu dirakit kembali dan dijalankan di server CI, lalu disebarkan menggunakan kemungkinan. Pada saat yang sama, pengembangan terutama dilakukan di Windows, dan server "pertempuran", demo, pengujian, dan server pra-produksi lainnya, tentu saja, berada di Linux. Saya tidak benar-benar membayangkan bagaimana mungkin menerapkan hal-hal seperti itu di pakar, tetapi secara bertahap cukup baik. Faktanya adalah file build gradle ditulis dalam Groovy. Ini bahasa yang sangat lucu, mereka bilang itu persilangan antara Java dan Ruby, tapi saya tidak tahu Ruby, tapi saya tahu sedikit Javascript, dan banyak konstruksi darinya juga berfungsi. Pembuat gradle telah mengimplementasikan API sedemikian rupa sehingga dalam kasus sederhana, file build terlihat cukup deklaratif (dan, menurut pendapat saya, ini bahkan lebih mudah dibaca daripada pom.xml Maven), tetapi jika Anda memerlukan sesuatu yang lebih kompleks, semua sifat deklaratif ini dibuang, variabel, fungsi, kelas muncul - singkatnya, semua fitur Groovy, yang, omong-omong, dapat dikompilasi dan dijalankan pada JVM yang sama dengan kode Java. Majelis itu sendiri, seperti yang telah saya sebutkan, adalah lintas platform, tetapi berinteraksi dengan lingkungan, sehingga perlu diperiksa di Windows juga. Untuk melakukan ini, saya menginstal Windows pada mesin virtual. KVM berkembang pesat, dan jika sistem tamu dikonfigurasi dengan benar, virtualisasi hampir tidak terlihat. Ya, Spice sekarang mendukung dua monitor, resolusi layar disesuaikan secara otomatis, dan driver perangkat yang diparavirtualisasi hampir tidak menyebabkan hilangnya kinerja. Terkadang saya mendapati diri saya berpikir bahwa saya tidak merasakan banyak perbedaan antara kedua platform tersebut. Namun, Java adalah alat luar biasa yang telah mendekatkan dua dunia yang sangat berbeda dan, terkadang, bahkan bermusuhan - dunia perangkat lunak berpemilik, crack, keygen dan serial,dicontohkan oleh Windows dan dunia sistem terbuka Linux. Jadi, proyek sudah selesai, kami meluncurkannya (tentu saja, juga melalui gradle) dan melihatnya. Ya, sayang sekali janggut abu-abu saya, saya tidak menerapkan salah satu persyaratan produksi, ini dia, ditulis hitam putih di wiki. Pada pekerjaan saya sebelumnya, saya sering menghadapi situasi ini dan selalu bingung dengan bagaimana pengembang bisa melewatkan satu paragraf penuh dari spesifikasi. Ya, dengan mudah! Saya memikirkannya, fokus pada masalah lain - dan ada bug. Hanya di sini, berkat beberapa tahap pengujian, dia akan ditangkap, tetapi di tempat sebelumnya - yah, apa pun yang terjadi. Untungnya, pekerjaan di sini tidak akan bertahan lama. Saya meluncurkan Idea Ultimate, yang merupakan salah satu dari sedikit produk berbayar yang digunakan dalam pengembangan. Pada prinsipnya, Anda dapat bertahan dengan Edisi Komunitas, tetapi Anda akan segera terbiasa dengan hal-hal bagus, misalnya integrasi dengan Spring. Anda juga memerlukan beberapa terminal untuk log, browser untuk frontend dan wiki, terminal lain dengan baris perintah, semuanya bergerak, berkedip... Secara umum, gambar di layar dua monitor mulai terlihat menakutkan Penampilannya, seperti yang ditampilkan di film-film berbudget rendah, menggambarkan kerja keras seorang hacker. Tapi ini masih hal-hal kecil, tapi saya ingat ketika saya harus menaikkan dan mengkonfigurasi cluster failover - tujuh jendela terminal, sesuatu yang lain di sudut layar, di semua jendela - beberapa angka dan gambar dari grafik ascii... Tapi Saya ngelantur sedikit dari pekerjaan, dan waktu berlalu. ... Fiuh, sepertinya saya telah melakukan semua yang saya butuhkan dan, sepertinya, saya tidak melanggar apa pun yang telah saya lakukan sebelumnya. Saya menambahkan komentar ke fitur tersebut dan mengirimkan thread untuk pengujian. Saya mencoba menulis lebih detail apa sebenarnya yang saya lakukan atau ubah untuk menyederhanakan pekerjaan penguji. Pada pekerjaan saya sebelumnya, saya sangat merindukan penjelasan seperti itu ketika saya harus memeriksa peningkatan yang diterima dari pengembang. Sementara itu, pagi hari mulus berganti siang, masyarakat berangsur-angsur berhenti. Sebentar lagi akan ada stand up meeting atau menurut kami stand up. Faktanya, hari kerja harus dimulai dengan hal ini, dan bagi sebagian besar “orang yang suka tidur malam” hal ini hampir terjadi. Stand-up berperan sebagai pembatas untuk tiba di tempat kerja selambat-lambatnya, sangat tidak disarankan untuk terlambat. Bagi saya, ini seperti istirahat. Jadi, mari kita semua berdiri. Saat stand-up, seperti biasa, para pengembang memberi tahu apa yang mereka lakukan kemarin dan apa yang mereka rencanakan hari ini, para penguji memberi tahu kami apa yang mereka uji dan dengan hasil apa, dan para bos, jelas, apa yang mereka rencanakan selanjutnya, permasalahan apa saja yang timbul dan apa saja yang perlu mendapat perhatian khusus. Tim kami tersebar secara geografis, dan kelengkapannya hanya dapat dilihat saat stand-up (tentu saja di TV), dan juga, mungkin, di acara perusahaan umum beberapa kali dalam setahun. Selama stand-up, saya sering berpikir bahwa ini sebenarnya diciptakan untuk mencegah pengembang bersantai. Ketika setiap hari Anda perlu menunjukkan kemajuan dalam pekerjaan Anda, dan bukan dalam laporan kertas yang hanya dibaca atasan Anda, tetapi di depan rekan kerja Anda, mau tidak mau Anda akan berusaha berbuat lebih banyak, ingin membicarakan sesuatu. Tentu saja ada “proyek konstruksi jangka panjang”, yang selama beberapa hari berturut-turut Anda mengulangi “kemarin saya melakukan ini, dan hari ini saya akan terus melakukannya,” tetapi bahkan di dalamnya ada beberapa tugas kecil yang mendesak terus-menerus. terjepit di. Singkatnya, nyata Seorang pengembang koboi selalu ingin menyampaikan sesuatu kepada rekan-rekannya. Saat stand-up saya diminta untuk segera mengupdate stand saya, jadi sekarang saya akan melakukannya. Ketika cabang utama proyek diterbitkan, pembaruan dilakukan oleh admin, tetapi sekarang kami perlu menerbitkan fitur yang belum selesai, dan pada saat yang sama pasti akan muncul beberapa masalah yang tidak dapat diselesaikan oleh admin. Standnya terletak di pusat data, akses ke sana hanya dapat dilakukan melalui ssh, tentu saja tidak ada shell grafis di sana - jadi hanya baris perintah, hanya hardcore! Pembaruan itu sendiri otomatis dan berjalan lancar, tetapi setelah pembaruan salah satu komponen tidak dimulai. Saya melihat log dengan perintah less; omong-omong, ini memiliki fungsi yang sangat nyaman: jika Anda menekan Shift-F, itu akan terus-menerus menampilkan konten file saat ini, yang sempurna untuk log. Dan apa ini... hal yang aneh? Layar penuh tanda tanya dipisahkan dengan koma. Layar kedua, ketiga, kesepuluh... Ada berapa banyak? Oh iya, udah tamat, ternyata stacktracenya lumayan banyak. Seseorang menulis kueri SQL dengan operator IN untuk memilih rekaman yang diinginkan dari daftar, dan membuat parameter untuk setiap elemen daftar. Semuanya berfungsi hingga daftar tersebut berisi lebih dari 32767 elemen, setelah itu server SQL akhirnya kehabisan kesabaran. Anda perlu menulis laporan bug tentang ini, tetapi ini tidak ada hubungannya dengan masalah komponen yang tidak berfungsi. Mari kita lihat lebih jauh. Sekarang jelas bahwa migrasi struktur database ke versi baru tidak berhasil, sepertinya pembuat fitur mengubah sesuatu dalam migrasi, dan di sini, di stand, ada versi sebelumnya. Anda harus mengembalikan perubahan struktur secara manual, melalui utilitas konsol server SQL. Bagaimana saya bisa menulis perintah di DML untuk menghapus suatu bidang? indeks? tabel? Sepertinya itu saja. Saya me-restart komponen, migrasi berjalan dengan baik... semuanya baik-baik saja. Ngomong-ngomong, ini waktunya makan siang, cuacanya bagus hari ini. “Bola kuning cerah yang tergantung tak bergerak di langit dan begitu menakutkan penduduk kota ternyata adalah Matahari.” Hampir hari cerah pertama tahun ini. Saya bahkan tidak ingin meninggalkan jalan, tetapi saya harus melakukannya - waktu untuk merger semakin dekat. Bersambung