Mengapa Kode Anda Butuh Pemeriksa Kedua (dan Sebuah Robot)
Anda baru saja selesai menulis fitur baru. Logikanya terlihat solid, kasus tepi sudah ditangani, dan Anda siap untuk menggabungkan kode. Tapi begini masalahnya: saat Anda menulis kode, Anda melihat apa yang Anda maksudkan terjadi, bukan apa yang sebenarnya terjadi. Typo lolos. Anda lupa menangani nilai null. Perubahan Anda secara diam-diam merusak sesuatu yang dikirim anggota tim lain satu jam yang lalu.
Ini bukan soal kepercayaan. Ini soal sifat manusia. Setiap pengembang memiliki titik buta saat bekerja sendiri. Solusinya bukan dengan merekrut lebih banyak insinyur senior atau menulis lebih banyak komentar. Solusinya adalah membangun proses pemeriksaan ke dalam cara kode berpindah dari laptop Anda ke basis kode bersama.
Pemeriksaan Manusia: Code Review
Bentuk pemeriksaan yang paling alami adalah meminta orang lain membaca kode Anda. Ini disebut code review. Satu atau dua rekan kerja melihat perubahan Anda dan mengajukan pertanyaan: Apakah logika ini masuk akal? Apakah ini mengikuti pola yang disepakati tim? Apakah ada efek samping yang tidak Anda sadari?
Review juga merupakan momen pembelajaran. Pengembang junior mendapatkan umpan balik tentang pendekatan yang lebih bersih. Pengembang senior melihat ketika seseorang memperumit masalah sederhana. Percakapan yang terjadi dalam review seringkali mencegah bug di masa depan lebih baik daripada alat otomatis mana pun.
Tapi review memiliki keterbatasan. Manusia lelah. Tidak ada yang membaca diff sepanjang 500 baris dengan saksama pada jam 5 sore di hari Jumat. Dan tidak ada manusia yang bisa menjalankan kode Anda di kepala mereka untuk memverifikasi setiap cabang berfungsi dengan benar. Di sinilah otomatisasi berperan.
Pemeriksaan Robot: Continuous Integration
Pemeriksaan otomatis yang berjalan setiap kali kode berubah memiliki nama: Continuous Integration, atau CI. Saat Anda mendorong kode, CI berjalan tanpa diminta siapa pun. CI membangun proyek Anda. CI menjalankan pengujian Anda. CI memeriksa kerentanan keamanan. CI menegakkan aturan format kode.
CI menangani pekerjaan membosankan dan berulang yang tidak bisa dilakukan manusia dengan baik. Apakah seseorang tidak sengaja menghapus titik koma? CI menangkapnya. Apakah pengujian gagal karena pembaruan dependensi? CI melaporkannya. Apakah seseorang memperkenalkan library rentan yang diketahui? CI menandainya.
Inilah poin kritisnya: CI bukanlah pengganti code review. Keduanya memiliki tujuan yang berbeda.
| CI melakukan | Review melakukan |
|---|---|
| Memeriksa aturan dan konsistensi | Mengevaluasi desain dan pendekatan |
| Menjalankan pengujian secara otomatis | Menemukan celah logika |
| Menegakkan standar | Berbagi pengetahuan di seluruh tim |
| Tidak pernah lelah | Menangkap hal-hal yang terlewat oleh otomatisasi |
CI memastikan tidak ada yang rusak. Review memastikan kode dirancang dengan baik. Anda membutuhkan keduanya.
Tempat Keduanya Bertemu: Pull Request
Pull request adalah tempat di mana pemeriksaan manusia dan otomatis bersatu. Anda membuat cabang terpisah, menulis kode, dan membuka permintaan untuk menggabungkannya ke cabang utama. Pull request menjadi satu tempat di mana semua orang dapat melihat:
Berikut adalah diagram alur yang menunjukkan bagaimana proses pull request menggabungkan pemeriksaan otomatis dan manusia:
- File apa yang berubah
- Apa kata CI tentang perubahan tersebut
- Apa yang dikomentari oleh reviewer
Tidak ada yang menggabungkan kode sampai CI lulus dan setidaknya satu reviewer menyetujui. Kombinasi ini memberi Anda keyakinan yang tidak didasarkan pada perasaan. Anda tahu kode telah diperiksa secara otomatis dan ditinjau oleh manusia. Jika sesuatu masih salah setelah penggabungan, setidaknya Anda tahu prosesnya telah berjalan dan Anda bisa mencari tahu apa yang terlewat.
Mengapa Ini Penting dalam Praktik
Tim yang melewatkan proses ini akan membayar mahal. Tanpa CI, bug yang seharusnya bisa ditangkap dalam hitungan detik ditemukan di produksi berjam-jam kemudian. Tanpa review, pola desain yang buruk menyebar karena tidak ada yang mempertanyakannya. Tanpa keduanya, menggabungkan kode menjadi perjudian.
Berikut adalah tampilan proses pemeriksaan yang sehat dalam alur kerja tipikal:
- Anda membuat cabang dari main
- Anda menulis kode dan mendorongnya
- CI berjalan secara otomatis di cabang Anda
- Anda membuka pull request
- Hasil CI muncul di pull request
- Seorang rekan meninjau kode Anda
- Anda menanggapi umpan balik, mendorong lagi, CI berjalan ulang
- CI lulus, reviewer menyetujui, Anda menggabungkan
Ini bukan birokrasi. Ini adalah asuransi. Setiap langkah menangkap kelas masalah yang berbeda sebelum mencapai produksi.
Daftar Periksa Praktis Cepat
Jika Anda menyiapkan atau meningkatkan proses pemeriksaan kode, berikut adalah hal-hal esensial:
- Otomatiskan dasar-dasarnya: Build, test, lint, dan pemindaian keamanan harus berjalan di setiap push. Tidak ada pengecualian.
- Wajibkan setidaknya satu reviewer: Buat pull request tidak bisa digabungkan tanpa persetujuan manusia.
- Jaga review tetap kecil: Review 50-100 baris bersifat menyeluruh. Review 500+ baris hanya sekilas.
- Biarkan CI menggagalkan penggabungan: Jangan biarkan siapa pun mengesampingkan kegagalan CI tanpa diskusi.
- Review diff Anda sendiri terlebih dahulu: Sebelum meminta orang lain, baca perubahan Anda sendiri. Anda akan menangkap kesalahan yang jelas sendiri.
Kesimpulan
Code review dan CI bukanlah beban. Keduanya adalah perbedaan antara berharap kode Anda berfungsi dan mengetahui bahwa kode telah diperiksa. Review menangkap apa yang dilihat manusia. CI menangkap apa yang terlewat oleh manusia. Bersama-sama, keduanya mengubah penggabungan kode dari lompatan keyakinan menjadi langkah terukur ke depan.
Setelah penggabungan, kode Anda masih perlu dibangun, digunakan, dan dijalankan. Tapi setidaknya Anda tahu kode tiba di titik itu dalam kondisi yang baik.