Kode Theseus
Ship of Theseus, sebuah filosofi tentang identitas kapal yang selalu dirombak dan diperbaharui. Tentu saja fokus kali ini bukan tentang identitas suatu program. Kita tahu bagaimana mengidentifikasi program. Sebuah kapal tidak memiliki versi. Sebuah kapal tidak perlu menaikkan MAJOR version ketika pintu masuknya berubah ukuran.
Fokus kali ini lebih kepada pertanyaan fundamental.
Kenapa kode selalu berubah?
Kita adalah programmer. Programmer adalah arsitek. Kita tidak suka melihat hasil pekerjaan orang lain. Kita tidak tertarik dengan perubahan-perubahan kecil seperti cat tembok ataupun kusen jendela. Kita ingin meratakan semuanya dan memulainya dari nol.
Kode yang lama itu sampah. Implementasi yang dulu salah. Pustaka tidak diperbarui. Ini semua karena satu hal:
Membaca kode lebih susah daripada menulis kode.
Semua orang punya utility libraries mereka sendiri, yang dibuat oleh mereka sendiri, dan diubah oleh mereka sendiri. Karena lebih menyenangkan mengetahui bagaimana sebuah kode bekerja dengan mencobanya daripada membaca implementasi orang lain. Mendesain itu menyenangkan, dan refaktor itu tidak.
Sebagai contoh, tanya seorang programmer untuk menjelaskan hal yang sedang mereka kerjakan.
Ini sebenarnya cuma [hal sederhana]. Tapi karena kemarin diminta buat [fitur lain] jadinya gini dulu. Harusnya ga kek gini, tapi yang penting jalan dulu.
Kita tidak mampu menghafal seluruh proyek
Sama halnya dengan memori pada komputer, kita tidak dapat menampung seluruh konteks sebuah proyek. Tidak juga oleh satu orang yang menulis semuanya. Programmer bekerja dengan memecah masalah menjadi masalah-masalah yang lebih kecil, kemudian menyelesaikannya. Kita memulai dengan satu file berisi 30 baris, yang kemudian menjadi puluhan file yang berisi ribuan baris. Kita bekerja sedikit demi sedikit.
Kesalahan-kaprahan tentang kode baru
Ide bahwa kode baru itu lebih bagus adalah absurd. Kode lama sudah diuji. Banyak masalah yang sudah ditemukan dan diperbaiki. Bugs tidak muncul begitu saja, bugs muncul karena kode dijalankan, dan program dipakai. Ketika kode lama dibuang, kita membuang pengetahuan.
Ketika programmer mengatakan, “Kode ini kacau”, mungkin karena kode yang tidak difaktorisasi dengan benar. Misalnya, kode cache yang berada di view. Masalah ini tidak terlalu besar dan dapat diselesaikan satu-persatu. Bahkan kesalahan desain yang besar masih bisa diperbaiki tanpa membuat dari awal. Atau mungkin karena kode dirasa tidak efisien atau elegan, seperti implementasi ray tracing sendiri. Tapi hal yang seperti ini hanyalah hal kecil yang bisa dibuat ulang. Tidak perlu membuat ulang semuanya.
Saya pernah membuat fungsi yang bernama render(), dengan berbagai macam closure dan parameter yang ditambahkan sesuai permintaan. Waktu itu pun baru mempelajari tentang callback JavaScript, sehingga alur kode pun tidak terlalu jelas. Setelah 6 bulan dilihat kembali, hanya butuh 15 menit untuk memecahkannya menjadi beberapa private function dan menggunakan promises sehingga alurnya lebih jelas.
Buat ulang bukan membuang
Perlu diingat bahwa ketika kita membuat dari awal, belum tentu kita tidak akan membuat kesalahan baru. Kita belum tentu bekerja sama dengan orang-orang yang membuat versi pertama. Menulis, membuat ulang, memfaktorisasi, dan menghapus satu-persatu adalah hal yang bagus. Tetapi menghapus semuanya adalah hal yang bodoh.
Jadilah programmer yang lebih baik
Seorang programmer yang hebat bukanlah seorang programmer yang sudah memikirkan implementasi yang sempurna sebelum kode ditulis.
Seorang programmer yang hebat adalah programmer yang menerima kesalahan dan beradaptasi dengan cepat, alih-alih memaksakan hal yang salah untuk terus digunakan. Seorang programmer yang hebat menulis kode dengan pola pikir bahwa kode ini akan diganti segera setelah ada hal yang salah ditemukan disini. Seorang programmer yang hebat menyadari bahwa resources yang ini tidak perlu ditaruh di dalam cache.
Buat dan ikuti konvensi yang sudah ditetapkan dalam tim. Beri nama fungsi yang menjelaskan fungsi tersebut. Beri nama variabel secara semantik. Beri komentar pada kode yang terlalu kompleks (misalnya bitshitfing). Buat commit yang menjelaskan, bukan hanya “fix bug”.
Arsitektur yang baik berasal dari keseimbangan memilih keputusan yang sulit dalam menyelesaikan masalah. Arsitektur yang bagus hanya bisa diapresiasi secara mendalam yang tidak seorang pun memahami di awal memulai proyek. Seringkali masalah yang ingin diselesaikan berubah ke arah yang tidak bisa kita prediksi. Buatlah desain seminimal mungkin, dan jangan karena “mungkin nanti diperlukan”.
Jangan buat arsitektur yang luar biasa kompleks sebelum bisa menarik manfaatnya. Prototyping akan lebih susah, dan fase selanjutnya akan sama susahnya.
Bosku tidak mengizinkan membayar tech debt
Bagi seorang yang membayar, kode dapat dikategorikan berdasarkan kegunaannya.
- Menambah pemasukan (fitur baru)
- Mengurangi pengeluaran (biaya operasi)
- Melindungi pemasukan (perbaikan bug)
- Melindungi dari pengeluaran (legalitas)
Kita tidak dibayar untuk memecah bagian-bagian kode karena itu adalah best practice, tetapi karena itu memudahkan kita menemukan kesalahan dan memperbaikinya.
Carilah bagian yang susah untuk diperbaiki, dan buatlah estimasi dan manfaat memperbaikinya.
Kita selalu menghabiskan waktu seharian, bahkan dua hari dalam deploy. Kalau diberi waktu 2 minggu, aku bisa mempermudah proses yang menjadikannya hanya 30 menit, dan dapat diulang kapan saja. Dengan begini akan menghemat waktu programmer dalam mengerjakan proyek.
Percaya dirilah dalam mencetuskan sebuah ide. Ketika perubahannya tidak signifikan.
Contoh kasus
Mozilla Firefox tidak membuang engine mereka. Mereka memperbaiki bagian dari browser satu-persatu. Mereka menganalogikan cara mereka sebagai “merebus lautan dua kali, perlahan-lahan”.
