XP, TDD, dan vibe coding: terjemahan sebagian wawancara Kent Beck di Programmatic Engineer

• Ringkasan beberapa bagian dari wawancara Programnatic Engineer dengan Kent Beck, bapak XP dan TDD, yang paling berkesan bagi saya
• Bagi yang menyukai Kent Beck, saya merekomendasikan menonton versi video lengkapnya

---

Q. Apa inti dari XP?

Melakukan empat aktivitas berikut.

1. Memahami apa yang harus dilakukan
2. Memahami struktur yang memungkinkan kita melakukan poin 1
3. Mengimplementasikan poin 1 dengan memanfaatkan poin 2
4. Memastikan poin 3 berjalan sesuai harapan

Hanya itu. Lalu waktu dipecah sangat kecil, dan pada setiap interval waktu, keempat aktivitas itu semuanya dilakukan sedikit demi sedikit.

Q. Kalau begitu, apakah pair programming bukan hal wajib dalam XP?

Saat pertama kali menjalankan tim XP, kami melakukan rilis sekali setiap 3 minggu, dan tentu saja ada bug.

Ketika pola bug yang ditemukan setelah rilis dianalisis, ternyata semua bug itu berasal dari kode yang dikembangkan sendirian. Sebaliknya, pada kode yang dikembangkan secara berpasangan, tidak ada cacat yang dilaporkan di lingkungan produksi.

Q. Jadi bukan wajib, melainkan sangat direkomendasikan?

Bukan juga. Intinya adalah bereksperimen. Anda boleh tetap mengembangkan seperti biasa. Hanya saja, lakukan dengan sadar.

Ingin mendapatkan manfaat dari desain berkelanjutan, verifikasi berkelanjutan, implementasi berkelanjutan, atau interaksi berkelanjutan dengan pelanggan? Namun kalau terus melakukannya dengan cara lama ternyata tidak berhasil, berarti caranya harus diubah.

Kalau seseorang datang kepada saya dan berkata, "Kent, saya tidak melakukan TDD." maka saya akan menjawab begini. "Lalu kenapa?"

Kalau Anda puas dengan tingkat kepadatan cacat pada kode Anda saat ini dan tingkat umpan balik terhadap keputusan desain, maka tidak masalah. Tetapi kalau tidak puas, cobalah pairing atau TDD.

Q. Ngomong-ngomong, kenapa Anda membuat TDD?

Saya orang yang mudah khawatir dan cemas, dan bagi saya pemrograman adalah sumber kecemasan yang tak ada habisnya. Apa yang saya lupa? Apa yang saya rusak?

Namun ketika mengembangkan dengan TDD, kecemasan ini hilang. Sudah tidak terpikir lagi test case yang mungkin gagal? Maka saya bisa yakin program saya berjalan. Begitu muncul sedikit rasa cemas? Tinggal tulis test case berikutnya.

Tentu saja ada banyak manfaat teknis TDD, seperti mengurangi kepadatan cacat, mendapatkan umpan balik lebih cepat atas keputusan desain, dan mengembangkan desain implementasi secara bertahap. Namun bagi saya yang paling penting adalah terbebas dari kecemasan terhadap pemrograman, dan pengalaman emosional yang diberikan pemrograman berubah total. Itulah alasan saya membuat TDD.

Q. Bagaimana pendapat Anda tentang kritik John Ousterhout bahwa TDD tidak memberi ruang bagi desain yang baik?

Ada bagian yang dia salah pahami. Itu hanyalah hasil dari sebuah keputusan. Jika TDD diperlakukan sekadar sebagai pengulangan Red-Green, tentu tidak ada ruang bagi desain untuk masuk.

Sebagai praktisi TDD, saya selalu bekerja sambil berpindah-pindah tingkat abstraksi. Contohnya:

• Sekarang saya sedang dalam keadaan Red. Untuk membuat test case berikutnya berhasil (Green), saya harus mengimplementasikannya bagaimana?
• Ini agak sulit. Kenapa sulit?
• Agar implementasi menuju Green menjadi lebih mudah, bagaimana desainnya harus diubah?
• Kapan ide itu harus diperkenalkan? Sekarang atau nanti?
• Kalau diperkenalkan sekarang, seberapa banyak? Sedikit saja sebatas yang bisa dilakukan sekarang, atau dalam chunk yang lebih besar?

Artinya, sebelum menulis tes, saya selalu punya momen desain.

Sebelum mengimplementasikan, saya membuat keputusan tentang interface, membuat tes Red, dan karena saya tidak suka keadaan Red, saya membuatnya Green secepat mungkin. Setelah menjadi Green, kecemasan saya hilang sesaat sehingga ada ruang untuk berpikir. "Hmm, memang lolos, tetapi ini tidak akan bekerja untuk kasus lain. Implementasinya harus saya generalisasi lagi."

Sedang Red? Buat jadi Green. Sedang Green? Tarik napas dan berpikir. Itulah siklus TDD saya.

Q. Kadang implementasinya terasa terlalu jelas, jadi saya mengimplementasikannya dulu lalu melakukan pengujian Red-Green. Bagaimana pendapat Anda tentang cara ini?

Mungkin itu karena Anda berasumsi bahwa "cara implementasi ini benar", dan semakin benar asumsi itu, tentu semakin kecil pula manfaat menulis tes lebih dulu.

Namun saya selalu berpikir seperti ini. "Saya akan terus belajar dan menambah pengalaman, dan saat ini adalah momen ketika saya paling bodoh."

Artinya saya berasumsi bahwa saya akan terus belajar, dan situasi juga akan berubah. Semakin banyak yang harus saya pelajari dan semakin banyak situasi berubah, semakin saya ingin menunda pengambilan keputusan selama mungkin. Ini prinsip umum. Mau itu saat berkencan atau memasak, sama saja.

Kalau saya bisa memprediksi lebih banyak, saya bisa melompat lebih jauh. Tetapi momen yang paling saya cintai dalam pemrograman adalah ketika saya merasa sudah tahu semuanya dan melaju terus, lalu tiba-tiba sadar bahwa ternyata ada cara implementasi yang jauh lebih baik. Saya ingin mengalami momen seperti itu sesering mungkin. Itulah sebabnya saya melakukan TDD.

Kalau gambaran di kepala sudah jelas, dan saya yakin input tertentu akan menghasilkan output tertentu, maka silakan langsung implementasikan. Tetapi semakin sering kita salah, semakin banyak kita belajar, dan semakin tidak terduga perubahan dunia, semakin menguntungkan untuk tidak berkomitmen sekarang dan menundanya sampai nanti.

Q. Saat menulis kode bersama AI, apakah Anda masih mengembangkan dengan TDD seperti dulu?

Sulit menjawabnya secara sederhana.

Saya menggunakan tes sebagai sarana berkomunikasi dengan AI, terutama sebagai sarana untuk memberi tahu apa yang salah dilakukan AI. Makhluk ini terus mencoba menghapus dan mengubah tes saya, dan setiap kali begitu saya memarahinya. Tes saya benar, jadi lakukan dengan benar.

AI sering membuat keputusan yang buruk dalam jangka panjang. AI juga sangat buruk dalam menurunkan coupling dan meningkatkan cohesion. Kalau diberi tahu tugas yang sangat jelas, kadang bisa melakukannya, tetapi secara umum harus dianggap tidak pandai dalam desain.

Karena itu saya menyiapkan sangat banyak tes. Saya memakainya sebagai cara untuk menangkap apakah AI sedang merusak sesuatu.

(Lihat tulisan ini untuk mengetahui bagaimana Kent Beck menggunakan TDD dalam vibe coding.)

Q. Rasanya akan lebih nyaman jika aturan agen seperti "jangan pernah memperbaiki tes" dan "kalau tes belum lolos, perbaiki hanya kode implementasi sampai lolos" menjadi lebih umum. Rasanya sekarang seperti masa menemukan kembali hal-hal yang penting pada tahun 2000-an. Bagaimana menurut Anda?

Kita harus terus bereksperimen. Kita harus mencoba semua yang memungkinkan. Karena saat ini kita belum tahu apa yang benar-benar terbaik.

Cakrawala tentang apa yang "murah" dan apa yang "mahal" telah berubah sepenuhnya. Banyak hal yang dulu dianggap mahal atau sulit sehingga tidak dilakukan, kini menjadi sangat murah sampai nyaris tidak masuk akal.

Kalau suatu hari mobil tiba-tiba menjadi gratis, menurut Anda apa yang akan terjadi? Tentu akan ada sesuatu yang berubah, tetapi bagaimana perubahan tingkat kedua dan ketiga akibatnya? Tidak ada yang bisa memprediksi. Jadi saat ini yang bisa kita lakukan hanyalah mencoba berbagai hal.

Q. Anda bilang setelah lebih dari 50 tahun memrogram, masa sekarang justru yang paling menyenangkan. Apa maksudnya?

Mewujudkan ide-ide besar saya kini menjadi lebih mudah daripada sebelumnya. Mengamati apakah AI bisa mengimplementasikan ide ini, dan bagaimana saya harus mengarahkan serta menyesuaikannya, sangat membuat ketagihan. Karena kita tidak pernah benar-benar tahu kapan hasilnya akan bagus, dan ketika tiba-tiba berjalan dengan baik seperti sulap, rasanya memabukkan, itu mirip mesin slot. Sebelum pergi jalan kaki atau makan siang, saya selalu dikuasai keinginan untuk setidaknya menulis satu prompt lagi agar makhluk ini terus bekerja.

Dua tahun lalu, saya menulis tweet ini: "Saya enggan mencoba ChatGPT, lalu hari ini saya berhasil melewati keengganan itu. Sekarang saya paham kenapa saya enggan. Nilai 90% keterampilan saya turun menjadi $0. Dan leverage untuk 10% sisanya naik 1000x. Sudah waktunya saya melakukan kalibrasi ulang."

> I've been reluctant to try ChatGPT. Today I got over that reluctance. Now I understand why I was reluctant.
>
> The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.
>
> -- Kent Beck 🌻 (@KentBeck) April 18, 2023

(Saat itu, ketika tweet ini ramai dibicarakan, Kent juga menulis artikel yang sedikit lebih panjang.)

Saat itu ia mengatakan masih sedang mengeksplorasi apa yang termasuk 90% dan apa yang termasuk 10%, tetapi sekarang ia merasa sudah bisa menjawabnya sampai taraf tertentu. Memiliki visi yang berani, mampu menetapkan milestone menuju visi itu, serta terus menyesuaikan desain sambil maju dan mengendalikan kompleksitas. Itulah keterampilan yang jauh, jauh lebih penting daripada pengetahuan tentang tata bahasa bahasa tertentu (misalnya: di Rust, di mana harus meletakkan &, *, [).