Agama Extreme Programming

Sejak bulan lalu, saya berlangganan video-video cleancoders.com. Tentu saja, dengan dibayari kantor dong. Jika ada benefit yang paling saya sukai dari sebuah pekerjaan, itu adalah belajar gratis dengan dibayari kantor. Karena, sebagai seorang pria berumah tangga, jatah mentahan itu bahkan tidak pernah mampir ke rekening pribadi saya. Terlebih lagi, saya tidak punya kartu ATM! Dengan adanya benefit seperti ini, saya bisa leluasa mengembangkan diri tanpa harus berfikir soal anggaran rumah tangga. Lumayan lah, USD 5000 setahun itu sudah cukup buat saya. Untuk menghabiskan jatah segitu, saya harus berfikir sangat keras. Beberapa teman lain mungkin lebih demen untuk mengejar sertifikasi atau konferensi. Entah mengapa kok saya tidak terlalu minat. Ya, kecuali kalo CppCon nggak ngasih video youtube gratisan ratusan jam tiap tahunnya.

Balik lagi ke cleancoders.com. Video-video yang saya ambil adalah video-video yang lanjutan. Ya kira-kira mulai dari bab 18-an sampai 60-an lah. Saya nggak minat untuk ambil yang seri-seri awal. Jujur ya, setelah saya menamatkan "Clean Architecture", saya jadi berfikir kalo "The SOLID Principle" itu jurus-jurusnya justru membingungkan. Seseorang bisa aja ngaku-ngaku kalo dia sudah SOLID, tapi setelah dilihat desainnya jelek sekali. Berbeda dengan "Clean Architecture". Begitu melihat suatu codebase, saya langsung bisa membayangkan keterkaitannya dengan "Clean Architecture". Kapan-kapan saya pengen bahas soal SOLID ini, tapi tidak sekarang. Saat ini, saya pengen ngobrol soal "Extreme Programming".

Extreme Programming ini diperkenalkan oleh Kent Beck dan masih merupakan rangkaian dari pergerakan "agile" di dunia rekayasa perangkat lunak. Uncle Bob adalah salah satu orang di pusat pergerakan ini. Makanya, walaupun produknya jauh kalah laku ketimbang buku-buku dan video-videonya, Uncle Bob bisa dengan gamblang menjelaskan Extreme Programming ini. Setelah saya mempelajari sedikit demi sedikit soal Extreme Programming, akhirnya saya teryakinkan bahwa tidak ada metodologi yang layak diikuti kecuali Extreme Programming. Agama saya tambah satu lagi. Berbeda dengan agama-agama yang sebelumnya macam Peopleware ataupun agama Kaizen, agama Extreme Programming jauh lebih konkret dan lebih mengena buat saya.

Mari kita mulai dengan Test-driven Development (TDD). Ketika pertama kali mengenal dan mencoba-coba TDD, saya akui saya bahwa saya terjebak dalam masalah fragile tests. Setiap kali refactor, banyak tes yang harus saya tulis ulang. Ketika mengalami itu, saya membatin, "kok gini ya?". Di situlah saya merasa ragu-ragu terhadap kehebatan metode ini. Ketika saya mencoba TDD yang kedua kalinya, saya tidak lagi menggunakan istilah unit test. Saya menamakannya Developer Test. Saya juga tidak lagi terpancang kepada satu klas satu unit test. Bahkan, untuk aplikasi yang rada besar, developer test yang saya bikin lebih mirip kepada integration test. Kemudian, saya juga mulai mencoba menerapkan mantra Given-When-Then secara rutin. Terakhir, saya menerapkan I/O and UI isolation secara konsisten. Setelah itu, TDD rasanya jadi lebih masuk akal. Akan tetapi, saya tetap tidak teryakinkan. TDD yang saya lakukan seringkali melewatkan fitur-fitur penting dan meloloskan bug-bug bodoh. Juga, merasa tidak punya waktu untuk menghasilkan program dengan arsitektur yang bagus. TDD seakan-akan mendorong kita untuk mempunyai arsitektur asal-asalan yang penting fiturnya lengkap.

Lalu saya mencermati video Uncle Bob secara seksama soal TDD ini. Tiba pada bagian Red-Green-Refactor, saya tersentak. Ternyata, selama ini saya masih salah dalam melakukan TDD. Ada paling tidak tiga kesalahan utama saya. Yang pertama, saya terburu-buru untuk langsung menuju masalah yang kompleks sebelum mulai menyelesaikan masalah yang sederhana. Ini membuat program yang dihasilkan jadi terlalu banyak lubang. Ketika melakukan TDD, sebisa mungkin kita harus mulai dari edge behaviors terlebih dahulu, baru pelan-pelan menginjak ke main behaviors. Dengan begini, setiap baris dari kode yang kita tulis secara tidak langsung akan dites. Tanpa disengaja pun, harusnya code coverage 90% bahkan 100% mudah dicapai. Kesalahan kedua, tidak melakukan refactor. Ketika melakukan TDD, refactor dilakukan setiap kali kita berhasil membuat kode kita lolos tes. Karena sudah ada tes, maka kita bisa dengan gagah berani merapikan kode kita. Kalau terus jadi merah, ya tinggal di-undo saja, beres. Dengan begini, mikroarsitektur dari kode kita akan jadi bagus dengan sendirinya. Setiap bagiannya mudah dibaca dan dipahami. Begitu juga dengan API dari kode yang kita tulis. Karena dimulai dengan menulis tes, maka API-nya biasanya enak dipakai. Selain itu, modulnya juga fleksibel dan mudah dilepas pasang. Kesalahan terakhir saya adalah tidak merapikan tes. Merapikan tes ini ternyata juga termasuk bagian refactor. Tests ini kalo Uncle Bob bilang lebih berharga daripada kode produksi, kalo acak-acakan, artinya kita jadi susah tahu kita tadinya pengen bikin apa. Setelah memperbaiki tiga kesalahan ini, saya merasa kalau TDD ini ternyata keren sekali!

Kerennya TDD yang pertama jelas, kode kita jadi rapi dan berkualitas tinggi. Kerennya yang kedua, kita jadi lebih cepat selesai ngerjainnya. Serius! Ya, walaupun tidak terus kemudian jadi lebih cepat tiga kali lipat sih. Kalo saya rasakan, mungkin sekitar 1.3x hingga 1.5x lebih cepat. Bagi orang dengan kecerdasan pas-pasan seperti saya, TDD ini membuat saya serasa jadi lebih pintar. Saya hepi. Soal lebih pintar ini, dan ini kerennya TDD yang ketiga, tanpa sadar saya menyelesaikan masalah yang rumit tanpa harus berpusing-pusing ria. Begitu program selesai ditulis dan saya periksa lagi, saya berpikir, "Loh, ini kok bisa ya saya nulis kode serumit ini?". TDD bagi saya adalah talent amplifier.

Lalu, bagaimana dengan praktik-praktik XP yang lain? Sembari belajar TDD, saya juga belajar soal continuous delivery dari Dave Farley. Saya belajar soal trunk based development, soal main branch yang harus siap dirilis setiap saat, soal automated tests yang harus terus menerus dijalankan, juga soal dark launch ataupun feature flag. Saya juga belajar soal bagaimana menulis user story yang baik, walaupun ini belum terlalu terkuasai dengan baik. Kalau berhasil menerapkannya dengan baik, saya bisa membayangkan bahwa ini adalah sebuah proses yang bisa lebih jauh memperbesar dampak dari TDD. TDD dan continuous delivery adalah satu kesatuan tak terpisahkan dari agile software development. Dengan adanya continuous delivery, maka kapan pun diminta, kita akan siap untuk demo kepada customer. Karena, rilis kita bahkan tidak tiap hari, tapi bisa jadi tiga kali sehari.

Efek samping dari ini semua adalah, saya bisa tidur nyenyak tiap malam tanpa harus lembur! Saya anti lembur. Lembur itu hanya dilakukan oleh orang-orang yang lemah. Ketika lembur, kemampuan otak kita jelas menurun. Artinya, kita tidak pernah bisa memberikan yang terbaik. Hasilnya jadi asal-asalan. Selain itu, lembur itu menurunkan efektivitas kita menyelesaikan masalah yang sulit. Saya merasakan satu jam di pagi hari setelah tidur nyenyak lebih baik hasilnya dari 5 jam lembur dari jam 8 malam hingga jam 1. Dan ini terjadi berkali-kali, bahkan di hampir semua kesempatan. Lembur hanya berarti kalo kerjaan kita bukan ngoding tapi ngetik. Alias, kalo kerjaannya banyak dan nggak mikir. Padahal kerjaan banyak yang nggak mikir itu harusnya dilakukan oleh mesin, bukan oleh manusia. Lembur membuat kita bego, karena itu janganlah kita lembur.

Yang tersisa tinggal pair programming. Saya belum banyak mempraktikkan ini, tapi bisa jadi pair programming bisa menambal lubang yang selama ini menjadi kelemahan saya. Yaitu, untuk memastikan bahwa kode-kode yang ditulis semuanya mempunyai kualitas yang baik, entah siapapun yang mengerjakannya. Untuk bisa seperti itu, harus banyak berbagi pengetahuan. Bagi saya, cara yang tidak menghabiskan tenaga untuk berbagi pengetahuan adalah dengan ngobrol. Dan, pair programming adalah salah satu sarana yang bisa dimanfaatkan untuk itu. Ngobrol sambil kerja, tahu-tahu kerjaan selesai. Enak nggak tuh?

Jelas, bahwa saya berpendapat kalo XP ini cocok untuk saya, utamanya TDD. Saya sudah coba sendiri dan saya suka. Saat paling hepi ketika ngoding adalah saat saya melakukan TDD. Apalagi, hasilnya bagus dan jadinya cepat selesai. Tapi, tidak semua orang mempunyai karakter dan kecerdasan yang sama. Kecerdasan bukan soal tinggi dan rendah, tapi soal kecerdasan berbahasa, kecerdasan berlogika, kecerdasan visual, kecerdasan spasial, dan kecerdasan lainnya. Perbedaan karakter dan kecerdasan inilah yang memungkinkan seseorang bisa saja tidak cocok dengan TDD dan XP. Kalau anda ternyata jauh lebih berhasil dengan metode yang berlawanan dengan XP, silakan saja. Saya tidak bisa. Saya jadi lebih jago karena saya pake TDD dan XP. Lain kali, kalo saya ngelamar kerjaan ke tempat lain, TDD, XP, clean code, dan continuous delivery jadi poin utama saya untuk bernegosiasi dengan calon kantor saya. Kalo calon kantor saya tidak membiarkan saya untuk menjadi versi terbaik saya sebagai seorang software engineer, ngapain saya ke situ?