Perubahan batasan tanggung jawab yang dibawa oleh Codex

Ketika saya pertama kali memperkenalkan Codex kepada tim dalam skala besar, hal baik pertama adalah saya akhirnya bersedia melakukan beberapa perubahan kecil.

Situasi umum di masa lalu adalah semua orang mengetahui dengan jelas: kode ini perlu difaktorkan ulang, skrip ini perlu diuji, dan batas ini perlu dicatat. Namun mereka semua terjebak dalam kenyataan yang sama. Anda harus memperhatikan biaya untuk mulai menulis, dan Anda harus mereview setelah menulis.

Codex mengurangi “gesekan langsung”.

Masalah mulai muncul sejak saat itu.

Karena seiring berkurangnya gesekan, batas-batas tanggung jawab juga perlahan-lahan bergeser.

Di permukaan, Anda mungkin berpikir bahwa Anda membeli penulis yang lebih cepat, namun sebenarnya yang Anda beli adalah lebih banyak perubahan. Ketika terdapat terlalu banyak perubahan, sistem memerlukan penerimaan yang lebih jelas dan mekanisme kontrol yang lebih kuat.

Jika tidak, efisiensi Codex akan diberikan dalam bentuk lain: kecelakaan online, kelelahan review, dan pengerjaan ulang yang “tampak benar tetapi tidak stabil” berulang kali.

Bagaimana hal-hal secara bertahap menjadi “peninjau bertanggung jawab”

Pada minggu pertama setelah diperkenalkannya Codex, semua orang menggunakannya dengan sangat hati-hati.

-Tulis widget

• Mengubah nama paragraf
• Tambahkan penilaian if

Perubahan-perubahan ini, jika tidak sempurna, mempunyai risiko yang terbatas.

Mulai minggu kedua, perubahannya semakin besar.

Beberapa orang mulai meminta Codex untuk “mengatur kode di sekitarnya”, beberapa orang mulai memintanya untuk “memfaktorkan ulang modul ini bersama-sama”, dan beberapa bahkan mengganti seluruh bagian logika kompleks dengan versi yang dihasilkan.

Pada tahap ini, kalimat yang paling umum adalah:

Lihat, semua kode sudah tertulis dan logikanya benar.

Masalahnya, ada substitusi tersembunyi dalam kalimat ini.

Di masa lalu, penulislah yang paling bertanggung jawab atas benar atau tidaknya logika tersebut. Penulis perlu melalui konvergensi menyeluruh saat menulis: alasan perubahan, apa batasannya, apa yang akan terjadi jika gagal, dan bagaimana cara memutarnya kembali.

Codex meratakan proses konvergensi di tengah. Penulis menjadi “orang yang mengajukan tuntutan” dan menyerahkan kendali kepada pengulas.

Jadi batas tanggung jawabnya dimulai dari:

• Penulis bertanggung jawab untuk menyatukan perubahan hingga siap untuk dirilis

menjadi:

• Reviewer bertanggung jawab untuk memfilter perubahan hingga tidak menimbulkan masalah

Ini bukan persoalan moral, ini persoalan mekanis.

Cara menghasilkan kode secara alami cenderung “menulis versi terlebih dahulu” daripada “berpikir jernih tentang batasannya terlebih dahulu”. Pengalihan tanggung jawab ini terjadi selama prosesnya tidak memperjelas batasannya.

Seringkali harga akan dibayar di tiga tempat sekaligus

1) Tinjauan menjadi “arkeologi”

Di masa lalu, ulasan melihat pilihan penulis:

• Gunakan ini untuk mencapainya
• Bagi menjadi fungsi-fungsi ini
• Tambahkan perlindungan ini di sini

Sekarang tinjauan melihat hasilnya:

• Apakah kode yang dihasilkan ini melewatkan batasan apa pun?
• Apakah ada efek samping baru yang muncul?
• Apakah Anda diam-diam mengubah semantik logika lama?

Ini bukan jenis pekerjaan yang sama.

Yang pertama adalah menilai proses penalaran penulis, dan yang kedua adalah menemukan jebakan dalam kode yang tidak dikenal. Cara terakhir ini lebih mahal dan lebih bergantung pada keakraban pengulas dengan konteksnya.

Anda akan segera melihat sebuah fenomena:

• Kode digabungkan
• Ada yang tidak beres saat online
• Selama peninjauan, tidak ada yang tahu mengapa ditulis seperti ini.

Karena “mengapa” tidak pernah ditulis.

2) Pengujian diperlakukan sebagai “opsional”

Godaan terbesar dalam menghasilkan kode adalah: terlihat lengkap.

Fungsi-fungsinya dipecah dengan indah, namanya sama, dan bahkan beberapa pengujian tunggal tambahan disediakan.

Masalahnya adalah pengujian unit ini sering kali bersifat “memverifikasi implementasi” daripada “memverifikasi persyaratan”.

Gejala khasnya adalah:

• Peningkatan cakupan
• Banyak kecelakaan

Karena yang kurang adalah kriteria penerimaannya, bukan kurangnya format JUnit/pytest.

3) Jalur rollback dilupakan

Perubahan tulisan tangan sering kali menimbulkan pemikiran alami tentang “bagaimana jika tidak berhasil”.

Menghasilkan perubahan dapat dengan mudah memberikan ilusi bahwa ini adalah implementasi yang lebih bersih dan seharusnya baik-baik saja.

Namun hal yang paling menyakitkan di dunia online adalah “perubahannya terlalu besar dan Anda tidak bisa kembali lagi.”

Ketika perubahan yang dihasilkan menjangkau banyak file dan difaktorkan ulang di banyak tempat, rollback bukan lagi tentang membatalkan penerapan, namun tentang membangun kembali semantik lama.

Ini adalah tagihan termahal setelah batas tanggung jawab dipindahkan.

Untuk mengembalikan batas tanggung jawab, yang perlu kita lakukan bukanlah “menonaktifkan Codex”

Ketika banyak tim melihat masalah ini, reaksi pertama mereka adalah membatasi penggunaannya:

• Nonaktifkan pembuatan segmen besar
• Modifikasi modul inti dilarang
• Logika kunci harus ditulis dengan tangan

Aturan-aturan ini berguna dalam jangka pendek, namun dengan cepat menjadi formalistis.

Pendekatan yang benar-benar efektif adalah dengan memajukan bagian “tanggung jawab penulis” ke dalam proses penggunaan Codex.

Saya akhirnya mempersempitnya menjadi empat persyaratan sulit. Jika salah satunya hilang, saya tidak akan menyerah:

1. Niat perubahan harus ditulis dengan jelas: uraikan perilaku yang ingin diubah dalam satu kalimat, bukan “refactor it”.
2. Kriteria penerimaan harus dapat dilaksanakan: apa saja masukannya, apa keluarannya yang diharapkan, dan bagaimana berperilaku jika terjadi kegagalan.
3. Batas risiko harus dicantumkan: Penelepon mana yang terkena dampak perubahan ini, dan apa skenario terburuknya?
4. Rencana rollback harus jelas: versi mana yang akan di-rollback, cara memproses data, dan di mana tombol downgrade berada.

Codex dapat membantu menulis implementasi, tetapi tidak dapat menggantikan keempat item tersebut.

Lebih penting lagi: setelah menulis keempat item ini, review menjadi lebih ringan.

Peninjau tidak perlu menebak “apa sebenarnya yang ingin Anda lakukan” dari kode tersebut, tetapi hanya perlu menilai “apakah maksud tertulis dan implementasinya konsisten”.

Kesalahpahaman paling umum

Kesalahpahaman 1: Memperlakukan Codex sebagai “pendatang baru yang bisa menulis kode”

Pendatang baru terjebak di tempat yang tidak mereka ketahui, mengajukan pertanyaan, dan mengungkap ketidakpastian.

Kodeks tidak.

Ini akan memberi Anda jawaban yang tampaknya paling nyaman ketika Anda tidak yakin. Tanpa kriteria penerimaan, hal ini akan mengubur ketidakpastian dalam kode.

Mitos 2: Menggunakan kata-kata yang lebih cepat untuk menggantikan proses rekayasa yang hilang

Kata-kata isyarat dapat membuatnya lebih cocok dengan gayanya, namun tidak dapat menggantikan mekanisme penjaga gerbang.

Memasukkan proses yang hilang ke dalam prompt akan berakhir dengan “memori organisasi yang ditulis semakin lama,” namun tidak memiliki kontrol versi, tidak ada strategi rollback, dan tidak ada latihan kegagalan.

Kesalahpahaman 3: Hanya menghitung “berapa banyak waktu yang dihemat”

Metrik yang paling berbahaya adalah: berapa banyak waktu pengembangan yang dihemat per kebutuhan.

Karena hal itu akan mendorong setiap orang untuk mengejar cakupan generasi yang lebih luas.

Saya lebih suka fokus pada dua indikator:

• Hasilkan tingkat pengerjaan ulang setelah integrasi perubahan
• Proporsi insiden yang disebabkan oleh perubahan generasi

Mereka terkait dengan batasan tanggung jawab.

Batasan yang berlaku

Tidak semua tim membutuhkan kendala seberat itu.

Jika sistemnya cukup kecil, rilis cukup sering, dan rollback cukup sederhana, risiko Codex akan tertelan.

Namun ketika salah satu dari hal berikut terpenuhi, batasan tanggung jawab harus dibuat jelas:

• Perubahan akan memengaruhi tautan berbiaya tinggi seperti pembayaran, pengendalian risiko, dan persetujuan
• Siklus rilis yang panjang dan biaya rollback yang tinggi
• Kepemilikan kode bersifat ambigu dan peninjauan sudah menjadi hambatan

Dalam skenario ini, “lebih cepat” Codex pertama-tama akan didorong ke lebih lambat.

Ringkasan

Codex tentunya membuat penulisan kode menjadi lebih cepat.

Namun yang benar-benar berubah adalah jawaban default tim terhadap “siapa yang bertanggung jawab atas perubahan?”

Jika niat, penerimaan, batasan, dan kemunduran tidak dimajukan, tanggung jawab secara alami akan jatuh ke tangan pengulas.

Pada akhirnya, Anda akan menemukan bahwa yang dihemat bukanlah waktu pengembangan, tetapi perhatian seluruh tim terbuang. Akun ini jauh lebih mahal daripada token.