Kembali ke Zaman di Mana Tak Ada yang Tahu

Bab 5

Belakangan ini, ada banyak hal yang harus dilakukan sebelum memulai pekerjaan.

Memeriksa tiket, membaca persyaratan, mencari dokumen terkait, membuat cabang, menulis ruang lingkup pekerjaan.

Setelah membuat kode, itu belum berakhir.

Melakukan pengujian, melakukan komitmen, membuat permintaan penarikan, menerima ulasan, memverifikasi pemeriksaan keamanan, menunggu jadwal penerapan.

Dulu, satu baris kode yang mungkin diperbaiki di pagi hari dan diunggah di sore hari sekarang harus melewati banyak mata.

Banyak hal yang membaik.

Kita bisa mengetahui siapa yang mengubah apa kapan, dan jika ada masalah, kita juga bisa kembali ke versi sebelumnya.

Dulu, seseorang masuk ke server operasi dan secara diam-diam menimpa satu file sehingga tidak ada yang tahu jarang terjadi.

Setidaknya secara teoritis.

Saya telah melihat satu tiket sepanjang pagi.

Isinya singkat.

Akumulasi poin terlewat setelah pesanan selesai dalam kondisi tertentu.

Ada prosedur reproduksi yang disertakan.

Ada juga akun uji coba, tangkapan layar layar terkait, dan waktu kejadian.

Dulu, itu adalah data yang sangat ramah.

Namun, setelah satu jam berlalu, penyebabnya tidak terlihat.

Layanan pesanan diproses dengan normal.

Pemanggilan layanan poin juga berhasil.

Tidak ada kesalahan dalam log.

Saya mengikuti kode yang terkait.

Pesanan selesai.

Acara diterbitkan.

Layanan poin dipanggil.

Hasil disimpan.

Semua tampak normal.

Seorang pengembang muda di sebelah saya bertanya.

“Masih melihatnya?”

“Ya.”

“Sudah ditanyakan ke AI?”

“Sudah.”

“Apa katanya?”

“Katanya kode itu tidak bermasalah.”

Dia tertawa.

“Itu jawaban paling menakutkan,” katanya.

“Benar sekali.”

Saya juga tertawa.

AI memberikan beberapa kemungkinan.

Masalah transaksi.

Kegagalan pemrosesan asinkron.

Logika pencobaan ulang.

Hilangnya acara.

Inkonsistensi cache.

Itu masuk akal.

Dan semuanya salah.

Saya membaca tiket itu lagi.

Kondisi tertentu.

Kata-kata itu mengganggu saya.

“Kondisi apa yang tepat?”

Pengembang muda itu melirik layar.

“Pesanan dengan kupon digunakan,” katanya.

“Semua kupon?”

“Tidak. Ada yang tertulis sebagai kupon tertentu.”

Saya mencari dokumen perencanaan.

Ada tautannya.

Dokumen itu tersusun dengan rapi.

Judul.

Riwayat perubahan.

Penanggung jawab.

Tiket terkait.

Saat membaca dokumen, saya menemukan kalimat aneh.

Untuk kupon promosi, kebijakan akumulasi poin mengikuti kebijakan yang ada.

Kebijakan yang ada.

Saya menatap kalimat itu untuk waktu yang lama.

Itu adalah salah satu kalimat yang paling saya benci saat mengembangkan.

Sama seperti sebelumnya.

Tetap seperti sekarang.

Menerapkan kebijakan yang ada.

Tidak ada yang pernah menuliskan apa yang terkandung di dalamnya.

“Kebijakan apa yang ada?”

Saya bergumam.

Bahkan AI tidak bisa mengetahuinya meskipun saya menempelkan dokumen ke dalamnya.

AI hanya bisa membaca apa yang ada di dokumen.

Apa yang tidak ada di dokumen, AI bahkan tidak tahu lebih dari saya.

Saya mencari tiket lama.

Tiga tahun yang lalu.

Lima tahun yang lalu.

Saya mengubah kata kunci pencarian.

Poin.

Kupon.

Promosi.

Tidak termasuk poin.

Tiket lama yang sudah sangat usang muncul.

Penggunaan kupon promosi afiliasi akan mengakibatkan poin tidak terkumpul.

Saya membuka kontennya.

Orang yang bertanggung jawab sudah mengundurkan diri.

Ada banyak komentar yang diposting.

Di bagian paling bawah ada kalimat pendek.

Hasil diskusi perencanaan, pengecualian poin hanya berlaku untuk beberapa kupon afiliasi. Kebijakan akan diringkas nanti.

Kebijakan selanjutnya tampaknya tidak pernah disusun.

Saya memeriksa kode kupon.

Kupon yang bermasalah adalah salah satu kupon afiliasi yang dibuat pada saat itu.

“Ditemukan.”

Saya berkata tanpa sadar.

Seorang pengembang muda menghampiri saya sambil mendorong kursinya.

“Ada apa?”

“Ini bukan bug.”

“Hah?”

“Awalnya kupon itu memang tidak mendapatkan poin.

“Tapi kenapa tiket ini masuk sebagai bug?”

“ sepertinya tim perencanaan tidak mengetahui kebijakan ini.”

Teman saya itu menatap layar sebentar, lalu berkata.

“Kalau begitu dokumennya salah.”

“Dokumennya tidak ada.”

“Bagaimana cara menemukan hal seperti ini?”

Saya akan menjawab, tapi berhenti.

Bagaimana saya menemukannya.

Tidak ada metode khusus.

Saya hanya tahu bahwa hal seperti ini sering terjadi sebelumnya.

Jika kode sudah benar tetapi hasilnya aneh, Anda harus melihat di luar kode.

Dan di balik kata “kebijakan yang ada” biasanya ada sesuatu yang tidak dijelaskan.

“Lama-lama akan tahu.”

Setelah mengatakannya, saya menyadari bahwa saya berbicara seperti senior yang saya benci dulu.

Pengembang muda itu tertawa.

“Jawaban yang paling tidak membantu.”

“Betul.”

Saya juga tertawa.

Saya menulis hasil penyelidikan di tiket.

Menambahkan tautan ke tiket terkait sebelumnya dan mencatat bahwa kebijakan saat ini berbeda dengan konten dokumen.

Saya menandai perencana yang bertanggung jawab.

Segera setelah itu, ada balasan.

Akan saya periksa.

Dan sekitar satu jam kemudian, komentar lain muncul.

Kebijakan pengecualian yang ada telah dikonfirmasi masih berlaku. Akan ditutup karena bukan bug.

Saya menutup tiket.

Saya tidak mengubah satu baris kode pun.

Pagi sudah berlalu.

Dulu, di hari seperti ini saya akan merasa seperti tidak melakukan pekerjaan apa pun.

Bukan lagi sekarang.

Saya belajar sejak lama bahwa tidak mengubah sesuatu pun juga bisa menjadi pekerjaan seorang pengembang.

Seringkali lebih baik tidak mengubahnya daripada memperbaikinya dengan salah.

Di sore hari, ada review kode untuk tugas lain.

Kode yang dibuat oleh seorang pengembang muda.

Ada tanda-tanda penggunaan AI.

Kodenya rapi.

Nama metode juga bagus, penanganan pengecualian sudah ada, dan kode pengujian juga tersedia.

Berbeda dengan kode yang dibuat oleh programmer junior dulu.

Masih terasa aneh bahwa seorang programmer junior bisa membuat kode seperti ini sejak awal.

Saya membaca kode dan berhenti di satu bagian.

Pemanggilan API eksternal diatur untuk melakukan tiga kali percobaan ulang jika gagal.

Secara sekilas, itu tampak logis.

Saya menambahkan komentar.

API ini adalah API persetujuan pembayaran. Percobaan ulang otomatis dapat menyebabkan kemungkinan persetujuan ganda.

Beberapa menit kemudian, ada balasan.

AI mengatakan bahwa retry bagus untuk menangani kesalahan jaringan jadi saya menambahkannya. Akan saya periksa.

Saya menatap monitor selama beberapa saat.

Itu bukan pernyataan yang salah.

Percobaan ulang adalah cara umum untuk menangani kesalahan jaringan.

Namun, tidak semua panggilan harus diulang.

Sulit untuk menyalahkan AI karena tidak mengetahuinya.

Kami tidak pernah memberitahunya.

Segera setelah itu, seorang pengembang muda datang ke meja saya.

“Kakak senior, sepertinya lebih baik menghilangkan percobaan ulang ini.”

"Ya. Atau saya harus mengecek status persetujuan melalui API query terlebih dahulu."

"Tapi hal seperti ini tidak ada di dokumentasi?"

"Mungkin ada."

"Di mana?"

"Saya juga perlu mencarinya."

Teman itu tertawa.

"Jadi kami mencari lagi pada akhirnya."

"Benar."

Dulu, kami mencari karena tidak ada bahan.

Sekarang, kami mencari karena ada terlalu banyak bahan.

Dokumentasi ada di wiki, tiket sudah terakumulasi bertahun-tahun, dan kode tersebar di puluhan repositori.

Ada catatan rapat, ada riwayat obrolan, dan ada dokumen desain.

Lebih baik daripada tidak ada apa-apa.

Pasti lebih baik.

Tetapi sering kali saya masih tidak tahu di mana jawaban yang dibutuhkan berada.

Dalam rapat sore, ada pembicaraan tentang proses pengembangan baru.

Penanggung jawab menjelaskan sambil berbagi layar.

"Mulai sekarang, sebelum memulai pengembangan, silakan tulis dokumen review teknis terlebih dahulu. Analisis dampak dan sertakan skenario pengujian juga."

Seseorang bertanya.

"Bahkan untuk perbaikan sederhana?"

"Secara prinsip, ya."

"Bahkan mengubah satu frasa?"

Tawa terdengar di ruang rapat.

Penanggung jawab juga tertawa.

"Itu tergantung situasinya."

Saya tertawa mendengar hal itu.

Pada akhirnya, itu tergantung pada situasi.

Aturan bertambah, prosedur menjadi lebih detail, dan alat menjadi jauh lebih baik.

Tetapi di akhir, kata-kata serupa selalu muncul.

Tergantung situasi.

Jika tidak ada dampak.

Jika diperlukan.

Secara tepat.

Pada akhirnya, manusia yang menentukan kata-kata itu.

Menjelang pulang kerja, pemimpin tim mengirim pesan.

Apakah kasus poin hari ini sudah ditangani?

Saya menjawab.

Ternyata bukan bug, melainkan kebijakan pengecualian yang sudah ada. Saya telah meninggalkan catatan di tiket.

Segera setelah itu, balasan datang.

Seperti biasa, Anda sangat baik dalam menemukan hal-hal seperti ini.

Itu adalah pujian.

Saya mengirim satu ^^.

Kemudian saya menatap layar sebentar.

Saya lebih baik dalam menemukan mengapa sistem lama itu seperti itu daripada membuat sistem baru.

Kadang-kadang saya bingung apakah itu pujian atau tidak.

Ketika saya akan menutup laptop, jendela AI menarik perhatian saya.

Log dan pertanyaan yang saya tempel di pagi hari masih ada di sana.

Lima kemungkinan.

Semuanya terlihat masuk akal, tetapi semuanya salah.

Saya bercanda dengan memasukkan satu pertanyaan terakhir.

Jika kodenya tidak ada masalah tetapi hasilnya aneh, apa yang harus saya periksa?

Jawabannya panjang.

Data.

Konfigurasi.

Sistem eksternal.

Cache.

Lingkungan penempatan.

Aturan bisnis.

Pada akhir, satu baris ditambahkan.

Sangat penting untuk memeriksa apakah ada aturan bisnis yang tidak terdokumentasi atau kondisi pengecualian warisan.

Saya tertawa sambil membaca kalimat itu.

"Sekarang kamu juga tahu."