Integrasi Static Analysis di Facebook
Embrace this fact that the code is gonna be changing fast, and it’s gonna be big.
Dalam post sebelumnya, saya bercerita tentang adopsi static analysis di dunia industri. Contoh kasus dalam post tersebut hanyalah berupa garis besarnya saja, karena hanya didapat dari blog post dan slide deck. Sulit untuk diketahui lebih lanjut tanpa menghadiri Hack Week Spotify atau menonton presentasi dari Uber. Kali ini saya menemukan contoh detil bagaimana static analysis diterapkan pada suatu proyek.
Profesor Peter O’Hearn (Facebook dan University College London) dalam presentasinya yang berjudul “Reasoning with Big Code” di Turing Lectures menceritakan bagaimana memasukkan static analysis ke dalam Facebook developer workflow. Pembicara adalah salah satu pembuat Infer, yang awalnya merupakan suatu produk dari startup yang diakuisisi Facebook di 2013. Post kali ini akan mencoba merangkum materi presentasi tersebut.
Setelah perkenalan, pembicara mengedepankan tema utama: perbedaan antara kerja di dunia akademik dan dunia industri. Dalam dunia akademik, kerja umumnya bersifat menyeluruh dan holistik, sementara di dunia industri sekarang ini lebih mengutamakan rapid incremental changes dan short iterative process untuk mendapatkan fast feedback cycle. Tema ini akan selalu diingatkan oleh pembicara selama presentasi. Pembicara juga sedikit membahas tooling, open source, dan deployment / release process di Facebook (diff lifecycle) yang mungkin kalian sudah lihat di F8.
Penjelasan teknis dari static analysis-nya kurang begitu jelas buat saya sepanjang 1–2 slides, tapi saya lebih tertarik ke proses integrasi ketimbang hal tersebut. Awalnya static analysis dijalankan nightly secara menyeluruh untuk mendapatkan feedback. Hal ini tidak berjalan dengan baik karena kode sudah banyak berubah ketika feedback datang. Slow model seperti ini akhirnya diganti dengan yang lebih cepat: feedback harus sudah masuk ketika peer review. Analisis pun dilakukan secara parsial, hanya yang relevan dengan perubahan yang terjadi. Feedback akan di-post berupa komentar di peer review tools.
Metrik yang dipakai pun berubah. Awalnya mereka memakai false positive rate, tapi ini merupakan hal yang sulit diukur. Kalaupun bisa, analisis yang bagus pun tidak akan banyak berguna kalau developer kesulitan memperbaiki bugs akibat integrasi yang kurang baik dan mengganggu developer workflow (seperti slow model, nightly run). Akhirnya mereka memakai fix rate sebagai metrik. Jika developer menindaklanjuti sebagian besar bugs yang dilaporkan, maka tentu static analysis memberikan nilai nyata pada programmer yang menggunakannya.
Menjelang akhir presentasi, pembicara berbagi contoh-contoh bugs yang tertangkap oleh static analysis: retain cycle di Objective-C, 2 (dari 15 total) bugs di OpenSSL, dan isu keamanan di Gerrit, tools untuk code review buatan Google. Pembicara kembali menekankan pentingnya fix rate ketimbang false positive rate karena lebih mudah diukur terlebih di code yang berubah dengan cepat. Untuk kasus bug di Gerrit, para ahli dari static analysis, security, dan pegawai Google sendiri tidak yakin dengan statusnya: apakah benar bug atau false positive. Mereka memutuskan untuk menindaklanjuti bug tersebut (fix rate++).
Mungkin ada beberapa detil penting yang terlewat dari ringkasan ini. Kalian bisa melihat videonya langsung di youtube. Profesor Peter O’Hearn juga terdaftar sebagai pembicara di konferensi Curry On tahun ini.
